Header compression handling during handoff

Abstract

Aspects of the present disclosure relate to wireless communications, and more particularly to handling header compression in scenarios with concurrent connections, such as build-before-break (MBB) handover or dual connectivity (DC) scenarios. A wireless communication method 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 with on a connection with the first BS and the second BS is communicated with on a connection with the second BS. The UE maintains a context of a header compression protocol for the connection with the first BS and for the connection with the second BS. Concurrently communicating includes sending one or more packets, receiving one or more packets, or both, using the context of the header compression protocol.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Application No. 16 / 808,091, filed on March 3, 2020, which claims the benefit of and priority to U.S. Provisional Application No. 62 / 847,262, filed on May 13, 2019, both of which are assigned to the assignee of the present application and are hereby expressly incorporated herein by reference in their entirety as if fully set forth below and for all applicable purposes.

[0003] background

[0004] Public domain:

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

[0006] Related technical description:

[0007] Wireless communication systems are widely deployed to provide various telecommunication services such as telephony, video, data, messaging, and broadcast. Typical wireless communication systems may employ multiple access technologies capable of supporting communication with multiple users by sharing available system resources (e.g., bandwidth, transmit power). Examples of such multiple access technologies 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.

[0008] These multiple access technologies have been adopted in various telecommunication standards to provide a common protocol that enables different wireless devices to communicate at a city, country, region, and even global level. An example of an emerging telecommunication standard is called New Radio (NR), for example, 5G radio access. It is designed to better support mobile broadband Internet access by improving spectrum 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 supports beamforming, multiple-input multiple-output (MIMO) antenna technology, and carrier aggregation.

[0009] 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 technologies and the telecommunication standards that employ these technologies.

[0010] Brief Overview

[0011] 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 in the appended claims, some features will now be discussed briefly. After considering this discussion, and particularly after reading the section entitled "Detailed Description," it will be understood how the features of the present disclosure provide advantages including improved communication between access points and stations in a wireless network.

[0012] Certain aspects of the present disclosure provide a method for wireless communication by a user equipment (UE). The method generally includes communicating with a first base station (BS) and a second BS concurrently, wherein the communication is with the first BS on a connection with the first BS and the communication is with the second BS on a connection with the second BS. The method generally includes maintaining a context of a header compression protocol for the connection with the first BS and the connection with the second BS. Concurrently communicating includes sending one or more packets, receiving one or more packets, or both using the context of the header compression protocol.

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

[0014] Certain aspects of the present disclosure provide a device for wireless communication. The device generally includes at least a processor coupled to a memory. The memory includes code that can be executed by the at least one processor so that the device communicates with a first BS and a second BS concurrently, wherein the device communicates with the first BS on a connection with the first BS and communicates with the second BS on a connection with the second BS. The memory includes code that can be executed by the at least one processor so that the device maintains a context of a header compression protocol for a connection with the first BS and a connection with the second BS. Concurrent communication includes sending one or more packets, receiving one or more packets, or both using the context of the header compression protocol.

[0015] Certain aspects of the present disclosure provide an apparatus for wireless communication. The apparatus generally includes at least a processor coupled to a memory. The memory includes code that can be executed by the at least one processor to cause the apparatus to perform the following operations: concurrently communicate with the UE while a UE connected to the apparatus is connected to another apparatus and communicates with the other apparatus. The memory includes code that can be executed by the at least one processor to cause the apparatus to perform the following operations: maintain a context of a header compression protocol for a connection with the UE and at least the apparatus. Concurrently communicating includes sending one or more packets, receiving one or more packets, or both using the context of the header compression protocol.

[0016] 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 communication is with the first BS on a connection with the first BS and the communication is with the second BS on a connection with the second BS. The apparatus generally includes means for maintaining a context of a header compression protocol for the connection with the first BS and the connection with the second BS. Concurrently communicating includes sending one or more packets, receiving one or more packets, or both using the context of the header compression protocol.

[0017] Certain aspects of the present disclosure provide a device for wireless communication. The device generally includes a device for concurrently communicating with a UE connected to the device while the UE is connected to another device and communicates with the other device. The device generally includes a device for maintaining a context of a header compression protocol for a connection with the UE and at least the device. Concurrently communicating includes sending one or more packets, receiving one or more packets, or both using the context of the header compression protocol.

[0018] Certain aspects of the present disclosure provide a computer-readable medium having computer executable code stored thereon for wireless communication. The computer executable code generally includes code for communicating concurrently with a first BS and a second BS, wherein the communication is with the first BS on a connection with the first BS and the communication is with the second BS on 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 the first BS and a connection with the second BS. Concurrently communicating includes sending one or more packets, receiving one or more packets, or both using the context of the header compression protocol.

[0019] Certain aspects of the present disclosure provide a computer-readable medium on which computer-executable code for wireless communication is stored. The computer-executable code generally includes code for concurrently communicating with a UE connected to a first BS while the UE is connected to a second BS and communicating with the second BS. The computer-executable code generally includes code for maintaining a context of a header compression protocol for a connection with the UE and at least the first BS. Concurrently communicating includes sending one or more packets, receiving one or more packets, or both using the context of the header compression protocol.

[0020] To achieve the foregoing and related ends, the one or more aspects include the features fully described below and particularly pointed out in the claims. The following description and drawings set forth in detail certain illustrative features of the one or more aspects. However, these features are merely indicative of several of the various ways in which the principles of the various aspects may be employed, and this description is intended to cover all such aspects and their equivalents. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] In order to understand in detail the manner in which the above-stated features of the present disclosure are used, a more particular description of the content briefly summarized above may be made with reference to various aspects, some of which are illustrated in the accompanying drawings. It should be noted, however, that the accompanying drawings illustrate only certain typical aspects of the present disclosure and are not to be considered limiting of its scope, as the description may admit to other equally effective aspects.

[0023] Figure 1 is a block diagram conceptually illustrating an example wireless communication network in accordance with certain aspects of the present disclosure.

[0024] Figure 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.

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

[0026] Figure 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.

[0027] Figure 5 An example of a frame format for a New Radio (NR) system is illustrated in accordance with certain aspects of the present disclosure.

[0028] Figure 6 A call flow diagram illustrating an example handover procedure.

[0029] Figure 7 A call flow diagram illustrating another example switching procedure.

[0030] Figure 8

[0013] Example operations for wireless communications by a user equipment (UE) are illustrated, in accordance with certain aspects of the present disclosure.

[0031] Fig. 9

[0013] Example operations for wireless communications by a network entity are illustrated in accordance with certain aspects of the present disclosure.

[0032] Fig.10 is an example of a user plane architecture illustrating header compression with uplink data duplication and with dual context during handover in a wireless communication network in accordance with aspects of the present disclosure.

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

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

[0035] 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.

[0036] 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.

[0037] 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.

[0038] 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.

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

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

[0041] Fig.19 is an example user plane architecture illustrating header compression during handover with a bearer termination point change for a split bearer in a wireless communication network in accordance with aspects of the present disclosure.

[0042] 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.

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

[0044] Fig. 22 Illustrated are communications devices that may include various components configured to perform operations for the techniques disclosed herein in accordance with aspects of the present disclosure.

[0045] Fig.23 Illustrated are communications devices that may include various components configured to perform operations for the techniques disclosed herein in accordance with aspects of the present disclosure.

[0046] 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 in other aspects without specific recitation.

[0047] Detailed Description

[0048] Various aspects of the present disclosure provide apparatus, methods, processing systems, and computer-readable media for handling header compression in scenarios where 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 dual connectivity (DC) scenario.

[0049] The following description provides an example of header compression handling during switching, without limiting the scope, applicability or examples set forth in the claims. Changes may be made to the functions and arrangements of the elements discussed without departing from the scope of the present disclosure. Various examples may appropriately omit, replace, or add various procedures or components. For example, the described method may be performed in an order different from the order described, and various steps may be added, omitted, or combined. Moreover, the features described with reference to some examples may be combined in some other examples. For example, any number of aspects set forth herein may be used to implement a device or practice method. In addition, the scope of the present disclosure is intended to cover such devices or methods practiced using other structures, functionalities, or structures and functionalities as supplements to the various aspects of the present disclosure set forth herein or in addition. It should be understood that any aspect of the present disclosure disclosed herein may be implemented by one or more elements of the claims. The wording "exemplary" is used herein to mean "used as an example, instance, or explanation". Any aspect described as "exemplary" herein need not be interpreted as being superior to or superior to other aspects.

[0050] In general, any number of wireless networks may be deployed in a given geographic area. Each wireless network may support a specific radio access technology (RAT) and may operate on one or more frequencies. RAT may also be referred to as radio technology, air interface, etc. Frequency may also be referred to as carrier, frequency channel, etc. Each frequency may support a single RAT in a given geographic area to avoid interference between wireless networks of different RATs. In some cases, NR or 5G RAT networks may be deployed.

[0051] The techniques described herein can be used for various wireless networks and radio technologies. Although various aspects may be described herein using terms commonly associated with 3G, 4G, and / or 5G wireless technologies, various aspects of the present disclosure may be applied in other generations such as later NR technologies.

[0052] NR can support various wireless communication services, such as enhanced mobile broadband (eMBB) targeting wide bandwidth (e.g., more than 80MHz), millimeter wave (mmW) targeting high carrier frequencies (e.g., 24GHz to 53GHz or above), massive MTC (mMTC) targeting non-backward compatible MTC technologies, and / or mission critical services targeting ultra-reliable low latency communications (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 can coexist in the same subframe. Beamforming can be supported and the beam direction can be dynamically configured. MIMO transmission with precoding can also be supported. The MIMO configuration in DL can support up to 8 transmit antennas (with multi-layer DL transmission of up to 8 streams) and up to 2 streams per UE. Multi-layer transmission of up to 2 streams per UE can be supported. Aggregation of multiple cells can be supported using up to 8 serving cells.

[0053] Figure 1 An example wireless communication network 100 is illustrated in which aspects of the present disclosure may be performed. The wireless communication network 100 may be a NR system (e.g., a 5G NR network). Figure 1 As shown, the wireless communication network 100 may be in communication with a core network 132. The core network 132 may be in communication with one or more base stations (BSs) 110 and / or user equipments (UEs) 120 in the wireless communication network 100 via one or more interfaces.

[0054] like Figure 1 As illustrated in , the wireless communication network 100 may include several BSs 110a-z (each also individually referred to herein as BS 110 or collectively referred to as BS 110) and other network entities. BS 110 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, BS 110 may be interconnected to each other and / or to one or more other BSs or network nodes (not shown) in the wireless communication network 100 via various types of backhaul interfaces (e.g., direct physical connections, virtual networks, etc.) using any suitable transport network. Figure 1In the example shown in FIG. 1 , BSs 110a, 110b, and 110c may be macro BSs for macro cells 102a, 102b, and 102c, respectively. BS 110x may be a pico BS for pico cell 102x. BSs 110y and 110z may be femto BSs for femto cells 102y and 102z, respectively. A BS may support one or more cells. A network controller 130 may be coupled to a group of BSs and provide coordination and control of the BSs. The network controller 130 may communicate with the BS 110 via a backhaul.

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

[0056] According to certain aspects, BS 110 and UE 120 may be configured for header compression during handover. Figure 1 As shown in FIG. 1 , BS 110a includes HO manager 112 and UE 120a includes HO manager 122. According to aspects of the present disclosure, HO manager 112 and HO manager 122 may be configured for header compression during handover.

[0057] Figure 2 An example architecture of a distributed radio access network (RAN) 200 is illustrated. Figure 1 The wireless communication network 100 described in the embodiment is implemented in FIG. Figure 2 As shown in FIG. 1 , the distributed RAN includes a core network (CN) 202 and access nodes 208 .

[0058] The CN 202 may host core network functions. The CN 202 may be centrally deployed. The CN 202 functionality may be offloaded (e.g., to Advanced Wireless Services (AWS)) in an effort to handle peak capacity. The CN 202 may include an access and mobility management function (AMF) 204 and a user plane function (UPF) 206. The AMF 204 and the UPF 206 may perform one or more core network functions.

[0059] AN 208 may communicate with CN 202 (e.g., via a backhaul interface). AN 208 may communicate with AMF 204 via an N2 (e.g., NG-C) interface. AN 208 may communicate with UPF 206 via an N3 (e.g., NG-U) interface. 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-218, and one or more antenna / remote radio units (AU / RRU) 220-224. 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 gNB 226. AN 208 may communicate with one or more neighboring gNBs.

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

[0061] A DU (such as DU 214, 216 and / or 218) may host one or more TRPs (transmission / reception points, which may include edge nodes (ENs), edge units (EUs), radio heads (RHs), smart radio heads (SRHs), etc.). A DU may be located at the edge of a network with radio frequency (RF) functionality. A DU may be connected to multiple CU-UPs, which are connected to the same CU-CP (e.g., under the control of the same CU-CP) (e.g., for RAN sharing, radio as a service (RaaS), and service-specific deployments). A DU may be configured to serve traffic to a UE individually (e.g., dynamically selected) or jointly (e.g., jointly transmitted). Each DU 214-216 may be connected to one of the AU / RRUs 220-224.

[0062] The CU-CP 210 may be connected to multiple DUs that are connected to the same CU-UP 212 (e.g., under the control of the same CU-UP 212). Connectivity between the CU-UP 212 and the DUs 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 DUs. Data forwarding between the CU-UPs 212 may be via an Xn-U interface.

[0063] The distributed RAN 200 may support forward haul solutions across different deployment types. For example, the RAN 200 architecture may be based on transport network capabilities (e.g., bandwidth, latency, and / or jitter). The distributed RAN 200 may share features and / or components with LTE. For example, the AN 208 may support dual connectivity with NR and may share a common forward haul for LTE and NR. The distributed RAN 200 may, for example, enable collaboration between and among the DUs 214-218 via the CU-CP 212. Inter-DU interfaces may not be used.

[0064] The various logical functions may be dynamically distributed in the distributed RAN 200. Figure 3 Described in more detail, 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.

[0065] Figure 3A diagram showing an example of a communication protocol stack 300 for implementing a RAN (e.g., such as RAN 200) according to various aspects of the present disclosure is illustrated. The illustrated communication protocol stack 300 may be implemented by a device operating in a wireless communication system (e.g., 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, as part of a processor or ASIC, as part 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 example, in a protocol stack for a network access device or UE. As Figure 3 As shown in , the system can support various services on one or more protocols. One or more protocol layers of the protocol stack 300 can be implemented by the AN and / or the UE.

[0066] like Figure 3 As shown in FIG, the protocol stack 300 is implemented in an AN (e.g., Figure 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, the CU-CP (e.g., Figure 2 210) and CU-UP (e.g., Figure 2 CU-UP 212 in each of the DUs may implement the RRC layer 305 and the PDCP layer 310. Figure 2 DU 214-218 in the AU / RRU (e.g., Figure 2 The AU / RRU 220-224 in the RF module may implement the PHY layer(s) 325 and the RF layer(s) 330. The PHY layer 325 may include a high PHY layer and a low PHY layer.

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

[0068] Figure 4A block diagram of a design of a BS 110a and a UE 120a is shown. At the BS 110a, 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), etc. The data may be used for a physical downlink shared channel (PDSCH), etc. The processor 440 may process (e.g., encode and symbol map) the data and the control information to obtain data symbols and control symbols, respectively. The processor 420 may also generate reference symbols (e.g., for PSS, SSS, and channel state information reference signal (CSI-RS)). The transmit (TX) multiple-input multiple-output (MIMO) processor 430 may perform spatial processing (e.g., precoding) on ​​data symbols, control symbols, and / or reference symbols, where applicable, and may provide an output symbol stream to modulators (MOD) 432a to 432t. 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 up-convert) the output sample stream to obtain a downlink signal. The downlink signals from modulators 432a to 432t may be transmitted via antennas 434a to 434t, respectively.

[0069] At UE 120a, antennas 452a to 452r may receive downlink signals from BS 110a and may provide received signals to demodulators (DEMODs) 454a to 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 to 454r, perform MIMO detection on the received symbols where 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.

[0070] On the uplink, at the UE 120a, a transmit processor 464 may receive and process data from a data source 462 (e.g., for a physical uplink shared channel (PUSCH)) and control information from a controller / processor 480 (e.g., for a physical uplink control channel (PUCCH)). The transmit processor 464 may also generate reference symbols for a reference signal. The symbols from the transmit processor 464 may be precoded by a TX MIMO processor 466, where applicable, further processed by modulators 454a through 454r (e.g., for SC-FDM, etc.), and transmitted to the BS 110a. At the BS 110a, the uplink signal from the UE 120a may be received by the antenna 434, processed by the demodulator 432, detected by the MIMO detector 436, where applicable, and further processed by the receive processor 438 to obtain decoded data and control information sent by the UE 120a. Receive processor 438 may provide decoded data to data sink 439 and decoded control information to controller / processor 440 .

[0071] Controllers / processors 440 and 480 may direct the operation at BS 110a and UE 120a, respectively. Processor 440 and / or other processors and modules at BS 110 may perform or direct the execution of various processes, such as for the techniques described herein. Figure 4 As shown in , according to various aspects of the present disclosure, the processor 440 includes a HO manager 441, which can be configured to handle header compression during handover. The processor 480 and / or other processors and modules at the UE 120a can also execute or direct. Figure 4 As shown in FIG. 4 , according to aspects of the present disclosure, the processor 480 includes a HO manager 481 , which may be configured for header compression handling during handover.

[0072] 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 divide the system bandwidth into multiple orthogonal subcarriers, which are also called frequency modulations, frequency slots, etc. Each subcarrier may be modulated with data. 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 subbands. For example, one subband may cover multiple resource blocks (RBs).

[0073] Figure 5is a diagram showing an example of a frame format 500 for NR. The transmission timeline of each of the downlink and uplink may be divided into units of radio frames. Each radio frame may have a predetermined duration (e.g., 10 ms) and may be divided into 10 subframes with indices 0 to 9, each subframe being 1 ms. Each subframe may include a variable number of slots (e.g., 1, 2, 4, 8, 16, ... slots), 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 subslot structure) refers to a transmission time interval having a duration (e.g., 2, 3, or 4 symbols) less than a slot. 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 time slot may include DL / UL data and DL / UL control information.

[0074] In some examples, access to the air interface may be scheduled, wherein a scheduling entity (e.g., a base station) allocates resources for communication between some or all devices and equipment within its service area or cell. In the present disclosure, as further discussed below, a scheduling entity may be responsible for scheduling, assigning, reconfiguring, and releasing resources for one or more subordinate entities. That is, for scheduled communications, a subordinate entity utilizes resources allocated by a scheduling entity. A base station is not the only entity that can be used as a scheduling entity. That is, in some examples, a UE may be used as a scheduling entity to schedule resources for one or more subordinate entities (e.g., one or more other UEs). In this example, the UE is being used as a scheduling entity, and other UEs utilize resources scheduled by the UE for wireless communication. A UE may be used as a scheduling entity in a peer-to-peer (P2P) network and / or in a mesh network. In a mesh network example, UEs may optionally communicate directly with each other in addition to communicating with a 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 communicate using the scheduled resources.

[0075] Example switching scene

[0076] Some techniques and devices described herein provide low latency or zero latency switching 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 devices described herein provide a switching configuration using a first protocol stack of a UE and a second protocol stack of the UE. The first protocol stack of the UE is used to communicate with the first BS, and the second protocol stack of the UE is used to communicate with the second BS. In some examples, this may be referred to as a build-before-break (MBB) switching or a dual active protocol stack (DAPS) switching. The use of these two protocol stacks enables the execution of a switching configuration with respect to the target BS while communication with the source BS is ongoing. Therefore, the waiting time associated with switching the UE from the source BS to the target BS is reduced. In addition, some techniques and devices described herein may provide buffering and backhauling of UE traffic between the source BS and the target BS so that the traffic flow to the UE is not interrupted (or so that the interruption is reduced or minimized), thereby further reducing the waiting time associated with switching the UE. In this way, the service level at the UE can be met in the event 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.

[0077] Some techniques and devices described herein may provide a common packet data convergence protocol (PDCP) function for a handover procedure, which may streamline security key management, encryption / decryption, integrity protection, integrity verification, data unit reordering / duplicate discarding, link selection logic, etc. Some techniques and devices described herein provide control plane (e.g., BS, network controller, control entity, etc.) messaging and handling to support handover. Some techniques and devices described herein provide handover using carrier aggregation (CA) multiple-input multiple-output (MIMO) technology, wherein the reduced MIMO configuration is signaled so that at least one antenna can be used for MBB handover. Still further, some techniques and devices described herein provide a handover technique based on role switching, wherein the primary cell group of the UE is switched from a source base station to a target base station while the connection with the source base station and the target base station is active. In this way, low latency or zero latency handover (and the benefits described above in conjunction with low latency or zero latency handover) is achieved.

[0078] Figure 6 6 is a diagram illustrating an example 600 of a handover procedure for a radio access network according to various aspects of the present disclosure. Figure 6 As shown in FIG. 1 , UE 120 switches from source BS 110-1 to target BS 110-2. Source BS 110-1 and target BS 110-2 may be provided by Figure 1 BS 110a is implemented. Figure 6The described switching may be intra-frequency or inter-frequency and / or may be intra-CU or inter-CU.

[0079] As in Figure 6 In the example 600 and as indicated by reference numeral 605, UE 120 has established a connection (hereinafter referred to as source connection) with source BS 110-1. As indicated by reference numeral 610, in example 600, UE 120 indicates the capabilities of UE 120 to any one or more of source BS 110-1, target BS 110-2, network entities such as access management functions, etc. For example, UE 120 may indicate that UE 120 has simultaneous transmission and reception capabilities and / or dual connectivity capabilities.

[0080] As shown by reference numeral 615, UE 120 may provide a measurement report to source BS 110-1. The measurement report may indicate that a handover from source BS 110-1 to target BS 110-2 is to be performed. As shown by reference numeral 620, 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 BS 110-2, and may receive a handover acknowledgment (ACK) from target BS 110-2. In some aspects, source BS 110-1 may communicate with target BS 110-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 that utilizes or does not utilize the indicated capability of UE 120. In some aspects, the handover configuration may indicate to perform a make-before-break (MBB) handover procedure, a DAPS handover procedure, and / or a DC-based MBB handover procedure. Thus, the UE 120 may be aware of maintaining the source connection while and / or after establishing the target connection.

[0081] As in Figure 6In the example 600 and further shown by reference numeral 630, UE 120 requests to connect with target BS 110-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 BS 110-2 (hereinafter referred to as target connection). As shown by reference numeral 635, target BS 110-2 may reply with an acknowledgement, and as shown by reference numeral 640, UE 120 and target BS 110-2 may establish a target connection. As is apparent in example 600, UE 120 may concurrently maintain source connections with both source BS 110-1 and target BS 110-2 during the handover process. In such a case, because UE 120 maintains active connections with both source BS 110-1 and target BS 110-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 art.

[0082] like Figure 6 As further shown in the figure and by reference numeral 645, the target BS 110-2 instructs the UE 120 to release the source connection (e.g., to complete the handover). For example, once it is determined that the UE 120 has established a strong connection (e.g., the parameter measured by the UE 120 meets the threshold indicating a strong connection), the target BS 110-2 can send an instruction to complete the handover. In some aspects, the release of the source connection may not be based on an instruction 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 the source BS 110-1, at least in part based on an indication of the establishment of the target connection received from the target BS 110-2 or from the UE 120. Accordingly, as shown by reference numeral 650, the UE 120 releases the source connection to the source BS 110-1. In addition, as shown by reference numeral 655, the UE 120 uses the target connection with the target BS 110-2 to continue the service.

[0083] Accordingly, if Figure 6 As shown in example 600 in FIG. 1 , the UE may provide the capability 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 capability during the handover procedure. Therefore, the UE may achieve enhanced performance during the handover procedure and may experience minimal mobility interruption time (e.g., via 0 ms handover) relative to a handover procedure that does not utilize the UE capability.

[0084] As indicated above, Figure 6 are provided as examples. Other examples may differ from those described in Figure 6 Examples described.

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

[0086] exist Figure 7 , before the call process starts, UE 120 can 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, UE 120 sends a measurement report to source BS 110-1. In some aspects, UE 120 sends the measurement report based at least in part on an event trigger associated with determining to initiate a handover procedure (e.g., a signal measurement that meets a threshold). UE 120 can be associated with a handover capability. For example, the capability can be a simultaneous transmit and receive capability that allows UE 120 to transmit and receive data and / or information concurrently. In this case, UE 120 can establish multiple connections with multiple different BSs (e.g., with source BS 110-1 and target BS 110-2).

[0087] As in Figure 7 , and further illustrated 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 enable the CU 702 to determine a handover configuration to be used for a handover procedure for the UE 120. For example, the CU 702 may select from possible handover procedures that may be performed by the UE 120 based at least in part on the indicated capabilities of the UE 120. In some aspects, the CU 702 may select an enhanced MBB or DAPS handover procedure for the UE 120 based at least in part on the UE 120 indicating a simultaneous transmit and receive capability.

[0088] As in Figure 7 7 and further illustrated by reference numeral 715, CU 702 sends a UE context setup request to target BS 110-2. For example, CU 702 may send the UE context setup request to indicate to target BS 110-2 that UE 120 will be handed over to target BS 110-2 during a handover procedure. As illustrated by reference numeral 720, target BS 110-2 sends a UE context setup response. For example, target BS 110-2 may send the UE context setup response to acknowledge the request and / or indicate an ability to serve UE 120 after a handover procedure.

[0089] As in Figure 7 , and as further shown 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 UE 120 will switch from source BS 110-1 to target BS 110-2. As shown by reference numeral 730, source BS 110-1 sends an RRC reconfiguration to UE 120. In some aspects, the RRC reconfiguration may include information identifying target BS 110-2, information identifying the handover configuration, and the like. For example, the RRC reconfiguration may indicate that UE 120 will perform an enhanced MBB or DAPS handover procedure with target BS 110-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, UE 120 performs a random access procedure with target BS 110-2 (e.g., to initiate and / or establish a connection with 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.

[0090] As shown by reference numeral 740, UE 120 sends an RRC reconfiguration completion message to target BS 110-2. In some aspects, UE 120 can use a dual protocol stack, which 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 protocol stack in these protocol stacks may include a packet data convergence protocol (PDCP) layer, a radio link control (RLC) layer, a media access control (MAC) layer, and / or a physical (PHY) layer. In some aspects, the source protocol stack and the target protocol stack can share one or more layers, such as a shared PDCP layer or entity (described in more detail elsewhere herein). In some aspects, the target protocol stack can be used for uplink data transmission.

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

[0092] 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 will be released and no longer serve UE 120. In some aspects, source BS 110-1 may provide downlink data delivery status to CU 702. As shown by reference numeral 755, source BS 110-1 sends a UE context modification response to CU 402. For example, the UE context modification response may include an acknowledgement that source BS 110-1 will be released and / or will no longer serve UE 120 during the handover procedure.

[0093] As in Figure 7 760, CU 702 sends a DL RRC transmission to target BS 110-2. For example, the DL RRC transmission to target BS 110-2 may include an RRC reconfiguration message indicating that the handover procedure is to be completed. As shown by reference numeral 765, target BS 110-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. In this way, UE 120 may release the connection with source BS 110-1 based at least in part on receiving the RRC reconfiguration message. In addition, UE 120 may then begin exchanging uplink user data and downlink user data with CU 702 via target BS 110-2.

[0094] As shown by reference numeral 770, UE 120 may send an RRC reconfiguration complete message to target BS 110-2. In some aspects, the RRC reconfiguration complete message may indicate that UE 120 has released the connection with source BS 110-1. As shown by reference numeral 775, target BS 110-2 may send an UL RRC transmission to CU 702. In some aspects, the UL RRC transmission may indicate that an RRC reconfiguration complete message is received from UE 120. As shown by reference numeral 780, CU 702 may then send a UE context release command to source BS 110-1 (e.g., so that source BS 110-1 does not continue to attempt to serve UE 120). As shown by reference numeral 785, source BS 110-1 sends a UE context release complete message to 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 serving UE 120.

[0095] As indicated above, Figure 7 are provided as examples. Other examples may differ from those described in Figure 7 Examples described.

[0096] Example Header Compression

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

[0098] In order to establish a data packet stream between a RoHC compressor and a RoHC decompressor, the compressor and decompressor may first establish a context for the data stream. A context is a state maintained by a compressor and a decompressor in order to correctly compress or decompress the headers of packets in a stream. 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 ​​used for compression and decompression. The context may further include information indicating the changing behavior of dynamic values, such as, for example, inter-packet increases in sequence numbers or timestamps. A value may be associated with a CID, where the value may identify a state maintained by a corresponding compressor and decompressor in order to respectively compress and decompress data contained in a data stream. The context information is conceptually stored in a table, and the table is indexed using a CID value, which is sent together with the compressed header and feedback information.

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

[0100] 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.

[0101] In an example RoHC compression scheme, a UE as a compressor may participate in a communication session with a BS as a decompressor and may transmit an initial packet in a data packet stream to the base station. The initial packet may be a packet including media data as a payload, such as video data or voice data. The packet may include a compressed header including various information, including a CID and a packet type. In another example compression scheme, a BS as a compressor may transmit an initial packet in the data packet stream to a UE as a decompressor.

[0102] In this example implementation, a compressor-decompressor pair maintains a context for each packet stream on each side. The context for each packet stream 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 stream (such as information about how the IP identifier field changes and the inter-packet increase of sequence numbers or timestamps) is also included in the context.

[0103] Initially, the compressor and decompressor may not agree on compressing or decompressing a packet stream. The compressor can send a RoHC packet with static and dynamic information about the packet stream (including CID) to the decompressor to establish the context. Once both static and dynamic fields are established, the compressor only needs to send minimal information to advance the regular sequence of compressed header fields.

[0104] In some systems (e.g., NR Release 15 systems), upon receiving the 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, the Packet Data Convergence Protocol (PDCP) entity may be reestablished (e.g., due to a PDCP termination point change). A field in the handover message (e.g., drb-ContinueROHC) may indicate whether the PDCP entity continues or resets the ROHC header compression protocol during PDCP reestablishment. In the case of a reconfiguration with synchronization (where the PDCP termination point is not changed and a full configuration is not indicated), this field may be configured.

[0105] When the PDCP entity is reestablished, the ROHC context is typically reset. For example, the ROHC context may be reset due to a PDCP anchor change (e.g., a security key change). In the above-mentioned MBB or DAPS scenarios, the reestablishment of the PDCP entity during handover can be eliminated by supporting a separate PDCP entity on the network side and a shared PDCP entity on the UE side. This can help minimize the impact on mobility interruption time during handover. The user plane radio protocol architecture with a shared PDCP entity on the UE can eliminate PDCP reestablishment during handover.

[0106] Example Header Compression Handling During Switching

[0107] Various aspects of the present disclosure provide methods for performing a multi-connection switch during a scenario where a user equipment (UE) has multiple connections, such as during a build-before-break (MBB) handover (e.g., as described above with respect to Figure 6 and Figure 7The present invention provides techniques for handling header compression protocols (e.g., such as the Robust Header Compression (ROHC) protocol or other types of header compression) during MBB or DAPS handover or dual connectivity scenarios, as described in the example scenarios of ), dual active protocol stack (DAPS) handover or dual connectivity scenarios. As will be described below, aspects of the present disclosure enable continued use of the ROHC context without a reset. The techniques described herein may be applied to a shared packet data convergence protocol (PDCP) entity during MBB or DAPS handover, as well as to dual connectivity scenarios, including handovers based on dual connectivity role switching (DCRS), or even conventional dual connectivity scenarios. These techniques may be applied to various deployments (e.g., in 5G / new radio (NR) and / or long term evolution (LTE) systems).

[0108] Figure 8 800 may be performed as part of a header compression approach in accordance with certain aspects of the present disclosure. Operations 800 may be performed, for example, by a UE (e.g., UE 120a in wireless communication network 100). Operations 800 may be implemented as a processor (e.g., Figure 4 In addition, signal transmission and reception by the UE in operation 800 may be performed by one or more antennas (e.g., Figure 4 In some aspects, the transmission and / or reception of signals by the UE may be implemented via a bus interface of one or more processors (eg, controller / processor 480) that obtain and / or output signals.

[0109] Operations 800 begin, at 805, with concurrently communicating with a first base station (BS) and a second BS, wherein communicating with the first BS over a connection with the first BS and communicating with the second BS over a connection with the second BS.

[0110] At 810, the UE maintains a context of a header compression protocol for a connection with a first BS and a connection with a second BS. Communicating concurrently includes sending one or more packets, receiving one or more packets, or both using the header compression protocol context.

[0111] Fig. 9 900 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., BS 110a in wireless communication network 100). Operations 900 may be complementary to operations 800 performed by a UE. Operations 900 may be implemented as a process performed on one or more processors (e.g., Figure 4In addition, signal transmission and reception by the BS in operation 900 may be performed by one or more antennas (e.g., Figure 4 In some aspects, the transmission and / or reception of signals by the BS may be implemented via a bus interface of one or more processors (eg, controller / processor 440) that obtain and / or output signals.

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

[0113] At 910, a base station maintains a context of a header compression protocol for a connection with at least a first BS. Communicating concurrently includes sending one or more packets, receiving one or more packets, or both using the header compression protocol context.

[0114] According to certain aspects, in the case of a handover (e.g., MBB or DAPS handover), once the target link is established and the source connection has not been released, the UE can use a single active compressor context (e.g., for ROHC) in the UE and the network to send uplink data and a copy of the uplink data. Alternatively, the UE can send uplink data and a copy of the uplink data on both. In the copy scenario, the UE can support ROHC dual context or single context. With or without copy, the UE can at least temporarily disable ROHC (e.g., in the Initialization and Refresh (IR) state / mode).

[0115] Example Header Compression During Handover with UL Data Duplication and Dual Contexts

[0116] Fig.10 The handling of header compression with data duplication for uplink transmission and header compression (eg, ROHC) using dual context in the UE is explained. Fig.10 As explained in , in the first step (step 1), the target cell connection establishment is performed. In the second step (step 2), the target cell connection establishment is completed. In the third step (step 3), the source cell connection release is completed.

[0117] like Fig.10 As explained in , during the concurrent connection phase, separate keys may be used to connect to the source and target cells. Fig.10As shown in , 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, the dual ROHC context is maintained independently for each link at the 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 the dual ROHC context and the duplicate operation mode. The PDCP PDU may be a control PDU or the PDCP PDU may be a data PDU, where certain bits in the data PDU header are set to indicate the dual ROHC context and the duplicate operation mode.

[0118] like Fig.10 As shown in , the source gNB can forward downlink data to the target gNB (e.g., on the Xn interface). The source gNB can forward decompressed uplink data (e.g., uplink PDCP SDU) to the target gNB.

[0119] like Fig.10 As shown in , for uplink transmission, the UE may use the source ROHC compression context to communicate on a link with the source BS, and the UE may use the target ROHC compression context to communicate on a link with the target BS. Fig.10 As shown in , the target gNB can perform two reordering / duplicate discards after ROHC decompression. Alternatively, the target gNB can perform a single reordering / duplicate discard after ROHC decompression of packets received from the source link and the target link.

[0120] Example Header Compression During Handover with UL Data Duplication and Single Context

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

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

[0123] Fig.12 The header compression process for a case with data duplication and a single compressed header context is described (e.g., Fig.11 An example call flow diagram is shown in Figure 1. Fig.12 As shown in , after establishing a connection with the target gNB (e.g., at 4b), the UE indicates to the source and target cells that it is switching to "single ROHC context mode with UL replication". In some examples, the UE common PDCP entity ROHC compressor switches to a single context for ROHC compression for the links to the source and target gNBs. In some examples, at 5A, after the target link is established, the UE sends an indication in a PDCP control PDU or in a PDCP header bit to explicitly indicate this 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, at 5C, the target gNB confirms receipt of the ROHC context and initiates replication by sending a PDCP control PDU. In some examples, at 5D, the target gNB starts single ROHC context decompression mode.

[0124] Example Header Compression Disabled

[0125] According to certain aspects, the UE may switch to an Initialization and Refresh (IR) state of operation.

[0126] Fig.13 is an example call flow diagram for header compression handling in IR mode / state. In some examples, the header compression protocol can be disabled in IR mode / state. Fig.13 As shown in , the common PDCP entity at the UE switches to IR mode / state. During the handover, the UE indicates to the source and target gNBs that it is switching to IR mode / state. In some examples, after the target link is established and before the source link is released, the UE may send a PDCP control PDU, or a PDCP header bit to the source and target gNBs to explicitly indicate the IR mode / state. In some examples, the source and target gNBs determine the IR mode switch based on the handover message. In some examples, the UE sends a PDCP control PDU to the source gNB before the target gNB link is established. The source and target gNB header compression and decompression entities may subsequently start the IR mode. In some examples, the UE sends a PDCP control PDU to the target gNB after the connection to the source gNB is released.

[0127] In some cases, procedures may be used to temporarily disable ROHC instead of switching to IR mode of operation. For example, the UE may send a PDCP control PDU to the source and target gNBs to indicate the disabling of ROHC.

[0128] Example header compression handling with single context and no DL data duplication

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

[0130] Fig.14 An example of header compression handling during handover with a single context for downlink header compression in the UE is illustrated. Fig.14 As shown in , after establishing a connection with the 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 the context of the source gNB connection or the target gNB connection. After sending an SN status transmission with the ROHC context to the target gNB, the source gNB does not decompress the received PDCP PDU. As shown in the figure, the source gNB sends an uncompressed UL PDPC SDU to the target gNB. The UE uses a PDCP entity (e.g., a common PDCP entity as described above) to perform reordering / duplicate discard and ROHC decompression on the DL PDUs received on the target link. Therefore, from the UE's perspective, the approach can be seamless. Fig.15 The header compression handling for the case where there is a single context for downlink header compression in the UE during handover (e.g., as Fig.14 An example call flow diagram is shown in FIG. Fig.16 An example call flow diagram for header compression handling during switching in IR / disabled mode is illustrated.

[0131] Example of bearer termination point change for split bearer

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

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

[0134] When split bearers are supported and the PDCP anchor has to be changed to the target gNB, following the conventional (e.g., Release 15) procedures may result in PDCP re-establishment and ROHC context reset and some disruption.

[0135] One solution to avoid this re-establishment is to extend the same PDCP entity (e.g., common PDCP entity) for target link handling. In such a scenario, upon indication of a switch of PDCP anchor (i.e., bearer termination point changes from source gNB to target gNB via an RRC reconfiguration message sent to the UE), the UE uses the same ROHC decompression context but a different security context to decrypt packets received on the target link.

[0136] 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, this bearer termination point change may be designed to avoid PDCP reestablishment / ROHC reset even for DCRS based HO bearer termination point change. This approach may also be extended to apply to regular DC bearer termination point changes.

[0137] Fig.18 An example of DL ROHC handling for a split bearer scenario is illustrated. As illustrated, in the first step (step 1), the target cell connection setup is performed. In the second step (step 2), the target cell connection setup is complete and the source cell configures the PDCP anchor and split bearers 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, during the concurrent connection phase, separate keys may be used to connect to the source and target cells.

[0138] When split bearers are supported and the PDCP anchor has to be changed to the target gNB, following the conventional (e.g., Release 15) procedures may result in PDCP re-establishment and ROHC context reset and some disruption.

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

[0140] Fig.19 An example of UL ROHC handling for a split bearer scenario is illustrated. As illustrated, in the first step (step 1), the target cell connection setup is performed. In the second step (step 2), the target cell connection setup is complete and the source cell configures the PDCP anchor and split bearers 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, during the concurrent connection phase, separate keys may be used to connect to the source and target cells.

[0141] In this example, the UE uses the same ROHC compression context even after the bearer termination point (e.g., PDCP anchor) changes to the target gNB. In this example, the source gNB sends the UL ROHC context to the target gNB, and the target gNB uses the transferred ROHC context to decompress the PDCP PDUs received on the split bearer.

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

[0143] Fig. 20 An example user plane radio architecture for uplink ROHC handling during handover with a single context and without data duplication is illustrated.

[0144] like Fig. 20As shown in FIG, in step 2, after the target cell connection is established and before the source cell connection is released, the UE uplink data communication (transmission and reception) may be switched to the target cell connection. That is, the UE switches the UL data transmission to the target cell after a successful RACH on the target cell. The source cell performs a downlink data forwarding procedure with the target cell. Therefore, during a handover (e.g., DAPS or MBB handover, which may be inter-CU), UL data is transmitted only on the source connection or the target connection, but not on both.

[0145] During the target cell connection setup, while the UE is performing RACH on the target cell, the UE uses the source ROHC compression context to transmit any UL data available in the PDCP buffer (at step A). ​​This UL data is received only 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 to the 5GC over NG-U.

[0146] After the target cell connection is established (e.g., successful transmission of the RRC Reconfiguration Complete message), the UL data available in the PDCP buffer is transmitted only on the target connection (in step C). If drb-ContinueROHC is set to true (TRUE) and instructs the PDCP entity to continue the ROHC context, the common PDCP entity on the UE may continue the ROHC context even after switching the UL data transmission from the source connection to the target connection - without PDCP re-establishment (e.g., maintaining PDCP SN continuity). Therefore, only the target gNB receives UL data from the UE (in step D) - the source gNB does not receive any UL data after the connection with the target gNB is established. The source gNB transfers the ROHC context to the target gNB via the SN Status data transmission on Xn to support ROHC continuity on the target connection during the handover. If drb-ContinueROHC is set to false (FALSE), after switching the UL data transmission from the source connection to the target connection, the common PDCP entity of the UE switches the ROHC context to the target connection ROHC handling. The source gNB may not transfer the ROHC context to the target gNB - because ROHC continuity is not required.

[0147] Header compression during handover with downlink data duplication and dual context

[0148] Fig.21 An example user plane radio architecture for uplink ROHC handling with dual context and with data duplication during handover is illustrated.

[0149] like Fig.21As shown in , after the target cell connection is established (in step 2) and before the source cell connection is released, the UE downlink data communication (e.g., transmission and reception) may be switched 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 a period of time with data duplication during which the UE may receive DL data on both the source and target connections during the handover.

[0150] During the target cell connection establishment (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.

[0151] After the target cell connection establishment is complete (e.g., successful transmission of RRC Reconfiguration Complete), the source gNB and target gNB coordinate to initiate SN status data transmission. The source gNB forwards the PDCP SDU (uncompressed) to the target gNB (in step C) and indicates the PDCP SN to be used for the DL packet. In some cases, the source gNB may also send a duplicate SDU compressed using the source gNB ROHC context to the UE. After compressing the packet with the target gNB ROHC context, the target gNB also transmits the PDCP SDU received from the source gNB to the UE. Therefore, the UE can receive DL packets compressed with the source gNB or target gNB context during handover (in steps E and F). To support ROHC for these packets, the UE maintains a dual ROHC context at the common PDCP entity until the source connection is released, such as Fig.21 As shown in . The UE can determine the security key to be used for decryption / integrity verification and the ROHC context to be used to decompress the PDU based on the logical channel of the received PDU.

[0152] Thus, according to certain aspects, during handover (e.g., during 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 inter-CU MBB HO or DAPS HO), the common PDCP entity in the UE applies different ROHC contexts (e.g., source link or target link ROHC context, respectively) to decompress data received on different logical channels associated with the source link and the target link.

[0153] Fig. 22 The description may include operations configured to perform the techniques disclosed herein (such as, Figure 8 2200 includes a communication device 2200 including various components (e.g., corresponding to means plus function components) for the operations explained in the description. 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 an 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.

[0154] The processing system 2202 includes a processor 2204 coupled to a computer readable medium / memory 2212 via a bus 2206. In some aspects, the computer readable medium / memory 2212 is configured to store a program that, when executed by the processor 2204, causes the processor 2204 to execute Figure 8 2204 includes circuitry 2218 for communicating concurrently with the first BS and the second BS during handover; and circuitry 2220 for maintaining a header compression context.

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

[0156] The processing system 2302 includes a processor 2304 coupled to a computer readable medium / memory 2312 via a bus 2306. In some aspects, the computer readable medium / memory 2312 is configured to store programs that, when executed by the processor 2304, cause the processor 2304 to execute Fig. 9 Instructions (e.g., computer executable code) for performing the operations explained in or other operations of the various techniques for header compression protocol handling during handover discussed herein. In certain aspects, according to various aspects of the present 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 a second BS and communicating with the 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 a circuit system configured to implement the code stored in the computer-readable medium / memory 2312. According to various aspects of the present disclosure, the processor 2304 includes a circuit system 2318 for concurrently communicating with a UE connected to a first BS while the UE is connected to a second BS and communicating with the second BS during a handover procedure; and a circuit system 2320 for maintaining a context of a header compression protocol for a connection with the UE and at least the first BS.

[0157] Example aspects

[0158] In a first aspect, a wireless communication method 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 communication is with the first BS on a connection with the first BS and the communication is with the second BS on a connection with the second BS. 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 sending one or more packets, receiving one or more packets, or both using the context of the header compression protocol.

[0159] In a second aspect, in combination with the first aspect, the header compression protocol comprises a Robust Header Compression (RoHC) protocol.

[0160] In a third aspect, in combination with one or more of the first and second aspects, the handover procedure is a build before break (MBB) handover procedure or a dual active protocol stack (DAPS) handover procedure.

[0161] In a fourth aspect, in combination with one or more of the first to third aspects, communicating concurrently with a first BS and a second BS includes: performing a common packet data convergence protocol (PDCP) function for a connection with the first BS and a connection with the second BS before releasing the connection with the first BS as part of an MBB or DAPS switching procedure.

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

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

[0164] In the seventh aspect, in combination with one or more of the first to sixth aspects, communicating concurrently with the first BS and the second BS further includes: sending 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, the single active context corresponding to the connection on which the data is sent; and / or receiving downlink data on a connection with the second BS or the first BS or simultaneously receiving downlink data from both the second BS and the first BS, and decompressing the downlink data using a decompressor context of a header compression protocol, the decompressor context corresponding to the connection on which the data is received.

[0165] In an eighth aspect, in combination with one or more of the first to 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 switching to the second BS and maintenance of a single active context corresponding to the second BS.

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

[0167] In a tenth aspect, in combination with one or more of the first to ninth aspects, the UE sends a packet data convergence protocol (PDCP) protocol data unit (PDU) to independently signal the first BS and the second BS to switch to the IR operation state.

[0168] 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 operation state after the connection with the first BS is released.

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

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

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

[0172] 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 the dual context.

[0173] In the 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 PDCP data PDU header, and the PDCP PDU is sent before activating uplink data replication on connections with both the second BS and the first BS.

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

[0175] In an eighteenth aspect, a wireless communication method performed by a first base station (BS) includes: concurrently communicating with a user equipment (UE) connected to the first base station (BS) while the UE is connected to and communicating with a second base station during a handover procedure. The first BS maintains a context of a header compression protocol for the connection with the UE and at least the first BS. Concurrently communicating includes sending one or more packets, receiving one or more packets, or both using the context of the header compression protocol.

[0176] In a nineteenth aspect, in combination with the eighteenth aspect, the header compression protocol includes at least a Robust Header Compression (RoHC) protocol.

[0177] In a twentieth aspect, in combination with one or more of the eighteenth and nineteenth aspects, the handover procedure is a build before break (MBB) handover procedure or a dual active protocol stack (DAPS) handover procedure.

[0178] In a twenty-first aspect, in combination with one or more of aspects eighteen to twentieth, concurrently communicating includes performing a common Packet Data Convergence Protocol (PDCP) function for a connection with the UE and the first BS and a connection with the UE and the second BS before releasing the connection with the first BS as part of an MBB or DAPS switching procedure.

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

[0180] In a twenty-third aspect, in combination with one or more of the eighteenth to twenty-second aspects, maintaining the context of the header compression protocol includes maintaining a single active context of the header compression protocol.

[0181] In aspect twenty-four, in combination with one or more of aspects eighteen to twenty-third, concurrently communicating includes: sending downlink data on a single connection with the UE and compressing the data using a single active context of a header compression protocol; and / or receiving uplink data on a single connection with the UE and decompressing the downlink data using a single active context of a header compression protocol.

[0182] In the 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 an uplink packet data convergence protocol (PDCP) protocol data unit (PDU) forwarded from the second BS before performing decompression using a single context of a header compression protocol.

[0183] In a twenty-sixth aspect, in combination with one or more of aspects 18 to 25, maintaining the context of the header compression protocol includes at least temporarily disabling the header compression protocol.

[0184] The methods disclosed herein include one or more steps or actions for achieving the described methods. These method steps and / or actions may be interchangeable with each other 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 changed without departing from the scope of the claims.

[0185] As used herein, a phrase referring to "at least one of" a list of items refers to any combination of those items, including single members. As an example, "at least one of a, b, or c" is intended to cover: a, b, c, ab, ac, bc, and abc, as well as any combination with multiple of the same elements (e.g., aa, aaa, aab, aac, abb, acc, bb, bbb, bbc, cc, and ccc, or any other ordering of a, b, and c).

[0186] As used herein, the term "determining" encompasses a wide variety of actions. For example, "determining" may include calculating, computing, processing, deriving, investigating, searching (e.g., searching 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.

[0187] The technology described herein can 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 can implement radio technologies such as Universal Terrestrial Radio Access (UTRA), cdma2000, etc. UTRA includes other variants of Wideband CDMA (WCDMA) and CDMA. cdma2000 covers IS-2000, IS-95 and IS-856 standards. A TDMA network can implement radio technologies such as Global System for Mobile Communications (GSM). An OFDMA network can 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, etc. UTRA and E-UTRA are part of Universal Mobile Telecommunications System (UMTS). NR is an emerging wireless communication technology being developed in collaboration with the 5G Technology Forum (5GTF). 3GPP Long Term Evolution (LTE) and Advanced LTE (LTE-A) are versions of UMTS that use E-UTRA. UTRA, E-UTRA, UMTS, LTE, LTE-A, and GSM are described in documents from an organization named "3rd Generation Partnership Project" (3GPP). cdma2000 and UMB are described in documents from an organization named "3rd Generation Partnership Project 2" (3GPP2).

[0188] In 3GPP, the term "cell" may refer to the coverage area of ​​a Node B and / or a Node B subsystem serving the coverage area, depending on the context in which the term is used. In NR systems, the terms "cell" and gNB, Node B, 5G NB, AP, NR BS, NR BS, or TRP may be interchangeable.

[0189] UE 120 (e.g., 120x, 120y, etc.) may be dispersed throughout the wireless communication network 100, and each UE may be stationary or mobile. UE may also be referred to as a mobile station, terminal, access terminal, subscriber unit, station, customer premises equipment (CPE), cellular phone, smart phone, personal digital assistant (PDA), wireless modem, wireless communication device, handheld device, laptop computer, cordless phone, wireless local loop (WLL) station, tablet device, camera, gaming device, netbook, smartbook, ultrabook, medical device or medical equipment, biometric sensor / device, wearable device (such as smart watch, smart clothing, smart glasses, smart wristband, smart jewelry (e.g., smart ring, smart necklace, etc.)), entertainment device (e.g., music device, video device, satellite radio, etc.), transportation component or sensor, smart meter / sensor, industrial manufacturing equipment, global positioning system device, or any other suitable device configured to communicate via wireless or wired medium. Some UEs may be considered as evolved or machine type communication (MTC) devices or evolved MTC (eMTC) devices. MTC and eMTC UEs include, for example, robots, drones, remote devices, sensors, meters, monitors, location tags, etc., which can communicate with a BS, another device (e.g., a remote device), or some other entity. A wireless node can provide connectivity for or to a network (e.g., a wide area network (such as the Internet) or a cellular network), for example, via a wired or wireless communication link. Some UEs may be considered Internet of Things (IoT) devices.

[0190] 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 easily understood by those skilled in the art, and the universal principles defined herein can be applied to other aspects. Thus, the claims are not intended to be limited to the various aspects shown herein, but should be granted the full scope consistent with the language of the claims, wherein the singular reference to the element is not intended to mean "there is and only one" (unless specifically stated) but "one or more". Unless otherwise specifically stated, the term "some / some" refers to one or more. The elements of the various aspects described throughout this disclosure are all structural and functional equivalents currently or hereafter known to ordinary technicians in the art and are explicitly incorporated herein by reference, and are intended to be covered by the claims. In addition, nothing disclosed herein is intended to be donated to the public, regardless of whether such disclosure is explicitly recorded in the claims. Any element of the claim should not be interpreted under the provisions of 35 U.S.C. §112, paragraph 6, unless the element is explicitly stated using the wording "device for..." or in the case of a method claim, the element is stated using the wording "step for...".

[0191] The various operations of the methods described above may be performed by any suitable device capable of performing the corresponding functions. These devices 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 accompanying drawings, these operations may have corresponding paired device-plus-function components with similar numbers.

[0192] The various illustrative logical blocks, modules, and circuits described in conjunction with the present disclosure may be implemented or executed 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. The processor may also be implemented as a combination of computing devices, for example, 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.

[0193] If implemented in hardware, an example hardware configuration may include a processing system in a wireless node. The processing system may be implemented using a bus architecture. Depending on the specific application and overall design constraints of the processing system, the bus may include any number of interconnecting buses and bridges. The bus may link together various circuits including a processor, a machine-readable medium, and a bus interface. The bus interface may be used to connect a network adapter, etc., to the processing system via the bus. The network adapter may be used to implement the signal processing functions of the PHY layer. In the user terminal 120 (see Figure 1 ), a user interface (e.g., a 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 will not be described further. The processor may be implemented with one or more general and / or special purpose processors. Examples include microprocessors, microcontrollers, DSP processors, and other circuit systems capable of executing software. Those skilled in the art will recognize how to best implement the functionality described with respect to the processing system, depending on the specific application and the overall design constraints imposed on the overall system.

[0194] If implemented in software, each function may be stored on or transmitted by a computer-readable medium as one or more instructions or codes. Software should be broadly interpreted to mean instructions, data, or any combination thereof, whether referred to as software, firmware, middleware, microcode, hardware description language, or other. Computer-readable media include both computer storage media and communication media, which include any media that facilitate the transfer of computer programs from one place to another. The processor may be responsible for managing the bus and general processing, including executing software modules stored on a machine-readable storage medium. A computer-readable storage medium may be coupled to a processor so that the processor can read and write information from / to the storage medium. In an alternative, a storage medium may be integrated into a processor. As an example, a machine-readable medium may include a transmission line, a carrier modulated by data, and / or a computer-readable storage medium having instructions stored thereon that is separated from a wireless node, all of which may be accessed by a processor through a bus interface. Alternatively or additionally, a machine-readable medium or any part thereof may be integrated into a processor, such as a cache and / or a general register file, which may be the case. As an example, examples of machine-readable storage media 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 disks, optical disks, hard drives, or any other suitable storage media, or any combination thereof. Machine-readable media may be implemented in a computer program product.

[0195] A software module may include a single instruction, or many instructions, and may be distributed over several different code segments, distributed between different programs, and distributed across multiple storage media. A computer-readable medium may include several software modules. These software modules include instructions that cause a processing system to perform various functions when executed by an apparatus such as a processor. These software modules may include a transmission module and a receiving module. Each software module may reside in a single storage device or may be distributed across multiple storage devices. As an example, when a triggering event occurs, a software module may be loaded into a RAM from a hard drive. During the execution of a software module, a processor may load some instructions into a 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 describing the functionality of a software module as described below, it will be understood that such functionality is implemented by the processor when the processor executes instructions from the software module.

[0196] Any connection is also properly referred to as a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source using a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technology (such as infrared (IR), radio, and microwave), then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technology (such as infrared, radio, and microwave) is included in the definition of medium. Disk and disc, as used herein, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Disks, where disks often reproduce data magnetically, and discs reproduce data optically with lasers. Thus, in some aspects, computer-readable media may include non-transitory computer-readable media (e.g., tangible media). Additionally, for other aspects, computer-readable media may include transient computer-readable media (e.g., signals). Combinations of the above should also be included within the scope of computer-readable media.

[0197] Thus, some aspects may include 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, which instructions can be executed by one or more processors to perform the operations described herein.

[0198] In addition, it should be appreciated that modules and / or other appropriate means for performing the methods and techniques described herein may 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 means 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 a floppy disk, etc.) so that once the storage device is coupled to or provided to a user terminal and / or base station, the device can obtain the various methods. In addition, any other suitable technology suitable for providing the methods and techniques described herein to a device may be utilized.

[0199] It will be understood that the claims are not limited to the precise configuration and components illustrated above. Various changes, substitutions and variations may be made in the arrangement, operation and details of the methods and apparatus described above without departing from the scope of the claims.

Claims

1. A wireless communication method performed by a user equipment UE, comprising: communicating concurrently with a first base station BS and a second BS during a handover procedure, wherein communicating with the first BS on a connection with the first BS and communicating with the second BS on a connection with the second BS; maintaining a context of a header compression protocol for a connection with the first BS and a connection with the second BS during the handover procedure, wherein: Communicating concurrently includes sending one or more packets, receiving one or more packets, or both using the context of the header compression protocol; and Operate in the Initialize and Refresh IR states during the switching procedure.

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

3. The method according to claim 1, wherein the switching procedure is a make-before-break MBB switching procedure.

4. The method of claim 1, wherein the switching procedure is a dual active protocol stack (DAPS) switching procedure.

5. The method of claim 1, wherein communicating concurrently with the first BS and the second BS further comprises: Before the connection with the first BS is released as part of the handover procedure, a common Packet Data Convergence Protocol (PDCP) function is performed for the connection with the first BS and the connection with the second BS.

6. 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.

7. 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.

8. The method of claim 7, wherein communicating with the first BS and the second BS concurrently further comprises: sending uplink data on a connection with the first BS or a connection with the second BS, and compressing the uplink data using the single-active compressor context of the header compression protocol, wherein the single-active compressor context corresponds to a compressor context of the connection with the first BS or the connection with the second BS on which the uplink data is sent; receiving downlink data on a connection with the first BS or a connection with the second BS, or on both the connection with the first BS and the connection with the second BS, and decompressing the downlink data using a decompressor context in the dual-active decompressor context of the header compression protocol, wherein the decompressor context corresponds to a decompressor context of the connection with the first BS, the connection with the second BS, or both on which the downlink data was received; or Its combination.

9. The method of claim 7, further comprising: A Packet Data Convergence Protocol (PDCP) control protocol data unit (PDU) is sent to the first BS after establishing a connection with the second BS during a handover procedure to indicate uplink data handover to the second BS and maintenance of a single active compressor context corresponding to the second BS.

10. The method of claim 1, wherein maintaining the context of the header compression protocol comprises switching to the IR state.

11. The method of claim 10, further comprising: A Packet Data Convergence Protocol (PDCP) Protocol Data Unit (PDU) is sent to independently signal the switching to the IR state to the first BS and the second BS.

12. The method of claim 11, wherein sending the PDCP PDU to independently signal the first BS and the second BS to switch to the IR state comprises: A first PDCP PDU is sent to signal a switch to the IR state to the first BS after establishing a connection with the second BS during the handover procedure, wherein the first BS is a source BS and the second BS is a target BS.

13. The method of claim 12, wherein sending the PDCP PDU to independently signal the first BS and the second BS to switch to the IR state comprises: A second PDCP PDU is sent after sending a Radio Resource Control (RRC) Connection Reconfiguration Complete message to the second BS during the handover procedure to signal the second BS of the handover to the IR state.

14. The method of claim 11, further comprising: After the connection with the first BS is released, the second BS is requested to switch to using the header compression protocol in another compressed operating state.

15. The method of claim 1, further comprising at least temporarily disabling the header compression protocol during the switching procedure.

16. The method of claim 1, wherein communicating concurrently comprises: sending uplink data over a connection with the first BS and a connection with the second BS, or receiving downlink data over a connection with the first BS and a connection with the second BS; or Its combination.

17. The method of claim 1, wherein: Maintaining the context of the header compression protocol includes maintaining, at the UE, a dual-active compressor context of the header compression protocol independently for a connection with the second BS and a connection with the first BS.

18. The method of claim 17, further comprising: A Packet Data Convergence Protocol (PDCP) Protocol Data Unit (PDU) is sent to the second BS to indicate the maintenance of the dual active compressor context.

19. The method of claim 18, wherein: The PDCP PDU corresponds to a PDCP control PDU or sets a specific bit in a PDCP data PDU header; and The PDCP PDU is sent prior to activating uplink data replication on connections with both the second BS and the first BS.

20. The method of claim 19, further comprising: activating the uplink data replication after sending the PDCP PDU; or The uplink data replication is activated after receiving a positive acknowledgement of the PDCP PDU.

21. An apparatus for wireless communication, comprising: at least one processor coupled to a memory, the memory comprising code executable by the at least one processor to cause the apparatus to: communicating concurrently with a first base station BS and a second BS during a handover procedure, wherein communicating with the first BS on a connection with the first BS and communicating with the second BS on a connection with the second BS; maintaining a context of a header compression protocol for a connection with the first BS and a connection with the second BS during the handover procedure, wherein: Communicating concurrently includes sending one or more packets, receiving one or more packets, or both using the context of the header compression protocol; and Operate in the Initialize and Refresh IR states during the switching procedure.

22. The apparatus of claim 21, wherein the header compression protocol comprises a Robust Header Compression (RoHC) protocol.

23. The apparatus of claim 21, wherein the handover procedure is a make-before-break MBB handover procedure.

24. The apparatus of claim 21, wherein the switching procedure is a Dual Active Protocol Stack (DAPS) switching procedure.

25. The apparatus of claim 21, wherein the code executable by the at least one processor to cause the apparatus to communicate concurrently with the first BS and the second BS further comprises code executable by the at least one processor to cause the apparatus to: Before the connection with the first BS is released as part of the handover procedure, a common Packet Data Convergence Protocol (PDCP) function is performed for the connection with the first BS and the connection with the second BS.

26. The apparatus of claim 21, wherein the code executable by the at least one processor to cause the apparatus to communicate concurrently with the first BS and the second BS further comprises code executable by the at least one processor to cause the apparatus to: Communicating over a split radio bearer having at least a first link to the first BS and a second link to the second BS.

27. The apparatus of claim 21, wherein code executable by the at least one processor to cause the apparatus to maintain the context of the header compression protocol comprises: Code executable by the at least one processor to cause the apparatus to maintain a single active compressor context and a dual active decompressor context for 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 communicate concurrently with the first BS and the second BS further comprises code executable by the at least one processor to cause the apparatus to: sending uplink data on a connection with the first BS or a connection with the second BS, and compressing the uplink data using the single-active compressor context of the header compression protocol, wherein the single-active compressor context corresponds to a compressor context of the connection with the first BS or the connection with the second BS on which the uplink data is sent; receiving downlink data on a connection with the first BS or a connection with the second BS, or on both the connection with the first BS and the connection with the second BS, and decompressing the downlink data using a decompressor context in the dual-active decompressor context of the header compression protocol, wherein the decompressor context corresponds to a decompressor context of the connection with the first BS, the connection with the second BS, or both on which the downlink data was received; or Its combination.

29. The apparatus of claim 27, wherein the code is further executable by the at least one processor to cause the apparatus to: A Packet Data Convergence Protocol (PDCP) control protocol data unit (PDU) is sent to the first BS after establishing a connection with the second BS during a handover procedure to indicate uplink data handover to the second BS and maintenance of a single active compressor context corresponding to the second BS.

30. The apparatus of claim 21, wherein the code executable by the at least one processor to cause the apparatus to maintain the context of the header compression protocol comprises code executable by the at least one processor to cause the apparatus to switch to the IR state.

31. The apparatus of claim 30, wherein the code is further executable by the at least one processor to cause the apparatus to: A Packet Data Convergence Protocol (PDCP) Protocol Data Unit (PDU) is sent to independently signal the switching to the IR state to the first BS and the second BS.

32. The apparatus of claim 31 , wherein the code executable by the at least one processor to cause the apparatus to send the PDCP PDU to independently signal the first BS and the second BS of the switch to the IR state comprises code executable by the at least one processor to cause the apparatus to: A first PDCP PDU is sent to signal a switch to the IR state to the first BS after establishing a connection with the second BS during the handover procedure, wherein the first BS is a source BS and the second BS is a target BS.

33. The apparatus of claim 32, wherein the code executable by the at least one processor to cause the apparatus to send the PDCP PDU to independently signal the first BS and the second BS of the switch to the IR state comprises code executable by the at least one processor to cause the apparatus to: A second PDCP PDU is sent after sending a Radio Resource Control (RRC) Connection Reconfiguration Complete message to the second BS during the handover procedure to signal the second BS of the handover to the IR state.

34. The apparatus of claim 31, wherein the code is further executable by the at least one processor to cause the apparatus to: After the connection with the first BS is released, the second BS is requested to switch to using the header compression protocol in another compressed operating state.

35. The apparatus of claim 21, the codes further executable by the at least one processor to cause the apparatus to at least temporarily disable the header compression protocol during the switching procedure.

36. The apparatus of claim 21, wherein the code executable by the at least one processor to cause the apparatus to communicate concurrently comprises code executable by the at least one processor to cause the apparatus to: sending uplink data over a connection with the first BS and a connection with the second BS, or receiving downlink data over a connection with the first BS and a connection with the second BS; or Its combination.

37. The apparatus of claim 21, wherein: The code executable by the at least one processor to cause the device to maintain the context of the header compression protocol includes code executable by the at least one processor to cause the device to maintain a dual-active compressor context of the header compression protocol at the device independently for a connection with the second BS and a connection with the first BS.

38. The apparatus of claim 37, wherein the code is further executable by the at least one processor to cause the apparatus to: A Packet Data Convergence Protocol (PDCP) Protocol Data Unit (PDU) is sent to the second BS to indicate the maintenance of the dual active compressor context.

39. The apparatus of claim 38, wherein: The PDCP PDU corresponds to a PDCP control PDU or sets a specific bit in a PDCP data PDU header; and The PDCP PDU is sent prior to activating uplink data replication on connections with both the second BS and the first BS.

40. The apparatus of claim 39, wherein the code is further executable by the at least one processor to cause the apparatus to: activating the uplink data replication after sending the PDCP PDU; or The uplink data replication is activated after receiving a positive acknowledgement of the PDCP PDU.

Images