top of page

The Xn Interface in 5G Networks

The Xn Interface in 5G Networks
The Xn Interface in 5G Networks

The Xn interface is a crucial component in 5G networks, facilitating communication and data transfer between gNodeBs (Next Generation Node B). It encompasses both control and user planes, supporting various procedures necessary for maintaining seamless connectivity and efficient network operation.


Overview of the Xn Interface

The Xn interface connects one gNodeB to another, with the control plane (Xn-C) handling signaling and the user plane (Xn-U) managing the transfer of application data. This interface is typically set up through the Automatic Neighbor Relation (ANR) procedure, which relies on the User Equipment (UE) to report the Physical Cell Identity (PCI) of neighboring cells. If the PCI is unknown to the serving gNodeB, the UE is requested to decode the Cell Global Identity (CGI) from the System Information.


Setting Up the Xn Interface

Automatic Neighbor Relation (ANR) Procedure

The ANR procedure begins with the UE reporting the PCI of a neighboring gNodeB. If the PCI is not known, the serving gNodeB uses the CGI to retrieve the IP address of the neighboring gNodeB by querying the Access and Mobility Management Function (AMF). The AMF forwards this query to the neighboring gNodeB and responds with its IP address. The serving gNodeB then establishes a Stream Control Transmission Protocol (SCTP) connection with the neighboring gNodeB, allowing the Xn Setup procedure to initiate.


Xn Setup Procedure

The Xn Setup procedure creates a logical Xn connection between two gNodeBs. It requires the first gNodeB to know the IP address of the second gNodeB to establish an SCTP connection. Following this, the Xn Setup Request/Xn Setup Response handshake is completed, enabling the gNodeBs to exchange information about their cells, AMF connectivity, and Tracking Areas. This procedure is usually completed after detecting a new neighboring base station and is repeated only if the Xn connection is deleted and needs re-establishment.


Maintaining and Updating Configuration

NG-RAN Node Configuration Update

The NG-RAN Node Configuration Update procedure ensures that a gNodeB can maintain its configuration information over time. This procedure supports updates to the set of supported Tracking Areas and changes triggered by 'Energy Saving' functions. For example, a gNodeB may deactivate cells during low traffic periods to conserve energy and reduce operating costs. This deactivation is communicated to neighboring gNodeBs using the NG-RAN Node Configuration Update procedure, which is also used to inform about cell reactivation during increased traffic.


Cell Activation Procedure

The Cell Activation procedure complements the NG-RAN Node Configuration Update by allowing a neighboring gNodeB to request cell activation. This procedure involves a Cell Activation Request/Cell Activation Response handshake, specifying the reactivated cells, thus avoiding the need for a subsequent NG-RAN Node Configuration Update procedure.


Error Handling and Reset Procedures

Reset Procedure

The Reset procedure initiates either a 'Full' or 'Partial' reset. A 'Full' reset deletes all UE context information associated with the source base station, while a 'Partial' reset deletes information for specific UE contexts. The target base station responds with a Reset Response message, ensuring that application-level data provided during the Xn Setup or NG-RAN Node Configuration Update procedures are not deleted.


Error Indication Procedure

The Error Indication procedure reports errors detected within an incoming XnAP message, especially when these errors cannot be reported using a failure message belonging to the procedure that created the errors.


Xn Removal Procedure

The Xn Removal procedure deletes the signaling connection between source and target base stations. The source base station initiates this procedure with an Xn Removal Request message, which the target base station acknowledges with an Xn Removal Response message. The source base station can include an Xn Removal Threshold information element, allowing the target base station to decide whether to accept the removal request based on the connection's importance level.


Mobility Procedures

Xn Handover Procedure

Mobility procedures are crucial during the Xn handover process. Handover Preparation requests resources at the target base station, while the Sequence Number (SN) Status Transfer procedure ensures that PDCP Sequence Numbers are preserved, enabling a lossless handover. The UE Context Release procedure instructs the source base station to release the UE context after a successful handover. If necessary, the source base station can use the Handover Cancel procedure to stop an ongoing Handover Preparation.


Retrieve UE Context Procedure

The Retrieve UE Context procedure is essential when a UE transitions from RRC Inactive to RRC Connected. If the UE moves to a new base station, the new serving base station must retrieve the UE context from the old serving base station using the Xn interface. This procedure also applies during RRC Connection Re-establishment, where the new base station retrieves the UE context from the old base station following a radio link failure and recovery.


Data Forwarding Address Indication Procedure

Following the Retrieve UE Context procedure, the new serving base station provides the old serving base station with a forwarding address for downlink data buffered at the old base station. This data is forwarded across the Xn-U interface to prevent packet loss.


RAN Paging Procedure

The RAN Paging procedure transfers paging messages across the Xn interface when a UE is in the RRC Inactive state. The serving base station distributes the paging message to other base stations within the RAN Notification Area, ensuring the message reaches the UE regardless of its current location within the area.


Dual Connectivity and Secondary Node Management

Dual Connectivity

Dual Connectivity allows a UE to benefit from resource allocations provided by two base stations. Within the Xn interface context, this applies to pairs of gNodeBs or a gNodeB neighboring a Next Generation eNodeB (ng-eNodeB). Secondary Node management procedures enable the addition, modification, and release of Secondary Nodes for specific UE connections.


Secondary Node Addition and Modification

The S-NG-RAN Node Addition Preparation and S-NG-RAN Node Reconfiguration Complete procedures manage the addition of Secondary Nodes. The S-NG-RAN Node Modification procedure can be initiated by either the Master Node or the Secondary Node, involving corresponding request/acknowledge handshakes and reconfiguration completion acknowledgments.


Secondary Node Release and Counter Check

The S-NG-RAN Node Release procedure can also be initiated by either the Master Node or the Secondary Node, with the Master Node responsible for releasing the UE context at the Secondary Node following the configuration release. The S-NG-RAN Node Counter Check procedure serves as a local authentication mechanism, detecting packet insertion by an intruder through PDCP COUNT value verification.


RRC Transfer and Notification Control

The RRC Transfer procedure relays downlink and uplink RRC messages between the Master Node and Secondary Node, supporting delivery status reporting for RRC messages originating from the Master Node. The Notification Control Indication procedure indicates whether the Guaranteed Flow Bit Rate (GFBR) of a GBR QoS Flow can be achieved, supporting the maintenance of Quality of Service.


Activity Notification and E-UTRA NR Cell Resource Coordination

The Activity Notification procedure indicates activity or inactivity for specific UEs or QoS Flows, aiding Radio Resource Management. The E-UTRA NR Cell Resource Coordination procedure coordinates radio resource allocation between a gNodeB and an ng-eNodeB sharing overlapping coverage areas, using bitmaps to signal selected Resource Blocks for future scheduling.


User Plane Protocols

The user plane of the Xn interface transfers application data between base stations, using GTP-U tunnels identified by their Tunnel Endpoint Identifier (TEID). These tunnels facilitate data forwarding during handover procedures or for connections using Dual Connectivity. The user plane protocol above the GTP-U layer includes control mechanisms for flow control, packet loss detection, and successful delivery reporting.


PDU Types and Control Mechanisms

The user plane protocol uses different PDU types for control mechanisms. PDU Type 0, sent by the base station hosting the PDCP layer, adds a sequence number to each downlink data packet for packet loss detection and discard instructions. PDU Type 1, sent by the receiving node, reports lost packets and controls the downlink data rate, indicating desired buffer levels and data rates. Additionally, PDU Type 1 can signal 'Radio Link Outage' or 'Radio Link Resume,' managing data forwarding accordingly.

25 views0 comments

Recent Posts

See All

Comments


bottom of page