Organizational View of LTE (Face 3)

We are in the middle of a journey exploring LTE as it may look to the movie fans of the 1957 movie, “The Three Faces of Eve”. We are presenting as an analogy, the “Three Faces of LTE”. Like Eve in the movie, LTE may take on multiple personalities, reflecting in each, the personality of various LTE stakeholders. In the “First Face of LTE”, we examined LTE with the personality reflecting those in the standards bodies, describing the rules that govern the operation of LTE. In the “Second Face of LTE”, we examined LTE with the personality of the service provider that must integrate LTE into its existing networking environment. This “Third Face of LTE” reflects the personality of the service provider’s management which must fit LTE into its business operating environment. This is a little more complex, so this blog will only lay the groundwork for the third face.

In any industry, the business design must be reflected in the organizational structure. Often a telecom a service provider organizes into several “regions” or customer-facing operating units. Each region is responsible for a collection of MSTOs. Each MSTO has responsibility for a collection of cell sites. Of course there are other aspects such as network operations and internal systems. We will focus here more of the customer facing aspects of the network. The chart below presents a very high level view of the organizational view of the network. Consider the MPLS core to be the third party we described earlier, responsible for transporting traffic between regions. “Outside” the MPLS core are a number of “regions” (in this example we define Region a, b, and c). Connectivity between regions is achieved through the MPLS Core. Also associated with each region are a collection of MTSOs. In our example we have shown the boundaries for MTSO 1, 2, and 3 within Region a. Connectivity between MTSOs is through the Region and MPLS core. Finally each MTSO provides an access point to a number of cell sites through the CSRs we alluded to before.

This chart depicts communication between two eNBs via a path from the eNB through a local CSR, to the MAG to which it is homed, through the Regional and MPLS core components of the network and taking a similar path in reverse to reach the second eNB.


One might ask what the importance is of viewing the network at this level. Though there are many reasons for describing the network this way, we will focus on the need for IP address planning. The chart below focuses again on the E-UTRAN part of the network.


 In his chart we consider a generic MTSO (MTSO q in Region r). A packet network is driven by IP addresses. This chart demonstrates different types of IP addresses required for the region. This is not intended to be an exhaustive list (for example, a device will need a separate loopback address – not shown). Whether the CSR requires an addressable IP address depends upon whether the Ethernet Backhaul solution is layer 2 based (i.e. the CSR functions as a layer 2 Ethernet switch in which no IP address is required) or is layer 3 based (i.e. the CSR functions as an IP router in which case the CSR requires a separate IP address).

Of all of the addresses described let’s rule out those that we do not need to advertise to other MTSOs or to other network sites. The Inter-MAG IP addresses are used only locally so there is no need to tell other MTSOs about these local addresses. The MAG-PE addresses are required to be globally unique, but there is no need to advertise these in order to let the outside world know how to reach your subscriber. The EVC addresses must be unique within this MSTO, but the same addresses can be used for EVCs in each MTSO. They will not be advertised outside. Finally, the link between the CSR and the eNB carries both user traffic (bearer and signaling for call management) as well as OAM traffic. Both of these types of traffic must be globally unique and must be advertised to other MTSOs. It should be noted that the bearer traffic and the OAM traffic will be advertised to different locations (i.e. the OAM traffic is sent to the OSS, and there is no need to advertise this to other MTSOs). Therefore we will focus simply of addressing for bearer and signaling traffic on the CSR to eNB link. The IP addresses for these types of links must be advertised.

In future blogs we hope to drill down on some of the details that should be considered in order to make this architecture work.