Layer 1 / Layer 2 trigger mobility for user plane relocation of base station centralized units

Abstract

Generally, the present subject matter relates to Layer 1 / Layer 2 (L1 / L2) triggered mobility (LTM) for intra-base station centralized unit user plane (CU-UP) relocation. In some implementations, a target distributed unit (DU) of a base station for serving a user equipment (UE) can determine that it is being served by a target CU-UP of the base station. A serving CU-UP of the base station can serve a serving DU of the base station that is currently serving the UE. A centralized unit control plane (CU-CP) of the base station can be used to prepare the target CU-UP for Layer 1 / Layer 2 triggered mobility (LTM), and the CU-CP can be used to prepare the target DU for LTM.

Description

Technical Field

[0001] In some implementations, the present subject matter relates to a telecommunications system, and more particularly, to layer 1 / layer 2 trigger mobility (LTM) for centralized unit user plane (CU-UP) relocation within a base station.

Background Art

[0002] In today's world, cellular networks provide on-demand communication capabilities to individuals and enterprises. Typically, a cellular network is a wireless network that can be distributed over a terrestrial area called a cell. Each such cell is served by at least one fixed-position transceiver called a cell site or base station. Each cell can use a different set of frequencies from its neighboring cells to avoid interference and provide improved service within each cell. When cells are joined together, they provide wireless coverage over a wide geographic area, whereby a large number of mobile phones, and / or other wireless devices or portable transceivers can communicate with each other and with a fixed transceiver and phone anywhere within the network. Such communication is carried out via a base station and is achieved even when a mobile transceiver is moving through two or more cells during transmission. Major wireless communication providers have deployed such cell sites around the world, thereby enabling communication mobile phones and mobile computing devices to connect to the public switched telephone network and the public Internet.

[0003] A mobile phone is a portable telephone that can receive and / or send phone and / or data communications via a cell site or transmission tower by transferring signals to and from the mobile phone using radio waves. Considering the large number of mobile phone users, current mobile phone networks provide limited shared resources. In this regard, cell sites and handsets can change frequencies and use low-power transmitters to enable simultaneous use of the network by many callers with less interference. Cell site coverage can depend on a particular geographical location and / or the number of users who can use the network. For example, in cities, a cell site may have a range of up to about half a mile, while in suburbs, the range may be as much as 5 miles, and in some areas, users can receive signals from cell sites 25 miles away.

[0004] The following are some examples of digital cellular technologies used by telecommunications providers, namely, Global System for Mobile Communications ("GSM"), General-Purpose Packet Radio Service ("GPRS"), cdmaOne, CDMA2000, Evolution Data Optimization ("EV-DO"), GSM Evolution Improved Data Rate ("EDGE"), Universal Mobile Communications System ("UMTS"), Digital Improved Cordless Communications ("DECT"), Digital AMPS ("IS-136 / TDMA"), and Integrated Digital Improved Network ("iDEN"). Long-Term Evolution, or 4G LTE, developed by the Third Generation Partnership Project ("3GPP®") standards body, is a high-speed data wireless communication standard for mobile phones and data terminals. Currently, 5G standards are being developed and deployed. 3GPP cellular technologies such as LTE and 5G NR are evolutions of earlier 3GPP technologies such as GSM / EDGE and UMTS / HSPA digital cellular technologies, enabling increased capacity and speed through the use of different radio interfaces, along with improvements to the core network.

[0005] A cellular network can be divided into a radio access network and a core network. The radio access network (RAN) may include network functions capable of handling radio layer communication processing. The core network may include network functions capable of handling higher layer communications, such as the Internet Protocol (IP), transport layer, and application layer. In some cases, the RAN functions may be divided into baseband unit functions and radio unit functions. For example, a radio unit connected to a baseband unit via a fronthaul network may be responsible for lower layer processing of the radio physical layer, while the baseband unit may be responsible for higher layer radio protocols, such as MAC and RLC.

[0006] A base station for a 5G cellular network may include a centralized unit (CU), one or more distributed units (DUs) commutably coupled to the CU, and one or more radio units (RUs), each commutably coupled to at least one of the one or more DUs and each configured to commutably coupled to one or more mobile phones and / or other user equipment (UEs). The CU may be logically divided into a control plane portion (CU-CP) and one or more user plane portions (CU-UPs). In a non-aggregated architecture, a base station may include two or more CU-UPs. In the process of an UE commutating with the base station, the CU-UPs of the base station that provide support to the UE may change from one CU-UP of the base station to another CU-UP of the base station. However, cell service changes under current standards are triggered by Layer 3 (L3) measurements, thus requiring resets at the lower Layer 1 (L1) and Layer 2 (L2) layers, which increases latency, overhead, and downtime. [Overview of the project] [Means for solving the problem]

[0007] In some implementations, this subject relates to computer implementations. This method may include determining that a base station's target distributed unit (DU) for serving a user equipment (UE) is being served by the base station's target centralized unit user plane (CU-UP). The base station's serving CU-UP can then serve the base station's serving DU currently serving the UE. This method may also include using the base station's centralized unit control plane (CU-CP) to prepare a target CU-UP for layer 1 / layer 2 triggered mobility (LTM) and using the CU-CP to prepare a target DU for LTM.

[0008] This method may enable a base station to provide LTM when the UE undergoes relocation from one CU-UP on the base station to another CU-UP on the base station with respect to one or more services.

[0009] In some implementations, this subject may include one or more of the following optional features.

[0010] In some implementations, preparing a target CU-UP may include using a CU-CP to fetch a security key from the target CU-UP, and preparing a target DU may include sending a security key from the CU-CP to the target DU. Furthermore, the security key configured by the target CU-UP may be sent from the CU-CP to the target DU in a UE CONTEXT SETUP REQUEST message, and / or fetching a security key may include the CU-CP sending a BEARER CONTEXT SETUP REQUEST message to the target CU-UP and the CU-UP sending a BEARER CONTEXT SETUP RESPONSE message to the CU-CP, the BEARER CONTEXT SETUP RESPONSE message may contain a security key that may correspond to the UE served by the target CU-UP. Furthermore, the BEARER CONTEXT SETUP REQUEST message may include an information element (IE) that notifies the target CU-UP of the LTM.

[0011] In some implementations, preparing a target CU-UP may involve sending an information element (IE) from the CU-CP to the target CU-UP to notify the LTM of the UE's resource reservation.

[0012] In some implementations, this method may also include triggering the serving CU-UP to initiate data transfer to the target CU-UP after the target CU-UP and target DU have been prepared. Furthermore, triggering may include sending a control packet data unit (PDU) from the serving DU to the serving CU-UP, followed by the serving CU-UP sending unsent and unaccnowledged data PDUs to the target CU-UP. Furthermore, this method may also include sending information from the CU-CP to the serving DU to identify changes in the serving CU-UP of the LTM before sending the control PDU to trigger data transfer. Furthermore, this information may be sent from the CU-CP to the serving DU in a UE CONTEXT MODIFICATION REQUEST message.

[0013] In some implementations, the method may also include, after the preparation of the target CU-UP and the target DU, triggering the target CU-UP to initiate service to the UE via the target DU. Furthermore, triggering may include the target DU sending a control packet data unit (PDU) to the target CU-UP to initiate downlink data transmission, followed by the target CU-UP sending a data PDU to the target DU; or triggering may include the serving DU sending a first message to the CU-CP, followed by the CU-CP sending a second message to the serving CU-UP, followed by the serving CU-UP sending a third message to the target CU-UP; and / or servicing the UE may include the target DU sending a first message to the CU-CP, followed by the CU-CP sending a second message to the target CU-UP, followed by the target CU-UP initiating downlink data transmission toward the target DU.

[0014] In some implementations, the determination may involve using a CU-CP to analyze radio resource control (RRC) measurement reports received by the UE at the CU-CP.

[0015] In some implementations, the serving CU-UP and the target CU-UP may be different entities.

[0016] In some implementations, a base station can be a new generation radio access network (NG-RAN) node.

[0017] In some implementations, the base station may include at least one processor and at least one non-temporary storage medium.

[0018] The description also includes non-temporary computer program products (i.e., physically embodied computer program products) that, when executed by one or more data processors of one or more computing systems, store instructions causing at least one data processor to perform the operations described herein. Similarly, the description also includes computer systems that may include one or more data processors and memory coupled to one or more data processors. The memory can temporarily or permanently store instructions causing at least one processor to perform one or more of the operations described herein. Furthermore, the methods may be implemented by one or more data processors within a single computing system or distributed across two or more computing systems. Such computing systems may be connected via one or more connections, including, but not limited to, connections via networks (e.g., the Internet, wireless wide area networks, local area networks, wide area networks, wired networks, etc.), and connections via direct connections between one or more of the computing systems, and may exchange data and / or commands or other instructions.

[0019] Details of one or more modifications of the subject matter described herein are shown in the accompanying drawings and the following description. Other features and advantages of the subject matter described herein will be evident from the description and drawings, and from the claims.

[0020] The accompanying drawings incorporated herein and constituting part of this specification illustrate specific aspects of the subject matter disclosed herein and, together with the description, help to illustrate some of the principles associated with the disclosed implementations. The drawings are described below. [Brief explanation of the drawing]

[0021] [Figure 1a] This figure illustrates an exemplary conventional Long-Term Evolution ("LTE") communication system. [Figure 1b]It is a diagram showing further details of an exemplary LTE system shown in FIG. 1a. [Figure 1c] It is a diagram showing further details of the evolved packet core of the exemplary LTE system shown in FIG. 1a. [Figure 1d] It is a diagram showing an exemplary evolved Node B of the exemplary LTE system shown in FIG. 1a. [Figure 2] It is a diagram showing further details of the evolved Node B shown in FIGS. 1a to 1d. [Figure 3] It is a diagram showing an exemplary virtual radio access network according to some implementations of the present subject matter. [Figure 4] It is a diagram showing an exemplary 3GPP split architecture for providing its users with the use of higher frequency bands. [Figure 5a] It is a diagram showing an exemplary 5G wireless communication system. [[ID=二十]] [Figure 5b] It is a diagram showing an exemplary layer architecture of a split gNB and / or a split ng-eNB (for example, a next-generation eNB that can be connected to a 5GC). [Figure 5c] It is a diagram showing an exemplary functional split in the gNB architecture shown in FIGS. 5a to 5b. [Figure 6a] It is a diagram showing an exemplary system according to some implementations of the present subject matter. [Figure 6b] It is a diagram showing an exemplary alternative configuration of the system of FIG. 6a according to some implementations of the present subject matter. [Figure 7] It is a diagram showing an exemplary method according to some implementations of the present subject matter. [Figure 8] It is a diagram showing another exemplary system according to some implementations of the present subject matter. [Figure 9] It is a diagram showing yet another exemplary system according to some implementations of the present subject matter. [Figure 10] It is a diagram showing another exemplary method according to some implementations of the present subject matter.

Mode for Carrying Out the Invention

[0022] This subject can provide systems and methods that can be implemented in wireless communication systems. Such systems may include various wireless communication systems, such as 5G New Radio communication systems and Long-Term Evolution communication systems.

[0023] Generally, this subject concerns Layer 1 (L1) / Layer 2 (L2) trigger mobility (LTM) for the relocation of centralized unit user planes (CU-UPs) within base stations.

[0024] In some implementations of this subject, a base station of a wireless communication system may have a distributed architecture in which the base station includes two or more CU-UPs. The base station may be configured to provide LTM when a UE commutably coupled to the base station undergoes relocation from one CU-UP of the base station to another CU-UP of the base station with respect to one or more services of the UE.

[0025] 3GPP standards that define one or more aspects that may relate to this subject matter include 3GPP TS 38.321 “NR; Media Access Control (MAC) Protocol Specification”, 3GPP TS 38.331 “NR; Radio Resource Control (RRC) Protocol Specification”, 3GPP TS 38.463 “NG-RAN; E1 Application Protocol (E1AP)”, and 3GPP TS 38.473 “NG-RAN F1 Application Protocol (F1AP)”. O-RAN Alliance standards may also relate to one or more aspects of this subject matter.

[0026] One or more aspects of this subject matter may be incorporated into the transmitter and / or receiver components of base stations (e.g., gNodeB, eNodeB, etc.) within such communication systems. The following is a general consideration of long-term evolution communication systems and 5G New Radio communication systems.

[0027] I. Long-Term Evolution Communication Systems Figures 1a-1c and 2 illustrate an exemplary conventional Long-Term Evolution ("LTE") communication system 100 with its various components. The LTE system, or 4G LTE, is governed by a high-speed data wireless communication standard for mobile phones and data terminals, as is commercially known. This standard is an evolution of GSM / EDGE ("Pan-European Digital Mobile Communication System" / "GSM Evolutionary High-Speed ​​Data Rate") and UMTS / HSPA ("Universal Mobile Communication System" / "High-Speed ​​Packet Access") network technologies. This standard was developed by 3GPP ("Third Generation Partnership Project").

[0028] As shown in Figure 1a, System 100 may include an Evolutionary Universal Terrestrial Radio Access Network ("EUTRAN") 102, an Evolutionary Packet Core ("EPC") 108, and a Packet Data Network ("PDN") 101, where EUTRAN 102 and EPC 108 provide communication between user devices 104 and PDN 101. EUTRAN 102 may include multiple Evolutionary Node B ("eNodeB" or "ENODEB" or "enodeb" or "eNB") or base stations 106 (a, b, c) that provide communication capabilities to multiple user devices 104 (a, b, c) (as shown in Figure 1b). User devices 104 may be mobile phones, smartphones, tablets, personal computers, personal digital assistants ("PDAs"), servers, data terminals, and / or any other type of user device, and / or any combination thereof. The user device 104 can connect to the EPC 108 and ultimately to the PDN 101 via any of the eNodeB 106. Typically, the user device 104 can connect to the eNodeB 106 that is geographically closest. In the LTE system 100, the EUTRAN 102 and EPC 108 work together to provide connectivity, mobility, and services to the user device 104.

[0029] Figure 1b shows further details of the network 100 shown in Figure 1a. As described above, EUTRAN 102 includes multiple eNodeB 106, also known as cell sites. The eNodeB 106 provides radio functionality and performs critical control functions, including scheduling or managing airlink resources, active mode mobility or handover, and admission control for services. The eNodeB 106 is responsible for selecting which mobility management entity (MME shown in Figure 1c) will service the user equipment 104, and for protocol functions such as header compression and encryption. The eNodeB 106 constituting EUTRAN 102 cooperate with each other in terms of radio resource management and handover.

[0030] Communication between user equipment 104 and eNodeB 106 takes place via air interface 122 (also known as the “LTE-Uu” interface). As shown in Figure 1b, air interface 122 provides communication between user equipment 104b and eNodeB 106a. Air interface 122 uses orthogonal frequency division multiple access (“OFDMA”) and single-carrier frequency division multiple access (“SC-FDMA”), as well as a modified OFDMA, for downlink and uplink, respectively. OFDMA enables the use of multiple known antenna techniques, such as multiple input multiple output (“MIMO”).

[0031] The air interface 122 uses various protocols, including radio resource control ("RRC") for signaling between the user device 104 and the eNodeB 106, and a non-accessible layer ("NAS") for signaling between the user device 104 and the MME (shown in Figure 1c). In addition to signaling, user traffic is transferred between the user device 104 and the eNodeB 106. Both signaling and traffic in system 100 are carried by physical layer ("PHY") channels.

[0032] Multiple eNodeB106s can be interconnected using X2 interfaces 130(a, b, c). As shown in Figure 1b, X2 interface 130a provides interconnection between eNodeB106a and eNodeB106b, X2 interface 130b provides interconnection between eNodeB106a and eNodeB106c, and X2 interface 130c provides interconnection between eNodeB106b and eNodeB106c. X2 interfaces may also be established between two eNodeBs to provide signal exchange, and these signals may include information related to load or interference, as well as information related to handover. The eNodeB106s communicate with the evolved packet core 108 via S1 interfaces 124(a, b, c). The S1 interface 124 may be divided into two interfaces: one for the control plane (shown as the control plane interface (S1-MME interface) 128 in Figure 1c) and the other for the user plane (shown as the user plane interface (S1-U interface) 125 in Figure 1c).

[0033] EPC108 establishes and implements Quality of Service ("QoS") for user services, enabling user equipment 104 to maintain a consistent Internet Protocol ("IP") address while in transit. Note that each node in network 100 has its own IP address. EPC108 is designed to interact with legacy wireless networks. EPC108 is also designed to separate the control plane (i.e., signaling) and the user plane (i.e., traffic) in the core network architecture, which allows for greater flexibility in implementation and independent scalability of control and user data functions.

[0034] The EPC108 architecture is dedicated to packet data and is shown in detail in Figure 1c. The EPC108 includes a Serving Gateway (S-GW) 110, a PDN Gateway (P-GW) 112, a Mobility Management Entity ("MME") 114, a Home Subscriber Server ("HSS") 116 (subscriber database for EPC108), and a Policy Control and Billing Rule Function ("PCRF") 118. Some of these (such as the S-GW, P-GW, MME, and HSS) are often integrated into the node, depending on the manufacturer's implementation.

[0035] S-GW110 functions as an IP packet data router and is the bearer route anchor for user equipment within EPC108. Therefore, when user equipment moves from one eNodeB106 to another during mobility operation, S-GW110 remains the same, and the bearer route toward EUTRAN102 is switched to communicate with the new eNodeB106 serving user equipment 104. If user equipment 104 moves to the domain of another S-GW110, MME114 forwards all of the user equipment's bearer routes to the new S-GW. S-GW110 establishes bearer routes for the user equipment to one or more P-GW112s. When downstream data is received for idle user equipment, S-GW110 buffers the downstream packets and requests MME114 to find and re-establish bearer routes toward EUTRAN102 and through EUTRAN102.

[0036] P-GW112 is the gateway between EPC108 (and user equipment 104 and EUTRAN102) and PDN101 (shown in Figure 1a). P-GW112 functions as a router for user traffic and performs functions on behalf of the user equipment. These include assigning IP addresses to user equipment, packet filtering of downstream user traffic to ensure that downstream user traffic is placed on the appropriate bearer route, and implementing downstream QoS, including data rates. Depending on the services used by the subscriber, there may be multiple user data bearer routes between user equipment 104 and P-GW112. A subscriber may use services on a PDN served by different P-GWs, in which case the user equipment has at least one bearer route established to each P-GW112. If the S-GW110 also changes during a handover of user equipment from one eNodeB to another, the bearer route from P-GW112 is switched to the new S-GW.

[0037] The MME114 manages user devices 104 within the EPC108, which includes managing subscriber authentication, maintaining context for authenticated user devices 104, establishing data bearer routes within the network for user traffic, and tracking the location of idle mobile devices that are not disconnected from the network. For idle user devices 104 that need to be reconnected to the access network to receive downstream data, the MME114 initiates paging to locate the user device and re-establishes a bearer route to and through the EUTRAN102. The MME114 for a particular user device 104 is selected by the eNodeB106 from which the user device 104 initiates system access. This MME is typically part of a group of MMEs within the EPC108 for load sharing and redundancy purposes. In establishing a user's data bearer route, the MME114 is responsible for selecting the P-GW112 and S-GW110, which constitute the endpoints of the data route through the EPC108.

[0038] PCRF118 is responsible for policy control decision-making and controlling the flow-based billing functionality within the policy control enforcement function ("PCEF") residing within P-GW110. PCRF118 provides QoS authorization (QoS class identifier ("QCI") and bitrate), which determines how a particular data flow is handled within the PCEF and ensures that this matches the user's subscription profile.

[0039] As described above, IP service 119 is provided by PDN101 (shown in Figure 1a).

[0040] Figure 1d shows an exemplary structure of eNodeB106. eNodeB106 may include at least one remote radio head ("RRH") 132 (typically, there may be three RRHs 132) and a baseband unit ("BBU") 134. The RRH 132 may be connected to an antenna 136. The RRH 132 and BBU 134 may be connected using an optical interface compliant with the Common Public Radio Interface ("CPRI") / Enhanced CPRI ("eCPRI") 142 standard, either using a custom control and user plane framing method specific to the RRH or using an O-RAN Alliance compliant control and user plane framing method. The operation of eNodeB106 can be characterized using the following standard parameters (and specifications), namely, high frequency bandwidth (bands 4, 9, 17, etc.), bandwidth (5, 10, 15, 20 MHz), access method (downlink: OFDMA, uplink: SC-OFDMA), antenna technology (single-user and multi-user MIMO, uplink: single-user and multi-user MIMO), number of sectors (up to 6), maximum transmission speed (downlink: 150 Mb / s, uplink: 50 Mb / s), S1 / X2 interface (1000Base-SX, 1000Base-T), and mobile environment (up to 350 km / h). BBU134 can handle digital baseband signal processing, S1 line termination, X2 line termination, call processing, and monitoring and control processing. IP packets received from EPC108 (not shown in Figure 1d) can be modulated into digital baseband signals and transmitted to RRH132. Conversely, the digital baseband signal received from the RRH132 can be demodulated into IP packets for transmission to the EPC108.

[0041] The RRH132 can transmit and receive radio signals using the antenna 136. The RRH132 can convert digital baseband signals from the BBU134 into radio frequency ("RF") signals (using a converter ("CONV") 140) and power amplified them (using an amplifier ("AMP") 138) for transmission to user equipment 104 (not shown in Figure 1d). Conversely, RF signals received from user equipment 104 are amplified (using AMP 138) and converted into digital baseband signals (using CONV 140) for transmission to the BBU134.

[0042] Figure 2 shows additional details of an exemplary eNodeB106. The eNodeB106 includes multiple layers, namely LTE Layer 1 202, LTE Layer 2 204, and LTE Layer 3 206. LTE Layer 1 includes the physical layer ("PHY"). LTE Layer 2 includes Medium Access Control ("MAC"), Radio Link Control ("RLC"), and Packet Data Convergence Protocol ("PDCP"). LTE Layer 3 includes various functions and protocols, including Radio Resource Control ("RRC"), Dynamic Resource Allocation, eNodeB Measurement Configuration and Provisioning, Radio Admission Control, Connectivity Mobility Control, and Radio Resource Management ("RRM"). The RLC protocol is an Automatic Retransmission Request ("ARQ") fragmentation protocol used on the cellular air interface. The RRC protocol handles LTE Layer 3 control plane signaling between user equipment and EUTRAN. RRC includes functions for connection establishment and release, broadcasting system information, establishing / reconfiguring and releasing radio bearers, RRC connection mobility procedures, paging notifications and releases, and outer loop power control. PDCP performs IP header compression and decompression, user data transfer, and maintaining the radio bearer sequence number. BBU134, shown in Figure 1d, may include LTE layers L1-L3.

[0043] One of the main functions of eNodeB106 is radio resource management, which includes scheduling of both uplink and downlink air interface resources for user equipment 104, as well as bearer resource control and admission control. As an agent for EPC108, eNodeB106 is responsible for forwarding paging messages used to locate mobile devices when they are idle. eNodeB106 also communicates common control channel information over the air, performs header compression, encryption and decryption of user data sent over the air, and establishes handover reporting and trigger criteria. As described above, eNodeB106 can cooperate with other eNodeB106s via the X2 interface for handover and interference management purposes. eNodeB106 communicates with the EPC's MME via the S1-MME interface and with the S-GW using the S1-U interface. Furthermore, eNodeB106 exchanges user data with the S-GW via the S1-U interface. eNodeB106 and EPC108 have a many-to-many relationship to support load sharing and redundancy between MMEs and S-GWs. eNodeB106 selects one MME from a group of MMEs so that the load can be distributed across multiple MMEs to avoid congestion.

[0044] II.5G NR Wireless Communication Network In some implementations, this subject concerns 5G new radio ("NR") communication systems. 5G NR is the next communication standard beyond the 4G / IMT-Advanced standard. 5G networks offer greater capacity than current 4G, enabling a greater number of mobile broadband users per area and allowing for greater and / or unlimited data consumption in gigabytes per month and per user. This could allow users to stream high-definition media for hours per day using their mobile devices, even if this is not possible on Wi-Fi networks. 5G networks also offer improved support for device-to-device communication, lower costs, lower latency than 4G equipment, and lower battery consumption. Such networks offer, compared to existing systems, tens of megabits per second data rates for numerous users, 100 Mb / s data rates for metropolitan areas, 1 Gb / s simultaneous connections to users within a limited area (e.g., an office floor), numerous simultaneous connections for wireless sensor networks, enhanced spectral efficiency, improved coverage, strengthened signaling efficiency, 1-10 ms latency, and reduced latency.

[0045] Figure 3 shows an exemplary virtual radio access network 300. The network 300 can provide communication between various components, including base stations (e.g., eNodeB, gNodeB) 301, radio equipment 303, a central unit 302, a digital unit 304, and radio devices 306. Components within the system 300 may be communicatively coupled to the core using backhaul links 305. The central unit ("CU") 302 may be communicatively coupled to a distributed unit ("DU") 304 using a midhaul connection 308. A high-frequency ("RU") component 306 may be communicatively coupled to the DU 304 using a fronthaul connection 310.

[0046] In some implementations, CU302 can provide intelligent communication functions to one or more DU units 304. Units 302, 304 may include one or more base stations, macro base stations, micro base stations, remote radio heads, and / or any combination thereof.

[0047] In lower-layer partitioned architecture environments, the CPRI bandwidth requirement for NR can be several hundred Gb / s. CPRI compression can be implemented in the DU and RU (as shown in Figure 3). In 5G communication systems, compressed CPRI on Ethernet frames is referred to as eCPRI and is the recommended fronthaul network. This architecture can enable fronthaul / midhaul standardization, which may include upper-layer partitioning (e.g., Option 2 or Option 3-1 (upper / lower RLC partitioned architecture)) and fronthaul using an L1 partitioned architecture (Option 7).

[0048] In some implementations, the lower layer partitioning architecture (e.g., Option 7) may include a receiver at the uplink, joint processing across multiple transmit points (TPs) for both DL / UL, and transport bandwidth and latency requirements to facilitate deployment. Furthermore, the lower layer partitioning architecture of this subject may include partitioning between cell-level processing and user-level processing, which may include cell-level processing at the remote unit ("RU") and user-level processing at the DU. Moreover, using the lower layer partitioning architecture of this subject, frequency-domain samples may be transported over the Ethernet fronthaul, and the frequency-domain samples may be compressed for reduced fronthaul bandwidth.

[0049] Figure 4 shows an exemplary communication system 400 that can implement 5G technology and provide users with the use of higher frequency bands (e.g., greater than 10 GHz). System 400 may include a macrocell 402 and small cells 404, 406.

[0050] The mobile device 408 may be configured to communicate with one or more of the small cells 404, 406. The system 400 can enable the division of the control plane (C-plane) and user plane (U-plane) between the macrocell 402 and the small cells 404, 406, with the C-plane and U-plane utilizing different frequency bands. Specifically, the small cells 404, 406 may be configured to utilize a higher frequency band when communicating with the mobile device 408. The macrocell 402 can utilize the existing cellular band for C-plane communication. The mobile device 408 may also be communicatively coupled via the U-plane 412, and the small cell (e.g., small cell 406) can provide higher data rates and more flexible / cost / energy-efficient operation. The macrocell 402 can maintain good connectivity and mobility via the C-plane 410. Furthermore, in some cases, LTE and NR may be transmitted on the same frequency.

[0051] Figure 5a shows an exemplary 5G wireless communication system 500 in several implementation forms of the subject. System 500 may be configured to have a lower-layer partitioned architecture according to option 7-2. System 500 may include a core network 502 (e.g., a 5G core) and one or more gNodeBs (or gNBs), where the gNB may have a centralized unit gNB-CU. The gNB-CU may be logically divided into a control plane portion gNB-CU-CP 504 and one or more user plane portions gNB-CU-UP 506. The control plane portion 504 and the user plane portion 506 may be configured to be communicatively coupled using an E1 communication interface 514 (as defined in the 3GPP standard). The control plane portion 504 may be configured to be responsible for executing the RRC and PDCP protocols of the radio stack.

[0052] The control plane portion 504 and user plane portion 506 of the gNB centralized unit may be configured to communicately couple to one or more distributed units (DUs) 508, 510 according to the upper layer partitioning architecture. The distributed units 508, 510 may be configured to run the upper parts of the RLC, MAC, and PHY layer protocols of the radio stack. The control plane portion 504 may be configured to communicately couple to the distributed units 508, 510 using an F1-C communication interface 516, and the user plane portion 506 may be configured to communicately couple to the distributed units 508, 510 using an F1-U communication interface 518. The distributed units 508, 510 may be coupled to one or more remote radio units (RUs) 512 via a fronthaul network 520 (which may include one or more switches, links, etc.), and the remote radio units 512 communicate with one or more user devices (not shown in Figure 5a). The remote radio unit 512 may be configured to execute the lower part of the PHY layer protocol and to provide antenna capabilities to the remote unit for communication with user equipment (similar to the above description relating to Figures 1a-2).

[0053] Figure 5b shows an exemplary layer architecture 530 of a segmented gNB. Architecture 530 may be implemented within the communication system 500 shown in Figure 5a, which can be configured as a virtualized isolated radio access network (RAN) architecture, thereby allowing layers L1, L2, L3 and radio processing to be virtualized and dissociated in centralized, distributed, and radio units. As shown in Figure 5b, the gNB-DU 508 can be communicatively coupled to the gNB-CU-CP control plane portion 504 (also shown in Figure 5a) and the gNB-CU-UP user plane portion 506. Each of components 504, 506, and 508 may be configured to include one or more layers.

[0054] The gNB-DU508 may include the RLC, MAC, and PHY layers, as well as various communication sublayers. These may include the F1 Application Protocol (F1-AP) sublayer, the GPRS Tunneling Protocol (GTPU) sublayer, the Stream Controlled Transmission Protocol (SCTP) sublayer, the User Datagram Protocol (UDP) sublayer, and the Internet Protocol (IP) sublayer. As described above, the distributed unit 508 may also be communicatively coupled to the control plane portion 504 of the centralized unit, which may also include the F1-AP, SCTP, and IP sublayers, as well as the Radio Resource Control and PDCP Control (PDCP-C) sublayers. Furthermore, the distributed unit 508 may also be communicatively coupled to the user plane portion 506 of the centralized unit of the gNB. The user plane portion 506 may include the Service Data Adaptive Protocol (SDAP), PDCP User (PDCP-U), GTPU, UDP, and IP sublayers.

[0055] Figure 5c shows an exemplary functional partition in the gNB architecture shown in Figures 5a to 5b. As shown in Figure 5c, gNB-DU508 may be communicatively coupled to gNB-CU-CP504 and gNB-CU-UP506 using the F1-C communication interface. gNB-CU-CP504 and gNB-CU-UP506 may be communicatively coupled using the E1 communication interface. The upper part of the PHY layer (or Layer 1) may be performed by gNB-DU508, and the lower part of the PHY layer may be performed by RU (not shown in Figure 5c). As shown in Figure 5c, the RRC and PDCP-C parts may be performed by the control plane part 504, and the SDAP and PDCP-U parts may be performed by the user plane part 506.

[0056] Some of the functions of the PHY layer in a 5G communication network may include error detection on the transport channel and display to higher layers, FEC coding / decoding of the transport channel, hybrid ARQ soft synthesis, rate matching of coded transport channels to physical channels, mapping of coded transport channels to physical channels, power weighting of physical channels, modulation and demodulation of physical channels, frequency and time synchronization, radio characteristics measurement and display to higher layers, MIMO antenna processing, digital and analog beamforming, RF processing, and other functions.

[0057] The Layer 2 MAC sublayer can perform beam management, random access procedures, mapping between logical channels and transport channels, concatenation of multiple MAC service data units (SDUs) belonging to a single logical channel into a transport block (TB), multiplexing / demultiplexing of SDUs belonging to a logical channel to / from a TB passed to and from the physical layer on the transport channel, scheduling information reporting, error correction by HARQ, priority processing between logical channels of a single UE, priority processing between UEs by dynamic scheduling, transport format selection, and other functions. The functions of the RLC sublayer may include forwarding upper layer packet data units (PDUs), error correction by ARQ, sorting, duplication and protocol error detection of data PDUs, and re-establishment. The PDCP sublayer can be responsible for forwarding user data, various functions during re-establishment procedures, retransmission of SDUs, discarding SDUs on the uplink, and forwarding control plane data.

[0058] The Layer 3 RRC sublayer can perform functions such as broadcasting system information to NAS and AS, establishing, maintaining, and releasing RRC connections, security, establishing, configuring, maintaining, and releasing point-to-point wireless bearers, mobility functions, reporting, and other functions.

[0059] III. LTM for relocation of CU-UPs within base stations In some implementations of this subject, a base station (e.g., gNodeB in Figure 5a) of a wireless communication system (e.g., a 5G wireless communication system, a 6G or later generation wireless communication system) may have a distributed architecture in which the base station includes two or more CU-UPs (e.g., gNB-CU-UP506 in Figures 5a-5c). The base station may be configured to provide LTM when a UE commutably coupled to the base station undergoes relocation from one CU-UP of the base station to another CU-UP of the base station with respect to one or more services.

[0060] Figure 6a shows an exemplary system 600 configured to provide LTM for in-base station CU-UP relocation. In this illustrated implementation, base station 624 is a gNB configured to be within a 5G wireless communication system similar to the 5G wireless communication system 500 in Figure 5a described above, but other base stations may be configured similarly and used to provide LTM for in-base station CU-UP relocation. In the illustrated implementation of Figure 6a, base station 624 includes multiple CU-UPs 606a, 606b, and 606c. Base station 624 includes three CU-UPs 606a, 606b, and 606c in this illustrated implementation, but may include other multiple CU-UPs. The CUs of base station 624, including multiple CU-UPs 606a, 606b, and 606c, are configured to be communicatively coupled to a core network (not shown in Figure 6a), such as 5GC502 in Figure 5a.

[0061] The CU of base station 624 also includes a CU-CP 604 configured to communicately couple to the user plane portions 606a, 606b, and 606c of the CU using an E1 communication interface 614. The E1 interface 614 includes three communication links in this illustrated implementation to reflect that there are three CU-UPs 606a, 606b, and 606c that the CU-CP 604 may be configured to communicate with.

[0062] Base station 624 also includes multiple DU608,610. While base station 624 includes two DU608,610 in this illustrated implementation, it may include multiple other DUs. CU-CP604 is configured to communicately couple to DU608,610 using F1-C communication interface 616. CU-UP606a,606b,606c are configured to communicately couple to DU608,610 using F1-U communication interface 618. The F1-U interface 618 associated with each DU608,610 includes three communication links in this illustrated implementation to reflect the fact that there are three CU-UP606a,606b,606c that each DU608,610 may be configured to communicate with.

[0063] Base station 624 also includes multiple RU612s. In this illustrated implementation, base station 624 includes five RU612s, but may include other multiple RUs. The RU612s are configured to be communicatively coupled to DU608, 610 via the fronthaul network 620. Furthermore, each of the RU612s is configured to be communicatively coupled to one or more UE622s. In this illustrated implementation, two of the RU612s are shown communicatively coupled to one UE622, two of the RU612s are shown communicatively coupled to two UE622s, and one of the RU612s is shown communicatively coupled to three UE622s, but each of the RU612s may be coupled to another number of UEs, either the same as or different from any of the other RU612s.

[0064] A base station CU-UP relocation may be configured to occur when one of the UE622s, which is communicably coupled to base station 624, is relocated from one of the CU-UPs 606a, 606b, or 606c to another of the CU-UPs 606a, 606b, or 606c for one or more services. One of the CU-UPs 606a, 606b, or 606c that is currently serving the UE622 is called the "serving CU-UP" because it is currently serving the UE622. One of the CU-UPs 606a, 606b, or 606c whose UE service is being moved to the relocation difference is called the "target CU-UP" because it is aiming to serve the UE622.

[0065] For example, an in-base station CU-UP relocation scenario may occur when one of the UE622s is being served (via one of the RU612s) by one of the DU608s which is being served by one of the CU-UP606a, and is moving at least one service (via the same one or a different one of the RU612s) to one of the DU612s which is being served by one of the CU-UP606b. The DU608 currently serving the UE622 is called the "serving DU" because it is currently serving the UE622. The DU610 to which the UE's service is being moved is called the "target DU" because it is aiming to serve the UE622. Each of the CU-UP606a, 606b, and 606c has a different security key used when securely communicating with the DU. Therefore, target DU610 requires a second security key for CU-UP606b before DU610 can serve UE622.

[0066] For example, in a scenario where one UE622 is served by one of the first and second DU608,610s, which is also served by one of the CU-UP606a,606b,606c, and is moving at least one service to another DU608,610, which is also served by the same CU-UP606a,606b,606c, base station CU-UP relocation is not required. Therefore, one of the DU608,610s serving the UE622 may change, but the CU-UP606a,606b,606c serving the UE622 does not change.

[0067] Scenarios in which CU-UP relocation within the base station is performed or not performed are further described with respect to Figure 6b. Figure 6b shows the CU-CP 604 and CU-UPs 606a, 606b, 606b of Figure 6a, but in the illustrated implementation of Figure 6b, base station 624 contains three or more DUs. In the illustrated implementation of Figure 6b, base station 624 contains 66 DUs 626, 628. Three of the DU628a, 628b, and 628c are macrocells (labeled macro1, macro2, and macro3 in Figure 6b), and 63 of the DU626 are small cells (9 of which are labeled gNB-DU10, gNB-DU20, gNB-DU30, gNB-DU40, gNB-DU50, gNB-DU60, gNB-DU70, gNB-DU80, and gNB-DU90 in Figure 6b). Base station 624 may include another number of macrocells and / or another number of small cells. Twenty-one of the small cells DU626, including macro1 DU628a, macro2 DU628b, and gNB-DU10, gNB-DU20, and gNB-DU30, are configured to be served by a first CU-UP606a (labeled CU-UP1 in Figure 6b). Twenty-one of the small cells DU626, including macro1 DU628a, macro2 DU628b, macro3 DU628c, and gNB-DU40, gNB-DU50, and gNB-DU60, are configured to be serviced by a second CU-UP606b (labeled CU-UP2 in Figure 6b). Twenty-one of the small cells DU626, including macro2 DU628b, macro3 DU628c, and gNB-DU70, gNB-DU80, and gNB-DU90, are configured to be serviced by a third CU-UP606c (labeled CU-UP3 in Figure 6b).

[0068] One example of a scenario in which the base station is not configured to perform CU-UP relocation is when at least one service of the UE moves from one macrocell serviced by a particular CU-UP to another macrocell also serviced by the same CU-UP, for example, from macro 1DU628a serviced by the first CU-UP606a to macro 2DU628b serviced by the first CU-UP606a, or from macro 3DU628c serviced by the second CU-UP606b to macro 2DU628b serviced by the second CU-UP606b. Another example of a scenario in which the base station is not configured to perform CU-UP relocation is when at least one service of UE622 moves from one small cell to another that is served by a particular CU-UP, for example, from gNB-DU10 626 to gNB-DU20 626, from gNB-DU50 626 to gNB-DU40 626, from gNB-DU50 626 to gNB-DU60 626, from gNB-DU70 626 to gNB-DU80 626, from gNB-DU80 626 to gNB-DU70 626, and so on.

[0069] One example of a scenario configured to enable CU-UP relocation within a base station is when at least one service of a UE moves from one macrocell serviced by a particular CU-UP to another macrocell serviced by a different CU-UP, for example, from macro 1 DU628a serviced by the first CU-UP 606a to macro 3 DU628c serviced by the second CU-UP 606b, or from macro 3 DU628a serviced by the second CU-UP 606a to macro 3 DU628c serviced by the third CU-UP 606c. Another example of a scenario configured to cause CU-UP relocation within a base station is when at least one service of a UE moves from one small cell served by a particular CU-UP to another small cell served by a different CU-UP, for example, from gNB-DU10 626 served by the first CU-UP 606a to gNB-DU40 626 served by the second CU-UP 606b, from gNB-DU80 626 served by the third CU-UP 606b to gNB-DU40 626 served by the second CU-UP 606b, from gNB-DU90 626 served by the third CU-UP 606c to gNB-DU30 626 served by the first CU-UP 606a, and from gNB-DU50 626 served by the second CU-UP 606b to gNB-DU20 626 served by the first CU-UP 606a For example, move to 626.

[0070] In the implementation shown in Figure 6b, each CU-UP 606a, 606b, and 606c serves a subset of DUs 626, 628a, 628, and 628c for all services. However, a CU-UP can serve all DUs at a base station for one service (e.g., advanced mobile broadband (eMBB)) while serving a subset of DUs for another service (e.g., vehicle-to-vehicle / vehicle-to-infrastructure (V2X) or ultra-high reliability low-latency communication (URLLC)).

[0071] The scenarios described above with respect to Figures 6a and 6b illustrate an example of in-base station CU-UP relocation. The in-base station CU-UP relocation described herein is also applicable to L1 / L2-based inter-cell mobility covering in-CU-DU scenarios. One example of such a scenario is when at least one service of a UE moves from one small cell served by a particular CU-UP to another small cell served by the same CU-UP, for example, from gNB-DU10 626 served by the first CU-UP606a to gNB-DU20 626 served by the first CU-UP606a, from gNB-DU40 626 served by the second CU-UP606b to gNB-DU60 626 served by the second CU-UP606b, from gNB-DU90 626 served by the third CU-UP606c to gNB-DU80 626 served by the third CU-UP606c, and so on.

[0072] In some implementations, providing an LTM for in-base station CU-UP relocation may include a preparation stage and a data transfer stage that takes place after the preparation stage. In some implementations, the preparation stage may include a CU-CP (e.g., gNodeB in Figure 5a, gNB624 in Figures 6a and 6b) of a base station (e.g., gNB-CU-CP504 in Figures 5a-5c, CU-CP604 in Figures 6a and 6b) that prepares the target DUs (e.g., DU508 in Figures 5a-5c, DU510 in Figure 5a, DU608 in Figure 6a, DU610 in Figure 6a, DU626 in Figure 6b, DU628 in Figure 6b, etc.) and target CU-UPs (e.g., gNB-CU-CP504 in Figures 5a-5c, CU-CP604 in Figures 6a and 6b, etc.) for the LTM.

[0073] The preparation of the target DU may include the CU-CP providing the target DU with the security key of the UE provided by the target CU-UP, thereby enabling the target DU to communicate securely with the UE and target CU-UP using the security key. The CU-CP may provide the security key to the target DU before a serving cell change occurs and at least one service of the UE (e.g., UE622 in Figure 6a) is relocated to the target CU-UP, so that the target DU can communicate securely with the UE and target CU-UP without delay once the serving cell change occurs. In some implementations, the CU-CP may be configured to provide the security key to the target DU in the F1:UE CONTEXT SETUP REQUEST message. The F1:UE CONTEXT SETUP REQUEST message is defined by 3GPP. Therefore, the security key may be sent from the CU-CP to the target DU using a message already sent from the CU-CP to the target DU in accordance with the 3GPP standard.

[0074] The preparation of a target CU-UP may include a CU-CP that notifies the target CU-UP that a relocation is to be performed for a given UE. The notification may allow the CU-CP to receive the security key of the UE's target CU-UP from the target CU-UP, for example in response to the notification, and as a result, the CU-CP can provide the security key to the target DU during LTM target cell preparation. In some implementations, the CU-CP may be configured to provide notification to the target CU-UP in a BEARER CONTEXT SETUP REQUEST message, such as the information element (IE) of the BEARER CONTEXT SETUP REQUEST message. 3GPP specifies the BEARER CONTEXT SETUP REQUEST message. Therefore, the notification may be sent from the CU-CP to the target CU-UP using a message already sent from the CU-CP to the target CU-UP in accordance with the 3GPP standard. The same message may be used to reserve the resources required for the UE's CU-UP relocation.

[0075] In some implementations, the data transfer stage may include a serving DU (e.g., DU508 in Figures 5a-5c, DU510 in Figure 5a, DU608 in Figure 6a, DU610 in Figure 6a, DU626 in Figure 6b, DU628 in Figure 6b) that indicates to the serving CU-UP (e.g., gNB-CU-UP506 in Figures 5a-5c, CU-UP606a, 606b, 606c in Figures 6a and 6b) when to begin data transfer to the target CU-UP. The data transfer stage may also include a CU-CP to the serving DU that identifies the target CU-UP of a given target cell, thereby enabling the serving DU to identify the target CU-UP corresponding to the target cell in the target DU to the serving CU-UP, so that the serving CU-UP can communicate with the target CU-UP for the purpose of triggering data transfer to the target CU-UP. In some implementations, the CU-CP may be configured to identify the target CU-UP for a given target cell to the serving DU in the UE CONTEXT MODIFICATION REQUEST message. The UE CONTEXT MODIFICATION REQUEST message is defined by 3GPP. Therefore, the identification of the target CU-UP for a given target cell can be provided from the CU-CP to the serving DU using a message already sent from the CU-CP to the serving DU in accordance with the 3GPP standard.

[0076] Figure 7 shows an exemplary method 700 in several implementation forms of the subject matter. As shown in Figure 7, method 700 includes a preparation stage 716 and a data transfer stage 718. Although method 700 is described in relation to the exemplary system 800 shown in Figure 8, it can be similarly implemented in other systems, such as the systems in Figures 6a and 6b. Although system 800 in Figure 8 is a 5G system, as described herein, the LTM for in-base station CU-UP relocation can be implemented in other types of wireless communication systems, such as 6G or later generation wireless communication systems.

[0077] In system 800, UE802 (e.g., UE622 in Figure 6a) is composed of 814 by LTMs having one or more target cells in one or more DU804, 806 (e.g., DU508 in Figures 5a-5c, DU510 in Figure 5a, DU608 in Figure 6a, DU610 in Figure 6a, DU626 in Figure 6b, DU628 in Figure 6b) of a base station, such as gNodeB (e.g., gNodeB in Figure 5a, gNodeB624 in Figures 6a and 6b). For the sake of clarity, System 800 is shown in Figure 8 with one UE 802, two DUs 804 and 806, and two CU-UPs 810 and 812 of the base station (e.g., gNB-CU-UP 506 in Figures 5a and 5c, CU-UPs 606a, 606b, and 606c in Figures 6a and 6b, etc.), but two or more UEs can be communicatively coupled to the base station, the base station can contain three or more DUs, and the base station can contain three or more CU-UPs. The base station of System 800 also includes a CU-CP 808 (e.g., gNB-CU-CP 504 in Figures 5a and 5c, CU-CP 604 in Figures 6a and 6b, etc.) and several RUs (e.g., RU 512 in Figure 5a, RU 612 in Figure 6a, etc.) (not shown in Figure 8). UE 802 is currently being served by Serving DU 804 and Serving CU-UP 810.

[0078] Method 700 includes CU-CP 808 determining 702 that UE 802's target DU 806 is being served by a different CU-UP (target CU-UP 812) than the serving CU-UP 810 currently serving serving DU 804. The CU-CP's determination 702 may include CU-CP 808 analyzing, in 818, a radio resource control (RRC) measurement report transmitted to CU-CP 808 by UE 802 in accordance with the 3GPP standard in 816. In accordance with the 3GPP standard, the RRC measurement report may include Layer 3 (L3) measurements that can be analyzed by CU-CP 808 when making resource control decisions, which may include service changes that result in UE 802 being served by a DU other than serving DU 804, e.g., target DU 806, for at least one service. CU-CP808 recognizes, according to the 3GPP standard, the serving CU-UP810 currently serving serving DU804 and the CU-UP812 currently serving target DU806. Therefore, CU-CP808 recognizes that the CU-UP serving UE802 is changing, and that the LTM for base station CU-UP relocation is being properly implemented in this scenario.

[0079] In response to 702 determining that the target DU806 of UE802 is being served by a different CU-UP810 (target CU-UP) than the serving CU-UP812 currently serving DU804, CU-CP808 prepares the LTM target CU-UP812. Preparing the target CU-UP812 may include CU-CP808 requesting the target CU-UP812 to reserve the necessary resources for UE802 and fetching the security key for UE802 from the target CU-UP812 704. As shown in Figure 8, preparing the LTM target CU-UP812 and fetching the security key 704 may include CU-CP808 sending an E1:BEARER CONTEXT SETUP REQUEST message to the target CU-UP812 on 820 using the E1 communication interface. As further shown in Figure 8, the E1:BEARER CONTEXT SETUP REQUEST message may include an IE that notifies the target CU-UP812 that a CU-UP relocation is taking place, so that the target CU-UP812 can reserve the resources of UE802.

[0080] In response to receiving the E1:BEARER CONTEXT SETUP REQUEST message, for example in response to receiving an IE indicating that a CU-UP relocation is taking place, target CU-UP812 sends an E1:BEARER CONTEXT SETUP RESPONSE message to CU-CP808 on 822, containing the security key of the target CU-UP on UE802. The E1:BEARER CONTEXT SETUP RESPONSE message is defined by 3GPP. Therefore, the security key may be sent from target CU-UP808 to CU-CP812 using a message already sent from target CU-UP812 to CU-CP808 in accordance with the 3GPP standard.

[0081] Once the security key for the target CU-UP of UE802 is fetched at 704, CU-CP808 sends the security key of UE802 to target DU806 at 706 in order to prepare the LTM target DU806. As shown in Figure 8, sending the security key to target DU806 at 706 may include CU-CP808 sending a UE CONTEXT SETUP REQUEST message containing the security key of the target CU-UP of UE802 at 824 using the F1 communication interface. In response to receiving the F1:UE CONTEXT SETUP REQUEST message, target DU806 reserves the necessary resources and sends an F1:UE CONTEXT SETUP RESPONSE message at 826. As shown in Figure 8, the F1:UE CONTEXT SETUP RESPONSE message may include cell group configuration information for target DU806. The F1:UE CONTEXT SETUP REQUEST and F1:UE CONTEXT SETUP RESPONSE messages are defined by 3GPP, respectively. Therefore, the security key is sent from CU-CP808 to target DU806, and target DU806 may respond to CU-CP808 with an acknowledgment using a message already sent in accordance with the 3GPP standard.

[0082] CU-CP808 also notifies Serving DU804 of a change in the CU-UP of a given target cell at 708 by identifying the target CU-UP812 and the corresponding target cell or target DU806. As shown in Figure 8, notification to Serving DU804 may include CU-CP808 sending a UE CONTEXT MODIFICATION REQUEST message to Serving DU804 at 828 using the F1 communication interface. As further shown in Figure 8, the UE CONTEXT MODIFICATION REQUEST message may include cell identification information and target CU-UP mapping information.

[0083] In response to receiving the UE CONTEXT MODIFICATION REQUEST message, the serving DU804 stores information identifying the received target CU-UP812 in 830 and sends a UE CONTEXT MODIFICATION RESPONSE message to CU-CP808 in 832. As shown in Figure 8, the UE CONTEXT MODIFICATION RESPONSE message contains aggregated cell group configuration information for all target cells identified by CU-CP808 to UE802. The UE CONTEXT MODIFICATION REQUEST message and the UE CONTEXT MODIFICATION RESPONSE message are defined by 3GPP, respectively. Therefore, the serving DU804 can receive information about the target CU-UP812 from CU-CP and acknowledge its receipt to CU-CP808 using a message already sent in accordance with the 3GPP standard.

[0084] At 710, CU-CP808 also notifies UE802 of a security key change (indirectly a CU-UP change) corresponding to the target cell. As shown in Figure 8, this notification to UE802 may include CU-CP808 sending an RRC reconfiguration message to UE802 at 834, in accordance with the 3GPP standard. As further shown in Figure 8, the RRC reconfiguration message includes target cell configuration information, including the security key corresponding to the target cell, as provided to CU-CP808 from target DU806 in a UE CONTEXT SETUP RESPONSE message, for example. The RRC reconfiguration message, including the target cell configuration information (LTMpreparation), indicates to UE802 that the security key of the new target cell served by target CU-UP812 is different. In this scenario, the PDCP (packet data convergence protocol) entity needs to be reset.

[0085] In response to receiving the RRC reconstruction message, UE802 transmits an in-frequency or inter-frequency L1 measurement report to Serving DU804 via 836, in accordance with the 3GPP standard. The in-frequency or inter-frequency L1 measurement report provides Serving DU804 with UE measurement radio state information and instructs Serving DU804 when to trigger Serving CU-UP810 to transfer data to Target DU806.

[0086] Subsequently, according to an L1 measurement report within or between frequencies indicating a predetermined threshold configured as a criterion for when the trigger should occur, the serving DU 804 triggers data transfer from the serving CU-UP 810 to the target CU-UP 812 by notifying the serving CU-UP 810 at 712 when data transfer to the target CU-UP 812 should begin. As shown in Figure 8, the serving DU 804 can notify the serving CU-UP 810 at 712 by sending a control packet data unit (PDU) to the serving CU-UP 810 at 840 in accordance with the 3GPP standard. The control PDU is not a control signaling message, as it is a user plane data packet containing control plane information. As also shown in Figure 8, the control PDU includes information that identifies the target CU-UP 812, for example by including the ID of the CU-UP 812 when provided to the serving DU 804 in a UE CONTEXT MODIFICATION REQUEST message, and information indicating that data transfer to the target CU-UP 812 should begin.

[0087] In response to being notified by Serving DU 804 at 712 to initiate data transfer, Serving CU-UP 810 initiates data transfer to Target CU-UP 812 at 714 by sending unsent and unanswered data PDUs to Target CU-UP 812 at 842. Serving CU-UP 810 knows which base station's CU-UP to contact as Target CU-UP 810, based on the CU-UPID provided to Serving DU 804.

[0088] In some implementations, instead of the serving DU 804 sending a control PDU to the serving CU-UP 810 on 840, the serving DU 804 can send a signaling message to the CU-CP 808 using the F1-C communication interface, which then initiates data transfer to the target CU-UP 812 by sending a message to the serving CU-UP 810 using the E1 communication interface, after which the serving CU-UP 810 initiates data transfer to the target CU-UP 812. This alternative implementation uses one more message transmission than the implementation shown in Figure 8, but unlike the implementation shown in Figure 8, it utilizes the E1-C communication interface to trigger data transfer.

[0089] Referring again to Figure 7, after the serving DU 804 triggers a data transfer, for example, after the serving DU 804 sends a control PDU to the serving CU-UP 810 (or CU-CP 808 in an alternative implementation) on 840, the serving DU 804 notifies the UE 802 on 716 that a serving cell change must be performed, for example, an LTM secondary component carrier (SCC) for the target DU 806 of the UE 802. As shown in Figure 8, the UE notification on 716 may include the serving DU 804 sending a MAC control element (MACCE) containing the serving cell change command to the UE 802 on 844. As further shown in Figure 8, the MAC CE may include a security key change indicator, which may be a 1-bit indicator within the MAC CE.

[0090] In response to receiving MACCE, UE802 sends a Random Access Channel (RACH) message to target DU812 on 846, in accordance with the 3GPP standard, and UE802 sends an RRC Reconfiguration Acknowledgment message to CU-CP808 on 852. In response to the successful completion of the RACH procedure, target DU812 sends a control PDU to target CU-UP812 on 848, and target DU812 sends a serving cell change notification message to CU-CP808 on 850 using the F1 communication interface. As shown in Figure 8, the control PDU may include SCC and RACH completion notifications. This notification initiates the transmission of downlink data to UE802. As further shown in Figure 8, the serving cell change notification message may include the ID of target DU812.

[0091] The base station in Figure 8 is coupled to the core network (not shown in Figure 8) in a communicative manner. Method 700 may also include performing a path switching procedure toward the core network, which may be done in accordance with 3GPP standards, such as in a CU-UP relocation scenario within a gNB.

[0092] In some implementations, this subject can be configured to be implemented in a system 900, as shown in Figure 9. The system 900 may include one or more of the following: a processor 910, memory 920, storage device 930, and input / output device 940. Each of the components 910, 920, 930, and 940 may be interconnected using a system bus 950. The processor 910 may be configured to process instructions for execution within the system 600. In some implementations, the processor 910 may be a single-threaded processor. In an alternative implementation, the processor 910 may be a multi-threaded processor. The processor 910 may be further configured to process instructions stored in the memory 920 or the storage device 930, which includes receiving or transmitting information through the input / output device 940. The memory 920 may store information within the system 900. In some implementations, the memory 920 may be a computer-readable medium. In an alternative implementation, the memory 920 may be a volatile memory unit. Furthermore, in some implementations, memory 920 may be a non-volatile memory unit. Storage device 930 may be capable of providing large-capacity storage to system 900. In some implementations, storage device 930 may be a computer-readable medium. In alternative implementations, storage device 930 may be a floppy disk device, a hard disk device, an optical disk device, a tape device, a non-volatile solid-state memory, or any other type of storage device. Input / output device 940 may be configured to provide input / output operations to system 900. In some implementations, input / output device 940 may include a keyboard and / or a pointing device. In alternative implementations, input / output device 940 may include a display unit for displaying a graphical user interface.

[0093] Figure 10 shows an exemplary method 1000 of the LTM for base station CU-UP relocation in several implementation forms of this subject. Method 1000 can be carried out using implementation forms shown, for example, in Figures 5a to 8 and described with respect to Figures 5a to 8.

[0094] Method 1000 includes determining that a target distributed unit (e.g., DU508 in Figures 5a to 5c, DU510 in Figure 5a, DU608 in Figure 6a, DU610 in Figure 6a, DU626 in Figure 6b, DU628 in Figure 6b, target DU806 in Figure 8, etc.) of a base station (e.g., gNodeB in Figure 5a, gNodeB624 in Figures 6a and 6b, gNodeB in Figure 8, etc.) that serves user equipment (e.g., UE622 in Figure 6a, UW802 in Figure 8, etc.) is being served by a target centralized unit user plane of the base station (e.g., gNB-CU-UP506 in Figures 5a to 5c, CU-UP606a, 606b, 606c in Figures 6a and 6b, target CU-UP812, etc.). The base station's serving CU-UP (e.g., gNB-CU-UP506 in Figures 5a-5c, CU-UP606a, 606b, 606c in Figures 6a and 6b, serving CU-UP810, etc.) serves the base station's serving DU (e.g., DU508 in Figures 5a-5c, DU510 in Figure 5a, DU608 in Figure 6a, DU610 in Figure 6a, DU626 in Figure 6b, DU628 in Figure 6b, serving DU804 in Figure 8, etc.). Method 1000 also includes preparing the target CU-UP of the LTM using the base station's centralized unit control plane (e.g., gNB-CU-CP504 in Figures 5a-5c, CU-CP604 in Figures 6a and 6b, CU-CP808, etc.) 1004 and preparing the target DU of the LTM using the CU-CP 1006.

[0095] In some implementations, this subject may include one or more of the following optional features.

[0096] In some implementations, preparing a target CU-UP may include using a CU-CP to fetch a security key from the target CU-UP, and preparing a target DU may include sending a security key from the CU-CP to the target DU. Furthermore, the security key configured by the target CU-UP may be sent from the CU-CP to the target DU in a UE CONTEXT SETUP REQUEST message, and / or fetching a security key may include the CU-CP sending a BEARER CONTEXT SETUP REQUEST message to the target CU-UP and the CU-UP sending a BEARER CONTEXT SETUP RESPONSE message to the CU-CP, the BEARER CONTEXT SETUP RESPONSE message may contain a security key that may correspond to the UE served by the target CU-UP. Furthermore, the BEARER CONTEXT SETUP REQUEST message may include an information element (IE) that notifies the target CU-UP of the LTM.

[0097] In some implementations, preparing a target CU-UP may involve sending an information element (IE) from the CU-CP to the target CU-UP to notify the LTM of the UE's resource reservation.

[0098] In some implementations, this method may also include triggering the serving CU-UP to initiate data transfer to the target CU-UP after the target CU-UP and target DU have been prepared. Furthermore, triggering may include sending a control packet data unit (PDU) from the serving DU to the serving CU-UP to initiate downlink data transmission, followed by the serving CU-UP sending unsent and unanswered data PDUs to the target CU-UP. Furthermore, this method may also include sending information from the CU-CP to the serving DU to identify changes in the serving CU-UP of the LTM before sending the control PDU to trigger data transfer. Furthermore, this information may be sent from the CU-CP to the serving DU in a UE CONTEXT MODIFICATION REQUEST message.

[0099] In some implementations, the method may also include, after the preparation of the target CU-UP and the target DU, triggering the target CU-UP to initiate service to the UE via the target DU. Furthermore, triggering may include the target DU sending a control packet data unit (PDU) to the target CU-UP, followed by the target CU-UP sending a data PDU to the target DU; or triggering may include the serving DU sending a first message to the CU-CP, followed by the CU-CP sending a second message to the serving CU-UP, followed by the serving CU-UP sending a third message to the target CU-UP; and / or servicing the UE may include the target DU sending a first message to the CU-CP, followed by the CU-CP sending a second message to the target CU-UP, followed by the target CU-UP initiating downlink data transmission toward the target DU.

[0100] In some implementations, the determination may involve using a CU-CP to analyze radio resource control (RRC) measurement reports received by the UE at the CU-CP.

[0101] In some implementations, the serving CU-UP and the target CU-UP may be different entities.

[0102] In some implementations, the base station may be a Next Generation Radio Access Network (NG-RAN) node (e.g., gNodeB).

[0103] In some implementations, the base station may include at least one processor and at least one non-temporary storage medium.

[0104] The systems and methods disclosed herein can be embodied in various forms, including, for example, data processors such as computers, which may also include databases, digital electronic circuits, firmware, software, or combinations thereof. Furthermore, the above features, as well as other aspects and principles of the implementations of this disclosure, can be implemented in various environments. Such environments and associated applications may be specifically constructed to perform various processes and operations according to the disclosed implementations, or they may include general-purpose computers or computing platforms that are selectively activated or reconfigured by code to provide the necessary functionality. The processes disclosed herein are essentially independent of any particular computer, network, architecture, environment, or other device and can be implemented by a preferred combination of hardware, software, and / or firmware. For example, various general-purpose machines may be used with programs written according to the teachings of the disclosed implementations, or it may be more convenient to construct dedicated devices or systems to perform the required methods and techniques.

[0105] The systems and methods disclosed herein may be implemented as computer program products, i.e., computer programs tangibly embodied in information carriers, e.g., machine-readable storage devices or propagating signals, for execution by or control of the operation of data processing devices, e.g., programmable processors, computers, or multiple computers. The computer programs may be written in any form of programming language, including compiled or interpreted languages, and may be deployed as standalone programs or in any form, including modules, components, subroutines, or other units suitable for use in a computing environment. The computer programs may be deployed to run on a single computer, or on multiple computers located at one site or distributed across multiple sites and interconnected by a communication network.

[0106] As used herein, the term "user" may refer to any entity, including a person or a computer.

[0107] Ordinal numbers such as "1st," "2nd," etc., may be related to order in some contexts, but as used in this document, ordinal numbers do not necessarily imply order. For example, ordinal numbers may simply be used to distinguish one item from another. For instance, distinguishing the first event from the second event does not necessarily imply any arbitrary chronological order or fixed reference system (the first event in one paragraph of the description may be different from the first event in another paragraph of the description).

[0108] The foregoing description is intended to illustrate, and not to limit, the scope of the present invention as defined by the attached claims. Other implementations are within the scope of the following claims.

[0109] These computer programs, which may also be called programs, software, software applications, applications, components, or code, include machine instructions for a programmable processor and may be implemented in high-level procedural and / or object-oriented programming languages, and / or assembly language / machine language. As used herein, the term “machine-readable medium” means any computer program product, apparatus, and / or device, such as magnetic disks, optical disks, memory, and programmable logic devices (PLDs), used to provide machine instructions and / or data to a programmable processor, including a machine-readable medium that receives machine instructions as machine-readable signals. The term “machine-readable signals” means any signals used to provide machine instructions and / or data to a programmable processor. A machine-readable medium may store such machine instructions non-temporarily, for example, non-temporarily stored solid-state memory or a magnetic hard drive or any equivalent storage medium. Alternatively or additionally, a machine-readable medium may store such machine instructions temporarily, for example, a processor cache or other random-access memory associated with one or more physical processor cores.

[0110] To provide user interaction, the subject matter described herein may be implemented on a computer having a display device, such as a cathode ray tube (CRT) or liquid crystal display (LCD) monitor, for displaying information to the user, and a keyboard and pointing device, such as a mouse or trackball, to which the user can provide input to the computer. User interaction may also be provided using other types of devices. For example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback, and user input may be received in any form, including, but not limited to, acoustic, verbal, or tactile input.

[0111] The subject matter described herein may be implemented in a computing system that includes, for example, one or more backend components such as data servers, or a computing system that includes, for example, one or more middleware components such as application servers, or a computing system that includes, for example, one or more frontend components such as one or more client computers having a graphical user interface or a web browser on which a user can interact with an implementation of the subject matter described herein, or any combination of such backend components, middleware components, or frontend components. The components of the system may be interconnected by digital data communications in any form or medium, such as a communication network. Examples of communication networks include, but are not limited to, local area networks ("LANs"), wide area networks ("WANs"), and the Internet.

[0112] A computing system may include clients and servers. Clients and servers are generally, but not mutually exclusive, separate from one another and typically interact via a communication network. The client-server relationship arises from computer programs running on each computer that have a client-server relationship with one another.

[0113] The implementations described above do not represent all implementations that are consistent with the subject matter described herein. Rather, they are only some examples that are consistent with the aspects relating to the subject matter described herein. While several variations are described in detail above, other modifications or additions are possible. In particular, further features and / or variations may be provided in addition to those described herein. For example, the implementations described above may cover various combinations and partial combinations of the disclosed features, and / or combinations and partial combinations of some of the further features disclosed above. In addition, the logical flows shown in the accompanying figures and / or described herein do not necessarily require a specific order or sequence shown to achieve the desired result. Other implementations may be within the scope of the following claims.

Claims

1. Determining that a base station's target distributed unit (DU) serving user equipment (UE) is being served by the base station's target centralized unit user plane (CU-UP), and determining that the base station's serving CU-UP is serving the base station's serving DU that is currently serving the UE, Using the centralized unit control plane (CU-CP) of the base station, prepare the target CU-UP for Layer 1 / Layer 2 trigger mobility (LTM), Using the aforementioned CU-CP, prepare the target DU of the LTM, , configured to perform an action including, Device.

2. Preparing the target CU-UP involves using the CU-CP to fetch the security key from the target CU-UP, Preparing the target DU involves transmitting the security key from the CU-CP to the target DU, The apparatus according to claim 1, including the following:

3. The apparatus according to claim 2, wherein the security key configured by the target CU-UP is transmitted from the CU-CP to the target DU in a UE CONTEXT SETUP REQUEST message.

4. Fetching the security key includes the CU-CP sending a BEARER CONTEXT SETUP REQUEST message to the target CU-UP, and the target CU-UP sending a BEARER CONTEXT SETUP RESPONSE message to the CU-CP, The apparatus according to claim 2, wherein the BEARER CONTEXT SETUP RESPONSE message includes the security key corresponding to the UE served by the target CU-UP.

5. The apparatus according to claim 4, wherein the BEARER CONTEXT SETUP REQUEST message includes an information element (IE) that notifies the target CU-UP of the LTM.

6. The apparatus according to claim 1, wherein preparing the target CU-UP includes transmitting an information element (IE) from the CU-CP to the target CU-UP to notify the target CU-UP of the LTM in order to reserve the resources of the UE.

7. The apparatus according to claim 1, further comprising triggering the serving CU-UP to initiate data transfer to the target CU-UP after the preparation of the target CU-UP and the preparation of the target DU.

8. The apparatus according to claim 7, wherein the triggering includes transmitting a control packet data unit (PDU) from the serving DU to the serving CU-UP, and the serving CU-UP then transmitting unsent and unanswered data PDUs to the target CU-UP.

9. The apparatus according to claim 1, further comprising, after the preparation of the target CU-UP and the preparation of the target DU, triggering the target CU-UP to initiate service to the UE via the target DU.

10. The apparatus according to claim 9, wherein the triggering includes the target DU transmitting a control packet data unit (PDU) to the target CU-UP to initiate downlink data transmission, and the target CU-UP subsequently transmitting a data PDU to the target DU.

11. The apparatus according to claim 8, further comprising transmitting information from the CU-CP to the serving DU for identifying a change in the serving CU-UP of the LTM, prior to the transmission of the control PDU to trigger a data transfer.

12. The apparatus according to claim 11, wherein the information is transmitted from the CU-CP to the serving DU in a UE-CONTEXT MODIFICATION REQUEST message.

13. The apparatus according to claim 9, wherein the triggering includes sending a first message from the serving DU to the CU-CP, then the CU-CP sending a second message to the serving CU-UP, and then the serving CU-UP sending a third message to the target CU-UP, the third message corresponding to unsent and unanswered data PDUs.

14. The apparatus according to claim 9, wherein servicing the UE includes sending a first message from the target DU to the CU-CP, then the CU-CP sending a second message to the target CU-UP, and then the target CU-UP initiating downlink data transmission toward the target DU.

15. The apparatus according to claim 1, wherein the determination includes analyzing a radio resource control (RRC) measurement report received by the CU-CP from the UE using the CU-CP.

16. The apparatus according to claim 1, wherein the serving CU-UP and the target CU-UP are different entities.

17. The apparatus according to claim 1, wherein the base station is a next-generation wireless access network (NG-RAN) node.

18. The apparatus according to claim 1, wherein the base station is configured to perform the operation described above.

19. Implementation method, Determining that a base station's target distributed unit (DU) serving user equipment (UE) is being served by the base station's target centralized unit user plane (CU-UP), and determining that the base station's serving CU-UP is serving the base station's serving DU that is currently serving the UE, Using the centralized unit control plane (CU-CP) of the aforementioned base station, prepare the target CU-UP for Layer 1 / Layer 2 trigger mobility (LTM), Using the aforementioned CU-CP, prepare the target DU of the LTM, Implementation methods, including those mentioned above.

20. On at least one computer, Determining that a base station's target distributed unit (DU) serving user equipment (UE) is being served by the base station's target centralized unit user plane (CU-UP), wherein the base station's serving CU-UP is serving the base station's serving DU that is currently serving the UE, Using the base station's centralized unit control plane (CU-CP), prepare the target CU-UP for Layer 1 / Layer 2 triggered mobility (LTM), Using the aforementioned CU-CP, prepare the target DU of the LTM, A program that executes something.

Images