LTE Network Sharing (MOCN) - eNodeB

Typically eNodeB and Core network components are owned and operated by same operator. It is quite common to share the physical infrastructure among multiple operators, specifically the cell sites - physical location, building etc... But every operator used to have their own base stations and transport card etc..  As I understand that is called passive sharing.  This sharing is now extended to active component sharing such as eNodeB. That is called network sharing or active sharing.

Networking sharing allows one frequency spectrum ,  eNodeB shared by multiple operators. Dedicated cells for each operator but still sharing rest of E-UTRAN infrastructure is also possible.

There are multiple business reasons for network sharing.Main reason being cost savings.

• Cost savings by sharing infrastructure - eNodeB and Frequency spectrum.
• LTE deployments will require major investments as new eNBs, new antennas need to be installed by operators.  To reduce the number of eNB one needs to own,  in some cases such as rural areas there by providing connectivity while reducing the costs.

3GPP body as part of LTE effort visualized these scenarios and created specifications to handle network sharing scenario. 3GPP specifications  22.951 and 23.251 describe the network sharing requirements and architecture & functional description of network sharing. Main feature that allows network sharing in LTE is that eNodeB broadcasts multiple PLMN IDs (Public Land Mobile Network ID which is combination of Mobile Country Code and Mobile Network Code - Each operator has unique PLMN ID) to the UE using SIB (system Information Block).  UE is expected to select the PLMN ID based on its selection process.  Using the selected PLMN ID,  UE is expected to make RRC connection with eNodeB.  eNodeB uses this PLMN ID to select the core network and in turn MME.

This feature of eNodeB serving multiple operator is also called 'Multi Operator Core Network' (MOCN).

Whenever a hardware is used for Multiple operators, there would be fairness would come in picture.  Due to this feature, identification of contexts (whether it is PDCP, GTP, RLC, MAC, IPsec or Qos) will need one  additional parameter - Operator ID.  Note that TEID which is used to terminate the GTP tunnels may not be unique across multiple operators.  In addition to this,  I believe following features would be expected from eNodeB to support MOCN.

• Additional identification parameter, Operator ID in user plane modules.
• Fairness in allocating resources in eNodeB (Buffers,  Contexts etc.. ) and Radio resource management if same cell is used by multiple operators.
• VLAN Support - One or few dedicated VLANs for each operator.  
• DHCP Client (Ipv4, IPv6) - Multiple instances :  eNodeBs typically get the IP address from the DHCP Server.  Since there are multiple VLANs due to multiple operators, DHCP client also needs to be capable to get multiple IP addresses - one for each operator (VLAN).  
• If other L3 connectivity protocols used instead of DHCP such as PPP, then one needs to ensure that these L3 connectivity protocols too get multiple IP addresses - one for each operator.
• eNodeB should ensure that right source IP addresses are used for GTP tunneling and Ipsec tunneling.
• Fairness to ensure that one operator traffic does not overwhelm the CPU
• Radio bandwidth is normally taken care as part of radio resource management on per operator basis.
• Incoming traffic from backhaul network is expected to be policed at the ingress port. Each operator VLAN may be configured to police the traffic or schedule the traffic coming from different VLANs to CPU fairly (weighted if configured).  Due to scheduling, packets may be pending in the queues for future scheduling.  This can eat up buffers and new packets may not get received.  So, there should be limits on number of buffers each VLAN can occupy at any time.  
• Outgoing traffic to Bachaul network also need to be controlled on per operator (VLAN) basis.  Note that all VLANs share the same physical link. Hence the outgoing traffic needs to be controlled on per VLAN basis to ensure that physical link is not overwhelmed.  Traffic shaping and scheduling on per VLAN basis is expected.  Within each VLAN,  priority based queuing might also may require traffic shaping & scheduling. Hence, eNodeB is expected to provide hierarchical shaping and scheduling.