Page 323 - From GMS to LTE

Long Term Evolution (LTE) and LTE-Advanced Pro 309

manufacturers. In other words, these network functions run on a server supplied by the
same manufacturer. In this example, the CSCFs are simply a piece of software and from
a technical point of view there is no need to run them on a specialized server. The idea
of NFV is to separate the software from the hardware and to put the CSCF software into
virtual machines. As explained above, there are a number of advantages to this. In this
scenario the separation means that network operators do not necessarily have to buy
the software and the hardware from the same network infrastructure provider. Instead,
the CSCF software is bought from a specialized vendor while off‐the‐shelf server hard-
ware can be bought from another company. The advantage is that off‐the‐shelf server
hardware is mass produced and there is stiff competition in that space between several
vendors, such as HP, IBM and others. In other words, the hardware is much cheaper. As
described above, it becomes very easy, for example, to add additional capacity by install-
ing off‐the‐shelf server hardware and starting additional CSCF instances as required.
Load sharing also becomes much easier because the physical server is not limited to
running virtual machines with a CSCF network function inside. As virtual machines are
completely independent of each other, any other operating system or software can be
run in other virtual machines running on the same physical server. Also, virtual
machines can be moved from one physical server to another while they are running
when a physical server reaches its processing capacity. Running different kinds of net-
work functions in virtual machines on standard server hardware also means that there
is less specialized hardware for network operators to maintain.
Another network function that lends itself to running in a virtual machine is the LTE
Mobility Management Entity (MME). As described at the beginning of this chapter, this
network function communicates directly with mobile devices via an LTE base station. It
is responsible for tasks such as authenticating a user and their device when a device is
switched on, instructing other network elements to set up a data tunnel for user data
traffic to the LTE base station where a device is currently located, instructing routers to
modify the tunnel endpoint when a user moves to another LTE base station, and gener-
ally keeping track of a device’s whereabouts so it can send a paging message for incom-
ing voice calls. All of these management actions are performed over IP so from an
architecture point of view, no special hardware is required to run MME software. It is
also very important to realize that the MME only manages the mobility of the user and
when the location of the user changes it sends an instruction to a router in the network
to change the path of the user data packets. All data exchanged between the user and a
node on the Internet completely bypass the MME. In other words, the MME network
function is itself the origin and sink of signaling messages that are encapsulated in IP
packets. Such a network function is easy to virtualize because the MME does not rely
on specific hardware to transmit and receive its signaling messages. This means that an
MME does not require any knowledge or insight into how these IP packets are sent and
received. A possibility, therefore, is to put a number of virtual machines each running
an MME instance and additional virtual machines running CSCF instances on the same
physical server. Mobile networks usually have many instances of MMEs and CSCFs and
as network operators add more subscribers, the amount of mobility management sign-
aling increases as well as the amount of signaling traffic via CSCF functions required for
establishing VoLTE calls. If both network functions run on the same standard physical
hardware, network operators can first fully utilize one physical server before adding
more hardware. This is quite unlike the situation today where the MME runs on