阅读说明：本技术 切换期间的报头压缩处置 (Header compression handling during handover ) 是由 K·帕拉杜古 S·卡纳玛拉普蒂 O·奥兹图科 P·R·卡迪里 于 2020-03-04 设计创作，主要内容包括：本公开的各方面涉及无线通信,并且尤其涉及在具有并发连接的场景(诸如先建后断(MBB)切换或双连通性(DC)场景)中处置报头压缩。由用户装备(UE)执行的无线通信方法可包括在切换规程期间与第一基站(BS)和第二BS并发地通信,其中在与第一BS的连接上与第一BS通信并且在与第二BS的连接上与第二BS通信。UE针对与第一BS的连接和与第二BS的连接维持报头压缩协议的上下文。并发地通信包括使用报头压缩协议的上下文来发送一个或多个分组、接收一个或多个分组、或两者。(Aspects of the present disclosure relate to wireless communications, and more particularly, to handling header compression in scenarios with concurrent connections, such as a Make Before Break (MBB) handover or a Dual Connectivity (DC) scenario. A method of wireless communication performed by a User Equipment (UE) may include concurrently communicating with a first Base Station (BS) and a second BS during a handover procedure, wherein the first BS is communicated over a connection with the first BS and the second BS is communicated over a connection with the second BS. The UE maintains a context of a header compression protocol for a connection with a first BS and a connection with a second BS. Concurrently communicating includes using a context of a header compression protocol to send one or more packets, receive one or more packets, or both.)

1. A method of wireless communication performed by a User Equipment (UE), comprising:

concurrently communicate with a first Base Station (BS) and a second BS during a handover procedure, wherein the first BS is communicated on a connection with the first BS and the second BS is communicated on a connection with the second BS; and

maintaining a context of a header compression protocol for connections with the first BS and connections with the second BS, wherein:

concurrently communicating includes transmitting one or more packets, receiving one or more packets, or both, using a context of the header compression protocol.

2. The method of claim 1, wherein the header compression protocol comprises a robust header compression (RoHC) protocol.

3. The method of claim 1, wherein the handover procedure is a Make Before Break (MBB) handover procedure or a Dual Active Protocol Stack (DAPS) handover procedure.

4. The method of claim 3, wherein communicating concurrently with the first BS and the second BS further comprises:

performing a common Packet Data Convergence Protocol (PDCP) function for the connection with the first BS and the connection with the second BS before the connection with the first BS is released as part of the MBB or DAPS handover procedure.

5. The method of claim 1, wherein communicating concurrently with the first BS and the second BS further comprises:

communicating over a split radio bearer having at least a first link to the first BS and a second link to the second BS.

6. The method of claim 1, wherein maintaining the context of the header compression protocol comprises maintaining a single active compressor context and a dual active decompressor context of the header compression protocol.

7. The method of claim 6, wherein communicating concurrently with the first BS and the second BS further comprises:

transmitting uplink data on a single connection with the second BS or the first BS and compressing the data using a single active context of the header compression protocol, the single active context corresponding to the connection on which the data is transmitted;

receiving downlink data on a connection with the second BS or the first BS or simultaneously from both the second BS and the first BS, and decompressing the downlink data using a decompressor context of the header compression protocol, the decompressor context corresponding to the connection on which the data is received; or

Both of the above are performed.

8. The method of claim 1, further comprising:

transmitting a Packet Data Convergence Protocol (PDCP) control Protocol Data Unit (PDU) to the first BS to indicate an uplink data handover to the second BS and a maintenance of a single active context corresponding to the second BS after establishing a connection with the second BS.

9. The method of claim 1, wherein maintaining the context of the header compression protocol comprises switching to an Initialization and Refresh (IR) operating state.

10. The method of claim 9, further comprising:

transmitting a Packet Data Convergence Protocol (PDCP) Protocol Data Unit (PDU) to independently signal the first BS and the second BS of the handover to the IR operation state.

11. The method of claim 9, further comprising:

requesting the second BS to switch to using the header compression protocol in another compressed operating state after the connection with the first BS is released.

12. The method of claim 1, wherein maintaining the context of the header compression protocol comprises at least temporarily disabling the header compression protocol.

13. The method of claim 1, wherein concurrently communicating comprises:

transmitting uplink data on a connection with both the second BS and the first BS, or

Receiving downlink data on a connection with both the second BS and the first BS; or

Both of the above are performed.

14. The method of claim 13, wherein:

maintaining the context of the header compression protocol includes maintaining, at the UE, a dual compressor context of the header compression protocol independently for the connection with the second BS and the connection with the first BS.

15. The method of claim 13, further comprising:

transmitting a Packet Data Convergence Protocol (PDCP) Protocol Data Unit (PDU) to the second BS to indicate maintenance of dual context.

16. The method of claim 15, wherein:

the PDCP PDU corresponds to a PDCP control PDU or sets a specific bit in a header of a PDCP data PDU; and

the PDCP PDUs are transmitted before activating uplink data replication on a connection with both the second BS and the first BS.

17. The method of claim 16, further comprising:

activating the uplink data replication after transmitting the PDCP PDUs; or

Activating the uplink data replication after receiving a positive acknowledgement of the PDCP PDUs.

18. A method of wireless communication performed by a first Base Station (BS), comprising:

concurrently communicating with a User Equipment (UE) connected with the first Base Station (BS) while the UE is connected to and communicating with a second BS during a handover procedure; and

maintaining a context of a header compression protocol for a connection with the UE and at least the first BS, wherein

Concurrently communicating includes transmitting one or more packets, receiving one or more packets, or both, using a context of the header compression protocol.

19. The method of claim 18 wherein the header compression protocol comprises at least a robust header compression (RoHC) protocol.

20. The method of claim 18, wherein the handover procedure is a Make Before Break (MBB) handover procedure or a Dual Active Protocol Stack (DAPS) handover procedure.

21. The method of claim 20, wherein concurrently communicating comprises:

performing a common Packet Data Convergence Protocol (PDCP) function for the connection with the UE and the first BS and the connection with the UE and the second BS before the connection with the first BS is released as part of the MBB or DAPS handover procedure.

22. The method of claim 18, wherein concurrently communicating comprises: communicating over a split radio bearer having at least a first link to the first BS and a second link to the second BS.

23. The method of claim 18, wherein maintaining the context of the header compression protocol comprises maintaining a single active context of the header compression protocol.

24. The method of claim 23, wherein concurrently communicating comprises:

sending downlink data over a single connection with the UE and compressing the data using the single activity context of the header compression protocol;

receiving uplink data on a single connection with the UE and decompressing the downlink data using the single activity context of the header compression protocol; or

Both of the above are performed.

25. The method of claim 24, further comprising:

at least one of: reordering or discarding duplicate data of an uplink Packet Data Convergence Protocol (PDCP) Protocol Data Unit (PDU) forwarded from the second BS before performing decompression using the single context of the header compression protocol.

26. The method of claim 18, wherein maintaining the context of the header compression protocol comprises at least temporarily disabling the header compression protocol.

27. An apparatus for wireless communication, comprising:

at least one processor coupled with a memory, the memory comprising code executable by the at least one processor to cause the apparatus to:

concurrently communicate with a first Base Station (BS) and a second BS during a handover procedure, wherein the first BS is communicated on a connection with the first BS and the second BS is communicated on a connection with the second BS; and

maintaining a context of a header compression protocol for connections with the first BS and connections with the second BS, wherein:

concurrently communicating includes transmitting one or more packets, receiving one or more packets, or both, using a context of the header compression protocol.

28. The apparatus of claim 27, wherein the code executable by the at least one processor to cause the apparatus to maintain context for the header compression protocol comprises: code executable by the at least one processor to cause the apparatus to maintain a single active context of the header compression protocol.

29. An apparatus for wireless communication, comprising:

at least one processor coupled with a memory, the memory comprising code executable by the at least one processor to cause the apparatus to:

concurrently communicating with a User Equipment (UE) connected with the apparatus while the UE is connected to and communicating with another apparatus during a handover procedure; and

maintaining a context of a header compression protocol for a connection with the UE and at least the apparatus, wherein

Concurrently communicating includes transmitting one or more packets, receiving one or more packets, or both, using a context of the header compression protocol.

30. The apparatus of claim 29, wherein the code executable by the at least one processor to cause the apparatus to maintain context for the header compression protocol comprises: code executable by the at least one processor to cause the apparatus to maintain a single active context of the header compression protocol.

The field of disclosure:

aspects of the present disclosure relate to wireless communications, and more particularly, to handling header compression in scenarios with concurrent connections during handoff.

Description of related art:

wireless communication systems are widely deployed to provide various telecommunication services such as telephony, video, data, messaging, and broadcasting. Typical wireless communication systems may employ multiple-access techniques capable of supporting communication with multiple users by sharing the available system resources (e.g., bandwidth, transmit power). Examples of such multiple-access techniques include Long Term Evolution (LTE) systems, Code Division Multiple Access (CDMA) systems, Time Division Multiple Access (TDMA) systems, Frequency Division Multiple Access (FDMA) systems, Orthogonal Frequency Division Multiple Access (OFDMA) systems, single carrier frequency division multiple access (SC-FDMA) systems, and time division synchronous code division multiple access (TD-SCDMA) systems.

These multiple access techniques have been adopted in various telecommunications standards to provide a common protocol that enables different wireless devices to communicate on a city, country, region, and even global level. An example of an emerging telecommunications standard is known as New Radio (NR), e.g., 5G radio access. It is designed to better support mobile broadband internet access by improving spectral efficiency, reducing costs, improving services, utilizing new spectrum, and better integrating with other open standards using OFDMA with Cyclic Prefix (CP) on Downlink (DL) and Uplink (UL), and to support beamforming, Multiple Input Multiple Output (MIMO) antenna techniques, and carrier aggregation.

However, as the demand for mobile broadband access continues to grow, there is a need for further improvements in NR technology. Preferably, these improvements should be applicable to other multiple access techniques and telecommunications standards employing these techniques.

Brief summary

The systems, methods, and devices of the present disclosure each have several aspects, no single one of which is solely responsible for its desirable attributes. Without limiting the scope of the present disclosure as expressed by the claims which follow, some features will now be discussed briefly. After considering this discussion, and particularly after reading the section entitled "detailed description" one will understand how the features of this disclosure provide advantages that include improved communications between access points and stations in a wireless network.

Certain aspects of the present disclosure provide a method for wireless communications by a User Equipment (UE). The method generally includes concurrently communicating with a first Base Station (BS) and a second BS, wherein the first BS is communicated over a connection with the first BS and the second BS is communicated over a connection with the second BS. The method generally includes maintaining a context of a header compression protocol for a connection with a first BS and a connection with a second BS. Concurrently communicating includes using a context of a header compression protocol to send one or more packets, receive one or more packets, or both.

Certain aspects of the present disclosure provide a method for wireless communication, which may be performed by a first BS. The method generally includes communicating concurrently with a UE connected to a first BS while the UE is connected to and communicating with a second BS. The method generally includes maintaining a context of a header compression protocol for a connection with a UE and at least a first BS. Concurrently communicating includes using a context of a header compression protocol to send one or more packets, receive one or more packets, or both.

Certain aspects of the present disclosure provide an apparatus for wireless communication. The apparatus generally includes at least a processor coupled with a memory. The apparatus includes means for concurrently communicating with a first BS and a second BS, wherein the first BS is in communication over a connection with the first BS and the second BS is in communication over a connection with the second BS. The apparatus includes means for maintaining a context of a header compression protocol for a connection with a first BS and a connection with a second BS. Concurrently communicating includes using a context of a header compression protocol to send one or more packets, receive one or more packets, or both.

Certain aspects of the present disclosure provide an apparatus for wireless communication. The apparatus generally includes at least a processor coupled with a memory. The memory includes code executable by the at least one processor to cause the apparatus to: the UE connected to the apparatus concurrently communicates with the UE while connecting to and communicating with another apparatus. The memory includes code executable by the at least one processor to cause the apparatus to: a context of a header compression protocol is maintained for a connection with the UE and at least the apparatus. Concurrently communicating includes using a context of a header compression protocol to send one or more packets, receive one or more packets, or both.

Certain aspects of the present disclosure provide an apparatus for wireless communication. The apparatus generally includes means for concurrently communicating with a first BS and a second BS, wherein the first BS is communicated over a connection with the first BS and the second BS is communicated over a connection with the second BS. The apparatus generally includes means for maintaining a context of a header compression protocol for a connection with a first BS and a connection with a second BS. Concurrently communicating includes using a context of a header compression protocol to send one or more packets, receive one or more packets, or both.

Certain aspects of the present disclosure provide an apparatus for wireless communication. The apparatus generally includes means for concurrently communicating with a UE connected to the apparatus while the UE is connected to and communicating with another apparatus. The apparatus generally includes means for maintaining a context of a header compression protocol for a connection with a UE and at least the apparatus. Concurrently communicating includes using a context of a header compression protocol to send one or more packets, receive one or more packets, or both.

Certain aspects of the present disclosure provide a computer-readable medium having stored thereon computer-executable code for wireless communications. The computer-executable code generally includes code for concurrently communicating with a first BS and a second BS, wherein the first BS is in communication over a connection with the first BS and the second BS is in communication over a connection with the second BS. The computer-executable code generally includes code for maintaining a context of a header compression protocol for a connection with a first BS and a connection with a second BS. Concurrently communicating includes using a context of a header compression protocol to send one or more packets, receive one or more packets, or both.

Certain aspects of the present disclosure provide a computer-readable medium having stored thereon computer-executable code for wireless communications. The computer-executable code generally includes code for concurrently communicating with a UE connected to a first BS while the UE is connected to and communicating with a second BS. The computer-executable code generally includes code for maintaining a context of a header compression protocol for a connection with a UE and at least a first BS. Concurrently communicating includes using a context of a header compression protocol to send one or more packets, receive one or more packets, or both.

To the accomplishment of the foregoing and related ends, the one or more aspects comprise the features hereinafter fully described and particularly pointed out in the claims. The following description and the annexed drawings set forth in detail certain illustrative features of the one or more aspects. These features are indicative, however, of but a few of the various ways in which the principles of various aspects may be employed and the present description is intended to include all such aspects and their equivalents.

Brief Description of Drawings

So that the manner in which the above recited features of the present disclosure can be understood in detail, a more particular description of the disclosure, briefly summarized above, may be had by reference to aspects, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only certain typical aspects of this disclosure and are therefore not to be considered limiting of its scope, for the description may admit to other equally effective aspects.

Fig. 1 is a block diagram conceptually illustrating an example wireless communication network, in accordance with certain aspects of the present disclosure.

Fig. 2 is a block diagram illustrating an example architecture of a distributed Radio Access Network (RAN) in accordance with certain aspects of the present disclosure.

Fig. 3 is a block diagram illustrating an example of a communication protocol stack for implementing in an example RAN architecture, in accordance with certain aspects of the present disclosure.

Fig. 4 is a block diagram conceptually illustrating a design of an example BS and User Equipment (UE), in accordance with certain aspects of the present disclosure.

Fig. 5 illustrates an example of a frame format for a New Radio (NR) system in accordance with certain aspects of the present disclosure.

Fig. 6 illustrates a call flow diagram of an example handover procedure.

Fig. 7 illustrates a call flow diagram of another example handover procedure.

Fig. 8 illustrates example operations for wireless communications by a User Equipment (UE) in accordance with certain aspects of the present disclosure.

Fig. 9 illustrates example operations for wireless communications by a network entity, in accordance with certain aspects of the present disclosure.

Fig. 10 is an example illustrating a user plane architecture showing header compression with uplink data replication and with dual contexts during handover in a wireless communication network, in accordance with aspects of the present disclosure.

Fig. 11 is an example user plane architecture illustrating header compression with uplink data replication and with single context during handover in a wireless communication network, in accordance with aspects of the present disclosure.

Fig. 12 is an example call flow illustrating header compression with uplink data replication and with single context during handover in a wireless communication network, in accordance with aspects of the present disclosure.

Fig. 13 is another example call flow illustrating header compression disabling during handover in a wireless communication network, in accordance with aspects of the present disclosure.

Fig. 14 is an example user plane architecture illustrating header compression without downlink data duplication and with a single context during handover in a wireless communication network, in accordance with aspects of the present disclosure.

Fig. 15 is an example call flow illustrating header compression without downlink data duplication and with a single context during handover in a wireless communication network, in accordance with aspects of the present disclosure.

Fig. 16 is another example call flow illustrating header compression without downlink data duplication and with a single context during handover in a wireless communication network, in accordance with aspects of the present disclosure.

Fig. 17 is another example call flow illustrating header compression during handover with a change in bearer termination point for a split bearer in a wireless communication network, in accordance with aspects of the present disclosure.

Fig. 18 is an example illustrating a user plane architecture showing header compression during handover in case of a change of bearer termination point for a split bearer in a wireless communication network, according to aspects of the present disclosure.

Fig. 19 is an example user plane architecture illustrating header compression during handover with a change in bearer termination point for split bearers in a wireless communication network, according to aspects of the present disclosure.

Fig. 20 is an example user plane architecture illustrating header compression without uplink data duplication and with a single context during handover in a wireless communication network, in accordance with aspects of the present disclosure.

Fig. 21 is an example user plane architecture illustrating header compression with downlink data replication and dual context during handover in a wireless communication network, in accordance with aspects of the present disclosure.

Fig. 22 illustrates a communication device that may include various components configured to perform operations for the techniques disclosed herein, in accordance with aspects of the present disclosure.

Fig. 23 illustrates a communication device that may include various components configured to perform operations for the techniques disclosed herein, in accordance with aspects of the present disclosure.

To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. It is contemplated that elements disclosed in one aspect may be beneficially utilized on other aspects without specific recitation.

Detailed Description

Aspects of the present disclosure provide apparatuses, methods, processing systems, and computer-readable media for handling header compression in scenarios in which a User Equipment (UE) has concurrent connections with multiple network entities, such as during a make-before-break (MBB) handover, a Dual Active Protocol Stack (DAPS) handover, and/or a handover in a Dual Connectivity (DC) scenario.

The following description provides examples of header compression handling during handover, and does not limit the scope, applicability, or examples set forth in the claims. Changes may be made in the function and arrangement of elements discussed without departing from the scope of the disclosure. Various examples may omit, substitute, or add various procedures or components as appropriate. For example, the described methods may be performed in an order different than described, and various steps may be added, omitted, or combined. Also, features described with reference to some examples may be combined in some other examples. For example, an apparatus may be implemented or a method may be practiced using any number of the aspects set forth herein. Moreover, the scope of the present disclosure is intended to cover such an apparatus or method as practiced using other structure, functionality, or structure and functionality in addition to or in addition to the various aspects of the present disclosure set forth herein. It should be understood that any aspect of the disclosure disclosed herein may be implemented by one or more elements of a claim. The word "exemplary" is used herein to mean "serving as an example, instance, or illustration. Any aspect described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects.

In general, any number of wireless networks may be deployed in a given geographic area. Each wireless network may support a particular Radio Access Technology (RAT) and may operate on one or more frequencies. A RAT may also be referred to as a radio technology, air interface, etc. The frequencies may also be referred to as carriers, frequency channels, etc. Each frequency may support a single RAT in a given geographic area in order to avoid interference between wireless networks of different RATs. In some cases, NR or 5G RAT networks may be deployed.

The techniques described herein may be used for various wireless networks and radio technologies. Although aspects may be described herein using terms commonly associated with 3G, 4G, and/or 5G wireless technologies, aspects of the disclosure may be applied in other generations based, for example, on offspring NR technologies.

NR may support various wireless communication services, such as enhanced mobile broadband (eMBB) targeting wide bandwidths (e.g., over 80MHz), millimeter wave (mmW) targeting high carrier frequencies (e.g., 24GHz to 53GHz or more), massive MTC (MTC) targeting non-backward compatible MTC technologies, and/or mission critical targeting ultra-reliable low latency communication (URLLC). These services may include latency and reliability requirements. These services may also have different Transmission Time Intervals (TTIs) to meet corresponding quality of service (QoS) requirements. In addition, these services may coexist in the same subframe. Beamforming may be supported and beam directions may be dynamically configured. MIMO transmission with precoding may also be supported. MIMO configuration in DL can support up to 8 transmit antennas (multi-layer DL transmission with up to 8 streams) and up to 2 streams per UE. Multi-layer transmission of up to 2 streams per UE may be supported. Aggregation of multiple cells may be supported using up to 8 serving cells.

Fig. 1 illustrates an example wireless communication network 100 in which aspects of the disclosure may be performed. The wireless communication network 100 may be an NR system (e.g., a 5G NR network). As shown in fig. 1, the wireless communication network 100 may be in communication with a core network 132. Core network 132 may be in communication with one or more Base Stations (BSs) 110 and/or User Equipments (UEs) 120 in wireless communication network 100 via one or more interfaces.

As illustrated in fig. 1, wireless communication network 100 may include a number of BSs 110a-z (each also individually referred to herein as BS110 or collectively as BS 110) and other network entities. BS110 may provide communication coverage for a particular geographic area (sometimes referred to as a "cell"), which may be stationary or mobile depending on the location of mobile BS 110. In some examples, BSs 110 may be interconnected to each other and/or to one or more other BSs or network nodes (not shown) in wireless communication network 100 by various types of backhaul interfaces (e.g., direct physical connections, virtual networks, etc.) using any suitable transport network. In the example shown in fig. 1, BSs 110a, 110b, and 110c may be macro BSs for macro cells 102a, 102b, and 102c, respectively. BS110 x may be a pico BS for picocell 102 x. BSs 110y and 110z may be femto BSs for femto cells 102y and 102z, respectively. The BS may support one or more cells. Network controller 130 may couple to a set of BSs and provide coordination and control for these BSs. Network controller 130 may communicate with BS110 via a backhaul.

BS110 communicates with UEs 120a-y (each also individually referred to herein as UE 120 or collectively as UE 120) in wireless communication network 100. UEs 120 (e.g., 120x, 120y, etc.) may be dispersed throughout wireless communication network 100, and each UE 120 may be stationary or mobile. Wireless communication network 100 may also include a relay station (e.g., relay station 110r) that receives a transmission of data and/or other information from an upstream station (e.g., BS110 a or UE 120r) and sends a transmission of data and/or other information to a downstream station (e.g., UE 120 or BS 110).

According to certain aspects, BS110 and UE 120 may be configured for header compression during handover. As shown in fig. 1, BS110 a includes HO manager 112 and UE 120a includes HO manager 122. According to aspects of the disclosure, the HO manager 112 and the HO manager 122 may be configured for header compression during handover.

Fig. 2 illustrates an example architecture of a distributed Radio Access Network (RAN)200, which may be implemented in the wireless communication network 100 illustrated in fig. 1. As shown in fig. 2, the distributed RAN includes a Core Network (CN)202 and an access node 208.

The CN 202 may host core network functions. CN 202 may be centrally deployed. CN 202 functionality may be offloaded (e.g., to Advanced Wireless Services (AWS)) in an effort to handle peak capacity. CN 202 may include access and mobility management functions (AMFs) 204 and User Plane Functions (UPFs) 206. The AMF 204 and the UPF 206 may perform one or more core network functions.

The AN 208 may communicate with the CN 202 (e.g., via a backhaul interface). The AN 208 may communicate with the AMF 204 via AN N2 (e.g., NG-C) interface. The AN 208 may communicate with the UPF 206 via AN N3 (e.g., NG-U) interface. The AN 208 may include a central unit control plane (CU-CP)210, one or more central unit user planes (CU-UP)212, one or more Distributed Units (DU)214 and 218, and one or more antenna/remote radio units (AU/RRUs) 220 and 224. The CU and DU may also be referred to as gNB-CU and gNB-DU, respectively. One or more components of AN 208 may be implemented in the gNB 226. AN 208 may communicate with one or more neighboring gnbs.

The CU-CP 210 may be connected to one or more DUs 214-218. The CU-CP 210 and DU 214-218 may be connected via the F1-C interface. As shown in fig. 2, the CU-CP 210 may be connected to a plurality of DUs, but the DUs may be connected to only one CU-CP. Although fig. 2 illustrates only one CU-UP 212, AN 208 may include multiple CU-UPs. The CU-CP 210 selects the appropriate CU-UP(s) for the requested service (e.g., for the UE). The CU-UP(s) 212 may be connected to the CU-CP 210. For example, CU-UP(s) 212 and CU-CP 210 may be connected via an E1 interface. The CU-CP 210 may be connected to one or more DUs 214-218. CU-UP 212 and DU 214-218 may be connected via the F1-U interface. As shown in fig. 2, a CU-CP 210 may be connected to multiple CU-UPs, but each CU-UP may be connected to only one CU-CP.

DUs, such as DUs 214, 216 and/or 218, can host one or more TRPs (transmission/reception points, which can include Edge Nodes (ENs), Edge Units (EUs), Radio Heads (RH), Smart Radio Heads (SRH), etc.). The DUs may be located at the edge of a network with Radio Frequency (RF) functionality. The DU may be connected to multiple CU-UPs that are connected to (e.g., under control of) the same CU-CP (e.g., for RAN sharing, radio as a service (RaaS), and service-specific deployment). The DUs can be configured to serve traffic to the UEs individually (e.g., dynamic selection) or jointly (e.g., joint transmission). Each DU 214-216 may be connected to one of the AU/RRU 220-224.

The CU-CP 210 may be connected to multiple DUs that are connected to the same CU-UP 212 (e.g., under control of the same CU-UP 212). Connectivity between the CU-UP 212 and the DU may be established by the CU-CP 210. For example, a bearer context management function may be used to establish connectivity between the CU-UP 212 and the DU. Data forwarding between the CUs-UP 212 may be via an Xn-U interface.

The distributed RAN200 may support fronthaul solutions across different deployment types. For example, the RAN200 architecture may be based on transport network capabilities (e.g., bandwidth, latency, and/or jitter). The distributed RAN200 may share features and/or components with LTE. For example, AN 208 may support dual connectivity with NRs and may share common deadlines for LTE and NR. The distributed RAN200 may implement cooperation between and among DUs 214 and 218, for example, via CU-CP 212. The inter-DU interface may not be used.

The logical functions may be dynamically distributed in the distributed RAN 200. As will be described in more detail with reference to fig. 3, a Radio Resource Control (RRC) layer, a Packet Data Convergence Protocol (PDCP) layer, a Radio Link Control (RLC) layer, a Medium Access Control (MAC) layer, a Physical (PHY) layer, and/or a Radio Frequency (RF) layer may be adaptively placed in the AN and/or the UE.

Fig. 3 illustrates a diagram showing an example for implementing a communication protocol stack 300 in a RAN (e.g., such as RAN200) according to aspects of the present disclosure. The illustrated communication protocol stack 300 may be implemented by a device operating in a wireless communication system, such as a 5G NR system (e.g., wireless communication network 100). In various examples, the layers of the protocol stack 300 may be implemented as separate software modules, portions of a processor or ASIC, portions of non-co-located devices connected by a communication link, or various combinations thereof. Co-located and non-co-located implementations may be used for network access devices or UEs, for example, in a protocol stack. As shown in fig. 3, the system may support various services over one or more protocols. One or more protocol layers of the protocol stack 300 may be implemented by the AN and/or the UE.

As shown in fig. 3, the protocol stack 300 is split in AN (e.g., AN 208 in fig. 2). The RRC layer 305, the PDCP layer 310, the RLC layer 315, the MAC layer 320, the PHY layer 325, and the RF layer 530 may be implemented by the AN. For example, a CU-CP (e.g., CU-CP 210 in FIG. 2) and a CU-UP (e.g., CU-UP 212 in FIG. 2) may each implement RRC layer 305 and PDCP layer 310. The DUs (e.g., DU 214-. AU/RRU (e.g., AU/RRU 220 and 224 in fig. 2) may implement PHY layer(s) 325 and RF layer(s) 330. PHY layer 325 may include a high PHY layer and a low PHY layer.

The UE may implement the entire protocol stack 300 (e.g., RRC layer 305, PDCP layer 310, RLC layer 315, MAC layer 320, PHY layer(s) 325, and RF layer(s) 330).

FIG. 4 shows a block diagram of a design of BS110 a and UE 120 a. At BS110 a, a transmit processor 420 may receive data from a data source 412 and control information from a controller/processor 440. The control information may be used for a Physical Broadcast Channel (PBCH), a Physical Control Format Indicator Channel (PCFICH), a physical hybrid ARQ indicator channel (PHICH), a Physical Downlink Control Channel (PDCCH), and the like. The data may be for a Physical Downlink Shared Channel (PDSCH), etc. Processor 440 may process (e.g., encode and symbol map) the data and control information to obtain data symbols and control symbols, respectively. Processor 420 may also generate reference symbols (e.g., for PSS, SSS, and channel state information reference signal (CSI-RS)). A Transmit (TX) multiple-input multiple-output (MIMO) processor 430 may perform spatial processing (e.g., precoding) on the data symbols, the control symbols, and/or the reference symbols, if applicable, and may provide output symbol streams to Modulators (MODs) 432a through 432 t. Each modulator 432 may process a respective output symbol stream (e.g., for OFDM, etc.) to obtain an output sample stream. Each modulator 432 may further process (e.g., convert to analog, amplify, filter, and upconvert) the output sample stream to obtain a downlink signal. Downlink signals from modulators 432a through 432t may be transmitted via antennas 434a through 434t, respectively.

At UE 120a, antennas 452a through 452r may receive downlink signals from BS110 a and may provide received signals to demodulators (DEMODs) 454a through 454r, respectively. Each demodulator 454 may condition (e.g., filter, amplify, downconvert, and digitize) a respective received signal to obtain input samples. Each demodulator 454 may further process the input samples (e.g., for OFDM, etc.) to obtain received symbols. A MIMO detector 456 may obtain received symbols from all demodulators 454a through 454r, perform MIMO detection on the received symbols if applicable, and provide detected symbols. A receive processor 458 may process (e.g., demodulate, deinterleave, and decode) the detected symbols, provide decoded data for UE 120a to a data sink 460, and provide decoded control information to a controller/processor 480.

On the uplink, at UE 120a, a transmit processor 464 may receive and process data from a data source 462 (e.g., for the Physical Uplink Shared Channel (PUSCH)) and control information from a controller/processor 480 (e.g., for the Physical Uplink Control Channel (PUCCH)). The transmit processor 464 may also generate reference symbols for a reference signal. The symbols from transmit processor 464 may be precoded by a TX MIMO processor 466 if applicable, further processed by modulators 454a through 454r (e.g., for SC-FDM, etc.), and transmitted to BS110 a. At BS110 a, the uplink signals from UE 120a may be received by antennas 434, processed by demodulators 432, detected by a MIMO detector 436 if applicable, and further processed by a receive processor 438 to obtain decoded data and control information sent by UE 120 a. The receive processor 438 may provide decoded data to a data sink 439 and decoded control information to a controller/processor 440.

Controllers/processors 440 and 480 may direct the operation at BS110 a and UE 120a, respectively. Processor 440 and/or other processors and modules at BS110 may perform or direct the performance of various processes, such as for the techniques described herein. As shown in fig. 4, the processor 440 includes a HO manager 441, which HO manager 441 may be configured for header compression handling during handover, according to aspects of the present disclosure. Processor 480 and/or other processors and modules at UE 120a may also perform or direct. As shown in fig. 4, in accordance with aspects of the present disclosure, processor 480 includes a HO manager 481, which HO manager 481 may be configured for header compression handling during handover.

The NR may utilize Orthogonal Frequency Division Multiplexing (OFDM) with a Cyclic Prefix (CP) on the downlink and/or uplink and may utilize single carrier frequency division multiplexing (SC-FDM) on the uplink and/or downlink. OFDM and SC-FDM partition the system bandwidth into multiple orthogonal subcarriers, which are also referred to as tones, bins, and so on. Each subcarrier may be modulated with data. The modulation symbols may be sent in the frequency domain under OFDM and in the time domain under SC-FDM. The spacing between adjacent subcarriers may be fixed, and the total number of subcarriers may depend on the system bandwidth. The system bandwidth may also be divided into sub-bands. For example, one sub-band may cover a plurality of Resource Blocks (RBs).

Fig. 5 is a diagram illustrating an example of a frame format 500 for NR. The transmission timeline for each of the downlink and uplink may be partitioned into units of radio frames. Each radio frame may have a predetermined duration (e.g., 10ms) and may be divided into 10 subframes with indices of 0 through 9, each subframe being 1 ms. Each subframe may include a variable number of slots (e.g., 1, 2, 4, 8, 16,. depending on the SCS. Each slot may include a variable number of symbol periods (e.g., 7, 12, or 14 symbols) depending on the SCS. An index may be assigned to the symbol period in each slot. A mini-slot (which may be referred to as a sub-slot structure) refers to a transmission time interval having a duration less than a time slot (e.g., 2, 3, or 4 symbols). Each symbol in a slot may indicate a link direction (e.g., DL, UL, or flexible) for data transmission, and the link direction for each subframe may be dynamically switched. The link direction may be based on the slot format. Each slot may include DL/UL data as well as DL/UL control information.

In some examples, access to the air interface may be scheduled, where a scheduling entity (e.g., a base station) allocates resources for communication among some or all of the devices and equipment within its service area or cell. Within the present disclosure, the scheduling entity may be responsible for scheduling, assigning, reconfiguring, and releasing resources for one or more subordinate entities, as discussed further below. That is, for scheduled communications, the subordinate entity utilizes the resources allocated by the scheduling entity. The base station is not the only entity that can be used as a scheduling entity. That is, in some examples, a UE may function as a scheduling entity, scheduling resources for one or more subordinate entities (e.g., one or more other UEs). In this example, the UE is acting as a scheduling entity and other UEs utilize resources scheduled by the UE for wireless communications. The UE may be used as a scheduling entity in a peer-to-peer (P2P) network and/or in a mesh network. In the mesh network example, the UEs may optionally communicate directly with each other in addition to communicating with the scheduling entity. Thus, in a wireless communication network having scheduled access to time-frequency resources and having a cellular configuration, a P2P configuration, and a mesh configuration, a scheduling entity and one or more subordinate entities may utilize the scheduled resources for communication.

Example switching scenarios

Some of the techniques and apparatus described herein provide for low latency or zero latency handover from a source BS to a target base station (e.g., in a network such as a 4G/LTE or 5G/NR network). For example, some techniques and apparatus described herein provide for a handover configuration using a first protocol stack of a UE and a second protocol stack of the UE. A first protocol stack of the UE is used for communication with the first BS, and a second protocol stack of the UE is used for communication with the second BS. In some examples, this may be referred to as a Make Before Break (MBB) handover or a Dual Active Protocol Stack (DAPS) handover. The use of these two protocol stacks may enable handover configuration with respect to the target BS to be performed while communication with the source BS is ongoing. Thus, latency associated with handing off the UE from the source BS to the target BS is reduced. Moreover, some techniques and apparatus described herein may provide for buffering and backhaul of UE traffic between the source BS and the target BS such that traffic flow to the UE is not interrupted (or such that interruptions are reduced or minimized), thereby further reducing latency associated with handing off the UE. In this way, the service level at the UE may be met in the case of a UE handover, which allows performance requirements for certain types of traffic (e.g., gaming traffic, multimedia traffic, high reliability traffic, low latency traffic, etc.) to be met.

Some of the techniques and apparatus described herein may provide common Packet Data Convergence Protocol (PDCP) functionality for handover procedures, which may simplify security key management, ciphering/deciphering, integrity protection, integrity verification, data unit reordering/copy discard, link selection logic, and so on. Some techniques and apparatuses described herein provide control plane (e.g., BS, network controller, control entity, etc.) messaging and handling to support handover. Some techniques and apparatus described herein provide for switching using Carrier Aggregation (CA) multiple-input multiple-output (MIMO) techniques, where a pruned MIMO configuration is signaled such that at least one antenna is available for MBB switching. Still further, some techniques and apparatus described herein provide a role switch based handover technique in which a primary cell group of a UE is handed over from a source base station to a target base station while connections with the source and target base stations are active. In this way, low-latency or zero-latency switching (and the benefits described above in connection with low-latency or zero-latency switching) is achieved.

Fig. 6 is a diagram illustrating an example 600 of a handover procedure of a radio access network in accordance with various aspects of the present disclosure. As shown in FIG. 6, UE 120 is handed off from source BS 110-1 to target BS 110-2. Source BS 110-1 and target BS110-2 may be implemented by BS110 a of fig. 1. The switching described in connection with fig. 6 may be intra-frequency or inter-frequency and/or may be intra-CU or inter-CU.

As shown in fig. 6 and by reference numeral 605, UE 120 has established a connection with source BS 110-1 (hereinafter referred to as a source connection). As shown by reference numeral 610, in example 600, UE 120 indicates capabilities of UE 120 to any one or more of source BS 110-1, target BS110-2, a network entity such as an access management function, and the like. For example, the UE 120 may indicate that the UE 120 has simultaneous transmit and receive capabilities and/or dual connectivity capabilities.

As shown by reference numeral 615, the UE 120 may provide a measurement report to the source BS 110-1. The measurement report may indicate that a handover is to be performed from the source BS 110-1 to the target BS 110-2. As shown by reference numeral 620, the source BS 110-1 may determine a configuration for a handover procedure based at least in part on the capability. For example, source BS 110-1 may provide a handover request to target BS110-2 and may receive a handover Acknowledgement (ACK) from target BS 110-2. In some aspects, source BS 110-1 may communicate with target BS110-2 to determine a handover configuration for UE 120. As shown by reference numeral 625, source BS 110-1 may then provide the handover configuration to UE 120. For example, the handover configuration may include a handover procedure configuration with or without the indicated capabilities of UE 120. In some aspects, the handover configuration may indicate that a Make Before Break (MBB) handover procedure, a DAPS handover procedure, and/or a DC-based MBB handover procedure is performed. Thus, the UE 120 may be aware of maintaining the source connection while and/or after establishing the target connection.

As shown in fig. 6 and further by reference numeral 630, UE 120 requests a connection with target BS110-2 (e.g., using the configuration received from source BS 110-1). For example, UE 120 may perform a random access procedure to establish a connection with target BS110-2 (hereinafter referred to as a target connection). Target BS110-2 may reply with an acknowledgement, as indicated by reference numeral 635, and UE 120 and target BS110-2 may establish a target connection, as indicated by reference numeral 640. As is evident in example 600, UE 120 may concurrently maintain a source connection with both source BS 110-1 and target BS110-2 during a handover procedure. In such a scenario, because UE 120 maintains an active connection with both source BS 110-1 and target BS110-2 for a period of time, UE 120 may experience reduced delay and/or minimum data interruption time (e.g., 0ms handover) relative to prior techniques.

As further shown in fig. 6 and by reference numeral 645, the target BS110-2 instructs the UE 120 to release the source connection (e.g., to complete the handover). For example, upon determining that UE 120 has established a strong connection (e.g., the parameters measured by UE 120 satisfy a threshold indicating a strong connection), target BS110-2 may send an instruction to complete the handover. In some aspects, the release of the source connection may not be based on instructions from the target BS 110-2. For example, the UE 120 may release the source connection based at least in part on the establishment of the target connection. In some aspects, the release of the source connection may be based on an instruction from source BS 110-1, based at least in part on receiving an indication of establishment of the target connection from target BS110-2 or from UE 120. Accordingly, as indicated by reference numeral 650, the UE 120 releases the source connection to the source BS 110-1. Further, as shown by reference numeral 655, the UE 120 continues service using the target connection with the target BS 110-2.

Accordingly, as shown in example 600 in fig. 6, the UE may provide capabilities to the BS or network entity and the BS may configure the MBB handover procedure for the UE to enable the UE to use the capabilities during the handover procedure. Accordingly, the UE may achieve enhanced performance during the handover procedure and may experience a minimum mobility interruption time (e.g., via a 0ms handover) relative to a handover procedure that does not utilize UE capabilities.

As indicated above, fig. 6 is provided as an example. Other examples may differ from the example described with respect to fig. 6.

Fig. 7 is a diagram illustrating an example 700 of a handover procedure of a radio access network in accordance with various aspects of the present disclosure. As shown in the call flow of example 700 of fig. 7, an example intra-CU handover procedure is performed using an enhanced MBB or DAPS handover, where both the source BS 110-1 and the target BS110-2 are associated with the same CU 702.

In fig. 7, before the call flow begins, UE 120 may exchange user data (e.g., uplink user data and/or downlink user data) with CU 702 via source BS 110-1. As shown by reference numeral 705, the UE 120 transmits a measurement report to the source BS 110-1. In some aspects, the UE 120 sends the measurement report based at least in part on an event trigger (e.g., a signal measurement that satisfies a threshold) associated with determining to initiate the handover procedure. The UE 120 may be associated with the capability of handover. For example, the capability may be a simultaneous transmit and receive capability that allows UE 120 to concurrently transmit and receive data and/or information. In this case, UE 120 may establish multiple connections with multiple different BSs (e.g., with source BS 110-1 and target BS 110-2).

As shown in fig. 7 and further by reference numeral 710, the source BS 110-1 sends an Uplink (UL) Radio Resource Control (RRC) transmission to the CU 702. In some aspects, the UL RRC transmission may include a measurement report. Further, in some aspects, the UL RRC transmission may cause CU 702 to determine a switching configuration to be used for a switching procedure of UE 120. For example, CU 702 may select from possible handover procedures that may be performed by UE 120 based at least in part on the indicated capabilities of UE 120. In some aspects, CU 702 may select an enhanced MBB or DAPS handover procedure for UE 120 based at least in part on UE 120 indicating simultaneous transmission and reception capabilities.

As further shown in fig. 7 and by reference numeral 715, CU 702 sends a UE context setup request to target BS 110-2. For example, CU 702 may send a UE context setup request to indicate to target BS110-2 that UE 120 is to be handed over to target BS110-2 during a handover procedure. The target BS110-2 sends a UE context setup response, as shown by reference numeral 720. For example, target BS110-2 may send a UE context setup response to acknowledge the request and/or indicate the capability to serve UE 120 after the handover procedure.

As further shown in fig. 7 and by reference numeral 725, CU 702 sends a Downlink (DL) RRC transmission to source BS 110-1. In some aspects, the DL RRC transmission may include an RRC reconfiguration message indicating a configuration of a handover procedure in which the UE 120 is to be handed over from the source BS 110-1 to the target BS 110-2. As shown by reference numeral 730, the source BS 110-1 sends an RRC reconfiguration to the UE 120. In some aspects, the RRC reconfiguration may include information identifying the target BS110-2, information identifying a handover configuration, and/or the like. For example, the RRC reconfiguration may indicate that UE 120 is to perform an enhanced MBB or DAPS handover procedure with target BS110-2 using the simultaneous transmit and receive capabilities of UE 120. In such a scenario, UE 120 may identify and/or determine that UE 120 is to maintain a connection with source BS 110-1 while establishing a connection with target BS 110-2. As indicated by reference numeral 735, the UE 120 performs a random access procedure with the target BS110-2 (e.g., to initiate and/or establish a connection with the target BS 110-2). In some aspects, UE 120 may continue to exchange user data (e.g., uplink user data and/or downlink user data) with CU 702 via source BS 110-1 after the random access procedure.

As illustrated by reference numeral 740, the UE 120 transmits an RRC reconfiguration complete message to the target BS 110-2. In some aspects, UE 120 may use a dual protocol stack that includes a source protocol stack for communicating with source BS 110-1 and a target protocol stack for communicating with target BS 110-2. Each of these protocol stacks may include a Packet Data Convergence Protocol (PDCP) layer, a Radio Link Control (RLC) layer, a Medium Access Control (MAC) layer, and/or a Physical (PHY) layer. In some aspects, the source and target protocol stacks may share one or more layers, such as a common PDCP layer or entity (described in more detail elsewhere herein). In some aspects, the target protocol stack may be used for uplink data transmission.

As shown by reference numeral 745, target BS110-2 sends a UL RRC transmission to CU 702. For example, the UL RRC transmission may indicate that the RRC reconfiguration is complete. Accordingly, in some aspects, CU 702 may determine a handover complete configuration based at least in part on receiving the RRC reconfiguration complete message. For example, when a completion determination is made, CU 702 may utilize and/or configure one or more thresholds for one or more measured parameters to perform a handover completion procedure (e.g., to release source BS 110-1). Further, in some aspects, after completing the RRC reconfiguration, UE 120 may perform uplink user plane/control plane replication with source BS 110-1 and CU 702. For example, control plane data may be replicated and shared between BS 110-1 and CU 702. Further, in some aspects, CU 402 may send downlink user data via target BS110-2, but continue to send downlink user plane/control plane replication via source BS 110-1 after CU 702 determines that the RRC reconfiguration is complete. Accordingly, UE 120 may achieve improved reliability when receiving data on the downlink.

As shown by reference numeral 750, CU 702 sends a UE context modification request to source BS 110-1. For example, the UE context modification request may include a transmission stop indicator to indicate that source BS 110-1 is to be released to no longer serve UE 120. In some aspects, source BS 110-1 may provide the downlink data delivery status to CU 702. As shown by reference numeral 755, the source BS 110-1 sends a UE context modification response to the CU 402. For example, the UE context modification response may include an acknowledgement that the source BS 110-1 will be released during the handover procedure and/or will no longer serve the UE 120.

As further shown in fig. 7 and by reference numeral 760, CU 702 sends a DL RRC transmission to target BS 110-2. For example, the DL RRC transmission to the target BS110-2 may include an RRC reconfiguration message indicating that the handover procedure is to be completed. As shown by reference numeral 765, target BS110-2 sends an RRC reconfiguration to UE 120. For example, the RRC reconfiguration message may indicate that UE 120 is to release the connection with source BS 110-1. As such, UE 120 may release the connection with source BS 110-1 based at least in part on receiving the RRC reconfiguration message. Further, UE 120 may then begin exchanging uplink and downlink user data with CU 702 via target BS 110-2.

As shown by reference numeral 770, the UE 120 may send an RRC reconfiguration complete message to the target BS 110-2. In some aspects, the RRC reconfiguration complete message may indicate that the UE 120 has released the connection with the source BS 110-1. As shown by reference number 775, the target BS110-2 may send a UL RRC transmission to the CU 702. In some aspects, the UL RRC transmission may indicate that an RRC reconfiguration complete message is received from the UE 120. CU 702 may then send a UE context release command to source BS 110-1 (e.g., such that source BS 110-1 does not continue to attempt to serve UE 120), as indicated by reference numeral 780. As shown by reference numeral 785, the source BS 110-1 transmits a UE context release complete message to the 7U 402. For example, the UE context release complete message may be an acknowledgement that source BS 110-1 is no longer communicating with UE 120 and/or is serving UE 120.

As indicated above, fig. 7 is provided as an example. Other examples may differ from the example described with respect to fig. 7.

Example header compression

Robust header compression (RoHC) is a header compression protocol that can be used to improve bandwidth efficiency (e.g., for VoLTE operation). Depending on the encoding standard, uncompressed VoIP packets may include 24 to 60 bits for header information and a payload of 32-33 bytes, while VoIP packets with RoHC compression may use a 3-4 byte header. With RoHC compression, the headers of data packets in a data flow may be compressed by removing certain context information from the packet headers to reduce overhead during transmission. In other words, since the information may not change for a period of time (e.g., during a VoLTE call duration), the packet header may be compressed by removing the information.

To establish a data packet flow between the RoHC compressor and the RoHC decompressor, the compressor and decompressor can first establish a context for the data flow. A context is the state maintained by the compressor and decompressor in order to correctly compress or decompress the headers of packets in a flow. Each context is identified using a Context Identifier (CID). The context may include information from previous headers in the data stream, such as static fields and reference values for compression and decompression. The context may further include information indicating the behavior of changes in the dynamic values, such as, for example, inter-packet increases in sequence numbers or timestamps. A value may be associated with the CID, where the value may identify a state maintained by the corresponding compressor and decompressor for respectively compressing and decompressing data contained in the data stream. The context information is conceptually kept in a table, and the table is indexed using the CID value, which is sent with the compressed header and feedback information.

Accordingly, all RoHC packet types have a header format containing: an optional Add-CID (plus-CID) octet (which includes a 4-bit CID); octets with ROHC packet type and indication; one or two octets of a CID; and a body of the packet. The RoHC header may start with a packet type indication or may have a packet type indication immediately after the Add-CID octet. When the RoHC channel is configured with a small CID space, the packet has a CID of the Add-CID if the Add-CID immediately precedes the packet type indication; otherwise, the packet has CID 0. The packet type indication specifies the type of packet, such as RTP, RTCP, TCP, etc.

Although the present disclosure specifically discusses RoHC, the present disclosure may be applied to other types of header compression protocols, such as the ethernet header compression protocol or any other header compression protocol.

In an example RoHC compression scheme, a UE acting as a compressor may participate in a communication session with a BS acting as a decompressor and may transmit initial packets in a data packet flow to a base station. The initial packet may be a packet of media data, e.g., video data or voice data, included as a payload. The packet may include a compressed header containing various information, including the CID and the packet type. In another example compression scheme, the BS, as a compressor, may transmit the initial packet in the data packet flow to the UE, as a decompressor.

In this example implementation, a compressor-decompressor pair maintains a context for each packet flow on each side. The context of each packet flow is identified by the same CID at the compressor and decompressor. The context includes information from previous headers in the packet stream and other possible reference values for compression and decompression. Data describing the packet flow, such as information about how the IP identifier field changes and the inter-packet addition of sequence numbers or timestamps, is also included in the context.

Initially, the compressor and decompressor may not agree on compressing or decompressing a certain packet flow. The compressor may send RoHC packets with static and dynamic information about the packet flow (including CID) to the decompressor to establish the context. Once both static and dynamic fields are set up, the compressor need only send minimal information to advance the regular sequence of compressed header fields.

In some systems (e.g., NR release 15 systems), upon receiving a handover message, the UE detaches from the source cell and stops data transmission on the source cell while synchronizing with the target cell. If the handover is an inter-gNB handover, a Packet Data Convergence Protocol (PDCP) entity may be re-established (e.g., due to a PDCP termination point change). A field (e.g., drb-conteinurohc) in the handover message may indicate whether the PDCP entity continues or resets the ROHC header compression protocol during PDCP re-establishment. This field may be configured in case of reconfiguration with synchronization (where the PDCP terminating point is not changed and full configuration is not indicated).

The ROHC context is typically reset when the PDCP entity is re-established. For example, the ROHC context may be reset due to a PDCP anchor change (e.g., a security key change). In the above-described MBB or DAPS scenario, the re-establishment of PDCP entities may be eliminated during handover by supporting separate PDCP entities on the network side and a common PDCP entity on the UE side. This may help to minimize the impact on mobility interruption time during handover. A user plane radio protocol architecture with a common PDCP entity on the UE may eliminate PDCP re-establishment during handover.

Example header compression handling during handover

Aspects of the present disclosure provide techniques for header compression protocol (e.g., such as robust header compression (ROHC) protocol or other types of header compression) handling during scenarios in which a User Equipment (UE) has multiple connections, such as during a make-before-break (MBB) handover (e.g., as described in the example scenarios above with respect to fig. 6 and 7), a Dual Active Protocol Stack (DAPS) handover, or a dual connectivity scenario. As will be described below, aspects of the present disclosure enable continued use of an ROHC context without requiring a reset. The techniques described herein may be applied to a common Packet Data Convergence Protocol (PDCP) entity during MBB or DAPS handover, as well as to dual connectivity scenarios, including handover based on Dual Connectivity Role Switching (DCRS), or even conventional dual connectivity scenarios. The techniques may be applied to various deployments (e.g., in 5G/New Radio (NR) and/or Long Term Evolution (LTE) systems).

Fig. 8 illustrates example operations 800 that may be performed as part of a header compression handling approach in accordance with certain aspects of the present disclosure. The operations 800 may be performed, for example, by a UE (e.g., the UE 120a in the wireless communication network 100). Operations 800 may be implemented as software components executed and run on one or more processors (e.g., controller/processor 480 of fig. 4). Moreover, the transmission and reception of signals by the UE in operation 800 may be implemented, for example, by one or more antennas (e.g., antenna 452 of fig. 4). In certain aspects, the transmission and/or reception of signals by the UE may be implemented via a bus interface of one or more processors (e.g., controller/processor 480) that obtains and/or outputs the signals.

Operations 800 begin, at 805, with concurrently communicating with a first Base Station (BS) and a second BS, where the first BS is communicated over a connection with the first BS and the second BS is communicated over a connection with the second BS.

At 810, the UE maintains a context of a header compression protocol for the connection with the first BS and the connection with the second BS. Concurrently communicating includes transmitting one or more packets, receiving one or more packets, or both, using a header compression protocol context.

Fig. 9 illustrates example operations 900 that may be performed as part of a RACH procedure in accordance with certain aspects of the present disclosure. Operations 900 may be performed by a networking entity, such as a first BS (e.g., BS110 a in wireless communication network 100). Operation 900 may be complementary to operation 800 performed by the UE. Operations 900 may be implemented as software components executing and running on one or more processors (e.g., controller/processor 440 of fig. 4). Moreover, the transmission and reception of signals by the BS in operation 900 may be implemented, for example, by one or more antennas (e.g., antenna 434 of fig. 4). In certain aspects, the transmission and/or reception of signals by the BS may be implemented via a bus interface of one or more processors (e.g., controller/processor 440) that obtains and/or outputs the signals.

Operations 900 begin, at 905, with communicating concurrently with a UE connected to a first BS while the UE is connected to and communicating with a second BS.

At 910, the base station maintains a context of a header compression protocol for a connection with at least a first BS. Concurrently communicating includes transmitting one or more packets, receiving one or more packets, or both, using a header compression protocol context.

According to certain aspects, in the case of a handover (e.g., an MBB or DAPS handover), once the target link is set up and the source connection has not been released, the UE may send uplink data and a copy of the uplink data using a single active compressor context (e.g., for ROHC) in the UE and network. Alternatively, the UE may send uplink data and a copy of the uplink data on both. In the replication scenario, the UE may support ROHC dual context or single context. Whether or not there is replication, the UE may disable ROHC at least temporarily (e.g., in an Initialization and Refresh (IR) state/mode).

Example header compression with UL data replication and Dual context during Handover

Fig. 10 illustrates header compression handling in the case of header compression (e.g., ROHC) with data replication for uplink transmission and using dual context in the UE. As illustrated in fig. 10, in a first step (step 1), target cell connection setup is performed. In the second step (step 2), the target cell connection setup is completed. In a third step (step 3), the source cell connection release is completed.

As illustrated in fig. 10, separate keys may be used to connect to the source and target cells during the concurrent connection phase. As shown in fig. 10, after connecting to the target cell (at step 2) but before releasing the source cell (at step 3), the UE may communicate the dual header compression context. For example, on the UE, dual ROHC contexts are independently maintained for each link at a common PDCP entity. In some cases, to enable this mode, a PDCP Protocol Data Unit (PDU) may be sent from the UE to the target cell to indicate a dual ROHC context and a duplicate mode of operation. The PDCP PDU may be a control PDU or the PDCP PDU may be a data PDU, wherein certain bits in the data PDU header are set to indicate a dual ROHC context and replication mode of operation.

As shown in fig. 10, the source gNB may forward downlink data to the target gNB (e.g., on an Xn interface). The source gNB may forward decompressed uplink data (e.g., uplink PDCP SDUs) to the target gNB.

As shown in fig. 10, for uplink transmission, the UE may communicate on the link with the source BS using the source ROHC compression context and the UE may communicate on the link with the target BS using the target ROHC compression. As shown in fig. 10, the target gNB may perform two reordering/copy discards after ROHC decompression. Alternatively, the target gNB may perform a single reordering/duplicate discard after ROHC decompression of packets received from the source link and the target link.

Example header compression with UL data replication and Single context during Handover

Fig. 11 illustrates header compression handling with data replication for uplink transmission and a single header compression context at the UE. As shown in fig. 11, the UE may communicate a single header compression context after connecting to the target cell (at step 2) but before releasing the source cell (at step 3). For example, a common PDCP entity at the UE maintains a source or target gNB ROHC context.

As shown in fig. 11, the source gNB does not decompress uplink data (e.g., PDCP PDUs) received therefrom after switching to the single context mode of operation. The source gNB forwards the compressed uplink PDCP SDUs to the target gNB. In this example, the target gbb PDCP entity performs reordering/duplicate discard on UL PDCP PDUs forwarded from the source before performing decompression using a single ROHC context.

Fig. 12 illustrates an example call flow diagram for header compression handling with data replication and single compression header context (e.g., as shown in fig. 11). As shown in fig. 12, after setting up the connection with the target gNB (e.g., at 4b), the UE indicates to the source and target cells to switch to "single ROHC context mode and UL replication". In some examples, the UE common PDCP entity ROHC compressor switches to a single context for ROHC compression for links to the source and target gnbs. In some examples, at 5A, after the target link is set up, the UE sends an indication in a PDCP control PDU or in PDCP header bits to explicitly indicate to the source and target gnbs. In some examples, at 5B, the source gNB sends the ROHC context to the target gNB. In some examples, the target gNB acknowledges receipt of the ROHC context and initiates replication by sending PDCP control PDUs at 5C. In some examples, at 5D, the target gNB starts the single ROHC context decompression mode.

Example header compression Disable

According to certain aspects, the UE may switch to an Initialization and Refresh (IR) operating state.

Fig. 13 is an example call flow diagram for header compression handling in IR mode/state. In some examples, the header compression protocol may be disabled in the IR mode/state. As shown in fig. 13, the common PDCP entity at the UE switches to the IR mode/state. During handover, the UE indicates to the source and target gnbs to switch to IR mode/state. In some examples, after the target link is set up and before the source link is released, the UE may send PDCP control PDUs, or PDCP header bits, to the source and target gnbs to explicitly indicate the IR mode/status. In some examples, the source and target gnbs determine the IR mode switch based on the switch message. In some examples, the UE sends PDCP control PDUs to the source gNB before the target gNB link is set up. The source and target gNB header compression decompressor entities may then initiate IR mode. In some examples, the UE sends PDCP control PDUs to the target gNB after the connection to the source gNB is released.

In some cases, procedures may be used to temporarily disable ROHC, rather than switching to an IR mode of operation. For example, the UE may send PDCP control PDUs to the source and target gnbs to indicate the disabling of ROHC.

Example header compression handling with Single context and without DL data replication

According to certain aspects, ROHC processing may be used for downlink communications during handover. During handover, data replication may not be used or may be used on both links once the target link is set up and before the source connection is released. For downlink ROHC with data replication, the UE and the network may maintain dual/independent ROHC context. For downlink ROHC without data replication, the UE may maintain a single context. In some examples, the UE may disable ROHC in IR mode.

Fig. 14 illustrates an example of header compression handling during handover with a single context for downlink header compression in a UE. As shown in fig. 14, after setting up a connection with a target cell and before releasing the connection with the source cell, the UE maintains a single DL ROHC context at the common PDPC entity. For example, the UE may maintain a context for a source or target gbb connection. After sending the SN status transmission with the ROHC context to the target gNB, the source gNB does not decompress the received PDCP PDUs. As shown, the source gNB sends uncompressed UL PDPC SDUs to the target gNB. The UE performs reordering/duplicate discard and ROHC decompression on DL PDUs received on the target link using a PDCP entity (e.g., a common PDCP entity as described above). Thus, from the UE perspective, the approach may be seamless. Fig. 15 illustrates an example call flow diagram for header compression handling during handover with a single context for downlink header compression in a UE (e.g., as shown in fig. 14). Fig. 16 illustrates an example call flow diagram for header compression handling during handover in IR/disabled mode.

Example bearer termination point change for split bearers

The techniques described herein may be applied to other scenarios, including dual connectivity scenarios involving split bearers (e.g., with links to both the target and source gnbs).

Fig. 17 illustrates an example call flow diagram for handling in the case of a change of bearer termination point for a split bearer. In this example, the source gNB may indicate to the target gNB about ROHC context and IR operating mode. After step 7, the target gNB may send a PDCP control PDU to the UE, or in PDCP header bits to the UE. The UE switches to IR mode/ROHC disabled mode after receiving the PDCP control PDU. As shown in fig. 17, after releasing the source connection in MBB HO, the target cell signals the UE to switch to ROHC compressed mode of operation (PDCP control PDU sent to the UE after the source is released; or the target gNB is determined based on step 9).

When a split bearer is supported and the PDCP anchor has to be changed to the target gNB, following conventional (e.g., release 15) procedures may result in PDCP re-establishment and ROHC context reset and some interruption.

One solution to avoid this re-establishment is to extend the same PDCP entity (e.g., a common PDCP entity) for target link handling. In such a case, upon indicating a handover of the PDCP anchor (i.e., a change of the bearer termination point from the source gNB to the target gNB via an RRC reconfiguration message sent to the UE), the UE decrypts packets received on the target link using the same ROHC decompression context but a different security context.

The source gNB may forward the ROHC context to the target gNB, and the target gNB uses the transferred ROHC context to send DL data forwarded on Xn. In some cases, the bearer termination point change may be designed to avoid PDCP re-establishment/ROHC reset even for DCRS-based HO bearer termination point change. The approach can also be extended to apply to conventional DC bearer termination point changes.

Fig. 18 illustrates an example of DL ROHC handling for a split bearer scenario. As illustrated, in a first step (step 1), a target cell connection setup is performed. In the second step (step 2), the target cell connection setup is completed and the source cell configures the PDCP anchor and split bearer during MBB HO. In the third step (step 3), the PDCP anchor is handed over to the target gNB without PDCP re-establishment. As illustrated, separate keys may be used to connect to the source and target cells during the concurrent connection phase.

When a split bearer is supported and the PDCP anchor has to be changed to the target gNB, following conventional (e.g., release 15) procedures may result in PDCP re-establishment and ROHC context reset and some interruption.

One solution to avoid this re-establishment is to extend the same PDCP entity (e.g., a common PDCP entity) for target link handling. Upon instructing a PDCP anchor to handover from a source gNB to a target gNB (e.g., bearer termination point change) via an RRC reconfiguration message sent to the UE, the UE may decrypt packets received on the target link using the same ROHC decompression context but a different security context. In this case, the source gNB may forward the ROHC context to the target gNB, and the target gNB uses the passed ROHC context to send DL data forwarded on Xn.

Fig. 19 illustrates an example of UL ROHC handling for a split bearer scenario. As illustrated, in a first step (step 1), a target cell connection setup is performed. In the second step (step 2), the target cell connection setup is completed and the source cell configures the PDCP anchor and split bearer during MBB HO. In the third step (step 3), the PDCP anchor is handed over to the target gNB without PDCP re-establishment. As illustrated, separate keys may be used to connect to the source and target cells during the concurrent connection phase.

In this example, the UE uses the same ROHC compression context even after the bearer termination point (e.g., PDCP anchor) is changed to the target gNB. In this example, the source gNB sends a UL ROHC context to the target gNB, and the target gNB decompresses PDCP PDUs received on the split bearer using the transferred ROHC context.

Header compression with single context and no UL data duplication during handover

Fig. 20 illustrates an example user plane radio architecture for uplink ROHC handling with single context and no data replication during handover.

As shown in fig. 20, at step 2, after the target cell connection setup is complete and before the source cell connection is released, the UE uplink data communications (transmission and reception) may be handed over to the target cell connection. That is, the UE hands over UL data transmission to the target cell after a successful RACH on the target cell. The source cell and the target cell perform a downlink data forwarding procedure. Thus, during handover (e.g., DAPS or MBB handover, which may be inter-CU), UL data is only transmitted on either the source connection or the target connection, but not both.

During the target cell connection setup, when the UE is performing RACH on the target cell, the UE uses the source ROHC compression context to transfer any UL data available in the PDCP buffer (at step a). This UL data is only received by the source gNB, and the source gNB may use its corresponding ROHC decompression context (at step B) for the data. The source gNB forwards the decompressed data on NG-U to the 5 GC.

After the target cell connection setup (e.g., successful transmission of the RRC reconfiguration complete message), the UL data available in the PDCP buffer is only transferred on the target connection (at step C). If drb-conteniueroch is set to TRUE (TRUE) and instructs the PDCP entity to continue the ROHC context, the common PDCP entity on the UE can continue the ROHC context even after switching UL data transmission from the source connection to the target connection — without PDCP re-establishment (e.g., maintaining PDCP SN continuity). Thus, only the target gNB receives UL data from the UE (at step D) -the source gNB does not receive any UL data after the connection with the target gNB is set up. The source gbb passes ROHC context to the target gbb over Xn via SN status data transmission to support ROHC continuity on the target connection during handover. If drb-conteinurohc is set to FALSE (FALSE), the common PDCP entity of the UE context switches ROHC to target connection ROHC handling after switching UL data transmission from the source connection to the target connection. The source gbb may not pass the ROHC context to the target gbb — because ROHC continuity is not required.

Header compression with downlink data replication and dual context during handover

Fig. 21 illustrates an example user plane radio architecture for uplink ROHC handling with dual context and with data replication during handover.

As shown in fig. 21, after the target cell connection setup is complete (at step 2) and before the source cell connection is released, the UE downlink data communications (e.g., transmissions and receptions) may be handed over to the target cell connection. That is, the source cell performs a DL data forwarding procedure with the target cell and stops DL data transfer to the target cell. In some cases, there may be periods with data duplication during which the UE may receive DL data on both the source and target connections simultaneously during handover.

During target cell connection setup (e.g., when the UE is performing RACH on the target cell), DL data may be transmitted by the source gNB using the source ROHC compression context (at step a). The DL data is received by the UE (at step B) and decompressed using the source ROHC decompression context.

Upon completion of the target cell connection setup (e.g., successful transmission of RRC reconfiguration complete), the source and target gbbs coordinate to initiate SN status data transmission. The source gbb forwards PDCP SDUs (uncompressed) to the target gbb (at step C) and indicates the PDCP SNs to be used for DL packets. In some cases, the source gNB may also send duplicate SDUs compressed using the source gNB ROHC context to the UE. After compressing the packet with the target gbb ROHC context, the target gbb also conveys PDCP SDUs received from the source gbb to the UE. Thus, the UE may receive DL packets compressed with the source or target gNB context during the handover period (at steps E and F). To support ROHC for these packets, the UE maintains dual ROHC context at the common PDCP entity until the source connection is released, as shown in fig. 21. The UE may determine a security key to be used for decryption/integrity verification and a subsequent ROHC context to be used for decompressing the PDU based on the logical channel on which the PDU was received.

Thus, according to certain aspects, during handover (e.g., during an inter-CU MBB HO or DAPS HO), both the source gNB and target gNB link ROHC contexts may be maintained in the UE common PDCP entity until the source connection is released. According to certain aspects, during handover (e.g., during an inter-CU MBB HO or DAPS HO), a common PDCP entity in the UE applies different ROHC contexts (e.g., source link or target link ROHC contexts, respectively) to decompress data received on different logical channels associated with the source link and the target link.

Fig. 22 illustrates a communication apparatus 2200 that may include various components (e.g., corresponding to means plus function components) configured to perform operations of the techniques disclosed herein, such as the operations illustrated in fig. 8. The communication device 2200 includes a processing system 2202 coupled to a transceiver 2208 (e.g., a transmitter and/or a receiver). The transceiver 2208 is configured to transmit and receive signals (such as various signals as described herein) for the communication device 2200 via the antenna 2210. The processing system 2202 may be configured to perform processing functions for the communication device 2200, including processing signals received and/or to be transmitted by the communication device 2200.

The processing system 2202 includes a processor 2204 coupled to a computer-readable medium/memory 2212 via a bus 2206. In certain aspects, the computer-readable medium/memory 2212 is configured to store instructions (e.g., computer-executable code) that, when executed by the processor 2204, cause the processor 2204 to perform the operations illustrated in fig. 8 or other operations for performing the various techniques for header compression handling during handover discussed herein. In certain aspects, according to aspects of the disclosure, the computer-readable medium/memory 2212 stores code 2214 for concurrently communicating with the first BS and the second BS during the handoff; and code 2216 for maintaining a header compression context. In certain aspects, the processor 2204 has circuitry configured to implement code stored in the computer-readable medium/memory 2212. According to aspects of the disclosure, the processor 2204 includes circuitry 2218 for concurrently communicating with the first BS and the second BS during handoff; and circuitry 2220 for maintaining a header compression context.

Fig. 23 illustrates a communication apparatus 2300 that may include various components (e.g., corresponding to means plus function components) configured to perform operations of the techniques disclosed herein, such as the operations illustrated in fig. 9. The communication device 2300 includes a processing system 2302 that is coupled to a transceiver 2308 (e.g., a transmitter and/or a receiver). The transceiver 2308 is configured to transmit and receive signals (such as various signals as described herein) for the communication device 2300 via the antenna 2310. The processing system 2302 may be configured to perform processing functions for the communication device 2300, including processing signals received by and/or to be transmitted by the communication device 2300.

The processing system 2302 includes a processor 2304 coupled to a computer-readable medium/memory 2312 via a bus 2306. In certain aspects, the computer-readable medium/memory 2312 is configured to store instructions (e.g., computer-executable code) that, when executed by the processor 2304, cause the processor 2304 to perform the operations illustrated in fig. 9 or other operations for performing the various techniques for header compression protocol handling during handoff discussed herein. In certain aspects, according to aspects of the disclosure, the computer-readable medium/memory 2312 stores code 2314 for concurrently communicating with a User Equipment (UE) connected to a first Base Station (BS) while the UE is connected to and communicating with a second BS during a handover procedure; code 2316 for maintaining a context of a header compression protocol for a connection with the UE and at least the first BS. In certain aspects, the processor 2304 has circuitry configured to implement code stored in the computer-readable medium/memory 2312. According to aspects of the disclosure, the processor 2304 includes circuitry 2318 for concurrently communicating with a UE connected to a first BS while the UE is connected to and communicating with a second BS during a handover procedure; circuitry 2320 for maintaining context of a header compression protocol for a connection with the UE and at least the first BS.

Illustrative aspects

In a first aspect, a method of wireless communication performed by a User Equipment (UE) includes concurrently communicating with a first Base Station (BS) and a second BS during a handover procedure, wherein the first BS is communicated over a connection with the first BS and the second BS is communicated over a connection with the second BS. The UE maintains a context of a header compression protocol for a connection with a first BS and a connection with a second BS. Concurrently communicating includes using a context of a header compression protocol to send one or more packets, receive one or more packets, or both.

In a second aspect, in combination with the first aspect, the header compression protocol comprises a robust header compression (RoHC) protocol.

In a third aspect, in combination with one or more of the first and second aspects, the handover procedure is a make-before-break (MBB) handover procedure or a Dual Active Protocol Stack (DAPS) handover procedure.

In a fourth aspect, in combination with one or more of the first through third aspects, the concurrently communicating with the first BS and the second BS comprises: a common Packet Data Convergence Protocol (PDCP) function is performed for a connection with a first BS and a connection with a second BS before the connection with the first BS is released as part of an MBB or DAPS handover procedure.

In a fifth aspect, in combination with one or more of the first through fourth aspects, concurrently communicating with the first BS and the second BS comprises communicating over a split radio bearer having at least a first link to the first BS and a second link to the second BS.

In a sixth aspect, in combination with one or more of the first through fifth aspects, maintaining the context of the header compression protocol comprises maintaining a single active compressor context and a dual active decompressor context of the header compression protocol.

In a seventh aspect, in combination with one or more of the first through sixth aspects, communicating concurrently with the first BS and the second BS further comprises: transmitting uplink data on a single connection with the second BS or the first BS, and compressing the data using a single active context of a header compression protocol that corresponds to the connection over which the data is transmitted; and/or receive downlink data over a connection with the second BS or the first BS or from both the second BS and the first BS simultaneously and decompress the downlink data using a decompressor context of a header compression protocol corresponding to the connection over which the data was received.

In an eighth aspect, in combination with one or more of the first through seventh aspects, the UE sends a Packet Data Convergence Protocol (PDCP) control Protocol Data Unit (PDU) to the first BS after establishing a connection with the second BS to indicate uplink data handover to the second BS and maintenance of a single active context corresponding to the second BS.

In a ninth aspect, in combination with one or more of the first through eighth aspects, maintaining the context of the header compression protocol includes switching to an Initialization and Refresh (IR) operating state.

In a tenth aspect, in combination with one or more of the first to ninth aspects, the UE sends Packet Data Convergence Protocol (PDCP) Protocol Data Units (PDUs) to independently signal the first BS and the second BS to switch to the IR operating state.

In an eleventh aspect, in combination with one or more of the first to tenth aspects, the UE requests the second BS to switch to using the header compression protocol in another compressed operating state after the connection with the first BS is released.

In a twelfth aspect, in combination with one or more of the first to eleventh aspects, maintaining the context of the header compression protocol comprises at least temporarily disabling the header compression protocol.

In a thirteenth aspect, in combination with one or more of the first to twelfth aspects, the concurrently communicating comprises sending uplink data on a connection with both the second BS and the first BS and/or receiving downlink data on a connection with both the second BS and the first BS.

In a fourteenth aspect, in combination with one or more of the first through thirteenth aspects, maintaining the context of the header compression protocol comprises maintaining, at the UE, a dual compressor context of the header compression protocol independently for the connection with the second BS and the connection with the first BS.

In a fifteenth aspect, in combination with one or more of the first to fourteenth aspects, the UE sends a Packet Data Convergence Protocol (PDCP) Protocol Data Unit (PDU) to the second BS to indicate maintenance of dual context.

In a sixteenth aspect, in combination with one or more of the first to fifteenth aspects, the PDCP PDU corresponds to a PDCP control PDU or sets a specific bit in a header of a PDCP data PDU, and the PDCP PDU is transmitted before activating uplink data replication on a connection with both the second BS and the first BS.

In a seventeenth aspect, in combination with one or more of the first to sixteenth aspects, the UE activates uplink data replication after sending the PDCP PDUs or after receiving a positive acknowledgement for the PDCP PDUs.

In an eighteenth aspect, a method of wireless communication performed by a first Base Station (BS) comprises: a User Equipment (UE) connected with a first Base Station (BS) communicates concurrently with a second Base Station (BS) while the UE is connected to and communicating with the second base station during a handover procedure. The first BS maintains a context of a header compression protocol for a connection with the UE and at least the first BS. Concurrently communicating includes using a context of a header compression protocol to send one or more packets, receive one or more packets, or both.

In a nineteenth aspect, in combination with the eighteenth aspect, the header compression protocol comprises at least a robust header compression (RoHC) protocol.

In a twentieth aspect, in combination with one or more of the eighteenth and nineteenth aspects, the handover procedure is a Make Before Break (MBB) handover procedure or a Dual Active Protocol Stack (DAPS) handover procedure.

In a twenty-first aspect, in combination with one or more of the eighteenth through twentieth aspects, concurrently communicating comprises: a common Packet Data Convergence Protocol (PDCP) function is performed for the connection with the UE and the first BS and the connection with the UE and the second BS before the connection with the first BS is released as part of an MBB or DAPS handover procedure.

In a twenty-second aspect, in combination with one or more of the eighteenth to twenty-first aspects, concurrently communicating comprises communicating over a split radio bearer having at least a first link to the first BS and a second link to the second BS.

In a twenty-third aspect, in combination with one or more of the eighteenth through twenty-second aspects, maintaining the context of the header compression protocol comprises maintaining a single active context of the header compression protocol.

In a twenty-fourth aspect, in combination with one or more of the eighteenth through twenty-fourth aspects, concurrently communicating comprises: sending downlink data over a single connection with the UE and compressing the data using a single active context of a header compression protocol; and/or receive uplink data over a single connection with the UE and decompress the downlink data using a single activity context of a header compression protocol.

In a twenty-fifth aspect, in combination with one or more of the eighteenth to twenty-fourth aspects, the first BS reorders and/or discards duplicate data of uplink Packet Data Convergence Protocol (PDCP) Protocol Data Units (PDUs) forwarded from the second BS before performing decompression using a single context of a header compression protocol.

In a twenty-sixth aspect, in combination with one or more of the eighteenth through twenty-fifth aspects, maintaining the context of the header compression protocol comprises at least temporarily disabling the header compression protocol.

The methods disclosed herein comprise one or more steps or actions for achieving the described method. The method steps and/or actions may be interchanged with one another without departing from the scope of the claims. In other words, unless a specific order of steps or actions is specified, the order and/or use of specific steps and/or actions may be modified without departing from the scope of the claims.

As used herein, a phrase referring to "at least one of a list of items" refers to any combination of these items, including a single member. By way of example, "at least one of a, b, or c" is intended to encompass: a. b, c, a-b, a-c, b-c, and a-b-c, and any combination having a plurality of the same elements (e.g., a-a-a, a-a-b, a-a-c, a-b-b, a-c-c, b-b-b, b-b-c, c-c, and c-c-c, or any other ordering of a, b, and c).

As used herein, the term "determining" encompasses a wide variety of actions. For example, "determining" can include calculating, computing, processing, deriving, studying, looking up (e.g., looking up in a table, a database, or another data structure), ascertaining, and the like. Also, "determining" may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), and the like. Also, "determining" may include resolving, selecting, choosing, establishing, and the like.

The techniques described herein may be used for various wireless communication networks, such as LTE, CDMA, TDMA, FDMA, OFDMA, SC-FDMA, and other networks. The terms "network" and "system" are often used interchangeably. A CDMA network may implement radio technologies such as Universal Terrestrial Radio Access (UTRA), CDMA2000, and so on. UTRA includes wideband CDMA (wcdma) and other variants of CDMA. cdma2000 covers IS-2000, IS-95 and IS-856 standards. TDMA networks may implement radio technologies such as global system for mobile communications (GSM). An OFDMA network may implement radio technologies such as NR (e.g., 5G RA), evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE802.11(Wi-Fi), IEEE 802.16(WiMAX), IEEE 802.20, Flash-OFDMA, and the like. UTRA and E-UTRA are part of the Universal Mobile Telecommunications System (UMTS). NR is an emerging wireless communication technology that is being developed in conjunction with the 5G technology forum (5 GTF). 3GPP Long Term Evolution (LTE) and LTE-advanced (LTE-A) are versions of UMTS that use E-UTRA. UTRA, E-UTRA, UMTS, LTE-A and GSM are described in literature from an organization named "third Generation partnership project" (3 GPP). cdma2000 and UMB are described in documents from an organization named "third generation partnership project 2" (3GPP 2).

In 3GPP, the term "cell" can refer to a coverage area of a node B and/or a node B subsystem serving that coverage area, depending on the context in which the term is used. In an NR system, the terms "cell" and gNB, node B, 5G NB, AP, NR BS, or TRP may be interchangeable.

UEs 120 (e.g., 120x, 120y, etc.) may be dispersed throughout wireless communication network 100, and each UE may be stationary or mobile. A UE may also be referred to as a mobile station, a terminal, an access terminal, a subscriber unit, a station, a client equipment (CPE), a cellular phone, a smartphone, a Personal Digital Assistant (PDA), a wireless modem, a wireless communication device, a handheld device, a laptop, a cordless phone, a Wireless Local Loop (WLL) station, a tablet device, a camera, a gaming device, a netbook, a smartbook, an ultrabook, a medical device or medical equipment, a biometric sensor/device, a wearable device (such as a smartwatch, a smart garment, smart glasses, a smart wristband, smart jewelry (e.g., a smart ring, a smart necklace, etc.)), an entertainment device (e.g., a music device, a video device, a satellite radio, etc.), a vehicle component or sensor, a smart meter/sensor, industrial manufacturing equipment, a global positioning system device, a smart meter/sensor, a smart phone, a Wireless Local Loop (WLL) station, a tablet device, a camera, a gaming device, a netbook, an ultrabook, a smart book, smart garment, smart glasses, smart wristband, smart jewelry, etc.), an entertainment device, a smart watch, a smart phone, a, Or any other suitable device configured to communicate via a wireless or wired medium. Some UEs may be considered evolved or Machine Type Communication (MTC) devices or evolved MTC (emtc) devices. MTC and eMTC UEs include, for example, a robot, a drone, a remote device, a sensor, a meter, a monitor, a location tag, etc., which may communicate with a BS, another device (e.g., a remote device), or some other entity. A wireless node may provide connectivity for or to a network, e.g., a wide area network such as the internet or a cellular network, e.g., via a wired or wireless communication link. Some UEs may be considered internet of things (IoT) devices.

The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean "one and only one" (unless specifically so stated) but rather "one or more". The term "some" or "an" refers to one or more, unless specifically stated otherwise. All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later come to be known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed by the claims. Moreover, nothing disclosed herein is intended to be dedicated to the public regardless of whether such disclosure is explicitly recited in the claims. No element of the claims should be construed under the provisions of 35u.s.c. § 112 sixth clause, unless the element is explicitly recited using the wording "means for … …" or in the case of a method claim the element is recited using the wording "step for … …".

The various operations of the methods described above may be performed by any suitable means capable of performing the corresponding functions. These means may include various hardware and/or software components and/or modules, including but not limited to, circuits, Application Specific Integrated Circuits (ASICs), or processors. Generally, where there are operations illustrated in the figures, the operations may have corresponding counterpart means plus functional components with similar numbering.

The various illustrative logical blocks, modules, and circuits described in connection with the disclosure may be implemented or performed with a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other Programmable Logic Device (PLD), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any commercially available processor, controller, microcontroller or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

If implemented in hardware, an example hardware configuration may include a processing system in the wireless node. The processing system may be implemented with a bus architecture. The bus may include any number of interconnecting buses and bridges depending on the specific application of the processing system and the overall design constraints. The bus may link together various circuits including the processor, the machine-readable medium, and the bus interface. A bus interface may be used to connect a network adapter or the like to the processing system via the bus. A network adapter may be used to implement the signal processing functions of the PHY layer. In the case of a user terminal 120 (see fig. 1), a user interface (e.g., keypad, display, mouse, joystick, etc.) may also be connected to the bus. The bus may also link various other circuits such as timing sources, peripherals, voltage regulators, power management circuits, and the like, which are well known in the art, and therefore, will not be described any further. A processor may be implemented with one or more general and/or special purpose processors. Examples include microprocessors, microcontrollers, DSP processors, and other circuitry capable of executing software. Those skilled in the art will recognize how best to implement the functionality described with respect to the processing system, depending on the particular application and the overall design constraints imposed on the overall system.

If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Software should be construed broadly to mean instructions, data, or any combination thereof, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. The processor may be responsible for managing the bus and general processing, including the execution of software modules stored on the machine-readable storage medium. A computer readable storage medium may be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. By way of example, the machine-readable medium may comprise a transmission line, a carrier wave modulated by data, and/or a computer-readable storage medium separate from the wireless node having instructions stored thereon, all of which may be accessed by a processor through a bus interface. Alternatively or additionally, the machine-readable medium or any portion thereof may be integrated into a processor, such as a cache and/or a general register file, as may be the case. Examples of a machine-readable storage medium may include RAM (random access memory), flash memory, ROM (read only memory), PROM (programmable read only memory), EPROM (erasable programmable read only memory), EEPROM (electrically erasable programmable read only memory), registers, magnetic disk, optical disk, hard drive, or any other suitable storage medium, or any combination thereof, as examples. The machine-readable medium may be embodied in a computer program product.

A software module may comprise a single instruction, or many instructions, and may be distributed over several different code segments, among different programs, and across multiple storage media. The computer readable medium may include several software modules. These software modules include instructions that, when executed by an apparatus, such as a processor, cause a processing system to perform various functions. These software modules may include a transmitting module and a receiving module. Each software module may reside in a single storage device or be distributed across multiple storage devices. As an example, a software module may be loaded into RAM from a hard drive when a triggering event occurs. During execution of the software module, the processor may load some instructions into the cache to increase access speed. One or more cache lines may then be loaded into a general register file for execution by the processor. When referring to the functionality of a software module below, it will be understood that such functionality is implemented by the processor when executing instructions from the software module.

Any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a web site, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL), or wireless technologies such as Infrared (IR), radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Disk (disk) and disc (disc), as used herein, includes Compact Disc (CD), laser disc, optical disc, Digital Versatile Disc (DVD), floppy disk, anddisks, where a disk (disk) usually reproduces data magnetically, and a disk (disc) reproduces data optically with a laser. Thus, in some aspects, computer-readable media may comprise non-transitory computer-readable media (e.g., tangible media). Additionally, for other aspects, the computer-readable medium may comprise a transitory computer-readable medium (e.g., a signal). Combinations of the above should also be included within the scope of computer-readable media.

Thus, certain aspects may comprise a computer program product for performing the operations presented herein. For example, such a computer program product may include a computer-readable medium having instructions stored (and/or encoded) thereon, the instructions being executable by one or more processors to perform the operations described herein.

Further, it is to be appreciated that modules and/or other appropriate means for performing the methods and techniques described herein can be downloaded and/or otherwise obtained by a user terminal and/or base station where applicable. For example, such a device can be coupled to a server to facilitate the transfer of an apparatus for performing the methods described herein. Alternatively, the various methods described herein can be provided via a storage device (e.g., RAM, ROM, a physical storage medium such as a Compact Disc (CD) or floppy disk, etc.), such that the apparatus can obtain the various methods upon coupling or providing the storage device to a user terminal and/or base station. Further, any other suitable technique suitable for providing the methods and techniques described herein to a device may be utilized.

It is to be understood that the claims are not limited to the precise configuration and components illustrated above. Various changes, substitutions and alterations in the arrangement, operation and details of the method and apparatus described above may be made without departing from the scope of the claims.