WO2020048479A1

WO2020048479A1 - Apparatus and method to support make-before-break (mbb) handover in next generation radio access network (ng-ran)

Info

Publication number: WO2020048479A1
Application number: PCT/CN2019/104352
Authority: WO
Inventors: Feng Yang; Jaemin HAN; Alexander Sirotkin; Xu Zhang
Original assignee: Intel Corporation
Priority date: 2018-09-07
Filing date: 2019-09-04
Publication date: 2020-03-12
Also published as: CN112602374B; CN112602374A

Abstract

Provided herein are apparatuses and methods to support make-before-break (MBB) handover in next generation radio access network (NG-RAN).

Description

APPARATUS AND METHOD TO SUPPORT MAKE-BEFORE-BREAK (MBB) HANDOVER IN NEXT GENERATION RADIO ACCESS NETWORK (NG-RAN)

Priority Claim

This application is based on and claims priority to International Application No. PCT/CN2018/104517, filed on September 07, 2018, which is incorporated herein by reference in its entirety.

Technical Field

Embodiments of the present disclosure generally relate to cellular communications, and in particular to a make-before-break (MBB) handover for a user equipment (UE) in a next generation radio access network (NG-RAN) .

Background Art

An MBB handover is a feature to allow a UE to continue transmitting/receiving data to/from a base station that has initiated a handover procedure (the base station is regarded as a “source base station” hereinafter) , after the handover procedure to another base station (which is regarded as a “target base station” hereinafter) has been initiated. That is to say, during the MBB handover procedure, the UE may simultaneously connect to two or more cells. The MBB handover could decease interruption time and improve data throughput for the UE during the handover.

A key point to implement the MBB handover is to let the source base station to determine when to stop scheduling the UE, rather than stopping transmissions upon a radio resource control (RRC) Connection Reconfiguration message including a handover command has been successfully transmitted to the UE. The MBB handover has already been introduced into a long term evolution (LTE) network. However, in the NG-RAN architecture with control plane (CP) /user plane (UP) split (i.e., in the NG-RAN architecture, a next generation Node B (gNB) may be separated into a central unit control plane (CU-CP) , a central unit user plane (CU-UP) , and one or more distribution units (DUs) ) , the MBB handover is not supported currently. For example, Figure 8.9.4-1 of the Third Generation Partnership Project (3GPP) Technical Specification (TS) 38.401 Release 15 (V15.2.0, June 2018) shows a procedure used for inter-gNB handover involving gNB-CU-UP change, in which a DU and a CU-CP of the source gNB stop transmitting/receiving data respectively in the “6. F1 UE Context Modification” and “7. Bearer Context Modification Request (data forwarding info) ” steps. As a result, a long-time interruption and low throughput for the UE during the inter-gNB handover are likely to be caused.

Brief Description of the Drawings

Embodiments of the disclosure will be illustrated, by way of example and not limitation, in the figures of the accompanying drawings in which like reference numerals refer to similar elements.

Fig. 1 is a block diagram illustrating an exemplary gNB with a separation of a central unit control plane (CU-CP) and a central unit user plane (CU-UP) , in accordance with some embodiments of the disclosure.

Fig. 2 is a communication diagram illustrating an exemplary MBB handover procedure between a source gNB and a target gNB in accordance with some embodiments of the disclosure.

Fig. 3 shows an exemplary Downlink Data Delivery Status (DDDS) format in accordance with some embodiments of the disclosure.

Fig. 4 shows an exemplary new user plane message in accordance with some embodiments of the disclosure.

Fig. 5 is a communication diagram illustrating an exemplary MBB handover procedure between a source gNB and a target gNB in accordance with some embodiments of the disclosure.

Fig. 6 is a communication diagram illustrating an exemplary MBB handover procedure between a source gNB and a target gNB in accordance with some embodiments of the disclosure.

Fig. 7 shows a method for performing a MBB handover for a UE in accordance with various embodiments of the disclosure.

Fig. 8 shows a method for performing a MBB handover for a UE in accordance with various embodiments of the disclosure.

Fig. 9 shows a method for performing a MBB handover for a UE in accordance with various embodiments of the disclosure.

Fig. 10 shows an exemplary architecture of a system of a cellular network in accordance with some embodiments.

Fig. 11 illustrates an architecture of a system of a network in accordance with various embodiments of the disclosure.

Fig. 12 illustrates exemplary components of a device in accordance with various embodiments of the disclosure.

Fig. 13 illustrates exemplary interfaces of baseband circuitry in accordance with various embodiments of the disclosure.

Fig. 14 illustrates hardware resources in accordance with various embodiments of the disclosure.

Detailed Description of Embodiments

Various aspects of the illustrative embodiments will be described using terms commonly employed by those skilled in the art to convey the substance of the disclosure to others skilled in the art. However, it will be apparent to those skilled in the art that many alternate embodiments may be practiced using portions of the described aspects. For purposes of explanation, specific numbers, materials, and configurations are set forth in order to provide a thorough understanding of the illustrative embodiments. However, it will be apparent to those skilled in the art that alternate embodiments may be practiced without the specific details. In other instances, well-known features may have been omitted or simplified in order to avoid obscuring the illustrative embodiments.

Further, various operations will be described as multiple discrete operations, in turn, in a manner that is most helpful in understanding the illustrative embodiments; however, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations need not be performed in the order of presentation.

The phrases “in an embodiment” “in one embodiment” and “in some embodiments” are used repeatedly herein. The phrase generally does not refer to the same embodiment; however, it may. The terms “comprising, ” “having, ” and “including” are synonymous, unless the context dictates otherwise. The phrases “A or B” and “A/B” mean “ (A) , (B) , or (A and B) . ”

In an NG-RAN, a base station, such as, a gNB, may be separated into a central unit control plane (CU-CP) for control plane functions, a central unit user plane (CU-UP) for user palne functions, and one or more distribution units (DUs) for user equipment communication functions. The CU-CP may be connected to a DU through an F1-C interface. The CU-UP may be connected to a DU through an F1-U interface. The CU-UP may be connected to the CU-CP through an E1 interface. In the NG-RAN, an Xn interface allows interconnection between NG-RAN nodes (such as, gNBs) with each other. There may be multiple NG-C logical interfaces towards the fifth generation core network (5GC) from any one NG-RAN node. The selection of the NG-C interface is then determined by the network access server (NAS) node selection function. There may be multiple NG-U logical interfaces towards the 5GC from any one NG-RAN node. The selection of the NG-U interface is done within the 5GC and signaled to the NG-RAN node by the access and mobility management function (AMF) .

Techniques, apparatus, and methods are discloses herein to support MBB in a separated CP and UP deployment. In an embodiment, an F1 message UE Context Modification Request transmitted by a CU-CP of a gNB (which may be abbreviated as “gNB-CU-CP” ) to a DU of the gNB (which may be abbreviated as “gNB-DU” ) , and an E1 message Bearer Context Modification Request transmitted by the CU-CP of the gNB to a CU-UP of the gNB (which may be abbreviated as “gNB-CU-UP” ) may be extended to include a dedicated indicator to respectively inform the gNB-DU and the gNB-CU-UP, of an MBB handover configured for a UE. Optionally, in the embodiment, a user plane message, e.g. Downlink Data Delivery Status (DDDS) , may be extended to notify the gNB-CU-UP to stop transmitting and receiving data with the gNB-DU for the UE, when the gNB-DU has decided not to schedule the UE anymore.

In another embodiment, a control plane message, e.g. F1 UE Context Modification Required, transmitted by the gNB-DU is extended to include a MBB completion indicator to notify the gNB-CU-CP that the DU has stopped scheduling the UE. The gNB-CU-CP of the then may transmit a Bearer Context Modification Request to the gNB-CU-UP to stop the gNB-CU-UP transmitting and receiving data with the gNB-DU for the UE. In the embodiment, the gNB-CU-CP is unware of the MBB handover configuration, and therefore this solution has no impact on the E1 interface.

In another embodiment, a user plane message is adopted to promptly notify the gNB-CU-UP in parallel to the above-mentioned control plane message, so as to avoid the gNB-DU dropping downlink data.

The Techniques, apparatus, and methods provided herein may at least decrease time duration of interruption and/or improve data throughputs for a UE during a handover from a source gNB to a target gNB in the NG-RAN.

Fig. 1 is a block diagram illustrating an exemplary gNB 100 with a separation of a CU-CP and a CU-UP, in accordance with some embodiments of the disclosure. The gNB 100 is shown to include a distributed unit (DU) 110, which may also be called as a gNB-DU. It should be noted that though only one gNB-DU is shown in Fig. 1, the gNB 100 can actually include one or more distributed units. As shown, the gNB 100 may include a central unit (CU) 120, which may also be called as a gNB-CU. The gNB-CU 120 may be further split into a central unit control plane (CU-CP) 121 (which may also be called as a gNB-CU-CP) for control plane functions and a central unit user plane (CU-UP) 122 (which may also be called as a gNB-CU-UP) for user plane functions. The control plane functions may include, for example, radio resource control (RRC) and packet data convergence protocol (PDCP) of a signaling radio bearer (SRB) . The user plane functions may include, for example, PDCP of a data radio bearer (DRB) and service data application protocol (SDAP) .

Each of the gNB-DU 110, the gNB-CU-CP 121 and the gNB-CU-UP 122 may include one or more corresponding memories and one or more corresponding processors (not shown for the gNB-CU-CP 121 and the gNB-CU-UP 122 in Fig. 1 for brevity) , to implement corresponding functions. The memories may include, but are not limited to any type of volatile or non-volatile memory such as dynamic random access memory (DRAM) , static random-access memory (SRAM) , erasable programmable read-only memory (EPROM) , electrically erasable programmable read-only memory (EEPROM) , Flash memory, solid-state storage, etc. The processors may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc. ) . The processors may be coupled with or may include memory and may be configured to execute instructions stored in the memory to enable various applications or operating systems to run on the gNB-DU 110, the gNB-CU-CP 121 or the gNB-CU-UP 122.

In an embodiment, the gNB-DU 110 may communicate with the gNB-CU 120 through an F1 interface. In the scenario that the gNB-CU 120 is split into the NB-CU-CP 121 and gNB-CU-UP 122, the F1 interface may include a control plane interface (i.e., F1-C interface) between the gNB-DU 110 and the NB-CU-CP 121 and a user plane interface (i.e., F1-U interface) between the gNB-DU 110 and the gNB-CU-UP 122.

In an embodiment, the NB-CU-CP 121 and gNB-CU-UP 122 may communicate with each other through an E1 interface. The E1 interface is a control plane interface that exchanges UE-associated and non-UE associated information.

In an embodiment, the gNB-CU 120 may transmit/receive information to/from a core network (CN) 130, such as, a fifth generation core network (5GC) , through an NG interface. In the scenario that the gNB-CU 120 is split into the NB-CU-CP 121 and gNB-CU-UP 122, the NB-CU- CP 121 may exchange data with the core network through a control plane interface (i.e., NG-C interface) and the gNB-CU-UP 122 may exchange data with the core network through a user plane interface (i.e., NG-U interface) . For example, the core network 130 such as the 5GC, may include an Access and Mobility Management Function (AMF) and/or a User Plane Function (UPF) , and other functions. Functions of the core network will not be detailed herein, in order not to obscure the subject matter of the present application.

Different gNBs (e.g., gNB 100) may exchange data with each other through an Xn interface.

Below, some embodiments of the disclosure will be described in conjunction with the gNB 100 of Fig. 1. However, the embodiments are not limited in this respect.

In the description below, both a source gNB and a target gNB for a handover may be referred to the gNB 100 of Fig. 1. That is to say, the exemplary gNB 100 of Fig. 1 may be used as a source gNB or a target gNB for a handover, as described in details below.

Fig. 2 shows a communication diagram illustrating an exemplary MBB handover procedure 200 between a source gNB 210 and a target gNB 220 in accordance with some embodiments of the disclosure. Messages are transferred among a source gNB-DU 211, a source gNB-CU-UP 212, a source gNB-CU-CP 213, a target gNB-DU 221, a target gNB-CU-UP 222, a target gNB-CU-CP 223, and a CN 230, which may be connected by various interfaces in the manner described in relation to Fig. 1. For brevity and clarity, data exchanges between a UE and the source gNB 210 (e.g., the source gNB-DU 211) or the target gNB 220 (e.g., target gNB-DU 221) are omitted, so as not to obscure the subject matter of the present application.

In an embodiment, the exemplary MBB handover procedure 200 of Fig. 2 may include following message flows.

1. The source gNB-CU-CP 213 sends a handover request message, such as, an Xn Handover Request message, to the target gNB-CU-CP 223. For example, in case that the UE supports MBB handover, the Xn Handover Request message may include a first information element (IE) having first information related to the MBB handover for the UE. An example of the Xn Handover Request message is shown in Table 1-a. As shown, the Xn Handover Request message is extended to include an extended HandoverPreparationInformation message in, for example, a RRC context IE.

As an example, the extended HandoverPreparationInformation message is defined in subclause 11.2.2 of 3GPP TS 38.331 Release 15 (V15.2.1, June 2018) . Table 1-b shows an example of the extended HandoverPreparationInformation message.

Table 1-a: Example of Xn Handover Request message

Table 1-b: Example of extended HandoverPreparationInformation message

2. The target gNB-CU-CP 223 sends a bearer context setup request message to the target gNB-CU-UP 222, to establish a bearer context in the target gNB-CU-UP 222, upon receiving the handover request message from the source gNB-CU-CP 213. For example, the bearer context setup request message, may be an E1AP Bearer Context Setup Request message.

3. The target gNB-CU-UP 222 sends a bearer context setup response message, for example, an E1AP Bearer Context Setup Response message, to the target gNB-CU-CP 223. The E1AP Bearer Context Setup Response message may include an F1-U uplink (UL) tunnel endpoint identifier (TEID) and a transport layer address allocated by gNB-CU-UP 222.

4. An F1 UE context setup procedure between the gNB-CU-CP 223 and the target gNB-DU 221 is performed to setup one or more bearers for the UE. The UE context setup procedure is well-known to those skilled in the art, and will not be repeated herein to avoid obscuration of the present application.

5. The target gNB-CU-CP 223 sends a handover request acknowledge message, such as, Xn Handover Request Acknowledge message, to the source gNB-CU-CP 213, in response to the handover request message. For example, in case that the Xn Handover Request message includes the first information related to the MBB handover, the Xn Handover Request Acknowledge message may include a second IE having second information related to the MBB handover for the UE. An example of the Xn Handover Request Acknowledge message is shown in Table 2-a. The Xn Handover Request Acknowledge message is extended to include an extended HandoverCommand message in for example a Target NG-RAN node To Source NG-RAN node Transparent Container IE.

Table 2-a: Example of Xn Handover Request Acknowledge message

As an example, the extended HandoverCommand message is defined in subclause 11.2.2 of the 3GPP TS 38.331. Table 2-b shows an example of the extended HandoverCommand message.

Table 2-b: Example of extended HandoverCommand message

6. The source gNB-CU-CP 213 sends a UE context modification request message, such as, F1 UE Context Modification Request message, to the source gNB-DU 211, to configure the MBB handover for the UE. For example, the F1 UE Context Modification Request message may be extended to include an MBB indicator to indicate to configure the MBB handover for the UE. An example of the extended F1 UE Context Modification Request message is shown in Table 3.

Table 3: Example of extended F1 UE Context Modification Request message

7. The source gNB-DU 211 responses to the source gNB-CU-CP 213 with a UE context modification response message, for example, an F1 UE Context Modification Response message.

For example, the F1 UE Context Modification Response message may be extended to include a Make-Before-Break Confirm IE to confirm the MBB handover for the UE. A first example of the extended F1 UE Context Modification Response message is shown in Table 4-a.

Table 4-a: Example of extended F1 UE Context Modification Response message

Alternatively, the F1 UE Context Modification Response message may be extended to include a Make-Before-Break Ack. IE to accept or reject the MBB handover for the UE. A second example of the extended F1 UE Context Modification Response message is shown in Table 4-b.

Table 4-b: Example of extended F1 UE Context Modification Response message

8. The source gNB-CU-CP 213 sends an E1 Bearer Context Modification Request message to the source gNB-CU-UP 212. The E1 Bearer Context Modification Request message may include data forwarding information. The E1 Bearer Context Modification Request message may be used to configure the MBB handover for the UE. For example, the E1 Bearer Context Modification Request message may be extended to include a Make-Before-Break indicator IE, which indicates to configure the MBB handover for the UE. An example of the extended E1 Bearer Context Modification Request message is shown in Table 5.

Table 5: Example of extended E1 Bearer Context Modification Request message

In an embodiment, the source gNB-CU-CP 213 may send the F1 UE Context Modification Request message to the source gNB-DU 211 (in message flow 6) and the E1 Bearer Context Modification Request message to the source gNB-CU-UP 212 (in message flow 8) simultaneously. In another embodiment, the transmission of the F1 UE Context Modification Request message and the transmission of the E1 Bearer Context Modification Request message may happen sequentially.

9. The source gNB-CU-UP 212 responds to the source gNB-CU-CP 213 with an E1 Bearer Context Modification Response message.

10. When deciding not to schedule the UE any longer, the source gNB-DU 211 encodes and sends a downlink data delivery status (DDDS) message to the source gNB-CU-UP 212. In an embodiment, the DDDS message may stop the source gNB-CU-UP 212 from transmitting downlink (DL) packet data convergence protocol (PDCP) for the UE immediately.

Fig. 3 shows an exemplary DDDS format in accordance with some embodiments of the disclosure. In the embodiment, the source gNB-DU 211 may encode and send a user plane message to the source gNB-CU-UP 212, to stop the source gNB-CU-UP 212 from sending DL PDCP packets for the UE immediately. As an example, the user plane message may be based on the exemplary DDDS format as shown in Fig. 3, such as, by extending the Cause Value IE of the exemplary DDDS format to include for example the following values: {0=UNKNOWN, 1=RADIO LINK OUTAGE, 2=RADIO LINK RESUME, 3=UL RADIO LINK OUTAGE, 4=DL RADIO LINK OUTAGE, 5=UL RADIO LINK RESUME, 6=DL RADIO LINK RESUME, 7=UE HANDOVER, 8-228=reserved for future value extensions, 229-255=reserved for test purposes} . Specific values and corresponding meanings of the Cause Value IE are not limited to the above example, as long as any of the values can indicate a UE handover to implement the above-mentioned function of the DDDS message.

Alternatively, the user plane message may be a complete new user plane message, which includes an IE to indicate the UE handover. Fig. 4 shows an exemplary new user plane message in accordance with some embodiments of the disclosure. As can be seen in Fig. 4, the exemplary new user plane message may include a bit to indicate a UE handover, for example, the UE handover indicator. In other embodiments, the new user plane message may include one or more bits to indicate the UE handover, which is not limited in this respect.

11. In order to report a DL/UL PDCP count value, for example, the source gNB-CU-UP 212 may perform a class 2 procedure, for example, by transmitting an SN Status Transfer message to the source gNB-CU-CP 213. An example of the SN Status Transfer message is shown in Table 6-a. As shown, the SN Status Transfer message may include a PDCP UL Count IE to indicate a PDCP count for a first unacknowledged UL packet, and a PDCP DL Count IE to indicate a PDCP count for a next DL packet to be assigned.

Table 6-a: Example of SN Status Transfer message

Alternatively, in order to report a DL/UL PDCP count value, the source gNB-CU-UP 212 may perform a class 1 procedure, for example, by transmitting an E1 Bearer Context Modification Required message to the source gNB-CU-CP 213. An example of the E1 Bearer Context Modification Required message is shown in Table 6-b. As shown, the E1 Bearer Context Modification Required message may include a PDCP UL Count IE to indicate a PDCP count for a first unacknowledged UL packet, and a PDCP DL Count IE to indicate a PDCP count for a next DL packet to be assigned.

Table 6-b: Example of E1 Bearer Context Modification Required message

12. The source gNB-CU-CP 213 sends an SN Status Transfer message to the target gNB-CU-CP 223, to report DL/UL PDCP status.

13. The target gNB-CU-CP 223 sends a bearer context modification request message, such as, an E1 Bearer Context Modification Request message to the target gNB-CU-UP 222. For example, the E1 Bearer Context Modification Request message may include an F1-U downlink (DL) tunnel endpoint identifier (TEID) and a transport layer address allocated by the target gNB-DU 221, as well as the PDCP UL/DL status.

14. The target gNB-CU-UP 222 responses to the target gNB-CU-CP 223 with a bearer context modification response message, such as, an E1AP Bearer Context Modification Response message.

15. Data Forwarding may be performed from the source gNB-CU-UP 212 to the target gNB-CU-UP 222. For example, the data source gNB-CU-UP 212 may forward corresponding data received from the CN 230 to the target gNB-CU-UP 222.

16-18. A path switch procedure may be performed to update DL transport network layer (TNL) address information for the NG-U interface towards the CN 230. The path switch procedure is well-known to those skilled in the art, and will not be repeated herein to avoid obscuration of the present application.

19. The target gNB-CU-CP 223 sends an UE Context Release message to the source gNB-CU-CP 213.

20 and 22. An E1 bearer context release procedure is performed. The E1 bearer context release procedure is well-known to those skilled in the art, and will not be repeated herein to avoid obscuration of the present application.

21. An F1 UE context release procedure is performed to release the UE context in the source gNB-DU 211. The F1 UE context release procedure is well-known to those skilled in the art, and will not be repeated herein to avoid obscuration of the present application.

In the exemplary MBB handover procedure 200 of Fig. 2, the Xn Handover Request message and the Xn Handover Request Acknowledge message are extended to configure the MBB handover for the UE. For example, the source gNB-CU-CP 213 may include MBB-related information in the RRC context IE of the Xn Handover Request message, and the target gNB-CU-CP 223 may include the MBB-related information in a target gNB to source gNB transparent container of the Xn Handover Request Acknowledge message. The F1 UE Context Modification Request message is extended to configure the MBB handover for the UE at the source gNB-DU 211, which may continue transmitting/receiving data with the UE rather than stops data delivery immediately. The E1 Bearer Context Modification Request message is extended to configure the MBB handover for the UE at the source gNB-CU-UP 212, which may continue transferring data with the source gNB-DU 211 as well as the UPF of the CN 230 rather than starting forwarding data to the target gNB-CU-UP 222 immediately. The user plane message (e.g., the DDDS message) may be extended to notify the source gNB-CU-UP 212 to stop delivering DL PDCP when the source gNB-DU 211 decides not to schedule the UE any longer. After receiving the DDDS, the source gNB-CU-UP 212 may report both DL and UL PDCP count values to the source gNB-CU-CP 213 and start forwarding data to the target gNB-CU-UP 222.

Fig. 5 is a communication diagram illustrating an exemplary MBB handover procedure 500 between a source gNB 510 and a target gNB 520 in accordance with some embodiments of the disclosure. Messages are transferred among a source gNB-DU 511, a source gNB-CU-UP 512, a source gNB-CU-CP 513, a target gNB-DU 521, a target gNB-CU-UP 522, a target gNB-CU-CP 523, and a CN 530, which may be connected by various interfaces in the manner described in relation to FIG. 1. For brevity and clarity, data exchanges between a UE and the source gNB 510 (e.g., the source gNB-DU 511) or the target gNB 520 (e.g., target gNB-DU 521) are omitted, so as not to obscure the subject matter of the present application.

In an embodiment, the exemplary MBB handover procedure 500 of Fig. 5 may include following message flows.

1. The source gNB-CU-CP 513 sends a handover request message, such as, an Xn Handover Request message, to the target gNB-CU-CP 523. For example, in case that the UE supports MBB handover, the Xn Handover Request message may include a first information element (IE) having first information related to the MBB handover for the UE. The above Table 1-a provides an example of the Xn Handover Request message. As shown, the Xn Handover Request message is extended to include an extended HandoverPreparationInformation message in for example a RRC context IE. The above Table 1-b shows an example of the extended HandoverPreparationInformation message.

2. The target gNB-CU-CP 523 sends a bearer context setup request message to the target gNB-CU-UP 522, to establish a bearer context in the target gNB-CU-UP 522, upon receiving the handover request message from the source gNB-CU-CP 513. For example, the bearer context setup request message, may be an E1AP Bearer Context Setup Request message.

3. The target gNB-CU-UP 522 sends a bearer context setup response message, for example, an E1AP Bearer Context Setup Response message, to the target gNB-CU-CP 523. The E1AP Bearer Context Setup Response message may include an F1-U UL TEID and a transport layer address allocated by gNB-CU-UP 522.

4. An F1 UE context setup procedure between the gNB-CU-CP 523 and the target gNB-DU 521 is performed to setup one or more bearers for the UE. The UE context setup procedure is well-known to those skilled in the art, and will not be repeated herein to avoid obscuration of the present application.

5. The target gNB-CU-CP 523 sends a handover request acknowledge message, such as, Xn Handover Request Acknowledge message, to the source gNB-CU-CP 513, in response to the handover request message. For example, in case that the Xn Handover Request message includes the first information related to the MBB handover, the Xn Handover Request Acknowledge message may include a second IE having second information related to the MBB handover for the UE. The above Table 2-a shows an example of the Xn Handover Request Acknowledge message. As shown, the Xn Handover Request Acknowledge message is extended to include an extended HandoverCommand message in for example a Target NG-RAN node To Source NG-RAN node Transparent Container IE. The above Table 2-b shows an example of the extended Handover Command message.

6. The source gNB-CU-CP 513 sends a UE context modification request message, such as, F1 UE Context Modification Request message, to the source gNB-DU 511, to configure the MBB handover for the UE. For example, the F1 UE Context Modification Request message may be extended to include an MBB indicator to indicate to configure the MBB handover for the UE. The above Table 3 shows an example of the extended F1 UE Context Modification Request message.

7. The source gNB-DU 511 responses to the source gNB-CU-CP 513 with a UE context modification response message, for example, an F1 UE Context Modification Response message.

8. The source gNB-DU 511 sends an F1 UE Context Modification Required message to the source gNB-CU-CP 513, when deciding not to schedule the UE any longer. For example, the F1 UE Context Modification Required message may indicate completion of the MBB handover for the UE. An example of the F1 UE Context Modification Required message is shown in Table 7. As shown, the F1 UE Context Modification Required message may a break indicator to indicate that scheduling of the UE has been stopped.

Table 7: Example of F1 UE Context Modification Required message

9. In response to the F1 UE Context Modification Required message, the source gNB-CU-CP 513 sends an F1 UE Context Modification Confirm message to the source gNB-DU 511. An example of the F1 UE Context Modification Confirm message is shown in Table 8. As shown, the F1 UE Context Modification Confirm message may a break indicator to indicate that scheduling of the UE has been stopped.

10-11. A bearer context modification procedure initiated by the source gNB-CU-CP 513 is performed to stop the source gNB-CU-UP 512 from sending DL PDCP packets to the source gNB-DU 511, and enable the source gNB-CU-CP 513 to retrieve PDCP UL/DL status and exchange data forwarding information for the bearer.

12. The source gNB-CU-CP 513 sends an SN Status Transfer message to the target gNB-CU-CP 523, to report DL/UL PDCP status.

13. The target gNB-CU-CP 523 sends a bearer context modification request message, such as, an E1 Bearer Context Modification Request message to the target gNB-CU-UP 522. For example, the E1 Bearer Context Modification Request message may include an F1-U DL TEID and a transport layer address allocated by the target gNB-DU 521, as well as the PDCP UL/DL status.

14. The target gNB-CU-UP 522 responses to the target gNB-CU-CP 523 with a bearer context modification response message, such as, an E1AP Bearer Context Modification Response message.

15. Data Forwarding may be performed from the source gNB-CU-UP 512 to the target gNB-CU-UP 522. For example, the data source gNB-CU-UP 512 may forward corresponding data received from the CN 530 to the target gNB-CU-UP 522.

16-18. A path switch procedure may be performed to update DL TNL address information for the NG-U interface towards the CN 530. The path switch procedure is well-known to those skilled in the art, and will not be repeated herein to avoid obscuration of the present application.

19. The target gNB-CU-CP 523 sends an UE Context Release message to the source gNB-CU-CP 513.

21. An F1 UE context release procedure is performed to release the UE context in the source gNB-DU 511. The F1 UE context release procedure is well-known to those skilled in the art, and will not be repeated herein to avoid obscuration of the present application.

As shown, in the exemplary MBB handover procedure 500, the F1 UE Context Modification Required message may be extended to include an MBB completion indicator to notify the source gNB-CU-CP 513 that the source gNB-DU 511 has stopped scheduling the UE. The source gNB-CU-CP 513 may then initiate an E1 bearer context modification procedure, so as to stop the source gNB-CU-UP 512 from transmitting or receiving data to/from the source gNB-DU 512 for the UE.

Alternatively, in other embodiments, the F1 UE Context Modification Response message sent from the source gNB-DU 511 to the source gNB-CU-CP 513 (as shown in the message flow 7 of Fig. 5) may be extended to indicate completion of the MBB handover, in case that the source gNB-DU 511 decides not to schedule the UE any longer. As a result, the transmission of the F1 UE Context Modification Required message (in the message flow 8 of Fig. 5) and the F1 UE Context Modification Required message (in the message flow 9 of Fig. 5) may be omitted. In the embodiments, the F1 UE Context Modification Response message may be extended to include an indicator indicate that scheduling of the UE has been stopped. An example of the Context Modification Response message is shown in Table 8. As shown, the Context Modification Response message includes a break indicator to indicate that scheduling of the UE has been stopped.

Table 8: Example of F1 UE Context Modification Response message

In the exemplary MBB handover procedure 500 of Fig. 5, completion of F1 procedures triggers E1 procedures (i.e., the E1 procedures happens after the F1 procedures are completed) , while in the exemplary MBB handover procedure 200 of Fig. 2, the E1 procedures may happen simultaneously with the F1 procedures.

Fig. 6 is a communication diagram illustrating an exemplary MBB handover procedure 600 between a source gNB 610 and a target gNB 620 in accordance with some embodiments of the disclosure. Messages are transferred among a source gNB-DU 611, a source gNB-CU-UP 612, a source gNB-CU-CP 613, a target gNB-DU 621, a target gNB-CU-UP 622, a target gNB-CU-CP 623, and a CN 630, which may be connected by various interfaces in the manner described in relation to FIG. 1. For breavity and clarity, data exchanges between a UE and the source gNB 610 (e.g., the source gNB-DU 611) or the target gNB 620 (e.g., target gNB-DU 621) are omitted, so as not to obscure the subject matter of the present application.

In an embodiment, the exemplary MBB handover procedure 600 of Fig. 6 may include following message flows.

1. The source gNB-CU-CP 613 sends a handover request message, such as, an Xn Handover Request message, to the target gNB-CU-CP 623. For example, in case that the UE supports MBB handover, the Xn Handover Request message may include a first information element (IE) having first information related to the MBB handover for the UE. The above Table 1-ashows an example of the Xn Handover Request message. As shown, the Xn Handover Request message is extended to include an extended HandoverPreparationInformation message in for example a RRC context IE. The above Table 1-b shows an example of the extended HandoverPreparationInformation message.

2. The target gNB-CU-CP 623 sends a bearer context setup request message to the target gNB-CU-UP 622, to establish a bearer context in the target gNB-CU-UP 622, upon receiving the handover request message from the source gNB-CU-CP 613. For example, the bearer context setup request message, may be an E1AP Bearer Context Setup Request message.

3. The target gNB-CU-UP 622 sends a bearer context setup response message, for example, an E1AP Bearer Context Setup Response message, to the target gNB-CU-CP 623. The E1AP Bearer Context Setup Response message may include an F1-U UL TEID and a transport layer address allocated by gNB-CU-UP 622.

4. An F1 UE context setup procedure between the gNB-CU-CP 623 and the target gNB-DU 621 is performed to setup one or more bearers for the UE. The UE context setup procedure is well-known to those skilled in the art, and will not be repeated herein to avoid obscuration of the present application.

5. The target gNB-CU-CP 623 sends a handover request acknowledge message, such as, Xn Handover Request Acknowledge message, to the source gNB-CU-CP 613, in response to the handover request message. For example, in case that the Xn Handover Request message includes the first information related to the MBB handover, the Xn Handover Request Acknowledge message may include a second IE having second information related to the MBB handover for the UE. The above Table 2-ashows an example of the Xn Handover Request Acknowledge message. As shown, the Xn Handover Request Acknowledge message is extended to include an extended HandoverCommand message in for example a Target NG-RAN node To Source NG-RAN node Transparent Container IE. The above Table 2-b shows an example of the extended Handover Command message.

6. The source gNB-CU-CP 613 sends a UE context modification request message, such as, F1 UE Context Modification Request message, to the source gNB-DU 611, to configure the MBB handover for the UE. For example, the F1 UE Context Modification Request message may be extended to include an MBB indicator to indicate to configure the MBB handover for the UE. The above Table 3 shows an example of the extended F1 UE Context Modification Request message.

7. The source gNB-DU 611 responses to the source gNB-CU-CP 613 with a UE context modification response message, for example, an F1 UE Context Modification Response message.

8a. The source gNB-DU 611 sends an F1 UE Context Modification Required message to the source gNB-CU-CP 613, when deciding not to schedule the UE any longer. For example, the F1 UE Context Modification Required message may indicate completion of the MBB handover for the UE. The above Table 7 provides an example of the F1 UE Context Modification Required message. As shown, the F1 UE Context Modification Required message may a break indicator to indicate to stop scheduling of the UE.

9. In response to the F1 UE Context Modification Required message, the source gNB-CU-CP 613 sends an F1 UE Context Modification Confirm message to the source gNB-DU 611. The above table 8 provides an example of the F1 UE Context Modification Confirm message. As shown, the F1 UE Context Modification Confirm message may a break indicator to indicate that scheduling of the UE has been stopped.

8b. The source gNB-DU 611 sends a user plane message, i.e., a DDDS message, to the source gNB-CU-UP 612. In an embodiment, the DDDS message may stop the source gNB-CU-UP 612 from transmitting DL PDCP for the UE immediately. An exemplary DDDS format is provided in the above Fig. 3. As an example, the Cause Value IE of the exemplary DDDS format may be extended to include a value to indicate the UE handover.

10-11. A bearer context modification procedure initiated by the source gNB-CU-CP 613 is performed to stop the source gNB-CU-UP 612 from sending DL PDCP packets to the source gNB-DU 611, and enable the source gNB-CU-CP 613 to retrieve PDCP UL/DL status and exchange data forwarding information for the bearer.

12. The source gNB-CU-CP 613 sends an SN Status Transfer message to the target gNB-CU-CP 623, to report DL/UL PDCP status.

13. The target gNB-CU-CP 623 sends a bearer context modification request message, such as, an E1 Bearer Context Modification Request message to the target gNB-CU-UP 622. For example, the E1 Bearer Context Modification Request message may include an F1-U DL TEID and a transport layer address allocated by the target gNB-DU 621, as well as the PDCP UL/DL status.

14. The target gNB-CU-UP 622 responses to the target gNB-CU-CP 623 with a bearer context modification response message, such as, an E1AP Bearer Context Modification Response message.

15. Data Forwarding may be performed from the source gNB-CU-UP 612 to the target gNB-CU-UP 622. For example, the data source gNB-CU-UP 612 may forward corresponding data received from the CN 630 to the target gNB-CU-UP 622.

16-18. A path switch procedure may be performed to update DL TNL address information for the NG-U interface towards the CN 630. The path switch procedure is well-known to those skilled in the art, and will not be repeated herein to avoid obscuration of the present application.

19. The target gNB-CU-CP 623 sends an UE Context Release message to the source gNB-CU-CP 613.

21. An F1 UE context release procedure is performed to release the UE context in the source gNB-DU 611. The F1 UE context release procedure is well-known to those skilled in the art, and will not be repeated herein to avoid obscuration of the present application.

In an embodiment, the transmission of the DDDS message (in the message flow 8b of Fig. 6) and the transmission of the F1 UE Context Modification Required message (in the message flow 8a of Fig. 6) may happen in parallel. In another embodiment, the F1 UE Context Modification Required message and the DDDS message may be transmitted sequentially by the source gNB-DU 611.

As compared with the exemplary MBB handover procedure 500, in the exemplary MBB handover procedure 600, in addition to the control plane message (i.e., the F1 UE Context Modification Required message of message flow 8a of Fig. 6) , the user plane message (i.e., the DDDS message of message flow 8b of Fig. 6) is adopted to promptly notify the source gNB-CU-UP 612 to stop transmitting DL PDCP for the UE. According to the solution of the exemplary MBB handover procedure 600, DL data dropped by the source gNB-DU 611 may be avoided, and a waste of F1-U bandwidth may also be avoided.

Referring to Fig. 7, illustrated is a flow chart of a method 700 for performing a MBB handover for a UE, in accordance with various embodiments of the disclosure. In some aspects, the method 700 can be performed by the gNB-CU-

CP

121, 213, 513, and 613 of Fig. 1, Fig. 2, Fig. 5 and Fig. 6. In other aspects, a machine-readable storage medium may store instructions associated with method 700, which when executed can cause a gNB-CU-CP to perform the method 700. For example, the machine readable storage medium may include one or more memories of the gNB-CU-CP.

The method 700 may include, at 710, encoding a handover request message to be transmitted to a target gNB. The handover request message may be an Xn Handover Request message, for example. In an embodiment, the Xn Handover Request message may include a first IE having first information related to the MBB handover for the UE, according to an indication of an MBB handover configuration for the UE (which may be stored in, for example, one or more memories of the gNB-CU-CP) . Particularly, the handover request message may be transmitted to a target gNB-CU-CP of the target gNB.

The method 700 may include, at 720, decoding a handover request acknowledge message received from the target gNB, particularly, the target gNB-CU-CP. The handover request acknowledge message may be an Xn Handover Request Acknowledge message, for example. In an embodiment, the Xn Handover Request Acknowledge message may include a second IE having second information related to the MBB handover for the UE.

The method 700 may include, at 730, encoding a UE context modification request message to be transmitted to a gNB-DU to configure the MBB handover for the UE. The UE context modification request message may be an F1 UE Context Modification Request message, for example. In an embodiment, the F1 UE Context Modification Request message may be extended to include an MBB indicator to indicate to configure the MBB handover for the UE.

The method 700 may further include, at 740, decoding a UE context modification response message received from the gNB-DU. The UE context modification response message may be an F1 UE Context Modification Response message, for example. The F1 UE Context Modification Response message may include a Make-Before-Break Confirm IE to confirm the MBB handover for the UE. Alternatively, the F1 UE Context Modification Response message may include a Make-Before-Break Ack. IE to accept or reject the MBB handover for the UE.

Referring to Fig. 8, illustrated is a flow chart of a method 800 for performing a MBB handover for a UE, in accordance with various embodiments of the disclosure. In some aspects, the method 800 can be performed by gNB-

DU

110, 211, 511, and 611 of Fig. 1, Fig. 2, Fig. 5 and Fig. 6. In other aspects, a machine readable storage medium may store instructions associated with method 800, which when executed can cause a gNB-DU to perform the method 800. For example, the machine readable storage medium may include one or more memories of the gNB-DU.

The method 800 may include, at 810, decoding a UE context modification request message received from a gNB-CU-CP to configure the MBB handover for the UE. The UE context modification request message may be an F1 UE Context Modification Request, for example. In an embodiment, the F1 UE Context Modification Request message may be extended to include an MBB indicator to indicate to configure the MBB handover for the UE.

The method 800 may include, at 820, encoding a UE context modification response message to be transmitted to the gNB-CU-CP. The UE context modification response may be an F1 UE Context Modification Response message, for example. The F1 UE Context Modification Response message may include a Make-Before-Break Confirm IE to confirm the MBB handover for the UE. Alternatively, the F1 UE Context Modification Response message may include a Make-Before-Break Ack. IE to accept or reject the MBB handover for the UE.

In some embodiments, the MBB handover for the UE has already been initiated at a time when the gNB-CU-CP transmitted a handover request message to the target gNB. For example, the handover request message may include an IE having information related to the MBB handover for the UE. In the embodiments, the method 800 may further include, at 830, continuing transmitting or receiving data to or from the UE, until the MBB handover for the UE is completed.

Referring to Fig. 9, illustrated is a flow chart of a method 900 for performing a MBB handover for a UE, in accordance with various embodiments of the disclosure. In some aspects, the method 900 can be performed by the gNB-CU-

UP

122, 212, 512, and 612 of Fig. 1, Fig. 2, Fig. 5 and Fig. 6. In other aspects, a machine-readable storage medium may store instructions associated with method 900, which when executed can cause a gNB-CU-UP to perform the method 900. For example, the machine readable storage medium may include one or more memories of the gNB-CU-UP.

The method 900 may include, at 910, decoding a bearer context modification request message received from a gNB-CU-CP. The bearer context modification request message may be an E1 Bearer Context Modification Request message, for example. The E1 Bearer Context Modification Request message may include data forwarding information. The E1 Bearer Context Modification Request message may be used to configure the MBB handover for the UE. For example, the E1 Bearer Context Modification Request message may be extended to include a Make-Before-Break indicator IE, which indicates to configure the MBB handover for the UE.

The method 900 may include, at 920, encoding a bearer context modification response message to be transmitted to the gNB-CU-CP. The bearer context modification response message may be an E1 Bearer Context Modification Response message, for example.

In some embodiments, the MBB handover for the UE has already been initiated at a time when the gNB-CU-CP transmitted a handover request message to the target gNB. For example, the handover request message may include an IE having information related to the MBB handover for the UE. In the embodiments, the method 900 may further include, at 930, continuing transmitting DL PDCP packet to a DU of the gNB and receiving UL PDCP packet from the DU of the gNB, until the MBB handover for the UE is completed.

Fig. 10 shows an exemplary architecture of a system 1000 of a cellular network in accordance with some embodiments. In some embodiments, the system 1000 may include a UE 1002, an Authentication Server Function (AUSF) 1004, a Unified Data Management (UDM) 1006, a Core Access and Mobility Management Function (AMF) 1008, a radio access network (RAN) 1010, a Session Management Function (SMF) 1012, a Policy Control Function (PCF) 1014, an Application Function (AF) 1016, a User Plane Function (UPF) 1018, and a Data Network (DN) 1020 (e.g., operator services, Internet access or 3 ^rd party services) .

A reference point representation can show the interaction between the network function services in the network functions described by point-to-point reference points (e.g., N 11) between any two network functions (e.g., AMF and SMF) . The system 1000 can further include the following reference point representations: an Nl reference point 1022, which connects UE 1002 and AMF 1008; an N2 reference point 1024, which connects RAN 1010 and AMF 1008; an N3 reference point 1026, which connects RAN 1010 and UPF 1018; an N4 reference point 1028, which connects UPF 1018 and SMF 1012; an N5 reference point 1030, which connects PCF 1014 and AF 1016; an N6 reference point 1032, which connects UPF 1018 and DN 1020; an N7 reference point 1034, which connects SMF 1012 and PCF 1014; an N8 reference point 1036, which connects AMF 1008 and UDM 1006; an N9 reference point 1038, which connects two core UPFs 1018; an N10 reference point 1040, which connects SMF 1012 and UDM 1006; an Ni l reference point 1042, which connects AMF 1008 and SMF 1012; an N12 reference point 1044, which connects AMF 1008 and AUSF 1004; an N13 reference point 1046, which connects AUSF 1004 and UDM 1006; an N10 reference point 1048, which connects two AMFs 1008; and an N15 reference point 1050, which connects AMF 1008 and PCF 1014. A reference point may be a representation showing of the interaction that exists between the network function services.

In some embodiments, the system 1000 without the UE 1002 and RAN 1010 can be referred to as the fifth generation core network (5GC) or core network (CN) .

Fig. 11 illustrates an architecture of a system 1100 of a network, in accordance with various embodiments of the disclosure. The system 1100 is shown to include a UE 1101 and a UE 1102. The

UEs

1101 and 1102 are illustrated as smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more cellular networks) , but may also comprise any mobile or non-mobile computing device, such as Personal Data Assistants (PDAs) , pagers, laptop computers, desktop computers, wireless handsets, or any computing device including a wireless communications interface.

In some embodiments, any of the

UEs

1101 and 1102 can comprise an IoT UE, which can comprise a network access layer designed for low-power IoT applications utilizing short-lived UE connections. For example, the

UE

1101 and 1102 may operate as any of UEs 120 of Fig. 1. An IoT UE can utilize technologies such as machine-to-machine (M2M) or machine-type communications (MTC) for exchanging data with an MTC server or device via a public land mobile network (PLMN) , Proximity-Based Service (ProSe) or device-to-device (D2D) communication, sensor networks, or IoT networks. The M2M or MTC exchange of data may be a machine-initiated exchange of data. An IoT network describes interconnecting IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure) , with short-lived connections. The IoT UEs may execute background applications (e.g., keep-alive messages, status updates, etc. ) to facilitate the connections of the IoT network

The

UEs

1101 and 1102 may be configured to connect, e.g., communicatively couple, with a radio access network (RAN) 1110 -the RAN 1110 may be, for example, an Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN) , a NextGen RAN (NG RAN) , or some other type of RAN. The

UEs

1101 and 1102 utilize

connections

1103 and 1104, respectively, each of which comprises a physical communications interface or layer (discussed in further details below) ; in this example, the

connections

1103 and 1104 are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols, such as a Global System for Mobile Communications (GSM) protocol, a code-division multiple access (CDMA) network protocol, a Push-to-Talk (PTT) protocol, a PTT over Cellular (POC) protocol, a Universal Mobile Telecommunications System (UMTS) protocol, a 3GPP Long Term Evolution (LTE) protocol, a fifth generation (5G) protocol, a New Radio (NR) protocol, and the like.

In this embodiment, the

UEs

1101 and 1102 may further directly exchange communication data via a ProSe interface 1105. The ProSe interface 1105 may alternatively be referred to as a sidelink interface comprising one or more logical channels, including but not limited to a Physical Sidelink Control Channel (PSCCH) , a Physical Sidelink Shared Channel (PSSCH) , a Physical Sidelink Discovery Channel (PSDCH) , and a Physical Sidelink Broadcast Channel (PSBCH) .

The UE 1102 is shown to be configured to access an access point (AP) 1106 via connection 1107. The connection 1107 can comprise a local wireless connection, such as a connection consistent with any IEEE 802.11 protocol, wherein the AP 1106 would comprise a wireless fidelity

router. In this example, the AP 1106 is shown to be connected to the Internet without connecting to the core network of the wireless system (described in further details below) .

The RAN 1110 can include one or more access nodes that enable the

connections

1103 and 1104. These access nodes (ANs) can be referred to as base stations (BSs) , NodeBs, evolved NodeBs (eNBs) , next Generation NodeBs (gNB) , RAN nodes, and so forth, and can comprise ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell) . The RAN 1110 may include one or more RAN nodes for providing macrocells, e.g., macro RAN node 1111, and one or more RAN nodes for providing femtocells or picocells (e.g., cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells) , e.g., low power (LP) RAN node 1112.

Any of the RAN nodes 1111 and 1112 can terminate the air interface protocol and can be the first point of contact for the

UEs

1101 and 1102. In some embodiments, any of the RAN nodes 1111 and 1112 can fulfill various logical functions for the RAN 1110 including, but not limited to, radio network controller (RNC) functions such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.

In accordance with some embodiments, the

UEs

1101 and 1102 can be configured to communicate using Orthogonal Frequency-Division Multiplexing (OFDM) communication signals with each other or with any of the RAN nodes 1111 and 1112 over a multicarrier communication channel in accordance various communication techniques, such as, but not limited to, an Orthogonal Frequency-Division Multiple Access (OFDMA) communication technique (e.g., for downlink communications) or a Single Carrier Frequency Division Multiple Access (SC-FDMA) communication technique (e.g., for uplink and ProSe or sidelink communications) , although the scope of the embodiments is not limited in this respect. The OFDM signals can comprise a plurality of orthogonal subcarriers.

In some embodiments, a downlink resource grid can be used for downlink transmissions from any of the RAN nodes 1111 and 1112 to the

UEs

1101 and 1102, while uplink transmissions can utilize similar techniques. The grid can be a time-frequency grid, called a resource grid or time-frequency resource grid, which is the physical resource in the downlink in each slot. Such a time-frequency plane representation is a common practice for OFDM systems, which makes it intuitive for radio resource allocation. Each column and each row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in a radio frame. The smallest time-frequency unit in a resource grid is denoted as a resource element. Each resource grid comprises a number of resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block comprises a collection of resource elements; in the frequency domain, this may represent the smallest quantity of resources that currently can be allocated. There are several different physical downlink channels that are conveyed using such resource blocks.

The physical downlink shared channel (PDSCH) may carry user data and higher-layer signaling to the

UEs

1101 and 1102. The physical downlink control channel (PDCCH) may carry information about the transport format and resource allocations related to the PDSCH channel, among other things. It may also inform the

UEs

1101 and 1102 about the transport format, resource allocation, and H-ARQ (Hybrid Automatic Repeat Request) information related to the uplink shared channel. Typically, downlink scheduling (assigning control and shared channel resource blocks to the UE 102 within a cell) may be performed at any of the RAN nodes 1111 and 1112 based on channel quality information fed back from any of the

UEs

1101 and 1102. The downlink resource assignment information may be sent on the PDCCH used for (e.g., assigned to) each of the

UEs

1101 and 1102.

The PDCCH may use control channel elements (CCEs) to convey the control information. Before being mapped to resource elements, the PDCCH complex-valued symbols may first be organized into quadruplets, which may then be permuted using a sub-block interleaver for rate matching. Each PDCCH may be transmitted using one or more of these CCEs, where each CCE may correspond to nine sets of four physical resource elements known as resource element groups (REGs) . Four Quadrature Phase Shift Keying (QPSK) symbols may be mapped to each REG. The PDCCH can be transmitted using one or more CCEs, depending on the size of the downlink control information (DCI) and the channel condition. There can be four or more different PDCCH formats defined in LTE with different numbers of CCEs (e.g., aggregation level, L=1, 2, 4, or 8) .

Some embodiments may use concepts for resource allocation for control channel information that are an extension of the above-described concepts. For example, some embodiments may utilize an enhanced physical downlink control channel (ePDCCH) that uses PDSCH resources for control information transmission. The ePDCCH may be transmitted using one or more enhanced the control channel elements (eCCEs) . Similar to above, each eCCE may correspond to nine sets of four physical resource elements known as an enhanced resource element groups (eREGs) . An eCCE may have other numbers of eREGs in some situations.

The RAN 1110 is shown to be communicatively coupled to a core network (CN) 1120 -via an S1 interface 1113. In embodiments, the CN 1120 may be an evolved packet core (EPC) network, a NextGen Packet Core (NPC) network, or some other type of CN. In this embodiment the S1 interface 1113 is split into two parts: the S1-U interface 1114, which carries traffic data between the RAN nodes 1111 and 1112 and the serving gateway (S-GW) 1122, and the S1- mobility management entity (MME) interface 1115, which is a signaling interface between the RAN nodes 1111 and 1112 and MMEs 1121.

In this embodiment, the CN 1120 comprises the MMEs 1121, the S-GW 1122, the Packet Data Network (PDN) Gateway (P-GW) 1123, and a home subscriber server (HSS) 1124. The MMEs 1121 may be similar in function to the control plane of legacy Serving General Packet Radio Service (GPRS) Support Nodes (SGSN) . The MMEs 1121 may manage mobility aspects in access such as gateway selection and tracking area list management. The HSS 1124 may comprise a database for network users, including subscription-related information to support the network entities’ handling of communication sessions. The CN 1120 may comprise one or several HSSs 1124, depending on the number of mobile subscribers, on the capacity of the equipment, on the organization of the network, etc. For example, the HSS 1124 can provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, etc.

The S-GW 1122 may terminate the S1 interface 1113 towards the RAN 1110, and routes data packets between the RAN 1110 and the CN 1120. In addition, the S-GW 1122 may be a local mobility anchor point for inter-RAN node handovers and also may provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful intercept, charging, and some policy enforcement.

The P-GW 1123 may terminate an SGi interface toward a PDN. The P-GW 1123 may route data packets between the EPC network 1123 and external networks such as a network including the application server 1130 (alternatively referred to as application function (AF) ) via an Internet Protocol (IP) interface 1125. Generally, the application server 1130 may be an element offering applications that use IP bearer resources with the core network (e.g., UMTS Packet Services (PS) domain, LTE PS data services, etc. ) . In this embodiment, the P-GW 1123 is shown to be communicatively coupled to an application server 1130 via an IP communications interface 1125. The application server 1130 can also be configured to support one or more communication services (e.g., Voice-over-Internet Protocol (VoIP) sessions, PTT sessions, group communication sessions, social networking services, etc. ) for the

UEs

1101 and 1102 via the CN 1120.

The P-GW 1123 may further be a node for policy enforcement and charging data collection. Policy and Charging Enforcement Function (PCRF) 1126 is the policy and charging control element of the CN 1120. In a non-roaming scenario, there may be a single PCRF in the Home Public Land Mobile Network (HPLMN) associated with a UE’s Internet Protocol Connectivity Access Network (IP-CAN) session. In a roaming scenario with local breakout of traffic, there may be two PCRFs associated with a UE’s IP-CAN session: a Home PCRF (H-PCRF) within a HPLMN and a Visited PCRF (V-PCRF) within a Visited Public Land Mobile Network (VPLMN) . The PCRF 1126 may be communicatively coupled to the application server 1130 via the P-GW 1123. The application server 1130 may signal the PCRF 1126 to indicate a new service flow and select the appropriate Quality of Service (QoS) and charging parameters. The PCRF 1126 may provision this rule into a Policy and Charging Enforcement Function (PCEF) (not shown) with the appropriate traffic flow template (TFT) and QoS class of identifier (QCI) , which commences the QoS and charging as specified by the application server 1130.

Embodiments described herein may be implemented into a system using any suitably configured hardware and/or software. Fig. 12 illustrates exemplary components of a device 1200, in accordance with various embodiments of the disclosure. In embodiments, the device 1200 may be, implement, be incorporated into, or otherwise be a part of the gNB 100 of Fig. 1, or some other electronic devices. In some embodiments, the device 1200 may include application circuitry 1202, baseband circuitry 1204, Radio Frequency (RF) circuitry 1206, front-end module (FEM) circuitry 1208, one or more antennas 1210, and power management circuitry (PMC) 1212 coupled together at least as shown. The components of the illustrated device 1200 may be included in a UE or a RAN node. In some embodiments, the device 1200 may include less elements (e.g., a RAN node may not utilize application circuitry 1202, and instead include a processor/controller to process IP data received from an EPC) . In some embodiments, the device 1200 may include additional elements such as, for example, memory/storage, display, camera, sensor, or input/output (I/O) interface. In other embodiments, the components described below may be included in more than one device (e.g., said circuitries may be separately included in more than one device for Cloud-RAN (C-RAN) implementations) .

The application circuitry 1202 may include one or more application processors. For example, the application circuitry 1202 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor (s) may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc. ) . The processors may be coupled with or may include memory/storage and may be configured to execute instructions stored in the memory/storage to enable various applications or operating systems to run on the device 1200. In some embodiments, processors of application circuitry 1202 may process IP data packets received from an EPC.

The baseband circuitry 1204 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 1204 may include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 1206 and to generate baseband signals for a transmit signal path of the RF circuitry 1206. Baseband circuitry 1204 may interface with the application circuitry 1202 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 1206. For example, in some embodiments, the baseband circuitry 1204 may include a third generation (3G) baseband processor 1204A, a fourth generation (4G) baseband processor 1204B, a fifth generation (5G) baseband processor 1204C, or other baseband processor (s) 1204D for other existing generations, generations in development or to be developed in the future (e.g., second generation (2G) , sixth generation (6G) , etc. ) . The baseband circuitry 1204 (e.g., one or more of baseband processors 1204A-D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 1206. In other embodiments, some or all of the functionality of baseband processors 1204A-D may be included in modules stored in the memory 1204G and executed via a Central Processing Unit (CPU) 1204E. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, etc. In an embodiment, the memory 1204G may store configurations of frames, for examples, the frames designed as described above in Figs. 2A-8.

In some embodiments, modulation/demodulation circuitry of the baseband circuitry 1204 may include Fast-Fourier Transform (FFT) , precoding, or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 1204 may include convolution, tail-biting convolution, turbo, Viterbi, or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments.

In some embodiments, the baseband circuitry 1204 may include one or more audio digital signal processor (s) (DSP (s) ) 1204F. The audio DSP (s) 1204F may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments. Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry 1204 and the application circuitry 1202 may be implemented together such as, for example, on a system on a chip (SOC) .

In some embodiments, the baseband circuitry 1204 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 1204 may support communication with an evolved universal terrestrial radio access network (EUTRAN) or other wireless metropolitan area networks (WMAN) , a wireless local area network (WLAN) , a wireless personal area network (WPAN) . Embodiments in which the baseband circuitry 1204 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

RF circuitry 1206 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 1206 may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. RF circuitry 1206 may include a receive signal path which may include circuitry to down-convert RF signals received from the FEM circuitry 1208 and provide baseband signals to the baseband circuitry 1204. RF circuitry 1206 may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry 1204 and provide RF output signals to the FEM circuitry 1208 for transmission.

In some embodiments, the receive signal path of the RF circuitry 1206 may include mixer circuitry 1206A, amplifier circuitry 1206B and filter circuitry 1206C. In some embodiments, the transmit signal path of the RF circuitry 1206 may include filter circuitry 1206C and mixer circuitry 1206A. RF circuitry 1206 may also include synthesizer circuitry 1206D for synthesizing a frequency for use by the mixer circuitry 1206A of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 1206A of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 1208 based on the synthesized frequency provided by synthesizer circuitry 1206D. The amplifier circuitry 1206B may be configured to amplify the down-converted signals and the filter circuitry 1206C may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals may be provided to the baseband circuitry 1204 for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 1206A of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 1206A of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 1206D to generate RF output signals for the FEM circuitry 1208. The baseband signals may be provided by the baseband circuitry 1204 and may be filtered by filter circuitry 1206C.

In some embodiments, the mixer circuitry 1206A of the receive signal path and the mixer circuitry 1206A of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and upconversion, respectively. In some embodiments, the mixer circuitry 1206A of the receive signal path and the mixer circuitry 1206A of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection) . In some embodiments, the mixer circuitry 1206A of the receive signal path and the mixer circuitry 1206A may be arranged for direct downconversion and direct upconversion, respectively. In some embodiments, the mixer circuitry 1206A of the receive signal path and the mixer circuitry 1206A of the transmit signal path may be configured for super-heterodyne operation.

In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In these alternate embodiments, the RF circuitry 1206 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 1204 may include a digital baseband interface to communicate with the RF circuitry 1206.

In some dual-mode embodiments, a separate radio IC circuitry may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect.

In some embodiments, the synthesizer circuitry 1206D may be a fractional-N synthesizer or a fractional N/N+1 synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 1206D may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

The synthesizer circuitry 1206D may be configured to synthesize an output frequency for use by the mixer circuitry 1206A of the RF circuitry 1206 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 1206D may be a fractional N/N+1 synthesizer.

In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO) , although that is not a requirement. Divider control input may be provided by either the baseband circuitry 1204 or the applications processor 1202 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a look-up table based on a channel indicated by the applications processor 1202.

Synthesizer circuitry 1206D of the RF circuitry 1206 may include a divider, a delay-locked loop (DLL) , a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DPA) . In some embodiments, the DMD may be configured to divide the input signal by either N or N+1 (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into N _d equal packets of phase, where N _d is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, synthesizer circuitry 1206D may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (fLO) . In some embodiments, the RF circuitry 1206 may include an IQ/polar converter.

FEM circuitry 1208 may include a receive signal path which may include circuitry configured to operate on RF signals received from one or more antennas 1210, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 1206 for further processing. FEM circuitry 1208 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 1206 for transmission by one or more of the one or more antennas 1210. In various embodiments, the amplification through the transmit or receive signal paths may be done solely in the RF circuitry 1206, solely in the FEM 1208, or in both the RF circuitry 1206 and the FEM 1208.

In some embodiments, the FEM circuitry 1208 may include a TX/RX switch to switch between transmit mode and receive mode operation. The FEM circuitry may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry may include an LNA to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 1206) . The transmit signal path of the FEM circuitry 1208 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 1206) , and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 1210) .

In some embodiments, the PMC 1212 may manage power provided to the baseband circuitry 1204. In particular, the PMC 1212 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion. The PMC 1212 may often be included when the device 1200 is capable of being powered by a battery, for example, when the device is included in a UE. The PMC 1212 may increase the power conversion efficiency while providing desirable implementation size and heat dissipation characteristics.

While Fig. 12 shows the PMC 1212 coupled only with the baseband circuitry 1204. However, in other embodiments, the PMC 12 12 may be additionally or alternatively coupled with, and perform similar power management operations for, other components such as, but not limited to, application circuitry 1202, RF circuitry 1206, or FEM 1208.

In some embodiments, the PMC 1212 may control, or otherwise be part of, various power saving mechanisms of the device 1200. For example, if the device 1200 is in an RRC_Connected state, where it is still connected to the RAN node as it expects to receive traffic shortly, then it may enter a state known as Discontinuous Reception Mode (DRX) after a period of inactivity. During this state, the device 1200 may power down for brief intervals of time and thus save power.

If there is no data traffic activity for an extended period of time, then the device 1200 may transition off to an RRC_Idle state, where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The device 1200 goes into a very low power state and it performs paging where again it periodically wakes up to listen to the network and then powers down again. The device 1200 may not receive data in this state, in order to receive data, it must transition back to RRC_Connected state.

An additional power saving mode may allow a device to be unavailable to the network for periods longer than a paging interval (ranging from seconds to a few hours) . During this time, the device is totally unreachable to the network and may power down completely. Any data sent during this time incurs a large delay and it is assumed the delay is acceptable.

Processors of the application circuitry 1202 and processors of the baseband circuitry 1204 may be used to execute elements of one or more instances of a protocol stack. For example, processors of the baseband circuitry 1204, alone or in combination, may be used execute Layer 3, Layer 2, or Layer 1 functionality, while processors of the application circuitry 1204 may utilize data (e.g., packet data) received from these layers and further execute Layer 4 functionality (e.g., transmission communication protocol (TCP) and user datagram protocol (UDP) layers) . As referred to herein, Layer 3 may comprise a radio resource control (RRC) layer. As referred to herein, Layer 2 may comprise a medium access control (MAC) layer, a radio link control (RLC) layer, and a packet data convergence protocol (PDCP) layer. As referred to herein, Layer 1 may comprise a physical (PHY) layer of a UE/RAN node.

In some embodiments, the 1200 of Fig. 12 may be configured to perform one or more processes, techniques, or methods as described herein, or portions thereof. For example, the device 1200 may perform operations described in Figs. 7-9.

Fig. 13 illustrates exemplary interfaces of baseband circuitry, in accordance with various embodiments of the disclosure. As discussed above, the baseband circuitry 1204 of Fig. 12 may comprise processors 1204A-1204E and a memory 1204G utilized by said processors. Each of the processors 1204A-1204E may include a memory interface, 1304A-1304E, respectively, to send/receive data to/from the memory 1204G.

The baseband circuitry 1204 may further include one or more interfaces to communicatively couple to other circuitries/devices, such as a memory interface 1312 (e.g., an interface to send/receive data to/from memory external to the baseband circuitry 1204) , an application circuitry interface 1314 (e.g., an interface to send/receive data to/from the application circuitry 1202 of Fig. 12) , an RF circuitry interface 1316 (e.g., an interface to send/receive data to/from RF circuitry 1206 of Fig. 12) , a wireless hardware connectivity interface 1318 (e.g., an interface to send/receive data to/from Near Field Communication (NFC) components,

components (e.g.,

Low Energy) ,

components, and other communication components) , and a power management interface 1320 (e.g., an interface to send/receive power or control signals to/from the PMC 1212) .

Fig. 14 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein. Specifically, Fig. 14 shows a diagrammatic representation of hardware resources 1400 including one or more processors (or processor cores) 1410, one or more memory/storage devices 1420, and one or more communication resources 1430, each of which may be communicatively coupled via a bus 1440. For embodiments where node virtualization (e.g., NFV) is utilized, a hypervisor 1402 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize the hardware resources 1400.

The processors 1410 (e.g., a central processing unit (CPU) , a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU) , a digital signal processor (DSP) such as a baseband processor, an application specific integrated circuit (ASIC) , a radio-frequency integrated circuit (RFIC) , another processor, or any suitable combination thereof) may include, for example, a processor 1412 and a processor 1414.

The memory/storage devices 1420 may include main memory, disk storage, or any suitable combination thereof. The memory/storage devices 1420 may include, but are not limited to any type of volatile or non-volatile memory such as dynamic random access memory (DRAM) , static random-access memory (SRAM) , erasable programmable read-only memory (EPROM) , electrically erasable programmable read-only memory (EEPROM) , Flash memory, solid-state storage, etc.

The communication resources 1430 may include interconnection or network interface components or other suitable devices to communicate with one or more peripheral devices 1404 or one or more databases 1406 via a network 1408. For example, the communication resources 1430 may include wired communication components (e.g., for coupling via a Universal Serial Bus (USB) ) , cellular communication components, NFC components,

components (e.g.,

Low Energy) ,

components, and other communication components.

Instructions 1450 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 1410 to perform any one or more of the methodologies discussed herein. The instructions 1450 may reside, completely or partially, within at least one of the processors 1410 (e.g., within the processor’s cache memory) , the memory/storage devices 1420, or any suitable combination thereof. Furthermore, any portion of the instructions 1450 may be transferred to the hardware resources 1400 from any combination of the peripheral devices 1404 or the databases 1406. Accordingly, the memory of processors 1410, the memory/storage devices 1420, the peripheral devices 1404, and the databases 1406 are examples of computer-readable and machine-readable media.

In embodiments in which the hardware resources 1400 are incorporated into the gNB-CU-

CP

121, 213, 513, and 613 of Fig. 1, Fig. 2, Fig. 5 and Fig. 6, the instructions 1450 may cause the processors 1410 to perform the method 700 as shown in the flow charts of Fig. 7.

In embodiments in which the hardware resources 1400 are incorporated into the gNB-

DU

110, 211, 511, and 611 of Fig. 1, Fig. 2, Fig. 5 and Fig. 6, the instructions 1450 may cause the processors 1410 to perform the method 800 as shown in the flow charts of Fig. 8.

UP

122, 212, 512, and 612 of Fig. 1, Fig. 2, Fig. 5 and Fig. 6, the instructions 1450 may cause the processors 1410 to perform the method 900 as shown in the flow charts of Fig. 9.

The resources described in Fig. 14 may also be referred to as circuitry. For example, communication resources 1430 may also be referred to as communication circuitry 1430.

Some non-limiting examples are provided below. Each of the examples stands as an embodiment itself.

Example 1 includes a central unit control plane (CU-CP) of a next generation Node B (gNB) . The gNB is operable to perform a handover for a user equipment (UE) to a target gNB. The CU-CP of the gNB comprises a memory to store an indication of a make-before-break (MBB) handover configuration for the UE; and processor circuitry to access the memory via one or more memory interfaces. The processor circuitry is to: encode a handover request message to be transmitted to the target gNB, the handover request message to include, based on the indication of the MBB handover configuration for the UE, a first information element (IE) having first information related to an MBB handover for the UE; decode a handover request acknowledge message received from the target gNB, the handover request acknowledge message to include a second IE having second information related to the MBB handover for the UE; encode a UE context modification request message to be transmitted to a distributed unit (DU) of the gNB to configure the MBB handover for the UE; and decode a UE context modification response message received from the DU of the gNB.

Example 2 may include the CU-CP of the gNB of example 1, wherein the first IE is a radio resource control (RRC) context IE, and the first information related to the MBB handover is to include an extended HandoverPreparationInformation message.

Example 3 may include the CU-CP of the gNB of examples 1 or 2, wherein the second IE is a target next generation radio access network (NG-RAN) node to source NG-RAN node transparent container, and the second information related to the MBB handover is to include an extended HandoverCommand message.

Example 4 may include the CU-CP of the gNB of any of examples 1-3, wherein the UE context modification request message is to include an MBB indicator to indicate to configure the MBB handover for the UE; and wherein the UE context modification response message is to include a Make-Before-Break Confirm IE to confirm the MBB handover for the UE, or a Make-Before-Break Ack. IE to accept or reject the MBB handover for the UE.

Example 5 may include the CU-CP of the gNB of any of examples 1-4, wherein the processor circuitry is further to encode a bearer context modification request message to be transmitted to a central unit user plane (CU-UP) of the gNB, the bearer context modification request message is to include information for data forwarding and is to configure the MBB handover for the UE; and decode a bearer context modification response message received from the CU-UP of the gNB.

Example 6 may include the CU-CP of the gNB of example 5, wherein the bearer context modification request message is to include an MBB indicator to indicate to configure the MBB handover for the UE.

Example 7 may include the CU-CP of the gNB of example 5, wherein the processor circuitry is to encode the UE context modification request message and the bearer context modification request message simultaneously.

Example 8 may include the CU-CP of the gNB of example 5, wherein the processor circuitry is further to: decode a sequence number (SN) status transfer message or a bearer context modification required message received from the CU-UP of the gNB, to obtain a uplink (UL) packet data convergence protocol (PDCP) count and a downlink (DL) PDCP count; wherein each of the SN status transfer message and the bearer context modification required message is to include a PDCP UL Count IE to indicate a PDCP count for a first unacknowledged UL packet, and a PDCP DL Count IE to indicate a PDCP count for a next DL packet to be assigned.

Example 9 may include the CU-CP of the gNB of any of examples 1-8, wherein the processor circuitry is further to: decode a UE context modification required message received from the DU of the gNB, the UE context modification required message is to indicate completion of the MBB handover for the UE; and encode a UE context modification confirm message to be transmitted to the DU of the gNB; wherein the UE context modification required message is to include a break indicator to indicate that scheduling of the UE has been stopped.

Example 10 may include the CU-CP of the gNB of example 9, wherein the processor circuitry is further to: initiate a bearer context modification procedure with the a central unit user plane (CU-UP) of the gNB, to stop the CU-UP of the gNB from sending a downlink packet data convergence protocol (PDCP) packet to the DU of the gNB.

Example 11 may include the CU-CP of the gNB of example 10, wherein the processor circuitry is further to: retrieve a downlink (DL) /uplink (UL) packet data convergence protocol (PDCP) status of a bearer between the CU-UP of the gNB and the CU-CP of the gNB; and exchange data forwarding information for the bearer.

Example 12 may include the CU-CP of the gNB of example 1, wherein the UE context modification response message is to include a break indicator to indicate that scheduling of the UE has been stopped.

Example 13 includes a distributed unit (DU) of a next generation Node B (gNB) . The gNB is operable to perform a handover for a user equipment (UE) to a target gNB. The DU of the gNB comprises a memory to store instructions for performing a make-before-break (MBB) handover for the UE; and processor circuitry to access the memory via one or more memory interfaces. The processor circuitry, when executing the instructions for performing the MBB handover for the UE, is to: decode a UE context modification request message received from a central unit control plane (CU-CP) of the gNB to configure the MBB handover for the UE; encode a UE context modification response message to be transmitted to the CU-CP of the gNB; wherein the MBB handover for the UE has already been initiated at a time when the CU-CP of the gNB transmitted a handover request message to the target gNB, the handover request message to include an information element (IE) having information related to the MBB handover for the UE; and continue transmitting or receiving data with the UE, until the MBB handover for the UE is completed.

Example 14 may include the DU of the gNB of example 13, wherein the UE context modification request message is to include an MBB indicator to indicate to configure the MBB handover for the UE; and wherein the UE context modification response message is to include a Make-Before-Break Confirm IE to confirm the MBB handover, or a Make-Before-Break Ack. IE to accept or reject the MBB handover.

Example 15 may include the DU of the gNB of examples 14 or 15, wherein the processor circuitry is further to: encode a UE context modification required message to be transmitted to the CU-CP of the gNB, the UE context modification required message indicates completion of the MBB handover for the UE; and decode a UE context modification confirm message received from the CU-CP of the gNB; wherein the UE context modification required message is to include a break indicator to indicate that scheduling of the UE has been stopped.

Example 16 may include the DU of the gNB of examples of any of examples 13-15, wherein the processor circuitry is further to: encode, based on a downlink data delivery status (DDDS) message, a user plane message to be transmitted to a central unit user plane (CU-UP) of the gNB, to stop the CU-UP of the gNB from transmitting DL PDCP for the UE immediately; wherein encoding the user plane message based on the DDDS message is to include extending a cause value IE of the DDDS message to include a value to indicate a UE handover.

Example 17 may include the DU of the gNB of example 16, wherein the processor circuitry is to encode the UE context modification required message and the user plane message in parallel.

Example 18 may include the DU of the gNB of example 13, wherein the UE context modification response message is to include a break indicator to indicate that scheduling of the UE has been stopped.

Example 19 includes a central unit user plane (CU-UP) of a next generation Node B (gNB) . The gNB is operable to perform a handover for a user equipment (UE) to a target Gnb. the CU-UP of the gNB comprises a memory to store instructions for performing a make-before-break (MBB) handover for the UE; and processor circuitry to access the memory via one or more memory interfaces. The processor circuitry, when executing the instructions for performing the MBB handover for the UE, is to: decode a bearer context modification request message received from a central unit control plane (CU-CP) of the gNB, the bearer context modification request message to include information for data forwarding and is to configure the MBB handover for the UE; encode a bearer context modification response message to be transmitted to the CU-CP of the gNB; wherein the MBB handover for the UE has already been initiated at a time when the CU-CP of the gNB transmitted a handover request message to the target gNB, the handover request message to include an information element (IE) having information related to the MBB handover for the UE; and continue transmitting a downlink (DL) packet data convergence protocol (PDCP) packet to a distributed unit (DU) of the gNB and receiving uplink (UL) PDCP packet from the DU of the gNB, until the MBB handover for the UE is completed.

Example 20 may include the CU-UP of the gNB of example 19, wherein the bearer context modification request message is to include an MBB indicator to indicate to configure the MBB handover for the UE.

Example 21 may include the CU-UP of the gNB of examples 19 or 20, wherein the processor circuitry is further to: decode a downlink data delivery status (DDDS) message based user plane message received from the DU of the gNB, the DDDS message based user plane message is to stop the CU-UP of the gNB from transmitting a DL PDCP packet for the UE immediately; wherein a cause value IE of the DDDS message is extended to include a value to indicate a UE handover.

Example 22 may include the CU-UP of the gNB of any of examples 19-21, wherein the processor circuitry is further to: encode a sequence number (SN) status transfer message or a bearer context modification required message to be transmitted to the CU-CP of the gNB, to indicate a UL PDCP count and a DL PDCP count; wherein each of the SN status transfer message and the bearer context modification required message is to include a PDCP UL Count IE to indicate a PDCP count for a first unacknowledged UL packet, and a PDCP DL Count IE to indicate a PDCP count for a next DL packet to be assigned.

Example 23 includes a computer-readable storage medium having instructions stored thereon, which when executed cause a distributed unit (DU) of a next generation Node B (gNB) to: decode a UE context modification request message received from a central unit control plane (CU-CP) of the gNB to configure a make-before-break (MBB) handover for the UE; encode a UE context modification response message to be transmitted to the CU-CP of the gNB; and encode, based on a downlink data delivery status (DDDS) message, a user plane message to be transmitted to a central unit user plane (CU-UP) of the gNB, to stop the CU-UP of the gNB from transmitting DL PDCP for the UE immediately.

Example 24 may include the computer-readable storage medium of example 23, wherein the DU of the gNB is to encode the user plane message by extending a cause value IE of the DDDS message to include a value to indicate a UE handover.

Example 25 may include the computer-readable storage medium of examples 23 or 24, wherein the UE context modification request message is to include an MBB indicator to indicate to configure the MBB handover for the UE; and wherein the UE context modification response message is to include a Make-Before-Break Confirm IE to confirm the MBB handover; or a Make-Before-Break Ack. IE to accept or reject the MBB handover.

Example 26 includes a method for performing a make-before-break (MBB) handover for a user equipment (UE) . The method is to be performed by a central unit control plane (CU-CP) of a next generation Node B (gNB) . The method comprises: encoding a handover request message to be transmitted to a target gNB, the handover request message to include a first information element (IE) having first information related to the MBB handover for the UE; decoding a handover request acknowledge message received from the target gNB, the handover request acknowledge message to include a second IE having second information related to the MBB handover for the UE; encoding a UE context modification request message to be transmitted to a distributed unit (DU) of the gNB to configure the MBB handover for the UE; and decoding a UE context modification response message received from the DU of the gNB.

Example 27 may include the method of example 26, wherein the first IE is a radio resource control (RRC) context IE, and the first information related to the MBB handover is to include an extended HandoverPreparationInformation message.

Example 28 may include the method of examples 26 or 27, wherein the second IE is a target next generation radio access network (NG-RAN) node to source NG-RAN node transparent container, and the second information related to the MBB handover is to include an extended HandoverCommand message.

Example 29 may include the method of any of examples 26-28, wherein the UE context modification request message is to include an MBB indicator to indicate to configure the MBB handover for the UE; and wherein the UE context modification response message is to include a Make-Before-Break Confirm IE to confirm the MBB handover for the UE, or a Make-Before-Break Ack. IE to accept or reject the MBB handover for the UE.

Example 30 may include the method of any of examples 26-29, further comprising: encoding a bearer context modification request message to be transmitted to a central unit user plane (CU-UP) of the gNB, the bearer context modification request message is to include information for data forwarding and is to configure the MBB handover for the UE; and decoding a bearer context modification response message received from the CU-UP of the gNB.

Example 31 may include the method of example 30, wherein the bearer context modification request message is to include an MBB indicator to indicate to configure the MBB handover for the UE.

Example 32 may include the method of example 30, further comprising encoding the UE context modification request message and the bearer context modification request message simultaneously.

Example 33 may include the method of example 30, further comprising: decoding a sequence number (SN) status transfer message or a bearer context modification required message received from the CU-UP of the gNB, to obtain a uplink (UL) packet data convergence protocol (PDCP) count and a downlink (DL) PDCP count; wherein each of the SN status transfer message and the bearer context modification required message is to include a PDCP UL Count IE to indicate a PDCP count for a first unacknowledged UL packet, and a PDCP DL Count IE to indicate a PDCP count for a next DL packet to be assigned.

Example 34 may include the method of any of examples 26-33, further comprising: decoding a UE context modification required message received from the DU of the gNB, the UE context modification required message is to indicate completion of the MBB handover for the UE; and encoding a UE context modification confirm message to be transmitted to the DU of the gNB; wherein the UE context modification required message is to include a break indicator to indicate that scheduling of the UE has been stopped.

Example 35 may include the method of example 34, further comprising: initiating a bearer context modification procedure with the a central unit user plane (CU-UP) of the gNB, to stop the CU-UP of the gNB from sending a downlink packet data convergence protocol (PDCP) packet to the DU of the gNB.

Example 36 may include the method of example 35, further comprising: retrieving a downlink (DL) /uplink (UL) packet data convergence protocol (PDCP) status of a bearer between the CU-UP of the gNB and the CU-CP of the gNB; and exchanging data forwarding information for the bearer.

Example 37 may include the method of example 26, wherein the UE context modification response is to include a break indicator to indicate that scheduling of the UE has been stopped.

Example 38 includes a method for performing a make-before-break (MBB) handover for a user equipment (UE) . The method is to be performed by a distributed unit (DU) of a next generation Node B (gNB) . The method comprises: decoding a UE context modification request message received from a central unit control plane (CU-CP) of the gNB to configure the MBB handover for the UE; encoding a UE context modification response message to be transmitted to the CU-CP of the gNB; wherein the MBB handover for the UE has already been initiated at a time when the CU-CP of the gNB transmitted a handover request message to a target gNB, the handover request message to include an information element (IE) having information related to the MBB handover for the UE; and continue transmitting or receiving data with the UE, until the MBB handover for the UE is completed.

Example 39 may include the method of example 38, wherein the UE context modification request message is to include an MBB indicator to indicate to configure the MBB handover for the UE; and wherein the UE context modification response message is to include a Make-Before-Break Confirm IE to confirm the MBB handover, or a Make-Before-Break Ack. IE to accept or reject the MBB handover.

Example 40 may include the method of examples 38 or 39, further comprising: encoding a UE context modification required message to be transmitted to the CU-CP of the gNB, the UE context modification required message indicates completion of the MBB handover for the UE; and decoding a UE context modification confirm message received from the CU-CP of the gNB; wherein the UE context modification required message is to include a break indicator to indicate that scheduling of the UE has been stopped.

Example 41 may include the method of any of examples 38 to 40, further comprising: encoding, based on a downlink data delivery status (DDDS) message, a user plane message to be transmitted to a central unit user plane (CU-UP) of the gNB, to stop the CU-UP of the gNB from transmitting DL PDCP for the UE immediately; wherein encoding the user plane message based on the DDDS message including extending a cause value IE of the DDDS message is to include a value to indicate a UE handover.

Example 42 may include the method of example 41, further comprising encoding the UE context modification required message and the user plane message in parallel.

Example 43 may include the method of example 38, wherein the UE context modification response message is to include a break indicator to indicate that scheduling of the UE has been stopped.

Example 44 includes a method for performing a make-before-break (MBB) handover for a user equipment (UE) . The method is to be performed by central unit user plane (CU-UP) of a next generation Node B (gNB) . The method comprises: decoding a bearer context modification request message received from a central unit control plane (CU-CP) of the gNB, the bearer context modification request message to include information for data forwarding and is to configure the MBB handover for the UE; encoding a bearer context modification response message to be transmitted to the CU-CP of the gNB; wherein the MBB handover for the UE has already been initiated at a time when the CU-CP of the gNB transmitted a handover request message to a target gNB, the handover request message to include an information element (IE) having information related to the MBB handover for the UE; and continuing transmitting a downlink (DL) packet data convergence protocol (PDCP) packet to a distributed unit (DU) of the gNB and receiving uplink (UL) PDCP packet from the DU of the gNB, until the MBB handover for the UE is completed.

Example 45 may include the method of example 44, wherein the bearer context modification request is to include an MBB indicator to indicate to configure the MBB handover for the UE.

Example 46 may include the method of examples 44 or 45, further comprising: decoding a downlink data delivery status (DDDS) message based user plane message received from the DU of the gNB, the DDDS message based user plane message is to stop the CU-UP of the gNB from transmitting a DL PDCP packet for the UE immediately; wherein a cause value IE of the DDDS message is extended to include a value to indicate a UE handover.

Example 47 may include the method of any of examples 44-46, further comprising: encoding a sequence number (SN) status transfer message or a bearer context modification required message to be transmitted to the CU-CP of the gNB, to indicate a UL PDCP count and a DL PDCP count; wherein each of the SN status transfer message and the bearer context modification required message is to include a PDCP UL Count IE to indicate a PDCP count for a first unacknowledged UL packet, and a PDCP DL Count IE to indicate a PDCP count for a next DL packet to be assigned.

Example 48 includes a non-transitory computer-readable storage medium having instructions stored thereon, which when executed by a central unit control plane (CU-CP) of a next generation Node B (gNB) , cause the CU-CP of the gNB to perform a method according to any of examples 26-37.

Example 49 includes an apparatus to be applied in a central unit control plane (CU-CP) of a next generation Node B (gNB) , comprising means for performing a method according to any of examples 26-37.

Example 50 includes a non-transitory computer-readable storage medium having instructions stored thereon, which when executed by a distributed unit (DU) of a next generation Node B (gNB) , cause the DU of the gNB to perform a method according to any of examples 38-43.

Example 51 includes an apparatus to be employed in a distributed unit (DU) of a next generation Node B (gNB) , comprising means for performing a method according to any of examples 38-43.

Example 52 includes a non-transitory computer-readable storage medium having instructions stored thereon, which when executed by a central unit user plane (CU-UP) of a next generation Node B (gNB) , cause the CU-UP of the gNB to perform a method according to any of examples 44-47.

Example 53 includes an apparatus to be applied in a central unit user plane (CU-UP) of a next generation Node B (gNB) , comprising means for performing a method according to any of examples 44-47.

Example 54 includes a distributed unit (DU) of a next generation Node B (gNB) . The gNB is operable to perform a handover for a user equipment (UE) to a target gNB. The DU of the gNB comprises a memory to store instructions for performing a make-before-break (MBB) handover for the UE, and processor circuitry to access the memory via one or more memory interfaces. The processor circuitry, when executing the instructions for performing the MBB handover for the UE, is to: decode a UE context modification request message received from a central unit control plane (CU-CP) of the gNB to configure the MBB handover for the UE; encode a UE context modification response message to be transmitted to the CU-CP of the gNB; and encode, based on a downlink data delivery status (DDDS) message, a user plane message to be transmitted to a central unit user plane (CU-UP) of the gNB, to stop the CU-UP of the gNB from transmitting DL PDCP for the UE immediately.

Example 55 may include the DU of the gNB of example 54, wherein the processor circuitry is to encode the user plane message by extending a cause value IE of the DDDS message to include a value to indicate a UE handover.

Example 56 may include the DU of the gNB of examples 54 or 55, wherein the UE context modification request message is to include an MBB indicator to indicate to configure the MBB handover for the UE; and wherein the UE context modification response message is to include a Make-Before-Break Confirm IE to confirm the MBB handover; or a Make-Before-Break Ack. IE to accept or reject the MBB handover.

Example 57 includes method for performing a make-before-break (MBB) handover for a user equipment (UE) . The method is to be performed by a distributed unit (DU) of a next generation Node B (gNB) . The method comprising: decoding a UE context modification request message received from a central unit control plane (CU-CP) of the gNB to configure the MBB handover for the UE; encoding a UE context modification response message to be transmitted to the CU-CP of the gNB; and encoding, based on a downlink data delivery status (DDDS) message, a user plane message to be transmitted to a central unit user plane (CU-UP) of the gNB, to stop the CU-UP of the gNB from transmitting DL PDCP for the UE immediately.

Example 58 may include the method of example 57, wherein encoding the user plane message is to include extending a cause value IE of the DDDS message to include a value to indicate a UE handover.

Example 59 may include the method of examples 57 or 58, wherein the UE context modification request message is to include an MBB indicator to indicate to configure the MBB handover for the UE; and wherein the UE context modification response message is to include a Make-Before-Break Confirm IE to confirm the MBB handover; or a Make-Before-Break Ack. IE to accept or reject the MBB handover.

Example 60 includes an apparatus to be employed in a distributed unit (DU) of a next generation Node B (gNB) , comprising means for performing a method according to any of examples 57-59.

Although certain embodiments have been illustrated and described herein for purposes of description, a wide variety of alternate and/or equivalent embodiments or implementations calculated to achieve the same purposes may be substituted for the embodiments shown and described without departing from the scope of the present disclosure. This application is intended to cover any adaptations or variations of the embodiments discussed herein. Therefore, it is manifestly intended that embodiments described herein be limited only by the appended claims and the equivalents thereof.

Claims

A central unit control plane (CU-CP) of a next generation Node B (gNB) , the gNB is operable to perform a handover for a user equipment (UE) to a target gNB, the CU-CP of the gNB comprising:

memory to store an indication of a make-before-break (MBB) handover configuration for the UE;and

processor circuitry to access the memory via one or more memory interfaces,

wherein the processor circuitry is to:

encode a handover request message to be transmitted to the target gNB, the handover request message to include, based on the indication of the MBB handover configuration for the UE, a first information element (IE) having first information related to an MBB handover for the UE;

decode a handover request acknowledge message received from the target gNB, the handover request acknowledge message to include a second IE having second information related to the MBB handover for the UE;

encode a UE context modification request message to be transmitted to a distributed unit (DU) of the gNB to configure the MBB handover for the UE; and

decode a UE context modification response message received from the DU of the gNB.
The CU-CP of the gNB of claim 1, wherein the first IE is a radio resource control (RRC) context IE, and the first information related to the MBB handover is to include an extended HandoverPreparationInformation message.
The CU-CP of the gNB of claim 1, wherein the second IE is a target next generation radio access network (NG-RAN) node to source NG-RAN node transparent container, and the second information related to the MBB handover is to include an extended HandoverCommand message.
The CU-CP of the gNB of claim 1, wherein the UE context modification request message is to include an MBB indicator to indicate to configure the MBB handover for the UE; and

wherein the UE context modification response message is to include a Make-Before-Break Confirm IE to confirm the MBB handover for the UE, or a Make-Before-Break Ack.IE to accept or reject the MBB handover for the UE.
The CU-CP of the gNB of claim 1, wherein the processor circuitry is further to:

encode a bearer context modification request message to be transmitted to a central unit user plane (CU-UP) of the gNB, the bearer context modification request message is to include information for data forwarding and is to configure the MBB handover for the UE; and

decode a bearer context modification response message received from the CU-UP of the gNB.
The CU-CP of the gNB of claim 5, wherein the bearer context modification request message is to include an MBB indicator to indicate to configure the MBB handover for the UE.
The CU-CP of the gNB of claim 5, wherein the processor circuitry is to encode the UE context modification request message and the bearer context modification request message simultaneously.
The CU-CP of the gNB of claim 5, wherein the processor circuitry is further to:

decode a sequence number (SN) status transfer message or a bearer context modification required message received from the CU-UP of the gNB, to obtain a uplink (UL) packet data convergence protocol (PDCP) count and a downlink (DL) PDCP count;

wherein each of the SN status transfer message and the bearer context modification required message is to include a PDCP UL Count IE to indicate a PDCP count for a first unacknowledged UL packet, and a PDCP DL Count IE to indicate a PDCP count for a next DL packet to be assigned.
The CU-CP of the gNB of claim 1, wherein the processor circuitry is further to:

decode a UE context modification required message received from the DU of the gNB, the UE context modification required message is to indicate completion of the MBB handover for the UE;and

encode a UE context modification confirm message to be transmitted to the DU of the gNB;

wherein the UE context modification required message is to include a break indicator to indicate that scheduling of the UE has been stopped.
The CU-CP of the gNB of claim 9, wherein the processor circuitry is further to:

initiate a bearer context modification procedure with the a central unit user plane (CU-UP) of the gNB, to stop the CU-UP of the gNB from sending a downlink packet data convergence protocol (PDCP) packet to the DU of the gNB.
The CU-CP of the gNB of claim 10, wherein the processor circuitry is further to:

retrieve a downlink (DL) /uplink (UL) packet data convergence protocol (PDCP) status of a bearer between the CU-UP of the gNB and the CU-CP of the gNB; and

exchange data forwarding information for the bearer.
The CU-CP of the gNB of claim 1, wherein the UE context modification response message is to include a break indicator to indicate that scheduling of the UE has been stopped.
A distributed unit (DU) of a next generation Node B (gNB) , the gNB is operable to perform a handover for a user equipment (UE) to a target gNB, the DU of the gNB comprising:

memory to store instructions for performing a make-before-break (MBB) handover for the UE;and

processor circuitry to access the memory via one or more memory interfaces,

wherein the processor circuitry, when executing the instructions for performing the MBB handover for the UE, is to:

decode a UE context modification request message received from a central unit control plane (CU-CP) of the gNB to configure the MBB handover for the UE;

encode a UE context modification response message to be transmitted to the CU-CP of the gNB;

wherein the MBB handover for the UE has already been initiated at a time when the CU-CP of the gNB transmitted a handover request message to the target gNB, the handover request message to include an information element (IE) having information related to the MBB handover for the UE; and

continue transmitting or receiving data with the UE, until the MBB handover for the UE is completed.
The DU of the gNB of claim 13, wherein the UE context modification request message is to include an MBB indicator to indicate to configure the MBB handover for the UE; and

wherein the UE context modification response message is to include a Make-Before-Break Confirm IE to confirm the MBB handover, or a Make-Before-Break Ack.IE to accept or reject the MBB handover.
The DU of the gNB of claim 13, wherein the processor circuitry is further to:

encode a UE context modification required message to be transmitted to the CU-CP of the gNB, the UE context modification required message indicates completion of the MBB handover for the UE; and

decode a UE context modification confirm message received from the CU-CP of the gNB;

wherein the UE context modification required message is to include a break indicator to indicate that scheduling of the UE has been stopped.
The DU of the gNB of any of claims 13 to 15, wherein the processor circuitry is further to:

encode, based on a downlink data delivery status (DDDS) message, a user plane message to be transmitted to a central unit user plane (CU-UP) of the gNB, to stop the CU-UP of the gNB from transmitting DL PDCP for the UE immediately;

wherein encoding the user plane message based on the DDDS message is to include extending a cause value IE of the DDDS message to include a value to indicate a UE handover.
The DU of the gNB of claim 16, wherein the processor circuitry is to encode the UE context modification required message and the user plane message in parallel.
The the DU of the gNB of claim 13, wherein the UE context modification response message is to include a break indicator to indicate that scheduling of the UE has been stopped.
A central unit user plane (CU-UP) of a next generation Node B (gNB) , the gNB is operable to perform a handover for a user equipment (UE) to a target gNB, the CU-UP of the gNB comprising:

memory to store instructions for performing a make-before-break (MBB) handover for the UE;and

processor circuitry to access the memory via one or more memory interfaces,

wherein the processor circuitry, when executing the instructions for performing the MBB handover for the UE, is to:

decode a bearer context modification request message received from a central unit control plane (CU-CP) of the gNB, the bearer context modification request message to include information for data forwarding and is to configure the MBB handover for the UE;

encode a bearer context modification response message to be transmitted to the CU-CP of the gNB;

wherein the MBB handover for the UE has already been initiated at a time when the CU-CP of the gNB transmitted a handover request message to the target gNB, the handover request message to include an information element (IE) having information related to the MBB handover for the UE; and

continue transmitting a downlink (DL) packet data convergence protocol (PDCP) packet to a distributed unit (DU) of the gNB and receiving uplink (UL) PDCP packet from the DU of the gNB, until the MBB handover for the UE is completed.
The CU-UP of the gNB of claim 19, wherein the bearer context modification request message is to include an MBB indicator to indicate to configure the MBB handover for the UE.
The CU-UP of the gNB of claim 19, wherein the processor circuitry is further to:

decode a downlink data delivery status (DDDS) message based user plane message received from the DU of the gNB, the DDDS message based user plane message is to stop the CU-UP of the gNB from transmitting a DL PDCP packet for the UE immediately;

wherein a cause value IE of the DDDS message is extended to include a value to indicate a UE handover.
The CU-UP of the gNB of claim 19, wherein the processor circuitry is further to:

encode a sequence number (SN) status transfer message or a bearer context modification required message to be transmitted to the CU-CP of the gNB, to indicate a UL PDCP count and a DL PDCP count;

wherein each of the SN status transfer message and the bearer context modification required message is to include a PDCP UL Count IE to indicate a PDCP count for a first unacknowledged UL packet, and a PDCP DL Count IE to indicate a PDCP count for a next DL packet to be assigned.
A computer-readable storage medium having instructions stored thereon, which when executed cause a distributed unit (DU) of a next generation Node B (gNB) to:

decode a UE context modification request message received from a central unit control plane (CU-CP) of the gNB to configure a make-before-break (MBB) handover for the UE;

encode a UE context modification response message to be transmitted to the CU-CP of the gNB; and

encode, based on a downlink data delivery status (DDDS) message, a user plane message to be transmitted to a central unit user plane (CU-UP) of the gNB, to stop the CU-UP of the gNB from transmitting DL PDCP for the UE immediately.
The computer-readable storage medium of claim 23, wherein the DU of the gNB is to encode the user plane message by extending a cause value IE of the DDDS message to include a value to indicate a UE handover.
The computer-readable storage medium of claim 23, wherein the UE context modification request message is to include an MBB indicator to indicate to configure the MBB handover for the UE; and

wherein the UE context modification response message is to include a Make-Before-Break Confirm IE to confirm the MBB handover; or a Make-Before-Break Ack. IE to accept or reject the MBB handover.