BACKGROUND OF THE INVENTION
The present disclosure relates to Radio Access Network (RAN) for 4G- and 5G-based mobile networks, and relates more particularly to handovers optimization when a user equipment (UE) moves from one cell to another cell in the RAN.
In 5G New Radio (NR) standards, handovers between a first next Generation Node B (gNB) and a second gNB are performed using an Xn interface or Next Generation Application Protocol (NGAP). Xn handover is performed through an Xn connection between two gNBs. NGAP handover is performed in the following sequence: the source gNB->Access & Mobility Function (AMF)->target gNB. Xn handover is preferred over NGAP handover due to less hop and typically faster speed.
UE would be connected to the source gNB, and the source gNB would have selected a specific Access & Mobility Function (AMF) to handle this UE. Source gNB receives the measurement report for the UE (for mobility) and then it identifies the target gNB. Source gNB sends the Xn handover request towards the target gNB. As part of the Xn handover request, source gNB specifies the Globally Unique AMF Identifier (GUAMI) of the AMF which currently handles the UE. As per 3rd Generation Partnership Project (3GPP) Technical Specification (TS) 23.502, Xn handovers are only supported for intra-AMF mobility.
As per 3GPP TS 23.003, the following are specified:
- <GUAMI>=<MCC><MNC><AMF Identifier>
- and
- <AMF Identifier>=<AMF Region ID><AMF Set ID><AMF Pointer>
Mobile Country Code (MCC) and Mobile Network Code (MNC) shall have the same field size as in earlier 3GPP systems.
- AMF Region ID shall be of 8 bits length.
- AMF Set ID shall be of 10 bits length.
- AMF Pointer shall be of 6 bits length.
On receiving the Xn handover request, the target gNB performs the following checks:
1. It checks whether it supports AMF set ID as received in handover request.
- a. If not supported, target gNB rejects the Xn handover request by sending handover preparation failure notification with cause as Invalid AMF Set ID.
2. If AMF set ID is supported, it checks whether it knows the GUAMI and has connection to this specified AMF or not.
- a. If not supported (or) not connected, target gNB rejects the Xn handover request by sending handover preparation failure notification with cause as Unknown GUAMI ID.
Upon receiving the handover preparation failure with the above causes, source gNB understands that the current AMF (which serves the UE) is not supported by the target gNB. Subsequently, the source gNB triggers the NGAP handover procedure. As part of the NGAP handover procedure, AMF relocation could be needed.
The above-described approach is a reactive approach because Xn AP handover is initially attempted, and only upon its failure is an NGAP handover initiated. This reactive approach has the following disadvantages:
- 1. This can actually increase the overall handover time.
- 2. This can lead to call drop due to delay in handover.
- 3. This leads to additional Xn signaling.
- 4. Xn handover preparation key performance indicators (KPIs) would be impacted negatively.
To remedy the above-discussed disadvantages of the reactive approach, a proactive approach can be implemented, in which proactive approach the source gNB knows whether the AMF (which currently serves the UE) is supported by the target gNB or not. If the AMF is supported, then only the Xn handover should be initiated. If the AMF is not supported, the NGAP handover shall be directly initiated. The current call flows based on invalid AMF set Id is illustrated in FIGS. 1a and 1b, and the current call flows based on unknown GUAMI Id are illustrated in FIGS. 2a & 2b.
FIGS. 1a and 1b illustrate the call flow sequence of a scenario in which Xn handover failure occurs with invalid AMF Set ID, and NGAP handover is subsequently triggered. The call flow sequence starts at the top with the interface level procedures, the beginning of which is summarized in box 101 of FIG. 1a, i.e., first gNB (gNB1) 12, and a first AMF (AMF1) 13, are connected through the NGAP procedures (i.e., NG setup), with the GUAMI of the AMF113 being 12345632800c. The NGAP procedures start with the gNB112 sending the NG setup request to the AMF113, as shown by the process arrow 1001. NG setup response is sent by AMF113 to the gNB112, GUAMI of the AMF113 being 12345632800c, as shown by the process arrow 1002. Next, as summarized in box 102 of FIG. 1a, second gNB (gNB2) 14, and a second AMF (AMF2) 15, are connected through the NGAP procedures (i.e., NG setup), with the GUAMI of the AMF215 being 12345632400a. The NGAP procedures start with the gNB214 sending the NG setup request to the AMF215, as shown by the process arrow 1003. NG setup response is sent by AMF215 to the gNB214, GUAMI of the AMF215 being 12345632400a, as shown by the process arrow 1004.
As summarized in box 103 of FIG. 1a, both AMF113 and AMF215 have (i.e., belong to) the same AMF region ID of 32, but AMF113 and AMF215 have (i.e., belong to) different AMF set IDs. Next, as summarized in box 104, gNB112 and gNB214 are connected through the Xn procedures (i.e., Xn setup). The Xn procedures start with the gNB112 sending the Xn setup request (with AMF region ID of 32 for gNB112) to gNB214, as shown by the process arrow 1005. Next, gNB214 sends the Xn setup response (with AMF region ID of 32 for gNB214) to the gNB112, as shown by the process arrow 1006. At this point in the call flow, UE 11 is connected to one of the cells in gNB112, as summarized in box 105.
The call flow illustrated in FIG. 1a is continued in FIG. 1B, with the radio resource connection (RRC) procedure shown at the top, which starts with the UE 11 sending the RRC Setup Request message 1007 to the gNB112. In response, the gNB112 sends the RRC Setup message 1008 to the UE 11, which in turn sends the RRC Setup Complete message 1009 to the gNB112. Next, the Initial UE message 1010 is sent from the gNB112 to the AMF113, which in turn responds by sending the Initial Context Setup Request message 1011 to the gNB112. Subsequently, RRC Reconfiguration procedures 1012 are implemented between the gNB112 and the UE 11. This is followed by the Initial Context Setup Response message 1013 being sent from the gNB112 to the AMF113. At this point in the call flow sequence, the Protocol Data Unit (PDU) session setup procedure is completed, as summarized in box 106.
Next in the call flow sequence, as summarized in box 107 shown in FIG. 1B, the UE moves to another cell in gNB214, and gNB112 (which has Xn connection to gNB214) initiates the Xn handover procedure towards the gNB214. The Xn handover procedure starts with the gNB112 sending the Xn handover request (with GUAMI of 12345632800c) to the gNB214, as shown by the process arrow 1014. At this point in the call flow sequence, gNB214 is not connected to AMF113 (with GUAMI of 12345632800c), i.e., the respective AMF set IDs for gNB112 and gNB214 are different (800 and 400, respectively), as summarized in box 108. Therefore, the gNB214 sends to gNB112 a message indicating Xn handover preparation failure with cause, i.e., Invalid AMF Set ID, as shown by the process arrow 1015. As summarized in box 109, Xn handover fails with the cause of Invalid AMF Set ID, and gNB112 understands that gNB214 doesn't support the AMF Set ID contained in GUAMI of 12345632800c, so gNB112 triggers NGAP handover. The NGAP handover is initiated by the gNB112 sending NGAP Handover Required message 1016 to the AMF113, and the NGAP handover procedure continues thereafter, as summarized in box 110.
FIGS. 2a and 2b illustrate the call flow sequence of a scenario in which Xn handover failure occurs with unknown GUAMI ID, and NGAP handover is subsequently triggered. The call flow sequence starts at the top with the interface level procedures, the beginning of which is summarized in box 201 of FIG. 2a, i.e., first gNB (gNB1) 12, and a first AMF (AMF1) 13, are connected through the NGAP procedures (i.e., NG setup), with the GUAMI of the AMF113 being 12345632800c. The NGAP procedures start with the gNB112 sending the NG setup request to the AMF113, as shown by the process arrow 2001. NG setup response is sent by AMF113 to the gNB112, GUAMI of the AMF113 being 12345632800c, as shown by the process arrow 2002. Next, as summarized in box 202 of FIG. 2a, second gNB (gNB2) 14, and a second AMF (AMF2) 15, are connected through the NGAP procedures (i.e., NG setup), with the GUAMI of the AMF215 being 12345632800d. The NGAP procedures start with the gNB214 sending the NG setup request to the AMF215, as shown by the process arrow 2003. NG setup response is sent by AMF215 to the gNB214, GUAMI of the AMF215 being 12345632800d, as shown by the process arrow 2004.
As summarized in box 203 of FIG. 2a, both AMF113 and AMF215 have (i.e., belong to) the same AMF region ID of 32, and the same AMF set ID of 800, but AMF113 and AMF215 have (i.e., belong to) different AMF pointers (“c” for AMF113, and “d” for AMF215). Next, as summarized in box 204, gNB112 and gNB214 are connected through the Xn procedures (i.e., Xn setup). The Xn procedures start with the gNB112 sending the Xn setup request (with AMF region ID of 32 for gNB112) to gNB214, as shown by the process arrow 2005. Next, gNB214 sends the Xn setup response (with AMF region ID of 32 for gNB214) to the gNB112, as shown by the process arrow 2006. At this point in the call flow, UE 11 is connected to one of the cells in gNB112, as summarized in box 205.
The call flow illustrated in FIG. 2a is continued in FIG. 2b, with the radio resource connection (RRC) procedure shown at the top, which starts with the UE 11 sending the RRC Setup Request message 2007 to the gNB112. In response, the gNB112 sends the RRC Setup message 2008 to the UE 11, which in turn sends the RRC Setup Complete message 2009 to the gNB112. Next, the Initial UE message 2010 is sent from the gNB112 to the AMF113, which in turn responds by sending the Initial Context Setup Request message 2011 to the gNB112. Subsequently, RRC Reconfiguration procedures 2012 are implemented between the gNB112 and the UE 11. This is followed by the Initial Context Setup Response message 2013 being sent from the gNB112 to the AMF113. At this point in the call flow sequence, the Protocol Data Unit (PDU) session setup procedure is completed, as summarized in box 206.
Next in the call flow sequence, as summarized in box 207 shown in FIG. 2b, the UE moves to another cell in gNB214, and gNB112 (which has Xn connection to gNB214) initiates the Xn handover procedure towards the gNB214. The Xn handover procedure starts with the gNB112 sending the Xn handover request (with GUAMI of 12345632800c) to the gNB214, as shown by the process arrow 2014. At this point in the call flow sequence, gNB214 is not connected to AMF113 (with GUAMI of 12345632800c), i.e., the respective AMF set IDs for gNB112 and gNB214 are the same, but the GUAMI of AMF113 is unknown to (i.e., is not recognized as being known to) gNB214, as summarized in box 208. Therefore, the gNB214 sends to gNB112 a message indicating Xn handover preparation failure with cause, i.e., Unknown GUAMI ID, as shown by the process arrow 2015. As summarized in box 209, Xn handover fails with the cause of Unknown GUAMI ID, and gNB112 understands that gNB214 doesn't know the GUAMI of AMF113, so gNB112 triggers NGAP handover. The NGAP handover is initiated by the gNB112 sending NGAP Handover Required message 2016 to the AMF113, and the NGAP handover procedure continues thereafter, as summarized in box 210.
As described above, only the AMF region Id is exchanged between two gNBs as part of the conventional Xn setup request/response procedure (e.g., as shown in FIGS. 1a-1b and 2a-2b), but each gNB doesn't know the supported GUAMI(s) of a peer (target) gNB.
Therefore, there is a need for a solution that optimizes the handover procedure by providing the information regarding the supported GUAMI(s) of a peer (target) gNB.
SUMMARY OF THE INVENTION
According to an example embodiment of the present disclosure, a method is presented in which, in addition to exchanging the respective AMF region Ids between two gNBs, all supported GUAMIs shall be exchanged as part of the Xn setup request/response procedure, thereby enabling each gNB to know the supported GUAMI(s) of a peer (target) gNB.
According to an example embodiment of the present disclosure, before initiating the Xn handover, source gNB shall check whether the target gNB supports the AMF (which currently serves the UE). If supported, the source gNB shall proceed with the Xn-based handover. If the AMF is not supported by the target gNB, the source gNB shall initiate the NGAP handover.
According to an example embodiment of the present disclosure, a method is presented in which the Xn setup request/response procedure as specified in 3GPP Xn specification TS 38.423 is modified such that all supported GUAMIs are exchanged as part of the Xn setup request/response procedure.
According to an example embodiment of the present disclosure, all supported GUAMIs shall be added as part of the New Generation Radio Access Network (NG-RAN) Configuration Update procedure, as well. Whenever there is any change in supported GUAMIs (addition/deletion/modification), the gNB shall initiate the NG-RAN configuration update towards the peer (target) gNB with the whole list of GUAMIs.
BRIEF DESCRIPTION OF THE DRAWINGS
FIGS. 1a and 1b illustrate the call flow sequence of a scenario in which Xn handover failure occurs with invalid AMF Set ID, and NGAP handover is subsequently triggered.
FIGS. 2a and 2b illustrate the call flow sequence of a scenario in which Xn handover failure occurs with unknown GUAMI ID, and NGAP handover is subsequently triggered.
FIGS. 3a and 3b illustrate an example call flow sequence for a proactive initiation of NGAP handover according to the present disclosure.
DETAILED DESCRIPTION OF THE INVENTION
According to an example embodiment of the present disclosure, a method is presented in which, in addition to exchanging the respective AMF region IDs between two gNBs, all supported GUAMIs shall be exchanged as part of the Xn setup request/response procedure, thereby enabling each gNB to know the supported GUAMI(s) of a peer (target) gNB. The Xn setup request/response procedure as specified in 3GPP Xn specification TS 38.423 is modified to reflect the exchange of all supported GUAMIs in the Xn setup request/response procedure. More specifically, the new IE List of GUAMIs (Served GUAMI List) needs to be added in the following messages: Xn setup request, Xn setup response, NG-RAN Node Configuration Update, NG-RAN Node Configuration Update acknowledge message in 3GPP Xn Application Protocol (XnAP) Technical Specification TS 38.423.
|
IE type and
Semantics
|
IE/Group Name
Presence
Range
reference
description
|
|
|
Served GUAMI List
O
|
>Served GUAMI Item
1 . . .
|
<maxnoofServedGUAMIs>
|
>>GUAMI
M
|
|
“maxnoofServedGUAMIs”—Maximum no. of GUAMIs served by an AMF; value is 256.
|
Definition of GUAMI is same as section 9.3.3.3 in 3GPP NGAP 38.413 specification.
|
FIGS. 3a and 3b illustrate an example call flow sequence for a proactive initiation of NGAP handover according to the present disclosure. The call flow sequence starts at the top with the interface level procedures, the beginning of which is summarized in box 301 of FIG. 3a, i.e., first gNB (gNB1) 12, and a first AMF (AMF1) 13, are connected through the NGAP procedures (i.e., NG setup), with the GUAMI of the AMF113 being 12345632800c. The NGAP procedures start with the gNB112 sending the NG setup request to the AMF113, as shown by the process arrow 3001. NG setup response is sent by AMF113 to the gNB112, GUAMI of the AMF113 being 12345632800c, as shown by the process arrow 3002. Next, as summarized in box 302 of FIG. 3a, second gNB (gNB2) 14, and a second AMF (AMF2) 15, are connected through the NGAP procedures (i.e., NG setup), with the GUAMI of the AMF215 being 12345632400a. The NGAP procedures start with the gNB214 sending the NG setup request to the AMF215, as shown by the process arrow 3003. NG setup response is sent by AMF215 to the gNB214, GUAMI of the AMF215 being 12345632400a, as shown by the process arrow 3004.
As summarized in box 303 of FIG. 3a, both AMF113 and AMF215 have (i.e., belong to) the same AMF region ID of 32, but AMF113 and AMF215 have (i.e., belong to) different AMF set IDs. Next, as summarized in box 304, gNB112 and gNB214 are connected through the Xn procedures (i.e., Xn setup). The Xn procedures start with the gNB112 sending the Xn setup request with i) AMF region ID of 32 and ii) the list of GUAMIs (i.e., 12345632800c in this case) for gNB112 to gNB214, as shown by the process arrow 3005. Next, gNB214 sends the Xn setup response with i) AMF region ID of 32 and ii) the list of GUAMIs (12345632400a) for gNB214 to the gNB112, as shown by the process arrow 3006. Because GUAMIs are exchanged between gNB112 and gNB214, each gNB knows the supported GUAMIs of the other gNB, which information can be used to determine whether an Xn handover would be rejected or not. At this point in the call flow, UE 11 is connected to one of the cells in gNB112, as summarized in box 305.
The call flow illustrated in FIG. 3a is continued in FIG. 3b, with the radio resource connection (RRC) procedure shown at the top, which starts with the UE 11 sending the RRC Setup Request message 3007 to the gNB112. In response, the gNB112 sends the RRC Setup message 3008 to the UE 11, which in turn sends the RRC Setup Complete message 3009 to the gNB112. Next, the Initial UE message 3010 is sent from the gNB112 to the AMF113, which in turn responds by sending the Initial Context Setup Request message 3011 to the gNB112. Subsequently, RRC Reconfiguration procedures 3012 are implemented between the gNB112 and the UE 11. This is followed by the Initial Context Setup Response message 3013 being sent from the gNB112 to the AMF113. At this point in the call flow sequence, the Protocol Data Unit (PDU) session setup procedure is completed, as summarized in box 306.
Next in the call flow sequence, as summarized in box 307 shown in FIG. 3b, the UE moves to another cell in gNB214. Because GUAMIs were previously exchanged between gNB112 and gNB214, each gNB knows the supported GUAMIs of the other gNB, and gNB112 (which has Xn connection to gNB214) checks whether gNB214 has connection to the currently connected AMF serving the UE 11, i.e., gNB112 checks whether the current GUAMI (i.e., 12345632800c) of the AMF serving the UE 11 is supported by (i.e., included in the list of GUAMIs for gNB214) or not. As gNB2 doesn't support the GUAMI 12345632800c (i.e., gNB214 doesn't have connection to the currently connected AMF serving the UE 11), gNB112 knows that Xn handover would be rejected by gNB214 with the cause “Unknown GUAMI ID”. Therefore, gNB112 doesn't initiate the Xn handover, but instead proceeds directly with the NGAP-based handover. The handover is initiated by the gNB112 sending NGAP Handover Required message 3014 to the AMF113, as shown by the process arrow 3014, and the NGAP handover procedure continues thereafter, as summarized in box 308. In the hypothetical case gNB214 supports the GUAMI 12345632800c, gNB112 would initiate the Xn handover.
Although the above-described example method was presented mainly in the context of 5G NR, the method according to the present disclosure is applicable for Long Term Evolution (LTE) as well. In LTE, X2 handover is applicable only within the same Mobility Management Entity (MME). For LTE, X2AP procedures (X2AP is a control protocol found between eNBs on the X2 control plane), e.g., X2 setup request, X2 setup response, ENB configuration update, and ENB configuration Update Acknowledge messages in 3GPP X2AP specification (TS 36.423) shall be enhanced to include the new Information Element Served Globally Unique MME Identifiers (GUMMEIs).
Patent Application
20230379779
