• 5G Handover

    December 22, 2019 edwin 5G, LTE, Mobility, Wireless

    5G Handover

    4G LTE handover was called X2 and S1, in 5G NR are called XN and N2

    5G has come close to standardization with many news from Verizon and T-Mobile regarding deployments and acquisitions specially with NOKIA.


    NOKIA logo

    5G Systems

    The new elements in 5G are gNB, AMF, UPF, which are using new interfaces as the XN and N2 interface to link the AMF with gNB and vice versa, replacing X2 and S1 AP interfaces.

    There are also several other components as follows:

    • gNB : Refers to the Base Station, like in the old LTE, the eNodeB
    • NR: Refers to the “New Radio” technology
    • NG-RAN: NG-RAN is Next Generation Radio Access Network. This consists of gNB and ng-ENB.
    • AMF Access and Mobility Management Function AF Application Function
    • UPF User Plane Function
    • NGC: Next Generation Core


    There in 5G the handover is called Xn Handover and N2 Handover

    • As the UE sends the measurement reports and the Source gNB detects that a handover is required, then it connects with the Target gNB to start a switch
    • The UE does a handover and connects to theTarget gNB That has already switched the tunnels to the target
    • The UE forwards as part of the handover process, This is called RRC

    The NG-RAN sends the UE Notification message to report the current RRC state for the UE (i.e. RRC Inactive state or RRC Connected state). The current UE location information (i.e. TAI + Cell Identity) is always included when RRC state information is reported.

    • Thru this, the UE can then handoff fast and all the data is available for you.

    How is the difference from the X2 Handover

    The differences are subtle, and the main difference is that the X2 handover. We server that Location Information is mandatory, but it was after LTE
    Rel-13 as well. The changes are minimum and this facilitates the understanding of all functions including AMF / UPF in 5G. In TS 38.423 V.15, the Xn-AP commands are shown, which is a similar document to the X2-AP specification.

    Technical Specification from 3GPP TS 123.502

    If the Location Reporting InformationIE is included in the HANDOVER REQUEST message, then the target NG-RAN node should initiate the requested location reporting functionality as defined in TS 38.413 [5].

    Similarly this is shown in TS 123.502 with

    1. Target NG-RAN to AMF: N2 Path Switch Request (List of PDU Sessions To Be Switched with N2 SM Information, List of PDU Sessions Rejected with a rejection Cause per PDU Session, UE Location Information)

    4G LTE Systems

    In the 4G LTE System, we would have an ENodeB, MME, S-GW, PDN-GW, as common elements of the network, hence the X2 and S1 interfaces were used for handover.

    In this design, X2 handover facilitates handoff between eNodeBs and relies on the MME for S1-AP handoff only.

    In 5G, things have changed a bit:

    As shown in the figure, the gNB has other entities and interfaces such as ch Xn interface, NG-C/U, and in the infrastructure called (NGC) no longer (EPC) we observe the AMF/UPF duality that resembles the MME/S-GW on LTE.

    In comparison, UEs are the same, different radios, on one end LTE, and into the future a 5G radio.

    What are the main actors for handover on LTE

    • ♠ eNodeB – or the Base Station, contains the RF and all IP-level connectivity to the MME/S-GW/PDN-GW to create and maintain connectivity between the RF and EPC-Bearer or Tunnels to the outside world.
    • ♠ S-GW: Refers to a component that connects the eNodeB with the PDN-GW and is usually a router that sends the tunnel to the PDN-GW with data from the eNodeB or the UE
    • ♠ PDN-GW: Functions as the anchor or the home of the network, is the main NAT/Routing GW to the internet and keeps track of all tunnels for each UE on the network, and knows how to forward packets to the UEs.
    • ♠ MME: The Mobility Management Entity, handles mobility in general, required for the S1-AP handover, and handles many mobility functions coordinating with the PDN-GW/S-GWs.

    There are multiple specifications related to handover on LTE and defined by ETSI/3GPP organizations.

    PDF TS 136.331
    PDF TS 136.300
    PDF TS 129.275

  • X2 Handover in LTE: A Tutorial

    X2 Handover:  How does it work?

    An X2 Handover is used by LTE as well as S1 handovers for User Equipment (“UE”) or mobile phone mobility.

    First and foremost,  LTE and 5G both share an ALL-IP Architecture. In the past, in UMTS systems or even older systems, mobility consisted in several layers of IuB interfaces from the RNC to the NodeBs.  It is not then an ALL-IP network as expected.

    We will not go over Tracking Area Updates and Tracking Area Indentifiers as that’s will be discussed in a later post.

    In UMTS, the Radio Network Controller (RNC) manages hundreds of NodeBs, all interconnected using the IuB interface and RNC to RNC uses the IuR Interface. The SGSN or Serving GPRS Support Node is in charge of setting up the internet link or GTP-U tunnel from the SGSN tot he RNC. However the IP link will not move although an you can switch from NodeBs, meaning that any soft-handover or hand-handovers that occur between NodeBs does not affect the GTP-U link form the internet to the UE.

    UMTS Network

    In LTE, on the other hand there are many changes, one is that eNodeB is the end-point of the IP link, making it an ALL-IP network. This change requires some redesign to the protocols and specially the insertion of “hard handovers” plus X2 and S1AP Handover protocols that are now based on IP Mobility.   As shown in the figure below, X2 interfaces communicate eNodeBs, and S1 links from eNodeBs to S-GWs and S1-MME to the MME. The MME is the Mobility Management Entity which tracks the UE and does paging, as well as updates.

    LTE X2 Interface

    As you can observe, the X2 Interface is key for handoff as this interface is used not only to detect adjacent eNodeBs but also to exchange information as interference and others.



    The X2 handover will be illustrated as follows:

    The UE has to be in RRC_CONNECTED stated not in RRC_IDLE where a process called “Cell Reselection” i used. Lets Start with 1-6 Steps:

    Step 1: Handover Command

    As opposed to others, we will start with the Handover Command, which is the an RRC Connection Reconfiguration Message that contains a field called “MobilityConttrolInfo” this field contains the Physical Cell ID to handover to, as well as a list of neighbor cells with their associated “Cell Individual Offsets” that are used for A3, A5 and other events.

    Handover Command

    The Handover Command forces the switch from a previous cell to the next cell. Handover can only occur

    In this example a Handover Command was issued to connect to eNodeB with ID=1.

    An RRC Connection Reconfiguration message may follow with a list of Cell IDs, in this example, 2, 3, and maybe 4, to add to the list to monitor for a measurement report to be created.

    Mobility Control Info Structure

    This structure can be found in the specification as follows:

    Mobility Control Info

    Step 2 : Measurement Reports and Events

    As we know, LTE specification defines several reports. In this example we will focus on A5 and A3 events, that are programmed using the Cell Individual Offsets and Frequency offsets found in the specification.   Since the device is in “Connected State”  Layer 3 filtering is applied to the measurements made by the UE.

    The filtering algorithm may use different coefficients that the eNodeB sets as default.

    L3 Interfaces


    Events and measurements

    The state machine inside the UE, is configured by the rrcConnectionReconfiguration message to track all the eNodeBs provided and its frequencies, including applying SIB4 blocks that are submitted by the eNodeB to the target.

    In a way the eNodeB is predicting the next state to follow reporting A5 and A3 Events to the eNodeB.

    X2 handover Measurement Reports


    Now it is known by the eNodeB that Handover might be required and decides based on all the events or measurement reports, where to Handoff the UE too, and creates a HANDOVER REQUEST to a a Target eNodeB or the one with ID=2.

    X2 handover Handover Request

    STEP 4: Allocation of resources in Target eNodeB

    Now that Handover Request is moving forward, a setup for tunnels is created to the Target such that all internet traffic will start flowing tot he Target eNodeB with Cell ID =2


    X2 handover Handover Resources Allocated

    Once this is successful a Handover Acknolwedgement is made to the source and packets start going to the Target, similarly, Downlink and Uplink tunnels start being moved to the target eNodeB with Cell ID = 2


    STEP 5.  Handover Command to Switch to Target

    Exactly as in STEP 1, a Handover Command (in an rrcConnection Reconfiguration message) containing the Target ID = 2 is issued from the Source, also at some point another rrcConnection Reconfiguration message will contain all neighbor nodes with its respective Cell Individual Offests and this process will continue.

    X2 handover Handover Command


    STEP 6.  All is switch to the Target and MME is updated of the move.

    As a final step of handover, the path switch is complete which is a process called “Late Path Switch” that generates all traffic to move from the Source to the Target eNodeB in its totality.


    X2 handover Handover Completion

    You can hire us for consulting for your 4G or 5G Project.

    We have R&D Labs with wireless capabilities for IOT, Mobile, Emulation

    Hands-on Experts in Computer Communications, Networking, Cloud, Network Function Virtualization (NFV), Edge Computing, Smartphones, and all your strategic intellectual property needs.

  • Cloud to Cable Patent Updates

    Cloud to Cable Patent Officially Issued (2nd Patent)

    The new patent also covering “Cloud to Cable TV” was issued on December 11th, 2019.

    What does Cloud to Cable Patent Covers?

    Cloud to Cable is a patented solution for music streaming providers to distribute content to MVPDs. Amplify your ooffering from online streaming to Cable TV & IPTV systems with linear channels and SVOD subscriptions. Create visually appealing streams with great sound, bundled with a mobile experience
    through the MEVIA app.

    Patents: US 10,123,074, and 10,524,002 with European Patent filed/PCT.

    Music and Video are ready in all broadcasting platforms for easy monetization from your affiliates in MVPD, IPTV, Smart TVs & Mobile systems.

    Cloud to Cable are high-performance servers ready for your customer’s CABSAT headend, with a fault-tolerance design for quick integration. The
    content is available in mobile applications and Cable TV Broadcasts as SVOD or linear channels, all at once

    Cloud to Cable TV patent Issued

    10,524,002 Patent Now Available

    Cloud to Cable Patent Portfolio

    As of December 11th, 2019, the USPTO officially issued US Patent 10,524,002 covering aspects of Cloud to Cable TV that were not covered in the initial patent. I received a notification today of my 12th issued US Patent and hopefully more to come in the coming years.

    This patent includes several claims that include: Generation of a parallelized set of MPEG TV / DVB Broadcasted to Cable TV systems or IPTV;  MPEG TV bi-directional communication from the Set Top Box to the Cable TV system’ Virtualized versions of the broadcasting embodiment or the Cloud and other important inventions covered..

    Edge Computing for TV Broadcasting

    Both, Cloud to Cable Patents, 10,123,074 and 10,524,002 cover a device or computing system that can be embodied into an edge server located at the Cable TV premises, IPTV System, or even at newly defined 4G LTE and 5G broadcasting platforms.

    Cloud to Cable TV brings virtualization to media broadcasting and distribution.

    For licensing proposals, partnerships, don’t hesitate to reach me.

    Cloud to Cable TV Patent

    The family of patents includes now 10,123,074 and 10,524,002, both patents entail

    As shown herein, those claims include for example:

    Two way control messages from Claim 24, Claim 24 itself,

    Injection of MPEG Metadata or MPEG Frames into the stream.

    Fault-tolerance system and multicasting server for MPEG encoded video and audio,

    HTTP Live Streaming, RTSP, or HTTP Playlist

    Linear and Video on Demand (VOD) Support.

    Software Platform and Reference Implementation

    The reference implementation and production device is implemented under our “MediaPlug” or “Mevia” Appliance. In general, any server with 8-16GB of RAM, i7 Intel Processor or AMD, 2TB drive (RAID), ethernet or fiber interfaces is more than sufficient to load all docker  images and be provisioned for media delivery.

    Additional Software Requirements

    Xen Server 7.2 or higher, or Ubuntu Linux 14.04 or higher with Docker Images.
    Sources implemented with PHP, Python, C/C++, BASH, and other modules.

    Mux and Cable Headend Requirements

    The Cable Headend should consist of a Motorola-based Cherry or any other DVB/MPEG mux. All Set Top Boxes can support multicast streams directly for IPTV systems with fiber, or Coaxial with DOCSIS 2.0-3.0.  MPEG messages and encoding depends on provider.

    Formatted for Audio-only, HTML-based Standard Definition (SD), High Definition (HD), 4K, and/or Dolby-digital Sound.