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.
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.