System, method and apparatus for MAC processing of mTRP for inter-du mobility within cu of UE

Abstract

Techniques described herein include a solution for handling multiple transmit and receive points (mTRP) for distributed inter-unit (DU) mobility within centralized units (CUs) of a user equipment (UE). The DUs may each implement a medium access control (MAC) layer, and the CU may add a new DU by configuring the DU to implement an instance of a Hybrid Automatic Repeat Request (HARQ) entity operating on an existing DU. The HARQ process associated with each DU may be the same or different, and the UE may be configured accordingly. The UE may communicate with each DU using the same MAC entity. In some implementations, a HARQ entity of a DU may be associated with an mTRP ID. Alternatively, a new MAC and / or RLC layer may be implemented in the new DU, and the UE may be configured accordingly. The RLC layer may be radio bearer (RB) or logical channel specific.

Description

Technical Field

[0001] The present disclosure relates to wireless communication networks, including techniques for conserving power within wireless communication networks. Background Art

[0002] As the number of mobile devices within wireless networks and the demand for mobile data traffic continues to increase, changes are being made to system requirements and architectures to better address current and anticipated needs. For example, some wireless communication networks may be developed to implement fifth generation (5G) or new radio (NR) technology, sixth generation (6G) technology, etc. One aspect of such technology includes device mobility, which may include processes and procedures for enabling a mobile device to move from one wireless network node to another within the network. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The present disclosure will be easily understood and implemented through the specific embodiments and the accompanying drawings. The same figure numerals may designate the same features and structural elements. The accompanying drawings and corresponding descriptions are provided as non-limiting examples of aspects, specific implementations, etc. of the present disclosure, and reference to "one" or "an" aspect, specific implementation, etc. may not necessarily refer to the same aspect, specific implementation, etc., and may mean at least one, one or more, etc.

[0004] Figure 1 is a diagram of an example overview of medium access control (MAC) processing for multiple transmit receive points (mTRPs) for mobility between distributed units (DUs) within a centralized unit (CU) according to one or more implementations described herein.

[0005] Figure 2 is a diagram of an example network according to one or more implementations described herein.

[0006] Figure 3 is a diagram of an example of a process for intra-centralized unit (CU) inter-distributed unit (DU) mobility based on a hybrid automatic repeat request (HARQ) process in accordance with one or more implementations described herein.

[0007] Figures 4 to 5 is a diagram of an example of an enhanced radio resource control (RRC) information element (IE) for intra-CU inter-DU mobility based on HARQ processes according to one or more implementations described herein.

[0008] Figure 6 is a diagram of an example of a process for intra-CU inter-DU mobility based on HARQ processes according to one or more implementations described herein.

[0009] Figures 7 and 8is a diagram of an example of an enhanced RRC IE for intra-CU inter-DU mobility based on HARQ processes according to one or more implementations described herein.

[0010] Fig. 9 is a diagram of an example of a process for intra-CU inter-DU mobility based on mTRP ID according to one or more implementations described herein.

[0011] Fig.10 is a diagram of an example of an enhanced RRC IE for intra-CU inter-DU mobility based on TRP ID according to one or more specific implementations described herein.

[0012] Fig.11 is a diagram of an example of a process for intra-CU inter-DU mobility based on a dual MAC architecture according to one or more implementations described herein.

[0013] Fig.12 is a diagram of an example of an enhanced RRC IE for intra-CU inter-DU mobility based on a dual MAC architecture according to one or more implementations described herein.

[0014] Fig.13 is a diagram of an example of a process for intra-CU inter-DU mobility based on a dual MAC and radio link control (RLC) architecture according to one or more implementations described herein.

[0015] Fig.14 is a diagram of an example of an enhanced RRC IE for intra-CU inter-DU mobility based on a dual MAC and RLC architecture according to one or more implementations described herein.

[0016] Fig.15 is a diagram of an example of a process for intra-CU inter-DU mobility based on a dual MAC and RLC architecture according to one or more implementations described herein.

[0017] Fig.16 is a diagram of an example of an enhanced RRC IE for intra-CU inter-DU mobility based on a dual MAC and RLC architecture according to one or more implementations described herein.

[0018] Fig.17 is a diagram of an example of components of a device according to one or more implementations described herein.

[0019] Fig.18 is a diagram of an example interface of a baseband circuit according to one or more implementations described herein.

[0020] Fig.19is a block diagram of an example control plane protocol stack according to one or more implementations described herein.

[0021] Fig. 20 is a block diagram illustrating components capable of reading instructions from a machine-readable medium or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more of the methodologies discussed herein in accordance with one or more specific implementations described herein. DETAILED DESCRIPTION

[0022] The following detailed description refers to the accompanying drawings. The same figure numbers in different drawings can identify the same or similar features, elements, operations, etc. In addition, the present disclosure is not limited to the following description, because other specific implementations can be utilized and structural changes or logical changes can be made without departing from the scope of the present disclosure.

[0023] A telecommunications network may include user equipment (UE) capable of communicating with base stations and other network nodes. The UE and base stations may implement various technologies for establishing and maintaining connections. Examples of such technologies may include multiple-input multiple-output (MIMO), enhanced MIMO (eMIMO), further enhanced MIMO (FeMIMO), carrier aggregation (CA), and dual connectivity (DC).

[0024] In a network implementing the 5th generation (5G) or new radio (NR) communication standard of the 3rd Generation Partnership Project (3GPP), different types of architectures may be used to implement a base station. For example, a base station may be a standalone base station, a non-standalone base station, or a so-called centralized unit (CU) and distributed unit (DU) split base station (also referred to as a CU-DU split base station).

[0025] The CU may include a control plane (CP) part (CU-CP) and a user plane (UP) part (CU-UP). The CU-CP may support higher layers of the protocol stack, such as the Service Data Adaptation Protocol (SDAP), the Radio Resource Control (RRC), and the Packet Data Convergence Protocol (PDCP). The CU may communicate with multiple DUs via an F1 interface (e.g., an F1-C interface for control plane communication and an F1-U for user plane communication (which may include a General Packet Radio Service (GPRS) Tunneling Protocol (GTP) user data tunnel (GTP-U tunnel))).

[0026] The DU may support lower layers of the protocol stack, such as radio link control (RLC), medium access control (MAC), and physical layer (PHY). The DU may also include both baseband processing and RF functions, and may be used as one or more transmit and receive points (TRP or multiple TRPs (mTRPs)). The DU may also support one or more cells that may have different physical cell IDs (PCIs) and support multiple beams, and may support one or more mobility scenarios, including intra-TRP mobility, intra-cell mobility, and intra-DU mobility.

[0027] While currently available technologies enable some types of mobility, currently available technologies fail to adequately enable other types of UE mobility, such as intra-CU inter-DU mobility—i.e., the ability of a UE to move between DUs of the same CU but in different cells and using different frequencies with different timing advances (TAs). These and other limitations are related to inadequate integration of the MAC layer with the functionality and operation of the DU. For example, depending on the network configuration, for a co-located DU with a single MAC layer, the UE may be limited to applying MIMO based on a single hybrid automatic repeat request (HARQ) entity, or for a non-co-located DU with a different MAC layer, the UE may be limited to applying MIMO based on multiple HARQ entities.

[0028] The technology described herein provides a solution for MAC processing of mTRP for intra-CU inter-DU mobility of UE. In some specific implementations, the DU may each implement a MAC layer, and the CU may add a new DU by configuring the DU to implement an instance of a HARQ entity operating on an existing DU (e.g., so that two DUs implement HARQ entities with the same HARQ ID). The CU may also assign a HARQ process ID different from the HARQ process ID used by the existing DU to the new DU. The CU may then configure the UE to associate each DU with a set of corresponding HARQ processes. In some specific implementations, the new DU may decide which HARQ processes to add. Additionally or alternatively, the CU may configure the UE to associate the HARQ process to the DU based on the TRP ID of the new DU. In some specific implementations, a new MAC and / or RLC layer may be implemented in the new DU, and the UE may be configured accordingly. Therefore, the technology described herein may enable the DU to be used as a separate cell / base station, and thus implement intra-CU inter-DU mobility of the UE.

[0029] Figure 11 is a diagram of an example overview 100 of MAC processing for mTRP for intra-CU inter-DU mobility according to one or more implementations described herein. As shown, the overview 100 may include a UE 110 and a base station 120. The base station 120 may include a CU 130, DUs 140-1 to DU 140-N (where N is greater than 1 and collectively referred to as "DUs 140"), and mTRPs 150-1 to mTRPs 150-M (where M is greater than 1 and collectively referred to as "mTRPs 150"). Figure 1 Each DU 140 is depicted as corresponding to one mTRP 150 ; however, the techniques described herein include implementations in which one DU 140 may correspond to multiple mTRPs 150 .

[0030] CU 130 may include a control plane (CP) 132 and a user plane (UP) 134 that communicate with each other via an E1-C interface for control information and an E1-U interface for user data. CP 132 and UP 134 may communicate with DU 140 using an F1-C interface for control information and an F1-U interface for user data. CU 130 may support higher layer protocols such as SDAP, RRC, and PDCP. DU 140 may support lower layer protocols such as RLC, MAC, and PHY. DU 140 may also include baseband processing and RF functions, and may operate one or more mTRPs 150. mTRPs 150 may be part of different cells, have different PCIs, be non-co-located relative to each other (e.g., located far away from each other), use different frequency bands, broadcast different, have different system synchronization blocks (SSBs), have different TAs, etc.).

[0031] Intra-CU inter-DU mobility can be achieved by CU 130 enabling DU 140 with mTRP 150 having different PCI to implement a MAC layer with the same HARQ entity (e.g., a HARQ entity using the same HARQ ID). CU 130 can allocate different HARQ processes of the HARQ entity to each DU 140, and use RRC message transmission to configure UE 110 to use the assigned HARQ process to communicate with DU 140. Downlink control information (DCI) from DU 140 can be used to provide HARQ ID to UE 110. DU 140 using different MAC layers and with different mTRP 150 with different PCI can enable DU 140 to be asynchronous (e.g., located far away from each other, using different frequency bands, broadcasting different SSBs with different SSBs, having different TAs, etc.). In other words, DU 140 and mTRP 150 can be used as separate cells / base stations, and thus achieve inter-DU mobility of UE 110. In the absence of one or more of the above configurations, the UE 110 may be configured to assume that the HARQ process corresponds to the same HARQ entity (eg, HARQ ID) and is shared across all DUs 140 .

[0032] In some implementations, the new DU 140 (instead of the CU 130) may decide which HARQ processes to support, and the CU 130 may configure the UE 110 to associate those HARQ processes to the new DU 140. In some implementations, each DU 140 may implement the same HARQ entity (e.g., have the same HARQ ID), and each DU 140 may use a HARQ process with the same HARQ process ID. In such implementations, the CU 130 may configure the UE 110 to distinguish between the DUs 140 based on the mTRP 150 (e.g., the PCI of the mTRP 150). In some implementations, the CU 130 may implement a dual MAC architecture, in which the UE 110 may implement a new instance of a MAC layer that corresponds to the MAC layer of the new DU 140 and is released when the new DU 140 (and / or the mTRP 150) is released. In some implementations, CU 130 may implement a dual RLC architecture, where UE 110 may implement new instances of MAC and RLC layers corresponding to the MAC and RLC layers of new DU 140. When new DU 140 (and / or mTRP 150) is released, the new instances of the MAC and RLC layers may be released.

[0033] Generally speaking, a MAC entity may include a HARQ entity, and each HARQ entity may handle many HARQ processes. Services may be distributed between the processes of the HARQ entities. Each process may handle one transmission (TB) at a time, but if DL spatial multiplexing is configured, two TBs may be used, for example. In DL, the HARQ process may also be used for time slot aggregation, which is also referred to as transmission time interval (TTI) bundling. In this case, the TB may be retransmitted without waiting for an acknowledgment (ACK). At the MAC layer, a new data indicator (NDI) may be used to determine whether the received TB is a new transmission or a retransmission. When the NDI is toggled in the DCI, it may imply new DL data. Toggling the NDI in the UL grant may notify the UE to send new data. When a retransmitted TB is received, the MAC layer may notify the PHY layer to combine the current transmission and the previous transmission of the TB. Therefore, the PHY layer may be responsible for soft combining and decoding.

[0034] Figure 2 2 is an example network 200 according to one or more implementations described herein. The example network 200 may include UE 210-1, UE 210-2, etc. (collectively, "UE 210", and individually, "UE 210"), a radio access network (RAN) 220, a core network (CN) 230, an application server 240, an external network 250, and satellites 260-1, 260-2, etc. (collectively, "satellite 260", and individually, "satellite 260"). As shown, the network 200 may include a non-terrestrial network (NTN) including one or more satellites 260 (e.g., of a global navigation satellite system (GNSS)) in communication with the UE 210 and the RAN 220.

[0035] The systems and devices of the example network 200 may operate in accordance with one or more communication standards, such as the 2nd generation (2G), 3rd generation (3G), 4th generation (4G) (e.g., Long Term Evolution (LTE)), and / or 5th generation (5G) (e.g., New Radio (NR)) communication standards of the 3rd Generation Partnership Project (3GPP). Additionally or alternatively, one or more of the systems and devices of the example network 200 may operate in accordance with other communication standards and protocols discussed herein, including future versions or generations of 3GPP standards (e.g., sixth generation (6G) standards, seventh generation (7G) standards, etc.), Institute of Electrical and Electronics Engineers (IEEE) standards (e.g., wireless metropolitan area networks (WMANs), Worldwide Interoperability for Microwave Access (WiMAX)), etc.), and the like.

[0036] As shown, UE 210 may include a smart phone (e.g., a handheld touch screen mobile computing device capable of connecting to one or more wireless communication networks). Additionally or alternatively, UE 210 may include other types of mobile or non-mobile computing devices capable of wireless communication, such as a personal data assistant (PDA), a pager, a laptop computer, a desktop computer, a wireless handheld phone, etc. In some specific implementations, UE 210 may include an Internet of Things (IoT) device (or IoT UE), which may include a network access layer designed for low-power IoT applications that utilize short-term UE connections. Additionally or alternatively, IoT UEs may utilize one or more types of technologies such as machine-to-machine (M2M) communication or machine-type communication (MTC) (e.g., to exchange data with an MTC server or other device via a public land mobile network (PLMN)), proximity services (ProSe) or device-to-device (D2D) communication, sensor networks, IoT networks, and more. Depending on the scenario, the M2M or MTC exchange of data may be a machine-initiated exchange, and the IoT network may include IoT UEs interconnected with short-lived connections (which may include uniquely identifiable embedded computing devices within the Internet infrastructure). In some scenarios, the IoT UE may execute background applications (eg, keep-alive messages, status updates, etc.) to facilitate connectivity to the IoT network.

[0037] UE 210 may communicate and establish connections with one or more other UEs 210 via one or more radio channels 212, each of which may include a physical communication interface / layer. The connection may include an M2M connection, an MTC connection, a D2D connection, etc. In some implementations, UE 210 may be configured to discover each other, negotiate radio resources between each other, and establish connections between each other without intervention or communication involving a RAN node 222 or another type of network node. In some implementations, discovery, authentication, resource negotiation, registration, etc. may involve communication with a RAN node 222 or another type of network node.

[0038] UE 210 may communicate with and establish a connection (e.g., communicatively coupled) with RAN 220, which may involve one or more radio channels 214-1 and 214-2, each of which may include a physical communication interface / layer. In some implementations, the UE may be configured with dual connectivity (DC) as a multi-radio access technology (multi-RAT) or multi-radio dual connectivity (MR-DC), where a UE capable of multiple reception and transmission (Rx / Tx) may use resources provided by different network nodes (e.g., 222-1 and 222-2), which may be connected via non-ideal backhaul (e.g., where one of the network nodes provides NR access and the other network node provides E-UTRA for LTE or NR access for 5G). In such a scenario, one network node may act as a master node (MN) and the other node may act as a secondary node (SN). The MN and the SN may be connected via a network interface, and at least the MN may be connected to CN 230. Additionally, at least one of the MN or the SN may operate via a shared spectrum channel access, and the functionality specified for the UE 210 may be used for an integrated access and backhaul mobile terminal (IAB-MT). Similar to the UE 201, the IAB-MT may access the network using one network node or using two different nodes with an enhanced dual connectivity (EN-DC) architecture, a new radio dual connectivity (NR-DC) architecture, etc. In some implementations, a base station (as described herein) may be an example of a network node 222.

[0039] As shown, UE 210 may additionally or alternatively connect to access point (AP) 216 via connection interface 218, which may include an air interface that enables UE 210 to communicatively couple with AP 216. AP 216 may include a wireless local area network (WLAN), a WLAN node, a WLAN termination point, etc. Connection 216 may include a local wireless connection, such as a connection consistent with any IEEE 702.11 protocol, and AP 216 may include a wireless fidelity router or other AP. Figure 2218. Although not explicitly depicted in the drawings, AP 216 may be connected to another network (e.g., the Internet) without being connected to RAN 220 or CN 230. In some scenarios, UE 210, RAN 220, and AP 216 may be configured to utilize LTE-WLAN aggregation (LWA) technology or LTE / WLAN radio level technology integrated with IPsec tunneling (LWIP). LWA may involve UE 210 in RRC_CONNECTED state being configured by RAN 220 to utilize radio resources of LTE and WLAN. LWIP may involve UE 210 using WLAN radio resources (e.g., connection interface 218) to authenticate and encrypt packets (e.g., Internet Protocol (IP) packets) communicated via connection interface 218 via IPsec protocol tunneling. IPsec tunneling may include encapsulating the entire original IP packet and adding a new packet header, thereby protecting the original header of the IP packet.

[0040] The RAN 220 may include one or more RAN nodes 222-1 and 222-2 (collectively referred to as RAN nodes 222 and individually referred to as RAN nodes 222) that enable the establishment of the channel 214-1 and the channel 214-2 between the UE 210 and the RAN 220. The RAN node 222 may include a network access point configured to provide a radio baseband function for data and / or voice connections between a user and a network based on one or more of the communication technologies described herein (e.g., 2G, 3G, 4G, 5G, WiFi, etc.). Thus, as an example, the RAN node may be an E-UTRAN node B (e.g., an enhanced node B, eNodeB, eNB, 4G base station, etc.), a next generation base station (e.g., a 5G base station, an NR base station, a next generation eNB (gNB), etc.). The RAN node 222 may include a road side unit (RSU), a transmit receive point (TRxP or TRP), and one or more other types of ground stations (e.g., a ground access point). In some scenarios, the RAN node 222 may be a dedicated physical device such as a macrocell base station and / or a low power (LP) base station for providing a femtocell, picocell, etc. having a smaller coverage area, smaller user capacity, or higher bandwidth than a macrocell. As described below, in some implementations, the satellite 260 may be used as a base station (e.g., RAN node 222) relative to the UE 210. Therefore, references herein to a base station, RAN node 222, etc. may relate to implementations in which the base station, RAN node 222, etc. is a terrestrial network node, and also to implementations in which the base station, RAN node 222, etc. is a non-terrestrial network node (e.g., satellite 260).

[0041] Some or all or portions of the RAN nodes 222 may be implemented as one or more software entities running on a server computer as part of a virtual network that may be referred to as a centralized RAN (CRAN) and / or a virtual baseband unit pool (vBBUP). In these implementations, the CRAN or vBBUP may implement a RAN functional split, such as a packet data convergence protocol (PDCP) split, where the radio resource control (RRC) and PDCP layers may be operated by the CRAN / vBBUP, and other layer 2 (L2) protocol entities may be operated by a separate RAN node 222; a medium access control (MAC) / physical (PHY) layer split, where the RRC, PDCP, radio link control (RLC), and MAC layers may be operated by the CRAN / vBBUP, and the PHY layer may be operated by a separate RAN node 222; or a "lower PHY" split, where the RRC, PDCP, RLC, MAC layer, and upper portions of the PHY layer may be operated by the CRAN / vBBUP, and the lower portions of the PHY layer may be operated by a separate RAN node 222. The virtualization framework may allow idle processor cores of the RAN node 222 to perform or execute other virtualized applications.

[0042] In some implementations, the separate RAN nodes 222 may represent separate gNB distributed units (DUs) connected to a gNB control unit (CU) via separate F1 or other interfaces. In such implementations, the gNB-DU may include one or more remote radio heads or radio frequency (RF) front end modules (RFEMs), and the gNB-CU may be operated by a server (not shown) located in the RAN 220 or by a server pool (e.g., a group of servers configured to share resources) in a manner similar to CRAN / vBBUP. Additionally or alternatively, one or more of the RAN nodes 222 may be next generation eNBs (i.e., gNBs) that may provide Evolved Universal Terrestrial Radio Access (E-UTRA) user plane and control plane protocol terminations to the UE 210 and may be connected to the 5G core network (5GC) 230 via an NG interface.

[0043] Any of the RAN nodes 222 may serve as an endpoint for an air interface protocol and may be the first point of contact for the UE 210. In some implementations, any of the RAN nodes 222 may perform various logical functions of the RAN 220, including but not limited to functions of a radio network controller (RNC), such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling and mobility management. The UE 210 may be configured to communicate with each other or with any of the RAN nodes 222 on a multi-carrier communication channel using orthogonal frequency division multiplexing (OFDM) communication signals according to various communication techniques, such as but not limited to OFDMA communication techniques (e.g., for downlink communications) or single carrier frequency division multiple access (SC-FDMA) communication techniques (e.g., for uplink and ProSe or sidelink (SL) communications), but the scope of such implementations is not limited in this respect. The OFDM signal may include multiple orthogonal subcarriers.

[0044] In some implementations, a downlink resource grid may be used for downlink transmissions from any of the RAN nodes 222 to the UE 210, and uplink transmissions may utilize similar techniques. The grid may be a time-frequency grid (e.g., a resource grid or a time-frequency resource grid) that represents the physical resources for the downlink in each time slot. Such a time-frequency plane representation is common for OFDM systems, which makes radio resource allocation intuitive. Each column and each row of the resource grid corresponds to an OFDM symbol and an OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to a time slot in a radio frame. The smallest time-frequency unit in the resource grid is represented as a resource element. Each resource grid includes resource blocks, which describe the mapping of certain physical channels to resource elements. Each resource block may include a set of resource elements (REs); in the frequency domain, this may represent the minimum amount of resources that can currently be allocated. Such resource blocks are used to transport several different physical downlink channels.

[0045] Further, the RAN node 222 may be configured to wirelessly communicate with the UE 210 and / or with each other via a licensed medium (also referred to as a "licensed spectrum" and / or a "licensed band"), an unlicensed shared medium (also referred to as an "unlicensed spectrum" and / or an "unlicensed band"), or a combination thereof. For example, the licensed spectrum may include channels operating in a frequency range of approximately 400 MHz to approximately 3.8 GHz, and the unlicensed spectrum may include a 5 GHz band. The licensed spectrum may correspond to channels or frequency bands that are selected, reserved, regulated, etc. for certain types of wireless activities (e.g., wireless telecommunications network activities), and the unlicensed spectrum may correspond to one or more frequency bands that are not restricted for certain types of wireless activities. Whether a particular frequency band corresponds to a licensed medium or an unlicensed medium may depend on one or more factors, such as frequency allocations determined by a public sector organization (e.g., a government agency, a regulatory agency, etc.) or by a private sector organization involved in developing wireless communication standards and protocols.

[0046] To operate in the unlicensed spectrum, the UE 210 and the RAN node 222 may operate using license assisted access (LAA), eLAA, and / or feLAA mechanisms. In these implementations, the UE 210 and the RAN node 222 may perform one or more known medium sensing operations or carrier sensing operations to determine whether one or more channels in the unlicensed spectrum are unavailable or otherwise occupied before transmitting in the unlicensed spectrum. The medium / carrier sensing operations may be performed in accordance with a listen-before-talk (LBT) protocol.

[0047] The LAA mechanism can be built on the carrier aggregation (CA) technology of the LTE-Advanced system. In CA, each aggregated carrier is called a component carrier (CC). In some cases, each CC may have a different bandwidth from other CCs. In a time division duplex (TDD) system, the number of CCs and the bandwidth of each CC may be the same for DL ​​and UL. CA also includes individual service cells to provide individual CCs. The coverage of the service cells may be different, for example, because CCs on different frequency bands will experience different path losses. The primary service cell or PCell can provide a primary component carrier (PCC) for both UL and DL, and can handle RRC and non-access stratum (NAS) related activities. Other service cells are called SCells, and each SCell can provide a single secondary component carrier (SCC) for both UL and DL. SCCs can be added and removed as needed, and changing PCCs may require UE 210 to undergo handover. In LAA, eLAA, and feLAA, some or all of the SCells may operate in an unlicensed spectrum (referred to as "LAA SCell"), and the LAA SCell is assisted by the PCell operating in the licensed spectrum. When the UE is configured with more than one LAA SCell, the UE may receive UL grants on the configured LAA SCells indicating different PUSCH start positions within the same subframe. To operate in unlicensed spectrum, the UE 210 and the RAN node 222 may also operate using independent unlicensed operation, where the UE may be configured with a PCell in addition to any SCell in the unlicensed spectrum.

[0048] The PDSCH may carry user data and higher layer signaling to the UE 210. The physical downlink control channel (PDCCH) may carry information about, among other things, transport formats and resource allocations related to the PDSCH channel. The PDCCH may also inform the UE 210 about transport formats, resource allocations, and hybrid automatic repeat request (HARQ) information related to uplink shared channels. Typically, downlink scheduling (assignment of control and shared channel resource blocks to the UE 210-2 within the cell) may be performed on any of the RAN nodes 222 based on channel quality information fed back from any of the UEs 210. Downlink resource allocation information may be sent on the PDCCH for (e.g., assigned to) each of the UEs 210.

[0049] PDCCH uses control channel elements (CCEs) to convey control information, where many CCEs (e.g., 6, etc.) can be composed of resource element groups (REGs), where REGs are defined as physical resource blocks (PRBs) in OFDM symbols. Before being mapped to resource elements, PDCCH complex-valued symbols can first be organized into quaternions, which can then be arranged, for example, using a sub-block interleaver for rate matching. One or more of these CCEs can be used to transmit each PDCCH, where each CCE can correspond to nine sets of four physical resource elements, respectively, referred to as REGs. Four orthogonal phase shift keying (QPSK) symbols can be mapped to each REG. Depending on the size of the DCI and channel conditions, one or more CCEs can be used to transmit the PDCCH. Four or more different PDCCH formats with different numbers of CCEs (e.g., aggregation levels, L=1, 2, 4, 8, or 16) can be defined in LTE.

[0050] Some implementations may use the concept of resource allocation for control channel information, which is an extension of the above concept. For example, some implementations may utilize an extended (E)-PDCCH that uses PDSCH resources for control information transmission. One or more ECCEs may be used to transmit EPDCCH. Similar to the above, each ECCE may correspond to nine sets of four physical resource elements, referred to as EREGs. In some cases, an ECCE may have other numbers of EREGs.

[0051] The RAN nodes 222 may be configured to communicate with each other via an interface 223. In a specific implementation where the system is an LTE system, the interface 223 may be an X2 interface. In an NR system, the interface 223 may be an Xn interface. The X2 interface may be defined between two or more RAN nodes 222 (e.g., two or more eNBs / gNBs or a combination thereof) connected to an evolved packet core (EPC) or CN 230, or between two eNBs connected to the EPC. In some specific implementations, the X2 interface may include an X2 user plane interface (X2-U) and an X2 control plane interface (X2-C). The X2-U may provide a flow control mechanism for user data packets transmitted over the X2 interface, and may be used to convey information about the delivery of user data between eNBs or gNBs. For example, X2-U may provide specific sequence number information about user data transmitted from a master eNB (MeNB) to a secondary eNB (SeNB); information about successful in-sequence delivery of PDCP packet data units (PDUs) from the SeNB to the UE 210 for user data; information about PDCP PDUs that are not delivered to the UE 210; information about the current minimum expected buffer size at the SeNB for transmitting user data to the UE; etc. X2-C may provide intra-LTE access mobility functions (e.g., including context transfer from a source eNB to a target eNB, user plane transmission control, etc.), load management functions, and inter-cell interference coordination functions.

[0052] As shown, RAN 220 may be connected (e.g., communicatively coupled) to CN 230. CN 230 may include a plurality of network elements 232 configured to provide various data and telecommunication services to customers / subscribers (e.g., users of UE 210) connected to CN 230 via RAN 220. In some implementations, CN 230 may include an evolved packet core (EPC), a 5G CN, and / or one or more additional or alternative types of CNs. The components of CN 230 may be implemented in one physical node or in separate physical nodes, including components for reading and executing instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium). In some implementations, network function virtualization (NFV) may be used to virtualize any or all of the above-mentioned network node roles or functions via executable instructions stored in one or more computer-readable storage media (described in further detail below). A logical instance of CN 230 may be referred to as a network slice, and a logical instance of a portion of CN 230 may be referred to as a network sub-slice. Network Function Virtualization (NFV) architecture and infrastructure can be used to virtualize one or more network functions onto physical resources including a combination of industry-standard server hardware, storage hardware, or switches (alternatively performed by proprietary hardware). In other words, the NFV system can be used to perform a virtual or reconfigurable implementation of one or more EPC components / functions.

[0053] As shown, CN 230, application server 240 and external network 250 can be connected to each other via interfaces 234, 236 and 238, which may include IP network interfaces. Application server 240 may include one or more server devices or network elements (e.g., virtual network functions (VNFs)) that provide applications (e.g., universal mobile telecommunications system packet service (UMTS PS) domain, LTE-PS data services, etc.) that use IP bearer resources with CM 230. Application server 240 may be additionally or alternatively configured to support one or more communication services (e.g., IP voice (VoIP sessions, push-to-talk (PTT) sessions, group communication sessions, social networking services, etc.) of UE 210 via CN 230. Similarly, external network 250 may include one or more networks (including the Internet) in a variety of networks, thereby providing network access to a variety of additional services, information, interconnection and other network features for mobile communication networks and UE 210.

[0054] As shown, the example network 200 may include an NTN that may include one or more satellites 260-1 and 260-2 (collectively, "satellites 260"). The satellites 260 may communicate with the UE 210 via a serving link or wireless interface 262 and / or communicate with the RAN 220 via a feeder link or wireless interface 264 (depicted individually as 264-1 and 264). In some implementations, the satellites 260 may function as a passive network relay node or a transparent network relay node with respect to communications between the UE 210 and a terrestrial network (e.g., the RAN 220). In some implementations, the satellites 260 may function as an active network node or a regenerated network node such that the satellites 260 may function as a base station to the UE 210 with respect to communications between the UE 210 and the RAN 220 (e.g., functioning as a gNB for the RAN 220). In some implementations, the satellites 260 can communicate with each other via a direct wireless interface (eg, 266) or an indirect wireless interface (eg, via the RAN 220 using interface 264-1 and interface 264-2).

[0055] Additionally or alternatively, the satellite 260 may include a GEO satellite, a LEO satellite, or another type of satellite. The satellite 260 may additionally or alternatively relate to one or more satellite systems or architectures, such as a global navigation satellite system (GNSS), a global positioning system (GPS), a global navigation satellite system (GLONASS), a Beidou navigation satellite system (BDS), etc. In some specific implementations, the satellite 260 may be used as a base station (e.g., a RAN node 222) relative to the UE 210. Therefore, references to base stations, RAN nodes 222, etc. herein may relate to specific implementations in which the base stations, RAN nodes 222, etc. are ground network nodes, and specific implementations in which the base stations, RAN nodes 222, etc. are non-ground network nodes (e.g., satellites 260). As described herein, the UE 210 and the base station 222 may communicate with each other via the interface 214 to implement enhanced power saving techniques.

[0056] Figure 3 300 for intra-CU inter-DU mobility based on HARQ processes according to one or more implementations described herein. As shown, process 300 may be implemented by UE 210, CU 302, DU / TRP 304, and DU / TRP 306. CU 302 and DU / TRP 304 may correspond to base station 222-1, and DU / TRP 306 may correspond to base station 222-2. CU 302 may be Figure 1 130, and DU / TRP 304 and DU / TRP 306 may each be Figure 11 and 150. For simplicity, DU / TRP 304 and DU / TRP 306 may be referred to as DU 304 and DU 306, respectively.

[0057] In some implementations, part or all of process 300 may be performed by one or more other systems or devices, including Figure 1 or Figure 2 In addition, process 300 may include Figure 3 One or more fewer, additional, differently ordered, and / or arranged operations than those shown. In some implementations, one or more of the operations of process 300 may be performed independently, sequentially, simultaneously, etc., relative to one or more of the other operations of process 300. Thus, the techniques described herein are not limited to Figure 3 The number, sequence, arrangement, timing, etc. of the operations or processes depicted. Additionally, a specific implementation of one or more of the operations involved in process 300 may include one or more operations or functions of another example described herein.

[0058] As shown, process 300 may include UE 210 connecting to DU 304 of base station 222-1 (at 310). By extension, although not shown, UE 210 may also connect to CU 302 of base station 222-1. Thus, UE 210 may transmit and receive user data from base station 222-1 via DU 304 and CU 306 (at 320). UE 210 may not connect to DU 306 of base station 222-2.

[0059] UE 210 may periodically detect and measure signals broadcast by base stations 222 in the area. UE 210 may send a measurement report describing the detected signal and the corresponding base station 222 and the signal strength to DU 304, and DU 304 may send the measurement report to CU 302 (at 330). The measurement report may be sent via a UL RRC transport message. CU 302 may receive the measurement report and determine to enable a connection between UE 210 and DU 306, and may also determine the appropriate MAC / HARQ extension for doing so (at 340). The MAC / HARQ extension may include a HARQ process differentiation technique, wherein DU 304 and DU 306 each have a MAC layer implementing a HARQ entity having the same HARQ ID; however, some of the HARQ processes (e.g., HARQ process ID, HARQ process number, etc.) associated with the HARQ entity (e.g., HARQ ID) may be assigned or associated with DU 304, while other HARQ processes associated with the HARQ entity may be assigned or associated with DU 306. Thus, UE 210 may communicate with DU 304 and DU 306 using a single MAC layer and HARQ entity. Although not shown, DU 306 may release or terminate the MAC / HARQ configuration in response to UE 210 moving out of the coverage area of ​​DU 306, in response to an explicit release message from UE 210, CU 203, or another device or entity, or in response to another release trigger. Therefore, intra-CU inter-DU mobility of UE 210 may be achieved by configuring the MAC layer of the DU to have a HARQ entity and a corresponding HARQ process.

[0060] As shown, the process 300 may include the CU 302 sending HARQ process configuration information to the DU 306 (at 350). The HARQ process configuration information may be sent via a UE Set Context Request message or another type of message. The HARQ process configuration information may cause the DU 306 to create a HARQ entity at the MAC layer of the DU 306 using the same HARQ ID as the HARQ entity used by the DU 304 for the UE 210. The HARQ process configuration information may also indicate which HARQ processes (e.g., which HARQ process IDs or HARQ process numbers) correspond to the DU 306 and / or the DU 304. For example, HARQ processes 1 to 8 of HARQ ID X may correspond to the DU 304, and HARQ processes 9 to 16 of HARQ ID X may correspond to the DU 306. The DU 306 may respond by sending HARQ process confirmation information to the CU 302 (at 360). The HARQ process confirmation information may be sent via a UE Set Context Response message or another type of message. The HARQ process confirmation information may indicate to the CU 302 that the DU 306 is configured according to the previously received HARQ process configuration information.

[0061] CU 302 may send HARQ process configuration information to DU 304 (at 370). The HARQ process configuration information may be sent via a DL RRC transmission message or another type of message. The DL RRC transmission message may include an RRC reconfiguration message (e.g., an RRCReconfiguration message). The HARQ process configuration information may indicate a MAC / HARQ configuration for DU 304 and DU 306. For example, the HARQ process configuration information may indicate a HARQ entity (e.g., a HARQ ID) for communicating with DU 304 and DU 306. Additionally or alternatively, the HARQ process configuration information may indicate which HARQ processes of the HARQ entity correspond to DU 304 and which HARQ processes correspond to DU 306. In some implementations, in the event that UE 210 is to release another DU (not shown), the HARQ process configuration information may also indicate the DU and the HARQ process that should be released for the DU. In such implementations, one or more of the released HARQ processes may be reused by the UE 210 for communicating with the DU 304 or the DU 306 .

[0062] DU 304 may send an RRC reconfiguration message to UE 210 (at 380). In some implementations, one or more other types of messages may be used. The RRC reconfiguration message may include information and instructions for UE 210 to establish a connection with DU 306. In some implementations, the RRC reconfiguration message may also include information and instructions for UE 210 to reestablish or reconfigure an existing connection with DU 304. UE 210 may respond to the RRC reconfiguration message by configuring the MAC layer of UE 210 according to the HARQ entities (e.g., HARQ IDs) and corresponding HARQ processes (e.g., HARQ process IDs) of DU 304 and DU 306. In such implementations, the DCI from DU 304 and / or DU 306 may indicate the HARQ IDs of the HARQ entities supported by DU 304 and / or DU 306. If / when there is a new ID, the bits of the DCI may reflect the new ID.

[0063] UE 210 may use the information in the RRC reconfiguration message to establish a connection with the TRP of DU 304 and / or DU 306 (at 385). In some implementations, UE 210 may maintain the previously established connection with DU 304 (e.g., at 310) and establish an additional connection with DU 306. In some implementations, UE 210 may adjust the previously established connection with DU 304 (e.g., at 310) and establish an additional connection with DU 306 based on the RRC reconfiguration message. In some implementations, UE 210 may establish a new connection with each of DU 304 and 306 based on the RRC reconfiguration message. UE 210 may use these connections to communicate user data (e.g., user plane information) to the network. UE 210 may communicate with DU 304 and CU 302 based on the HARQ process associated with DU 304 (at 390). The UE may communicate with the DU 306 and the CU 302 based on the HARQ process associated with the DU 306 (at 395). The UE 210 may continue to periodically measure radio signals from base stations in the area, send measurement reports to the CU 302, etc., to achieve intra-CU inter-DU mobility of the UE 210 by repeating one or more of the operations of the process 300.

[0064] Figures 4 to 5Schematic diagrams of examples 400 and 500 of enhanced RRC messages and / or information elements (IEs) for intra-CU inter-DU mobility based on HARQ processes according to one or more implementations described herein. In some implementations, examples 400 and 500 may represent ways in which one or more of the intra-CU inter-DU mobility techniques described herein may be integrated into one or more existing 3GPP processes, IEs, RRC messages, etc. The following description does not describe all instructions and parameters of the messages and / or IEs, but rather emphasizes example enhancements to the messages and / or IEs that may implement the techniques described herein. Thus, CU 302, DU 304, DU 306, and / or UE 210 may use one or more of examples 400 and 500 to implement one or more of the techniques described herein. In other implementations, CU 302, DU 304, DU 306, and / or UE 210 may use one or more additional, alternative, or differently arranged messages and / or IEs. Thus, Figures 4 to 5 Provided as non-limiting examples.

[0065] Example 400 may include that CU 302 may use Figure 3 Information and instructions for configuring / reconfiguring UE 210. Example 400 can be part of an RRC reconfiguration message sent from CU 302 to UE 210 (relayed by DU 304) so ​​that UE 210 can establish a connection with DU 306. As shown, example 400 can include information and instructions for adding or modifying a non-serving TRP (see, e.g., NonServingTRPCell-Configuration, nonServingCellIndex, and nonServingCellConfigCommon). Example 400 can include information and instructions for indicating the number of HARQ processes for a TRP and the starting number of HARQ processes (see, e.g., nrofHARQ-ProcessesForMAC and harqProcessStartingNumber).

[0066] Example 500 may include information and instructions that CU 302 may use to configure / reconfigure DU 306 with appropriate MAC / HARQ entities. Example 500 may correspond to a UE context setup request message or another type of message sent from CU 302 to DU 306 via an F1 inter-node interface (see, e.g., UEContextSetupRequest, UEContextSetupRequestIEs, and F1AP-PROTOCOL-IES). Example 500 may also include information indicating a MAC HARQ process ID number and a corresponding starting position for UE 210DU 306 communication (see, e.g., id-GNBDUUEMacHarqProcessIDNumber and id-GNBDUUEMacHarqProcessIDStart).

[0067] Figure 6 6 is a diagram of an example of a process 600 for intra-CU inter-DU mobility based on HARQ processes according to one or more implementations described herein. As shown, process 600 may be implemented by UE 210, CU 302, DU / TRP 304, and DU / TRP 306. CU 302 and DU / TRP 304 may correspond to base station 222-1, and DU / TRP 306 may correspond to base station 222-2. CU 302 may be Figure 1 130, and DU / TRP 304 and DU / TRP 306 may each be Figure 1 1 and 150. For simplicity, DU / TRP 304 and DU / TRP 306 may be referred to as DU 304 and DU 306, respectively.

[0068] In some implementations, part or all of process 600 may be performed by one or more other systems or devices, including Figure 1 or Figure 2 In addition, process 600 may include Figure 6 One or more fewer, additional, differently ordered, and / or arranged operations than those shown. In some implementations, one or more of the operations of process 600 may be performed independently, sequentially, simultaneously, etc., relative to one or more of the other operations of process 600. Thus, the techniques described herein are not limited to Figure 6 The number, sequence, arrangement, timing, etc. of the operations or processes depicted. Additionally, a specific implementation of one or more of the operations involved in process 600 may include one or more operations or functions of another example described herein.

[0069] As shown, process 600 may include UE 210 connecting to DU 304 of base station 222-1 (at 610). By extension, although not shown, UE 210 may also connect to CU 302 of base station 222-1. Thus, UE 210 may transmit and receive user data from base station 222-1 via DU 304 and CU 306 (at 620). UE 210 may not connect to DU 306 of base station 222-2.

[0070] UE 210 may periodically detect and measure signals broadcast by base stations 222 in the area. UE 210 may send a measurement report describing the detected signal and the corresponding base station 222 and the signal strength to DU 304, and DU 304 may send the measurement report to CU 302 (at 630). The measurement report may be sent via an UL RRC transport message. CU 302 may receive the measurement report and determine to enable a connection between UE 210 and DU 306, and may also determine the appropriate MAC / HARQ extension for doing so (at 640). The MAC / HARQ extension may include a HARQ process differentiation technique, wherein DU 304 and DU 306 each have a MAC layer implementing a HARQ entity having the same HARQ ID; however, some of the HARQ processes (e.g., HARQ process ID, HARQ process number, etc.) associated with the HARQ entity (e.g., HARQ ID) may be assigned or associated with DU 304, while other HARQ processes associated with the HARQ entity may be assigned or associated with DU 306. Thus, UE 210 may communicate with DU 304 and DU 306 using a single MAC layer and HARQ entity. Although not shown, DU 306 may release or terminate the MAC / HARQ configuration in response to UE 210 moving out of the coverage area of ​​DU 306, in response to an explicit release message from UE 210, CU 203, or another device or entity, or in response to another release trigger. Therefore, intra-CU inter-DU mobility of UE 210 may be achieved by configuring the MAC layer of the DU to have a HARQ entity and a corresponding HARQ process.

[0071] As shown, the process 600 may include the CU 302 sending a HARQ process ID request to the DU 306 (at 650). The HARQ process ID request may be sent via a UE set context request message or another type of message. The HARQ process ID request may cause the DU 306 to create a HARQ entity with a HARQ ID that matches the HARQ entity / ID of the DU 304. In response, the DU 306 determines which HARQ processes (e.g., which HARQ process ID numbers) to use to communicate with the UE 210 (at 655). In some implementations, the DU 304 may determine the HARQ process based at least in part on which HARQ processes the DU 304 has used to communicate with the UE 210. For example, if the DU 304 is using HARQ process ID numbers 9-16 of HARQ ID Y to communicate with the UE 210, the DU 306 may determine to use HARQ process ID numbers 1-8 of HARQ ID Y. In some implementations, the DU 306 may use one or more other or alternative factors to determine which HARQ processes to use to communicate with the UE 210. The DU 306 may respond to the request from the CU 302 (at 660) by sending HARQ process ID preference information to the CU 302. The HARQ process ID preference information may be sent via a UE Set Context Response message or another type of message. The HARQ process ID preference information may indicate a HARQ process (e.g., a HARQ process ID number) determined by the DU 306 for communicating with the UE 210.

[0072] CU 302 may send HARQ process configuration information to DU 304 (at 670). The HARQ process configuration information may be sent via a DL RRC transmission message or another type of message. The DL RRC transmission message may include an RRC reconfiguration message (e.g., an RRCReconfiguration message). The HARQ process configuration information may indicate a MAC / HARQ configuration for DU 304 and DU 306. For example, the HARQ process configuration information may indicate a HARQ entity (e.g., a HARQ ID) for communicating with DU 304 and DU 306. Additionally or alternatively, the HARQ process configuration information may indicate which HARQ processes of the HARQ entity correspond to DU 304 and which HARQ processes correspond to DU 306. In some implementations, in the event that UE 210 is to release another DU (not shown), the HARQ process configuration information may also indicate the DU and the HARQ process that should be released for the DU. In such implementations, one or more of the released HARQ processes may be reused by the UE 210 for communicating with the DU 304 or the DU 306 .

[0073] DU 304 may send an RRC reconfiguration message to UE 210 (at 680). In some implementations, one or more other types of messages may be used. The RRC reconfiguration message may include information and instructions for UE 210 to establish a connection with DU 306. In some implementations, the RRC reconfiguration message may also include information and instructions for UE 210 to reestablish or reconfigure an existing connection with DU 304. UE 210 may respond to the RRC reconfiguration message by configuring the MAC layer of UE 210 according to the HARQ entities (e.g., HARQ IDs) and corresponding HARQ processes (e.g., HARQ process IDs) of DU 304 and DU 306. In such implementations, the DCI from DU 304 and / or DU 306 may indicate the HARQ IDs of the HARQ entities supported by DU 304 and / or DU 306. If / when there is a new ID, the bits of the DCI may reflect the new ID.

[0074] UE 210 may use the information in the RRC reconfiguration message to establish a connection with the TRP of DU 304 and / or DU 306 (at 685). In some implementations, UE 210 may maintain the previously established connection with DU 304 (e.g., at 610) and establish an additional connection with DU 306. In some implementations, UE 210 may adjust the previously established connection with DU 304 based on the RRC reconfiguration message (e.g., at 610) and establish an additional connection with DU 306. In some implementations, UE 210 may establish a new connection with each of DU 304 and 306 based on the RRC reconfiguration message. UE 210 may use these connections to communicate user data (e.g., user plane information) to the network. UE 210 may communicate with DU 304 and CU 302 based on the HARQ process associated with DU 304 (at 690). The UE may communicate with the DU 306 and the CU 302 based on the HARQ process associated with the DU 306 (at 695). The UE 210 may continue to periodically measure radio signals from base stations in the area, send measurement reports to the CU 302, etc., to achieve intra-CU inter-DU mobility of the UE 210 by repeating one or more of the operations of process 600.

[0075] Figures 7 and 8 Schematic diagrams of examples 700 and 800 of enhanced RRC messages and / or IEs for intra-CU inter-DU mobility based on HARQ processes according to one or more implementations described herein. In some implementations, examples 700 and 800 may represent ways in which one or more of the intra-CU inter-DU mobility techniques described herein may be integrated into one or more existing 3GPP processes, IEs, RRC messages, etc. The following description does not describe all instructions and parameters of the messages and / or IEs, but rather emphasizes example enhancements to the messages and / or IEs that may implement the techniques described herein. Thus, CU 302, DU 304, DU 306, and / or UE 210 may use one or more of examples 700 and 800 to implement one or more of the techniques described herein. In other implementations, CU 302, DU 304, DU 306, and / or UE 210 may use one or more additional, alternative, or differently arranged messages and / or IEs. Thus, Figures 7 and 8 Provided as non-limiting examples.

[0076] Example 700 may include information and instructions that CU 302 may use to configure / reconfigure DU 306 with an appropriate MAC / HARQ entity and / or prompt DU 306 to determine and provide a HARQ process for communicating with UE 210. Example 700 may correspond to a UE context setup request message or another type of message sent from CU 302 to DU 306 via an F1 inter-node interface (see, e.g., UEContextSetupRequest, UEContextSetupRequestIEs, and F1AP-PROTOCOL-IES). Example 700 may also include information requesting a MAC HARQ process ID number for communication between UE 210 and DU 306 (see, e.g., id-GNBDUUEMacHarqProcessInformationReq).

[0077] Example 800 may include information and instructions that DU 306 may send to CU 302 to indicate a HARQ process for communicating with UE 210. Example 800 may correspond to a UE context setup response message or another type of message sent from DU 306 to CU 302 via an F1 interface (see, e.g., UEContextSetupResponse, UEContextSetupResponseIEs, and F1AP-PROTOCOL-IES). Example 800 may also include information indicating a MAC HARQ process ID number and a corresponding starting position for UE 210 DU 306 communications (see, e.g., id-DUtoCUMACInformation).

[0078] Fig. 9 1 is a diagram of an example of a process 900 for intra-CU inter-DU mobility based on HARQ processes according to one or more implementations described herein. As shown, process 900 may be implemented by UE 210, CU 302, DU / TRP 304, and DU / TRP 306. CU 302 and DU / TRP 304 may correspond to base station 222-1, and DU / TRP 306 may correspond to base station 222-2. CU 302 may be Figure 1 130, and DU / TRP 304 and DU / TRP 306 may each be Figure 1 1 and 150. For simplicity, DU / TRP 304 and DU / TRP 306 may be referred to as DU 304 and DU 306, respectively.

[0079] In some implementations, part or all of process 900 may be performed by one or more other systems or devices, including Figure 1 or Figure 2 In addition, process 900 may include: Fig. 9 One or more fewer, additional, differently ordered, and / or arranged operations than those shown. In some implementations, one or more of the operations of process 900 may be performed independently, sequentially, simultaneously, etc., relative to one or more of the other operations of process 900. Thus, the techniques described herein are not limited to Fig. 9 The number, sequence, arrangement, timing, etc. of the operations or processes depicted. Additionally, a specific implementation of one or more of the operations involved in process 900 may include one or more operations or functions of another example described herein.

[0080] As shown, process 900 may include UE 210 connecting to DU 304 of base station 222-1 (at 910). By extension, although not shown, UE 210 may also connect to CU 302 of base station 222-1. Thus, UE 210 may transmit and receive user data from base station 222-1 via DU 304 and CU 306 (at 920). UE 210 may not connect to DU 306 of base station 222-2.

[0081] UE 210 may detect and measure signals broadcast by base stations 222 in the area. UE 210 may send a measurement report describing the detected signal and the corresponding base station 222 and the signal strength to DU 304, and DU 304 may send the measurement report to CU 302 (at 930). The measurement report may be sent via a UL RRC transmission message. CU 302 may receive the measurement report and determine to implement a connection between UE 210 and DU 306, and may also determine the appropriate MAC / HARQ extension for doing so (at 940). MAC / HARQ extensions may include TRP differentiation techniques, wherein DU 304 and DU 306 each have a MAC layer that implements a HARQ entity with the same HARQ ID; however, a TRP ID (e.g., PCI or another type of ID) associated with each of DU 304 and DU 306 is used to distinguish between a HARQ process corresponding to DU 304 and a HARQ process corresponding to DU 306. Thus, the UE 210 can use a single MAC layer and HARQ entity to communicate with the DU 304 and the DU 306 because the UE 210 can determine the source of the communication (e.g., DU 304 or DU 306) (having the same HARQ ID and the same HARQ process ID number) based on the TRP ID associated with the communication. In some implementations, the CU 302 may not communicate the TRP IDs of the DUs 304 and 306 to the UE 210. Instead, the CU 302 may inform the UE 210 that TRP differentiation is being used, and the UE 210 may determine the TRP IDs of the DUs 304 and 306 based on the PDSCH (e.g., based on the TRP beam that the UE uses to demodulate the PDSCH or the carrier / TRP / beam from which the PDSCH is received).

[0082] Therefore, even when DU 304 and DU 306 use the same HARQ ID and the same (or overlapping) HARQ process ID number, TRP differentiation can also achieve intra-CU inter-DU mobility. In addition (although not shown), DU 306 can release or terminate the MAC / HARQ configuration in response to UE 210 moving out of the coverage area of ​​DU 306, in response to an explicit release message from UE 210, CU 203 or another device or entity, or in response to another release trigger.

[0083] Process 900 may include CU 302 sending a UE Set Context Request message or another type of message to DU 306 (at 950). DU 306 may respond by sending a UE Set Context Response message or another type of message to CU 302 (at 960). Because TRP differentiation may enable UE 210 to determine the HARQ ID based on the TRP ID, DUs 304 and 306 may use the same or different HARQ IDs. In turn, in accordance with 3GPP communication standards, UE Set Context Request and Response messages from CU 302 may include the same or similar information.

[0084] CU 302 may send HARQ process configuration information to DU 304 (at 970). The HARQ process configuration information may be sent via a DL RRC transmission message or another type of message. The DL RRC transmission message may include an RRC reconfiguration message (e.g., an RRCReconfiguration message). The HARQ process configuration information may include an indication that UE 210 is to implement HARQ based on a TRP ID (e.g., based on the ID of the TRP providing the corresponding PDSCH). DU 304 may send an RRC reconfiguration message to UE 210 (at 980). In some implementations, one or more other types of messages may be used. The RRC reconfiguration message may include information and instructions for UE 210 to establish a connection with DU 306. In some implementations, the RRC reconfiguration message may also include information and instructions for UE 210 to configure the MAC layer and the corresponding HARQ entity of UE 210 based on the TRP distinction, and in response, UE 210 may do so.

[0085] UE 210 may use the information in the RRC reconfiguration message to establish a connection with the TRP of DU 304 and / or DU 306 (at 985). In some implementations, UE 210 may maintain the previously established connection with DU 304 (e.g., at 910) and establish an additional connection with DU 306. In some implementations, UE 210 may establish a new connection with each of DU 304 and 306 based on the RRC reconfiguration message. UE 210 may use these connections to communicate user data (e.g., user plane information) to DU 304 (at 990) and to communicate user data to DU 306 (at 995). UE 210 may communicate with DU 304, DU 306, and CU 302 by determining HARQ IDs and / or HARQ processes for DU 304 and 306 based on the TRP IDs of the TRPs of DU 304, DU 306.

[0086] Fig.10 is a diagram of an example of enhanced RRC messages and / or IEs for intra-CU inter-DU mobility based on TRP ID according to one or more specific implementations described herein. In some specific implementations, example 1000 may represent a manner in which one or more of the intra-CU inter-DU mobility techniques described herein may be integrated into one or more existing 3GPP processes, IEs, RRC messages, etc. The following description does not describe all instructions and parameters of the messages and / or IEs, but rather emphasizes example enhancements to the messages and / or IEs that may implement the techniques described herein. Thus, CU 302, DU 304, DU 306, and / or UE 210 may use example 1000 to implement one or more of the techniques described herein. In other specific implementations, CU 302, DU 304, DU 306, and / or UE 210 may use one or more additional, alternative, or differently arranged messages and / or IEs. Thus, Fig.10 Provided as non-limiting examples.

[0087] Example 1000 may include that CU 302 may use Fig. 9 Information and instructions for configuring / reconfiguring UE 210. Example 1000 can be part of an RRC reconfiguration message sent from CU 302 to DU 304 and / or from DU 304 to UE 210 so that UE 210 can establish a connection with DU 306. As shown, example 1000 may include information and instructions for adding or modifying a non-serving TRP (see, e.g., NonServingTRPCell-Configuration, nonServingCellIndex, and nonServingCellConfigCommon). Example 1000 may include information and instructions for implementing TRP-based differentiation of HARQ procedures (see, e.g., nrofHARQ-ProcessesForMAC, harqProcessStartingNumber, and useTRPbased).

[0088] Fig.11 1 is a diagram of an example of a process 1100 for intra-CU inter-DU mobility based on a dual MAC architecture according to one or more implementations described herein. As shown, process 1100 may be implemented by UE 210, CU 302, DU / TRP 304, and DU / TRP 306. CU 302 and DU / TRP 304 may correspond to base station 222-1, and DU / TRP 306 may correspond to base station 222-2. CU 302 may be Figure 1130, and DU / TRP 304 and DU / TRP 306 may each be Figure 1 1 and 150. For simplicity, DU / TRP 304 and DU / TRP 306 may be referred to as DU 304 and DU 306, respectively.

[0089] In some implementations, part or all of process 1100 may be performed by one or more other systems or devices, including Figure 1 or Figure 2 In addition, process 1100 may include one or more Fig.11 In some implementations, one or more of the operations of process 1100 may be performed independently, sequentially, simultaneously, etc., relative to one or more of the other operations of process 1100. Thus, the techniques described herein are not limited to Fig.11 The number, sequence, arrangement, timing, etc. of the operations or processes depicted. Additionally, a specific implementation of one or more of the operations involved in process 1100 may include one or more operations or functions of another example described herein.

[0090] As shown, process 1100 may include UE 210 connecting to DU 304 of base station 222-1 (at 1110). By extension, although not shown, UE 210 may also connect to CU 302 of base station 222-1. Thus, UE 210 may transmit and receive user data from base station 222-1 via DU 304 and CU 306 (at 1120). UE 210 may not connect to DU 306 of base station 222-2.

[0091] UE 210 may detect and measure signals broadcast by base stations 222 in the area. UE 210 may send a measurement report describing the detected signal and the corresponding base station 222 and the signal strength to DU 304, and DU 304 may send the measurement report to CU 302 (at 1130). The measurement report may be sent via a UL RRC transmission message. CU 302 may receive the measurement report and determine to implement a connection between UE 210 and DU 306 via a dual MAC architecture (at 1140). As described herein, a dual MAC architecture may include a scenario in which DU 304 and DU 306 implement their own MAC / HARQ entity for communicating with UE 210 and UE 210 implements a separate MAC / HARQ entity for each of DU 304 and DU 306. Additionally or alternatively, as described herein, a dual MAC architecture may include more than two MAC / HARQ entities for DU / TRP (e.g., a multi-MAC architecture).

[0092] The process 1100 may include the CU 302 sending a UE set context request message or another type of message to the DU 306 (at 1150). The UE set context request message may include information and / or instructions for the DU 306 to implement a MAC layer, a HARQ entity, and / or a corresponding HARQ process for communicating with the UE 210. In response, the DU 306 may operate according to the request by creating a corresponding MAC layer, a HARQ entity, and / or a HARQ process. Additionally or alternatively, the DU 306 may respond by sending a UE set context response message or another type of message to the CU 302 (at 1160). The UE set context response message may confirm that the DU 306 has been configured to communicate with the UE 210 according to the UE set context request message, and / or provide support or enabling information corresponding to the configuration.

[0093] CU 302 may send a DL RRC transmission message or another type of message to DU 304 (at 1170). The DL RRC transmission message may include an RRC reconfiguration message or RRC reconfiguration information. Additionally or alternatively, the DL RRC transmission message may include MAC / HARQ configuration information for enabling UE 210 to communicate with DU 306 and establish a connection therewith. Examples of such information may include MAC layer configuration information, HARQ entity configuration information, HARQ process information, etc. In response, DU 304 may send an RRC reconfiguration message to UE 210 (at 1180). In some implementations, one or more other types of messages may be used. The RRC reconfiguration message may include information and instructions for UE 210 to establish a connection with DU 306 via a dual MAC architecture. In some implementations, this may include information and instructions for UE 210 to create and configure an additional MAC layer, a corresponding HARQ entity, etc. to enable UE 210 to communicate with DU 306. In this scenario, UE 210 may support the pre-existing MAC layer and corresponding HARQ entity for DU 304 and create an additional MAC layer and corresponding HARQ entity for DU 306.

[0094] Thus, UE 210 may use the information in the RRC reconfiguration message to establish a connection with DU 304 and / or DU 306 (at 1185). In some implementations, UE 210 may maintain the previously established connection with DU 304 (e.g., at 1110) and establish an additional connection with DU 306. In some implementations, UE 210 may establish a new connection with each of DUs 304 and 306 based on the RRC reconfiguration message. UE 210 may use these connections to communicate user data (e.g., user plane information) to DU 304 (at 1190) and to communicate user data to DU 306 (at 1195).

[0095] As shown, the UE may additionally or alternatively communicate power headroom report (PHR) information, buffer status report (BSR), and / or one or more additional or alternative types of information. The UE 210 may additionally or alternatively trigger one or more processes or procedures when adding DU 604, such as UL power handling procedures for communication toward DU 604. The PHR information may include a type of MAC control element (CE) for reporting the amount of headroom between the current UE Tx power and the nominal power. In addition to the power used for the current transmission (e.g., toward DU 604), the PHR information may also indicate how much transmit power is available or how much transmit power is left for the UE 210. The BSR information may also include the type of MAC CE from the UE 210 to the DU 306, which carries information indicating how much data is in the transmit buffer of the UE 210 and waiting to be sent to the DU 306.

[0096] Sending PHR information, BSR information, BSR information, etc. can facilitate or enhance one or more dual MAC implementations, as described herein. For example, when a new beam / TRP / carrier is added, UE 210 can allocate power to transmissions in that beam / TRP / carrier because, for example, UE 210 may have a limited amount of power (based on power amplifiers). Therefore, UE 210 can be configured to notify the network how much power can be allocated to the beam / TRP / carrier because some power has already been used to transmit on the original beam / TRP / carrier. Therefore, one or more of the techniques described herein enable intra-CA inter-DU mobility via a dual MAC architecture.

[0097] Fig.12 is a diagram of examples of enhanced RRC messages and / or IEs for intra-CU inter-DU mobility based on a dual MAC architecture according to one or more implementations described herein. In some implementations, example 1200 may represent a manner in which one or more of the intra-CU inter-DU mobility techniques described herein may be integrated into one or more existing 3GPP processes, IEs, RRC messages, etc. The following description does not describe all instructions and parameters of the messages and / or IEs, but rather emphasizes example enhancements to the messages and / or IEs that may implement the techniques described herein. Thus, CU 302, DU 304, DU 306, and / or UE 210 may use example 1200 to implement one or more of the techniques described herein. In other implementations, CU 302, DU 304, DU 306, and / or UE 210 may use one or more additional, alternative, or differently arranged messages and / or IEs. Thus, Fig.12 Provided as non-limiting examples.

[0098] Example 1200 may include that CU 302 may use Fig.11 Information and instructions for configuring / reconfiguring UE 210. Example 1200 can be part of an RRC reconfiguration message sent from CU 302 to DU 304 and / or from DU 304 to UE 210 so that UE 210 can establish a connection with DU 306. As shown, example 1200 can include information and instructions for adding or modifying a non-serving TRP (see, e.g., NonServingTRPCell-Configuration, nonServingCellIndex, and nonServingCellConfigCommon). Example 1200 can additionally or alternatively include information and instructions for implementing intra-CU inter-DU mobility based on a dual MAC architecture (see, e.g., nonServingCellConfigCommon and useSeperateMACforTRP).

[0099] Fig.13 1 is a diagram of an example of a process 1300 for intra-CU inter-DU mobility based on a dual MAC and RLC architecture according to one or more implementations described herein. As shown, process 1300 may be implemented by UE 210, CU 302, DU / TRP 304, and DU / TRP 306. CU 302 and DU / TRP 304 may correspond to base station 222-1, and DU / TRP 306 may correspond to base station 222-2. CU 302 may be Figure 1 130, and DU / TRP 304 and DU / TRP 306 may each be Figure 1 1 and 150. For simplicity, DU / TRP 304 and DU / TRP 306 may be referred to as DU 304 and DU 306, respectively.

[0100] In some implementations, part or all of process 1300 may be performed by one or more other systems or devices, including Figure 1 or Figure 2 In addition, process 1300 may include Fig.13 The operations shown may be fewer, additional, differently ordered, and / or arranged than those shown. In some implementations, one or more of the operations of process 1300 may be performed independently, sequentially, simultaneously, etc., relative to one or more of the other operations of process 1300. Thus, the techniques described herein are not limited to Fig.13The number, sequence, arrangement, timing, etc. of the operations or processes depicted. Additionally, a specific implementation of one or more of the operations involved in process 1300 may include one or more operations or functions of another example described herein.

[0101] As shown, process 1300 may include UE 210 connecting to DU 304 of base station 222-1 (at 1310). By extension, although not shown, UE 210 may also connect to CU 302 of base station 222-1. Thus, UE 210 may transmit and receive user data from base station 222-1 via DU 304 and CU 306 (at 1320). UE 210 may not connect to DU 306 of base station 222-2.

[0102] UE 210 may detect and measure signals broadcast by base stations 222 in the area. UE 210 may send a measurement report describing the detected signal and the corresponding base station 222 and the signal strength to DU 304, and DU 304 may send the measurement report to CU 302 (at 1330). The measurement report may be sent via a UL RRC transport message. CU 302 may receive the measurement report and determine to implement a connection between UE 210 and DU 306 via a dual MAC and RLC architecture (at 1340). As described herein, the dual MAC and RLC architecture may include a scenario in which DU 304 and DU 306 implement their own MAC / HARQ entity and RLC layer for communicating with UE 210 and UE 210 implements a separate MAC / HARQ entity and RLC layer for each of DU 304 and DU 306. In process 1300, each RLC layer / entity may be a copy of each radio bearer (RB) supported. Additionally or alternatively, as described herein, a dual MAC and RLC architecture may include more than two MAC / HARQ entities and RLC layers for communicating with a DU / TRP (e.g., a multiple MAC and RLC architecture). In addition, the UE 210 may be configured to release additional MAC and RLC layers when the corresponding connection with the DU / TRP is lost or no longer used.

[0103] The process 1300 may include the CU 302 sending a UE set context request message or another type of message to the DU 306 (at 1350). The UE set context request message may include information and / or instructions for the DU 306 to implement a MAC layer, a corresponding HARQ entity, and / or an RLC layer for communicating with the UE 210. In response, the DU 306 may operate according to the request by creating a protocol stack instance with a corresponding MAC layer, HARQ entity, HARQ process, and / or RLC layer. Additionally or alternatively, the DU 306 may respond by sending a UE set context response message or another type of message to the CU 302 (at 1360). The UE set context response message may confirm that the DU 306 has been configured to communicate with the UE 210 according to the UE set context request message, and / or provide support or enabling information corresponding to the configuration.

[0104] CU 302 may send a DL RRC transmission message or another type of message to DU 304 (at 1370). The DL RRC transmission message may include an RRC reconfiguration message or RRC reconfiguration information. Additionally or alternatively, the DL RRC transmission message may include MAC / RLC configuration information for enabling UE 210 to communicate with DU 306 and establish a connection therewith. Examples of such information may include MAC layer configuration information, HARQ entity configuration information, HARQ process information, RLC layer configuration information, etc. In response, DU 304 may send an RRC reconfiguration message to UE 210 (at 1380). In some implementations, one or more other types of messages may be used. The RRC reconfiguration message may include information and instructions for UE 210 to establish a connection with DU 306 via a dual MAC / RLC architecture. In some implementations, this may include information and instructions for UE 210 to create and configure an additional MAC layer, a corresponding HARQ entity, an additional RLC layer, etc. to enable UE 210 to communicate with DU 306. In this scenario, UE 210 may support the pre-existing MAC layer, corresponding HARQ entity, and RLC layer for DU 304 , and create an additional MAC layer, corresponding HARQ entity, and RLC layer for DU 306 .

[0105] Thus, UE 210 may use the information in the RRC reconfiguration message to establish a connection with DU 304 and / or DU 306 (at 1385). In some implementations, UE 210 may maintain the previously established connection with DU 304 (e.g., at 1310) and establish an additional connection with DU 306. In some implementations, UE 210 may establish a new connection with each of DUs 304 and 306 based on the RRC reconfiguration message. UE 210 may use these connections to communicate user data (e.g., user plane information) to DU 304 (at 1390) and to communicate user data to DU 306 (at 1395). As shown,

[0106] CU 302 may be configured to transmit a PDCP service data unit (SDU) to DU 304 or DU 306 based on the configuration requirements or capabilities of DU 304 or DU 306 (at 1397). In some implementations, the PDCP SDU is secured at CU 302 (e.g., at UP 134 of CU 302) such that no additional security information is required at the DU / TRP. In the UL direction, CU 302 may implement a common PDCP for dual MAC and RLC layers. RLC protocol data units (PDUs) and / or PDCP SDUs from UE 210 may arrive at the common PDCP, and the common PDCP may detect and discard copies that may arrive at CU 302 via different branches of DU 304 and DU 306 (at 1397).

[0107] Fig.14 is a diagram of an example of an enhanced RRC IE 1400 for intra-CU inter-DU mobility based on a dual MAC and RLC architecture according to one or more implementations described herein. In some implementations, example 1400 may represent a manner in which one or more of the intra-CU inter-DU mobility techniques described herein may be integrated into one or more existing 3GPP processes, IEs, RRC messages, etc. The following description does not describe all instructions and parameters of the messages and / or IEs, but rather emphasizes example enhancements to the messages and / or IEs that may implement the techniques described herein. Thus, CU 302, DU 304, DU 306, and / or UE 210 may use example 1400 to implement one or more of the techniques described herein. In other implementations, CU 302, DU 304, DU 306, and / or UE 210 may use one or more additional, alternative, or differently arranged messages and / or IEs. Thus, Fig.14 Provided as non-limiting examples.

[0108] Example 1400 may include that CU 302 may use Fig.13 Information and instructions for configuring / reconfiguring UE 210. Example 1400 can be part of an RRC reconfiguration message sent from CU 302 to DU 304 and / or from DU 304 to UE 210 so that UE 210 can establish a connection with DU 306. As shown, example 1400 may include information and instructions for adding or modifying a non-serving TRP (see, e.g., NonServingTRPCell-Configuration, nonServingCellIndex, and nonServingCellConfigCommon). Example 1400 may additionally or alternatively include information and instructions for implementing intra-CU inter-DU mobility based on a dual MAC architecture (see, e.g., nonServingCellConfigCommon and useSeperateRLCforTRP).

[0109] Fig.15 1 is a diagram of an example of a process 1500 for intra-CU inter-DU mobility based on a dual MAC and RLC architecture according to one or more implementations described herein. As shown, process 1500 may be implemented by UE 210, CU 302, DU / TRP 304, and DU / TRP 306. CU 302 and DU / TRP 304 may correspond to base station 222-1, and DU / TRP 306 may correspond to base station 222-2. CU 302 may be Figure 1 130, and DU / TRP 304 and DU / TRP 306 may each be Figure 1 1 and 150. For simplicity, DU / TRP 304 and DU / TRP 306 may be referred to as DU 304 and DU 306, respectively.

[0110] In some implementations, part or all of process 1500 may be performed by one or more other systems or devices, including Figure 1 or Figure 2 In addition, process 1500 may include Fig.15 The operations shown may be fewer, additional, differently ordered, and / or arranged than those shown. In some implementations, one or more of the operations of process 1500 may be performed independently, sequentially, simultaneously, etc., relative to one or more of the other operations of process 1500. Thus, the techniques described herein are not limited to Fig.15The number, sequence, arrangement, timing, etc. of the operations or processes depicted. Additionally, a specific implementation of one or more of the operations involved in process 1500 may include one or more operations or functions of another example described herein.

[0111] As shown, process 1500 may include UE 210 connecting to DU 304 of base station 222-1 (at 1510). By extension, although not shown, UE 210 may also connect to CU 302 of base station 222-1. Thus, UE 210 may transmit and receive user data from base station 222-1 via DU 304 and CU 306 (at 1520). UE 210 may not connect to DU 306 of base station 222-2.

[0112] UE 210 may detect and measure signals broadcast by base stations 222 in the area. UE 210 may send a measurement report describing the detected signal and the corresponding base station 222 and the signal strength to DU 304, and DU 304 may send the measurement report to CU 302 (at 1530). The measurement report may be sent via a UL RRC transport message. CU 302 may receive the measurement report and determine to implement a connection between UE 210 and DU 306 via a dual MAC and RLC architecture (at 1540). As described herein, the dual MAC and RLC architecture may include scenarios in which DU 304 and DU 306 implement their own MAC / HARQ entity and RLC layer for communicating with UE 210 and UE 210 implements a separate MAC / HARQ entity and RLC layer for each of DU 304 and DU 306. Additionally or alternatively, as described herein, a dual MAC and RLC architecture may include more than two MAC / HARQ entities and RLC layers for communicating with a DU / TRP (e.g., a multiple MAC and RLC architecture). In process 1500, the RLC layer / entity may be specific to an RB or logical channel. For example, each RB supported by a DU TRP 306 may have a different RLC configuration. In addition, the UE 210 may be configured to release additional MAC and RLC layers when the corresponding connection to the DU / TRP is lost or no longer used.

[0113] The process 1500 may include the CU 302 sending a UE set context request message or another type of message to the DU 306 (at 1550). The UE set context request message may include information and / or instructions for the DU 306 to implement a MAC layer, a corresponding HARQ entity, and / or an RLC layer for communicating with the UE 210. In response, the DU 306 may operate according to the request by creating a protocol stack instance with a corresponding MAC layer, HARQ entity, HARQ process, and / or RLC layer. Additionally or alternatively, the DU 306 may respond by sending a UE set context response message or another type of message to the CU 302 (at 1560). The UE set context response message may confirm that the DU 306 has been configured to communicate with the UE 210 according to the UE set context request message, and / or provide support or enabling information corresponding to the configuration.

[0114] CU 302 may send a DL RRC transmission message or another type of message to DU 304 (at 1570). The DL RRC transmission message may include an RRC reconfiguration message or RRC reconfiguration information. Additionally or alternatively, the DL RRC transmission message may include MAC / RLC configuration information for enabling UE 210 to communicate with DU 306 and establish a connection therewith. Examples of such information may include MAC layer configuration information, HARQ entity configuration information, HARQ process information, RLC layer configuration information, etc. In response, DU 304 may send an RRC reconfiguration message to UE 210 (at 1580). In some implementations, one or more other types of messages may be used. The RRC reconfiguration message may include information and instructions for UE 210 to establish a connection with DU 306 via a dual MAC / RLC architecture. In some implementations, this may include information and instructions for UE 210 to create and configure an additional MAC layer, a corresponding HARQ entity, an additional RLC layer, etc. to enable UE 210 to communicate with DU 306. The RLC layer / entity may be specific to an RB or logical channel (e.g., each RB used to enable communication between UE 210 and DU TRP 306 may have a different RLC configuration). In this scenario, UE 210 may support the pre-existing MAC layer, corresponding HARQ entity, and RLC layer for DU 304, and create an additional MAC layer, corresponding HARQ entity, and RLC layer for DU 306.

[0115] Thus, UE 210 may use the information in the RRC reconfiguration message to establish a connection with DU 304 and / or DU 306 (at 1585). In some implementations, UE 210 may maintain the previously established connection with DU 304 (e.g., at 1510) and establish an additional connection with DU 306. In some implementations, UE 210 may establish a new connection with each of DUs 304 and 306 based on the RRC reconfiguration message. UE 210 may use these connections to communicate user data (e.g., user plane information) to DU 304 (at 1590) and to communicate user data to DU 306 (at 1595). As shown,

[0116] CU 302 may be configured to transmit a PDCP service data unit (SDU) to DU 304 or DU 306 based on the configuration requirements or capabilities of DU 304 or DU 306 (at 1597). In some implementations, the PDCP SDU is secured at CU 302 (e.g., at UP 134 of CU 302) such that no additional security information is required at the DU / TRP. In the UL direction, CU 302 may implement a common PDCP for dual MAC and RLC layers. RLC protocol data units (PDUs) and / or PDCP SDUs from UE 210 may arrive at the common PDCP, and the common PDCP may detect and discard copies that may arrive at CU 302 via different branches of DU 304 and DU 306 (at 1597).

[0117] Fig.16 is a diagram of an example of an enhanced RRC IE 1600 for intra-CU inter-DU mobility based on a dual MAC and RLC architecture according to one or more implementations described herein. In some implementations, example 1600 may represent a manner in which one or more of the intra-CU inter-DU mobility techniques described herein may be integrated into one or more existing 3GPP processes, IEs, RRC messages, etc. The following description does not describe all instructions and parameters of the messages and / or IEs, but rather emphasizes example enhancements to the messages and / or IEs that may implement the techniques described herein. Thus, CU 302, DU 304, DU 306, and / or UE 210 may use example 1600 to implement one or more of the techniques described herein. In other implementations, CU 302, DU 304, DU 306, and / or UE 210 may use one or more additional, alternative, or differently arranged messages and / or IEs. Thus, Fig.16 Provided as non-limiting examples.

[0118] Example 1600 may include that CU 302 may use Fig.13 Information and instructions for configuring / reconfiguring UE 210. Example 1600 can be part of an RRC reconfiguration message sent from CU 302 to DU 304 and / or from DU 304 to UE 210 so that UE 210 can establish a connection with DU 306. As shown, example 1600 may include information and instructions for adding or modifying a non-serving TRP (see, e.g., NonServingTRPCell-Configuration, nonServingCellIndex, and nonServingCellConfigCommon). Example 1600 may additionally or alternatively include information and instructions for implementing intra-CU inter-DU mobility based on a dual MAC architecture (see, e.g., nonServingCellConfigCommon and useSeperateRLCforTRP). Example 1600 may additionally or alternatively include information and instructions for configuring UE 210 to support each RB used or supported by a new TRP (e.g., TRP of DU 306) having a different RLC configuration than an existing TRP (e.g., TRP of DU 304) (see, e.g., useSeperateRLCforTRP, rlcTRP-BearerToModList, servedRadioBearer CHOICE, etc.). In such a specific implementation, CU 302 may configure the new DU (e.g., DU 306) before configuring UE 210.

[0119] Fig.171700 is a diagram of an example of components of a device according to one or more implementations described herein. In some implementations, the device 1700 may include at least an application circuit 1702, a baseband circuit 1704, an RF circuit 1706, a front-end module (FEM) circuit 1708, one or more antennas 1710, and a power management circuit (PMC) 1712 coupled together as shown. The components of the example device 1700 may be included in a UE or a RAN node. In some implementations, the device 1700 may include fewer elements (e.g., the RAN node may not utilize the application circuit 1702, but may include a processor / controller to process IP data received from a CN such as a 5GC 130 or an evolved packet core (EPC)). In some implementations, the device 1700 may include additional elements, such as, for example, a memory / storage device, a display, a camera, a sensor (including one or more temperature sensors, such as a single temperature sensor, multiple temperature sensors at different locations in the device 1700, etc.) or an input / output (I / O) interface. In other implementations, the components described below may be included in more than one device (eg, these circuits may be separately included in more than one device for a Cloud-RAN (C-RAN) implementation).

[0120] The application circuit 1702 may include one or more application processors. For example, the application circuit 1702 may include circuits such as, but not limited to, one or more single-core or multi-core processors. The processor may include any combination of general-purpose processors and special-purpose processors (e.g., graphics processors, application processors, etc.). The processor may be coupled to or may include a memory / storage device, and may be configured to execute instructions stored in the memory / storage device to enable various applications or operating systems to run on the device 1700. In some specific implementations, the processor of the application circuit 1702 may process IP data packets received from the EPC.

[0121] The baseband circuit 1704 may include circuits such as, but not limited to, one or more single-core or multi-core processors. The baseband circuit 1704 may include one or more baseband processors or control logic components to process baseband signals received from the receive signal path of the RF circuit 1706 and generate baseband signals for the transmit signal path of the RF circuit 1706. The baseband circuit 1704 may interact with the application circuit 1702 to generate and process baseband signals and control the operation of the RF circuit 1706. For example, in some specific implementations, the baseband circuit 1704 may include a 3G baseband processor 1704A, a 4G baseband processor 1704B, a 5G baseband processor 1704C, or other baseband processors 1704D of other existing generations, generations under development, or generations to be developed in the future (e.g., 2G, 6G, etc.). The baseband circuit 1704 (e.g., one or more baseband processors of the baseband processors 1704A to 1704D) may handle various radio control functions that enable communication with one or more radio networks via the RF circuit 1706. In other implementations, some or all of the functions of the baseband processors 1704A to 1704D may be included in a module stored in the memory 1704G and executed via the central processing unit (CPU) 1704E. The radio control functions may include, but are not limited to, signal modulation / demodulation, encoding / decoding, radio frequency shifting, etc. In some implementations, the modulation / demodulation circuitry of the baseband circuitry 1704 may include fast Fourier transform (FFT), precoding, or cluster mapping / demapping functions. In some implementations, the encoding / decoding circuitry of the baseband circuitry 1704 may include convolution, tail-biting convolution, turbo, Viterbi, or low-density parity check (LDPC) encoder / decoder functions. The implementation of the modulation / demodulation and encoder / decoder functions is not limited to these examples and may include other suitable functions in other aspects.

[0122] In some implementations, the baseband circuit 1704 may include one or more audio digital signal processors (DSPs) 1704F. The audio DSP 1704F may include elements for compression / decompression and echo cancellation, and may include other suitable processing elements in other implementations. In some implementations, the components of the baseband circuit may be appropriately combined in a single chip, a single chipset, or disposed on the same circuit board. In some implementations, some or all of the components of the baseband circuit 1704 and the application circuit 1702 may be implemented together, such as, for example, on a system on a chip (SOC).

[0123] In some implementations, the baseband circuit 1704 may provide communications compatible with one or more radio technologies. For example, in some implementations, the baseband circuit 1704 may support communications with NG-RAN, Evolved Universal Terrestrial Radio Access Network (EUTRAN) or other wireless metropolitan area network (WMAN), wireless local area network (WLAN), wireless personal area network (WPAN), etc. Implementations in which the baseband circuit 1704 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuits.

[0124] RF circuit 1706 can enable communication with a wireless network using modulated electromagnetic radiation through a non-solid medium. In various specific implementations, RF circuit 1706 may include switches, filters, amplifiers, etc. to facilitate communication with a wireless network. RF circuit 1706 may include a receive signal path, which may include circuits that down-convert RF signals received from FEM circuit 1708 and provide baseband signals to baseband circuit 1704. RF circuit 1706 may also include a transmit signal path, which may include circuits that up-convert baseband signals provided by baseband circuit 1704 and provide RF output signals to FEM circuit 1708 for transmission.

[0125] In some implementations, the receive signal path of the RF circuit 1706 may include a mixer circuit 1706A, an amplifier circuit 1706B, and a filter circuit 1706C. In some implementations, the transmit signal path of the RF circuit 1706 may include a filter circuit 1706C and a mixer circuit 1706A. The RF circuit 1706 may also include a synthesizer circuit 1706D for synthesizing frequencies used by the mixer circuit 1706A of the receive signal path and the transmit signal path. In some implementations, the mixer circuit 1706A of the receive signal path may be configured to down-convert the RF signal received from the FEM circuit 1708 based on the synthesized frequency provided by the synthesizer circuit 1706D. The amplifier circuit 1706B may be configured to amplify the down-converted signal, and the filter circuit 1706C may be a low pass filter (LPF) or a band pass filter (BPF) configured to remove unwanted signals from the down-converted signal to generate an output baseband signal. The output baseband signal may be provided to the baseband circuit 1704 for further processing. In some implementations, the output baseband signal may be a zero frequency baseband signal, but this is not required. In some implementations, the mixer circuit 1706A of the receive signal path may include a passive mixer, but the scope of the implementation is not limited in this respect.

[0126] In some implementations, the mixer circuit 1706A of the transmit signal path can be configured to up-convert an input baseband signal based on a synthesized frequency provided by the synthesizer circuit 1706D to generate an RF output signal for the FEM circuit 1708. The baseband signal can be provided by the baseband circuit 1704 and can be filtered by the filter circuit 1706C.

[0127] In some implementations, the mixer circuit 1706A of the receive signal path and the mixer circuit 1706A of the transmit signal path may include two or more mixers and may be arranged for quadrature down-conversion and up-conversion, respectively. In some implementations, the mixer circuit 1706A of the receive signal path and the mixer circuit 1706A of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some implementations, the mixer circuit 1706A of the receive signal path and the mixer circuit 2006A may be arranged for direct down-conversion and direct up-conversion, respectively. In some implementations, the mixer circuit 1706A of the receive signal path and the mixer circuit 1706A of the transmit signal path may be configured for superheterodyne operation.

[0128] In some implementations, the output baseband signal and the input baseband signal may be analog baseband signals, although the scope of the implementation is not limited in this respect. In some alternative implementations, the output baseband signal and the input baseband signal may be digital baseband signals. In these alternative implementations, the RF circuit 1706 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuits, and the baseband circuit 1704 may include a digital baseband interface to communicate with the RF circuit 1706.

[0129] In some dual-mode implementations, separate radio IC circuits may be provided to process signals for each spectrum, although the scope of the implementations is not limited in this respect.

[0130] In some implementations, synthesizer circuit 1706D can be a fractional-N synthesizer or a fractional N / N+1 synthesizer, but the scope of the implementation is not limited in this respect, as other types of frequency synthesizers may also be suitable. For example, synthesizer circuit 1706D can be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer including a phase-locked loop with a frequency divider.

[0131] The synthesizer circuit 1706D can be configured to synthesize an output frequency based on the frequency input and the divider control input for use by the mixer circuit 1706A of the RF circuit 1706. In some implementations, the synthesizer circuit 1706D can be a fractional-N / N+1 synthesizer.

[0132] In some implementations, the frequency input can be provided by a voltage controlled oscillator (VCO), although this is not required. The divider control input can be provided by the baseband circuit 1704 or the application circuit 1702 according to the desired output frequency. In some implementations, the divider control input (e.g., N) can be determined from a lookup table based on the channel indicated by the application circuit 1702.

[0133] The synthesizer circuit 1706D of the RF circuit 1706 may include a frequency divider, a delay locked loop (DLL), a multiplexer, and a phase accumulator. In some implementations, the frequency divider may be a dual-mode frequency divider (DMD), and the phase accumulator may be a digital phase accumulator (DPA). In some implementations, the DMD may be configured to divide the input signal by N or N+1 (e.g., based on a carry output) to provide a fractional frequency division ratio. In some example implementations, the DLL may include a cascaded, tunable, delay element, a phase detector, a charge pump, and a set of D-type flip-flops. In these implementations, the delay element may be configured to divide the VCO cycle into Nd equal phase groups, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

[0134] In some implementations, the synthesizer circuit 1706D can be configured to generate a carrier frequency as an output frequency, while in other implementations, the output frequency can be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency), and can be used with a quadrature generator and divider circuit to generate multiple signals with multiple different phases relative to each other at the carrier frequency. In some implementations, the output frequency can be an LO frequency (fLO). In some implementations, the RF circuit 1706 can include an IQ / polarity converter.

[0135] The FEM circuitry 1708 may include a receive signal path that may include circuitry configured to operate on RF signals received from one or more antennas 1710, amplify the received signals, and provide an amplified version of the received signals to the RF circuitry 1706 for further processing. The FEM circuitry 1708 may also include a transmit signal path that may include circuitry configured to amplify transmit signals provided by the RF circuitry 1706 for transmission through one or more of the one or more antennas 1710. In various implementations, amplification by the transmit or receive signal path may be accomplished only in the RF circuitry 1706, only in the FEM circuitry 1708, or in both the RF circuitry 1706 and the FEM circuitry 1708.

[0136] In some implementations, the FEM circuit 1708 may include a TX / RX switch to switch between transmit mode and receive mode operation. The FEM circuit may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuit may include an LNA to amplify the received RF signal and provide the amplified received RF signal as an output (e.g., provided to the RF circuit 1706). The transmit signal path of the FEM circuit 1708 may include a power amplifier (PA) for amplifying an input RF signal (e.g., provided by the RF circuit 1706); and one or more filters for generating an RF signal for subsequent transmission (e.g., through one or more of the one or more antennas 1710).

[0137] In some implementations, the PMC 1712 can manage the power provided to the baseband circuit 1704. Specifically, the PMC 1712 can control power selection, voltage scaling, battery charging, or DC-DC conversion. When the device 1700 is capable of being powered by a battery, for example, when the device is included in a UE, the PMC 1712 can generally be included. The PMC 1712 can improve power conversion efficiency while providing the desired implementation size and heat dissipation characteristics.

[0138] Although Fig.17 The PMC 1712 is shown coupled only to the baseband circuit 1704. However, in other implementations, the PMC 1712 may additionally or alternatively be coupled to other components (such as, but not limited to, the application circuit 1702, the RF circuit 1706, or the FEM circuit 1708) and perform similar power management operations for the other components.

[0139] In some implementations, the PMC 1712 can control or otherwise be part of various power saving mechanisms of the device 1700. For example, if the device 1700 is in the RRC_Connected state, in which the device is still connected to the RAN node because it expects to receive traffic soon, then after a period of inactivity, the device can enter a state known as discontinuous reception mode (DRX). During this state, the device 1700 can be powered off for short time intervals to save power.

[0140] If there is no data traffic activity for an extended period of time, the device 1700 may transition to the RRC_Idle state, in which the device is disconnected from the network and does not perform operations such as channel quality feedback, handover, etc. The device 1700 enters a very low power state, and the device performs paging, in which the device wakes up periodically again to listen to the network, and then powers down again. The device 1700 may not receive data in this state; in order to receive data, the device may transition back to the RRC_Connected state.

[0141] An additional power saving mode can keep a device from using the network for longer than the paging interval (which can range from a few seconds to several hours). During this time, the device is completely unable to connect to the network and can be completely powered down. Any data sent during this time will be significantly delayed, and it is assumed that the delay is acceptable.

[0142] The processor of the application circuit 1702 and the processor of the baseband circuit 1704 can be used to execute elements of one or more instances of the protocol stack. For example, the processor of the baseband circuit 1704 can be used alone or in combination to perform the functions of Layer 3, Layer 2, or Layer 1, and the processor of the baseband circuit 1704 can utilize the data received from these layers (e.g., packet data) and further perform the functions of Layer 4 (e.g., Transport Communication Protocol (TCP) and User Datagram Protocol (UDP) layers). As mentioned herein, Layer 3 may include an RRC layer, which will be described in further detail below. As mentioned herein, Layer 2 may include a Medium Access Control (MAC) layer, a Radio Link Control (RLC) layer, and a Packet Data Convergence Protocol (PDCP) layer, which will be described in further detail below. As mentioned herein, Layer 1 may include a physical (PHY) layer of a UE / RAN node, which will be described in further detail below.

[0143] Fig.18 is a diagram of an example interface of a baseband circuit according to one or more specific implementations described herein. As discussed above, Fig.17 The baseband circuit 1704 may include processors 1704A to 2004E and a memory 1704G used by these processors. Each of the processors 1704A to 2004E may include a memory interface 1804A to 2104E for sending / receiving data to / from the memory 1704G, respectively.

[0144] The baseband circuit 1704 may also include one or more interfaces to communicatively couple to other circuits / devices, such as a memory interface 1812 (e.g., an interface for sending / receiving data to / from a memory external to the baseband circuit 1704), an application circuit interface 1814 (e.g., an interface for sending / receiving data to / from a memory external to the baseband circuit 1704), and an application circuit interface 1815 (e.g., an interface for sending / receiving data to / from a memory external to the baseband circuit 1704). Fig.17The application circuit 1702 sends / receives data), the RF circuit interface 1816 (for example, for sending / receiving data to / from Fig.17 an interface for sending / receiving data to / from a RF circuit 1706), a wireless hardware connection interface 1818 (e.g., for sending / receiving data to / from a near field communication (NFC) component, Parts (e.g. Low power consumption), components and other communication components to send / receive data) and a power management interface 1820 (for example, an interface for sending / receiving power or control signals to / from the PMC 1712).

[0145] Fig.19 is an illustration of a control plane protocol stack according to some embodiments. In this embodiment, control plane 1900 is shown as a communication protocol stack between network devices or entities.

[0146] The PHY layer 1901 may transmit or receive information used by the MAC layer 1902 over one or more air interfaces. The PHY layer 1901 may also perform link adaptation or adaptive modulation and coding (AMC), power control, cell search (e.g., for initial synchronization and handover purposes), and other measurements used by higher layers such as the RRC layer 1905. The PHY layer 1901 may still further perform: error detection on transport channels, forward error correction (FEC) encoding / decoding of transport channels, modulation / demodulation of physical channels, interleaving, rate matching, mapping to physical channels, and multiple-input multiple-output (MIMO) antenna processing.

[0147] The MAC layer 1902 can perform: mapping between logical channels and transport channels, multiplexing MAC service data units (SDUs) from one or more logical channels onto transport blocks (TBs) to be delivered to PHY via transport channels, demultiplexing MAC SDUs from transport blocks (TBs) delivered from PHY via transport channels to one or more logical channels, multiplexing MAC SDUs onto TBs, scheduling information reporting, error correction through hybrid automatic repeat request (HARQ), and logical channel prioritization.

[0148] The RLC layer 1903 can operate in multiple operating modes, including: transparent mode (TM), unacknowledged mode (UM) and / or acknowledged mode (AM). The RLC layer 1903 can perform transmission of upper layer protocol data units (PDUs), error correction through automatic repeat request (ARQ) for AM data transmission, and concatenation, segmentation and reassembly of RLC SDUs for UM and AM data transmission. The RLC layer 1903 can also perform re-segmentation of RLC data PDUs for AM data transmission, reordering of RLC data PDUs for UM and AM data transmission, detection of duplicate data for UM and AM data transmission, discarding RLC SDUs for UM and AM data transmission, detecting protocol errors for AM data transmission, and performing RLC re-establishment.

[0149] The PDCP layer 1904 can perform header compression and decompression of IP data, maintain the PDCP sequence number (SN), perform in-order delivery of upper layer PDUs when the lower layer is re-established, eliminate duplication of lower layer SDUs when the lower layer is re-established for the radio bearer mapped on RLC AM, encrypt and decrypt control plane data, perform integrity protection and integrity verification on control plane data, control timer-based data discard, and perform security operations (e.g., encryption, decryption, integrity protection, integrity verification, etc.).

[0150] The main services and functions of the RRC layer 1905 may include broadcasting of system information (e.g., included in a master information block (MIB) or a system information block (SIB) associated with a non-access stratum (NAS)), broadcasting of system information associated with an access stratum (AS), paging, establishment, maintenance, and release of RRC connections (e.g., RRC connection paging, RRC connection establishment, RRC connection modification, and RRC connection release), establishment, configuration, maintenance, and release of point-to-point radio bearers, security functions including key management, mobility between radio access technologies (RATs), and measurement configuration for UE measurement reporting. The MIB and SIB may include one or more information elements (IEs), each of which may include a separate data field or data structure.

[0151] The UE and the RAN node may utilize a Uu interface (e.g., an NR interface) to exchange control plane data via a protocol stack including a PHY layer 1901, a MAC layer 1902, an RLC layer 1903, a PDCP layer 1904, and an RRC layer 1905.

[0152] The non-access stratum (NAS) protocol 1906 forms the highest layer of the control plane between the UE and the core network (CN). The NAS protocol 1906 may support the mobility of the UE and session management procedures to establish and maintain an IP connection between the UE and the network.

[0153] Fig. 20 is a block diagram illustrating components capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and capable of performing any one or more of the methods discussed herein, according to some example embodiments. Specifically, Fig. 20 A diagrammatic representation of hardware resources 2000 is shown, the hardware resources including one or more processors (or processor cores) 2010, one or more memory / storage devices 2020, and one or more communication resources 2030, each of which can be communicatively coupled via a bus 2040. For embodiments in which node virtualization (e.g., NFV) is utilized, a hypervisor 2002 can be executed to provide an execution environment for one or more network slices / subslices to utilize the hardware resources 2000.

[0154] Processor 2010 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP) (such as a baseband processor), an application specific integrated circuit (ASIC), a radio frequency integrated circuit (RFIC), another processor, or any suitable combination thereof) may include, for example, processor 2012 and processor 2014.

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

[0156] The communication resources 2030 may include interconnect or network interface components or other suitable devices to communicate with one or more peripheral devices 2004 or one or more databases 2006 via the network 2008. For example, the communication resources 2030 may include wired communication components (e.g., for coupling via a universal serial bus (USB)), cellular communication components, NFC components, Parts (such as Low power consumption), components and other communication components.

[0157] The instructions 2050 may include software, programs, applications, applet, applications, or other executable code for causing at least any one of the processors 2010 to perform any one or more of the methodologies discussed herein. The instructions 2050 may reside completely or partially in at least one of the processors 2010 (e.g., in a cache memory of the processor), the memory / storage device 2020, or any suitable combination thereof. In addition, any portion of the instructions 2050 may be transferred to the hardware resources 2000 from any combination of the peripheral device 2004 or the database 2006. Therefore, the memory of the processor 2010, the memory / storage device 2020, the peripheral device 2004, and the database 2006 are examples of computer-readable and machine-readable media.

[0158] Embodiments herein may include subject matter, such as a method, components for performing actions or blocks of the method, and at least one machine-readable medium including executable instructions that, when executed by a machine (e.g., a processor with memory, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc.), cause the machine to perform actions of a method or apparatus or system for concurrent communication using multiple communication technologies according to the described specific implementations and embodiments.

[0159] In Example 1, which may also include one or more of the examples described herein, a base station may include a centralized unit (CU), the centralized unit including one or more processors configured to: communicate with a user equipment (UE) via a first distributed unit (DU) of the base station; receive a measurement report of a wireless signal detected by the UE from the UE via the first DU; determine to implement a connection between the UE and a second DU based on the measurement report; communicate with the second DU to configure a medium access control (MAC) layer of the second DU for communicating with the UE; convey a radio resource control (RRC) reconfiguration message to the UE via the first DU to configure the MAC layer of the UE for communicating with the second DU; and communicate with the UE via a connection between the UE and the first DU and a connection between the UE and the second DU.

[0160] In Example 2, which may also include one or more of the examples described herein, the MAC layer of the second DU includes a hybrid automatic repeat request (HARQ) entity having a HARQ ID equal to the HARQ ID associated with the HARQ entity of the MAC layer of the first DU.

[0161] In Example 3, which may also include one or more of the examples described herein, the HARQ entity of the second DU is associated with a HARQ process different from that of the HARQ entity of the first DU.

[0162] In Example 4, which may also include one or more of the examples described herein, the HARQ processes associated with the second DU are determined by the CU and provided to the second DU.

[0163] In Example 5, which may also include one or more of the examples described herein, the HARQ processes associated with the second DU are determined by the DU and provided to the CU.

[0164] In Example 6, which may also include one or more of the examples described herein, the RRC reconfiguration message enables the UE to communicate with the first DU and the second DU using a single HARQ entity by associating a different HARQ process with the first DU compared to the second DU.

[0165] In Example 7, which may also include one or more of the examples described herein, the RRC reconfiguration message enables the UE to communicate with the first DU and the second DU by associating the transmit and receive point (TRP) IDs of the first DU and the second DU with the HARQ processes of the first DU and the second DU.

[0166] In Example 8, which may also include one or more of the examples described herein, the RRC reconfiguration message enables the UE to communicate with the second DU by creating an additional MAC layer and HARQ entity corresponding to the MAC layer of the second DU.

[0167] In Example 9, which may also include one or more of the examples described herein, the RRC reconfiguration message enables the UE to communicate with the second DU by creating an additional MAC layer and radio link control (RLC) layer corresponding to the MAC layer and RLC layer of the second DU.

[0168] In Example 10, which may also include one or more of the examples described herein, a Packet Data Convergence Protocol (PDCP) layer of the CU is configured to detect and ignore copy information of RLC protocol data units from the RLC layer of the first DU and the RLC layer of the second DU.

[0169] In Example 11, which may also include one or more of the examples described herein, multiple radio bearers (RBs) are used for communication between the UE and the second DU, and each of the multiple radio bearers is associated with a different RLC configuration.

[0170] In Example 12, which may also include one or more of the examples described herein, a base station may include: a distributed unit (DU), the distributed unit including one or more processors, the one or more processors configured to: receive a UE context setting request message from a centralized unit (CU) of another base station that communicates with a user equipment (UE) via another DU; in response to the UE context setting request message, configure a medium access control (MAC) layer of the second DU for communicating with the UE; communicate a UE context setting response message to the CU; and establish a connection with the UE using the MAC layer.

[0171] In Example 13, which may also include one or more of the examples described herein, the MAC layer of the DU includes a hybrid automatic repeat request (HARQ) entity having a HARQ ID equal to the HARQ ID associated with the HARQ entity of the MAC layer of the other DU.

[0172] In example 14, which may also include one or more of the examples described herein, the HARQ entity of the DU is associated with a HARQ process that is different from the HARQ entity of the other DU.

[0173] In Example 15, which may also include one or more of the examples described herein, the HARQ processes associated with the DU are determined by the CU and provided to the DU.

[0174] In Example 16, which may also include one or more of the examples described herein, the HARQ processes associated with the DU are determined by the DU and provided to the CU.

[0175] In Example 17, which may also include one or more of the examples described herein, the DU communicates with the UE using the different HARQ processes.

[0176] In Example 18, which may also include one or more of the examples described herein, the DU is configured to communicate with the UE based on a transmit and receive point (TRP) ID provided to the UE by a TRP of the DU.

[0177] In Example 19, which may also include one or more of the examples described herein, the DU is configured to create a radio link control (RLC) layer corresponding to the MAC layer for communicating with the UE, and provide corresponding data plane configuration information to the CU in a UE setup context response message.

[0178] In Example 20, which may also include one or more of the examples described herein, multiple radio bearers (RBs) are used to communicate with the UE, and each of the multiple radio bearers is associated with a different RLC configuration.

[0179] In Example 21, which may also include one or more of the examples described herein, a baseband processor of a user equipment (UE) may include: one or more processors configured to: communicate a measurement report of a wireless signal detected by the UE to a base station including a first distributed unit (DU) and a centralized unit (CU); in response to the measurement report, receive a radio resource control (RRC) reconfiguration message, the RRC reconfiguration message including information for configuring a medium access control (MAC) layer of the UE to communicate with a second DU; based on the RRC reconfiguration message, configure the MAC layer of the UE; and communicate with the first DU and the second DU.

[0180] In Example 22, which may also include one or more of the examples described herein, the UE communicates with the first DU and the second DU based on different hybrid automatic repeat request (HARQ) processes of a single HARQ entity associated with each of the first DU and the second DU.

[0181] In Example 23, which may also include one or more of the examples described herein, the UE communicates with the first DU and the second DU based on associating the transmit and receive point (TRP) IDs of the first DU and the second DU with the HARQ processes of the first DU and the second DU.

[0182] In Example 24, which may also include one or more of the examples described herein, the RRC reconfiguration message causes the UE to configure the MAC layer by creating an additional MAC layer and HARQ entity for communicating with the second DU in addition to the MAC layer and HARQ entity for communicating with the first DU.

[0183] In Example 25, which may also include one or more of the examples described herein, the RRC reconfiguration message causes the UE to configure the radio link control (RLC) layer by creating an additional MAC layer and RLC layer for communicating with the second DU in addition to the MAC layer and RLC layer for communicating with the first DU.

[0184] In Example 26, which may also include one or more of the examples described herein, the UE is configured to communicate with the second DU using multiple radio bearers (RBs), and each of the multiple RBs is associated with a different RLC configuration.

[0185] In Example 27, which may also include one or more of the examples described herein, a method performed by a base station includes the following operations: communicating with a user equipment (UE) via a first distributed unit (DU) of the base station; receiving a measurement report of a wireless signal detected by the UE from the UE via the first DU; determining to implement a connection between the UE and a second DU based on the measurement report; communicating with the second DU to configure a medium access control (MAC) layer of the second DU for communicating with the UE; conveying a radio resource control (RRC) reconfiguration message to the UE via the first DU to configure the MAC layer of the UE for communicating with the second DU; and communicating with the UE via a connection between the UE and the first DU and a connection between the UE and the second DU.

[0186] In Example 28, which may also include one or more of the examples described herein, a method performed by a base station includes the following operations: receiving a UE set context request message from a centralized unit (CU) of another base station that communicates with a user equipment (UE) via another DU; in response to the UE set context request message, configuring a medium access control (MAC) layer of the second DU for communicating with the UE; communicating a UE set context response message to the CU; and establishing a connection with the UE using the MAC layer.

[0187] In Example 29, which may also include one or more of the examples described herein, a method performed by a UE includes the following operations: communicating a measurement report of a wireless signal detected by the UE to a base station including a first distributed unit (DU) and a centralized unit (CU); in response to the measurement report, receiving a radio resource control (RRC) reconfiguration message, the RRC reconfiguration message including information for configuring a medium access control (MAC) layer of the UE to communicate with a second DU; based on the RRC reconfiguration message, configuring the MAC layer of the UE; and communicating with the first DU and the second DU.

[0188] The above description of illustrative examples, implementations, aspects, etc. of the disclosed subject matter, including what is described in the abstract, is not intended to be exhaustive or to limit the disclosed aspects to the precise forms disclosed. Although specific examples, implementations, aspects, etc. are described herein for illustrative purposes, various modifications can be considered within the scope of such examples, implementations, aspects, etc., as can be appreciated by those skilled in the relevant art.

[0189] In this regard, while the subject matter of the present disclosure has been described in conjunction with various examples, implementations, aspects, etc. and corresponding figures, it should be understood that other similar aspects may be used or modifications and additions may be made to the disclosed subject matter, where applicable, for performing the same, similar, alternative or alternative functions of the subject matter without departing from the disclosed subject matter. Therefore, the disclosed subject matter should not be limited to any single example, implementation, or aspect described herein, but should be interpreted in accordance with the breadth and scope of the following claims.

[0190] In particular, with respect to the various functions performed by the above-described components or structures (assemblies, devices, circuits, systems, etc.), unless otherwise specified, the terms used to describe such components (including references to "members") are intended to correspond to any component or structure that performs the specified function of the component (e.g., functionally equivalent), even if not structurally equivalent to the disclosed structure that performs the function in the exemplary implementations illustrated herein. In addition, while particular features have been disclosed with respect to only one of a plurality of implementations, for any given or particular application, such features may be combined with one or more other features of other implementations, which may be desirable and advantageous.

[0191] As used herein, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or". That is, unless otherwise specified or clear from the context, "X employs A or B" is intended to mean any natural inclusive arrangement of natural inclusive arrangements. That is, if X employs A; X employs B; or X employs both A and B, then "X employs A or B" is satisfied in any of the foregoing cases. In addition, the articles "a" and "an" used in this application and the appended claims should generally be interpreted as meaning "one or more" unless otherwise specified or clear from the context to be directed to the singular form. In addition, to the extent that the terms "including", "comprising", "having", "having", "with", or variations thereof are used in the detailed description and claims, such terms are intended to be included in a manner similar to the term "comprising". In addition, where one or more numbered items (e.g., "first X", "second X", etc.) are discussed, generally, the one or more numbered items may be different or they may be the same, but in some cases, the context may indicate that they are different or that they are the same.

[0192] It is understood that the use of personally identifiable information should be subject to privacy policies and practices that are generally recognized to meet or exceed industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of the authorized use should be clearly stated to users.

Claims

1. A base station, comprising: A centralized unit (CU), the CU comprising one or more processors, the one or more processors being configured to: communicating with a user equipment (UE) via a first distributed unit (DU) of the base station; receiving, from the UE via the first DU, a measurement report of a wireless signal detected by the UE; Determine, based on the measurement report, to enable a connection between the UE and the second DU; communicating with the second DU to configure a medium access control (MAC) layer of the second DU for communicating with the UE; communicating a radio resource control (RRC) reconfiguration message to the UE via the first DU to configure a MAC layer of the UE for communicating with the second DU; as well as Communicating with the UE via a connection between the UE and the first DU and a connection between the UE and the second DU.

2. The base station according to claim 1, wherein the MAC layer of the second DU includes a hybrid automatic repeat request (HARQ) entity, and the HARQ entity of the MAC layer of the second DU has a HARQ ID equal to the HARQ ID associated with the HARQ entity of the MAC layer of the first DU. 3 . The base station according to claim 2 , wherein the HARQ entity of the second DU and the HARQ entity of the first DU are associated with different HARQ processes. 4 . The base station of claim 3 , wherein the HARQ process associated with the second DU is determined by the CU and provided to the second DU. 5 . The base station of claim 3 , wherein the HARQ process associated with the second DU is determined by the DU and provided to the CU.

6. The base station of claim 1, wherein the RRC reconfiguration message enables the UE to communicate with the first DU and the second DU using a single HARQ entity by associating a different HARQ process with the first DU compared to the second DU.

7. The base station of claim 1, wherein the RRC reconfiguration message enables the UE to communicate with the first DU and the second DU by associating transmit and receive point (TRP) IDs of the first DU and the second DU with HARQ processes of the first DU and the second DU.

8. The base station of claim 1, wherein the RRC reconfiguration message enables the UE to communicate with the second DU by creating an additional MAC layer and HARQ entity corresponding to the MAC layer of the second DU.

9. The base station of claim 1, wherein the RRC reconfiguration message enables the UE to communicate with the second DU by creating an additional MAC layer and a radio link control (RLC) layer corresponding to the MAC layer and the RLC layer of the second DU.

10. The base station of claim 9, wherein a Packet Data Convergence Protocol (PDCP) layer of the CU is configured to detect and ignore duplicate information of RLC protocol data units from the RLC layer of the first DU and the RLC layer of the second DU.

11. The base station of claim 9, wherein a plurality of radio bearers (RBs) are used for communication between the UE and the second DU, and each of the plurality of radio bearers is associated with a different RLC configuration.

12. A base station, comprising: A distributed unit (DU), the DU comprising one or more processors, the one or more processors being configured to: receiving a UE set context request message from a centralized unit (CU) of another base station communicating with a user equipment (UE) via another DU; In response to the UE setup context request message, configuring a medium access control (MAC) layer of the second DU for communicating with the UE; Communicate a UE setup context response message to the CU; as well as A connection with the UE is established using the MAC layer.

13. The base station of claim 12, wherein the MAC layer of the DU includes a hybrid automatic repeat request (HARQ) entity, and the HARQ entity of the MAC layer of the DU has a HARQ ID equal to the HARQ ID associated with the HARQ entity of the MAC layer of the other DU.

14. The base station of claim 13, wherein the HARQ entity of the DU and the HARQ entity of the another DU are associated with different HARQ processes.

15. The base station of claim 14, wherein the HARQ process associated with the DU is determined by the CU and provided to the DU.

16. The base station of claim 14, wherein the HARQ process associated with the DU is determined by the DU and provided to the CU.

17. The base station of claim 14, wherein the DU uses the different HARQ process to communicate with the UE.

18. The base station of claim 12, wherein the DU is configured to communicate with the UE based on a transmit and receive point (TRP) ID provided to the UE by a TRP of the DU.

19. The base station of claim 12, wherein the DU is configured to create a radio link control (RLC) layer corresponding to the MAC layer for communicating with the UE, and provide corresponding data plane configuration information to the CU in a UE setup context response message.

20. The base station of claim 19, wherein a plurality of radio bearers (RBs) are used to communicate with the UE, and each of the plurality of radio bearers is associated with a different RLC configuration.

21. A baseband processor of a user equipment (UE), comprising: One or more processors configured to: communicating a measurement report of a wireless signal detected by the UE to a base station including a first distributed unit (DU) and a centralized unit (CU); receiving, in response to the measurement report, a radio resource control (RRC) reconfiguration message including information for configuring a medium access control (MAC) layer of the UE to communicate with the second DU; Based on the RRC reconfiguration message, configure the MAC layer of the UE; as well as Communicate with the first DU and the second DU.

22. The UE of claim 21, wherein the UE is to communicate with the first DU and the second DU based on different hybrid automatic repeat request (HARQ) processes of a single HARQ entity associated with each of the first DU and the second DU.

23. The UE of claim 21, wherein the UE communicates with the first DU and the second DU based on associating transmit and receive point (TRP) IDs of the first DU and the second DU with HARQ processes of the first DU and the second DU.

24. The UE of claim 21, wherein the RRC reconfiguration message causes the UE to configure the MAC layer by creating an additional MAC layer and HARQ entity for communicating with the second DU in addition to the MAC layer and HARQ entity for communicating with the first DU.

25. The UE of claim 21, wherein the RRC reconfiguration message causes the UE to configure a radio link control (RLC) layer for communicating with the second DU by creating an additional MAC layer and an RLC layer for communicating with the first DU in addition to the MAC layer and the RLC layer for communicating with the first DU.

26. The base station of claim 23, wherein the UE is configured to communicate with the second DU using a plurality of radio bearers (RBs), and each of the plurality of RBs is associated with a different RLC configuration.

Images