Patent Description:
A unified air interface, which utilizes licensed, unlicensed, and shared license radio spectrum in multiple frequency bands is one aspect of enabling the capabilities of <NUM> systems. The <NUM> air interface utilizes radio spectrum in bands below <NUM> (sub-gigahertz), below <NUM> (sub-<NUM>), and above <NUM>. Radio spectrum above <NUM> includes millimeter wave (mmWave) frequency bands that provide wide channel bandwidths to support higher data rates for wireless broadband. Another aspect of enabling the capabilities of <NUM> systems is the use of Multiple Input Multiple Output (MIMO) antenna systems to beamform signals transmitted between base stations and user equipment to increase the capacity of <NUM> radio networks.

To support the transition to <NUM> networks, multiple radio access technology connectivity enables a user equipment (UE) to simultaneously connect to Evolved Universal Terrestrial Radio Access (E-UTRA) and <NUM> base stations. In Multi-Radio-Access-Technology (MRAT) Dual Connectivity (DC), there are interfaces between network nodes (E-UTRA and/or <NUM> base stations) for exchanging information, such as cell-group configurations. Upon a network role transition, such as secondary node change or handover, there is a need to exchange configurations or signaling from the source node to target node to help the target node prepare follow-up configurations. Depending on the received configuration versions or implementation concerns, the target node decides whether to perform delta configuration based on the current configuration from the source node or to perform full configuration.

Additionally, the architecture of the <NUM> Radio Access Network (RAN) provides flexibility in the deployment of components of base stations. A <NUM> base station may be a monolithic unit that supports all the network layer entities of the RAN, or the base station may be distributed with a central unit (CU) that implements upper-layer network entities and is interfaced to multiple distributed units (DU) that support lower-layer network entities. The exchange and signaling of configurations between the CU and the DUs in a base station are undefined.

By way of background, related interactions between the E-UTRA base stations and <NUM> base stations are specified in 3GPP TS <NUM> v15. <NUM>, 3GPP TS <NUM> v15. <NUM>, 3GPP TS <NUM> v15. <NUM>, and 3GPP TS <NUM> v15. The F1 interface between the CU and the DU are introduced in 3GPP TS <NUM> v15. <NUM> and 3GPP TS <NUM> v15.

<CIT> describes a method and radio access node for controlling beam transmission from a radio access node. <CIT> describes a method carried out by a wireless device (<NUM>) operating in a wireless communications network, where the method includes determining (<NUM>) a reporting quality threshold for a parameter related to channel state information, CSI, and performing (<NUM>) a measurement for each of a plurality of beams from a first predetermined set of beams for evaluation. <CIT> describes a method for performing beam tracking in a wireless communication network.

This summary is provided to introduce simplified concepts of central unit-distributed unit architecture. The simplified concepts are further described below in the Detailed Description. This summary is not intended to identify essential features of the claimed subject matter, nor is it intended for use in determining the scope of the claimed subject matter.

In some aspects, a method for determining a user equipment (UE) context by a central unit (CU) of a base station engaged as a secondary base station in dual-connectivity communication with a UE is described in which the CU receives a configuration message including configuration information from a master node of the dual-connectivity communication. Based on the received configuration message, the CU determines a configuration type, generates a UE Context Setup Request message based on the determined configuration type, and sends the generated UE Context Setup Request message to a Distributed Unit (DU) of the base station, the generated UE Context Setup Request effective to direct the DU to generate a cell-group configuration. The CU receives the generated cell-group configuration, generates a secondary-cell-group configuration using the received cell-group configuration, and sends the secondary-cell-group configuration in a configuration response message to the master node to configure the context for the UE.

In another aspect, a method for determining a user equipment (UE) context for a handover by a central unit (CU) of a target base station for dual-connectivity communication with a UE is described in which the CU receives a Handover Request configuration message including configuration information from a source base station. Based on the received configuration message, the CU determines a configuration type, generates a UE Context Setup Request message based on the determined configuration type, and sends the generated UE Context Setup Request message to a Distributed Unit (DU) of the base station, the generated UE Context Setup Request effective to direct the DU to generate a cell-group configuration. The CU receives the generated cell-group configuration, generates a Handover Command using the received cell-group configuration, and sends the Handover Command to the source base station.

In a further aspect, a base station including a central unit (CU) and one or more distributed units (DU), with each DU being connected to the CU via an F1 interface, is described. The CU is configured to: receive a configuration message including configuration information from a master node; based on the received configuration message, determine a configuration type; based on the determined configuration type, generate a User Equipment (UE) Context Setup Request message; and send the generated UE Context Setup Request message to at least one of the one or more DUs using the F1 interface. The at least one DU is configured to: receive the UE Context Setup Request message using the F1 interface, generate a cell-group configuration, and send the generated cell-group configuration to the CU using the F1 interface. The CU is configured to: receive the generated cell-group configuration using the F1 interface, generate a secondary-cell-group configuration using the received cell-group configuration, and send the secondary-cell-group configuration in a response message to the configuration message to the master node.

The details of one or more aspects of full and delta configuration in a central unit-distributed unit architecture is described below. The use of the same reference numbers in different instances in the description and the figures may indicate like elements:.

This document describes methods, and devices for the exchange of configuration information during network role transitions, such as a secondary node change or a handover. A secondary base station node includes a central unit (CU) and one or more distributed units (DU) that are connected to the CU via an F1 interface. The secondary base station node receives an addition request message including configuration information for its configuration and, based on the received configuration information, determines, at the CU of the secondary base station, whether to apply a full configuration or a delta configuration. The CU generates secondary cell group information, based on cell group configuration information received from the one or more DUs, and sends an addition response message, including the generated secondary cell group information, to a master base station.

Upon a network role transition (e.g., handover), there is a need to exchange configurations and/or signaling from a source node (base station) to a target node to assist the target node to prepare for follow-up configurations. Depending on the received configuration versions or implementation concerns, the target node decides whether to perform delta configuration change based on the current configuration from the source node or, alternatively, to perform a full configuration. However, a process for these role transition configurations is not defined for <NUM> NR base stations with a central unit-distributed unit architecture in which the central unit and the distributed unit(s) host different network layer entities. In this central unit-distributed unit architecture, no defined process and protocols exist for the determination of configuration information by the control unit and the distributed units.

<FIG> illustrates an example environment <NUM>, which includes multiple user equipment <NUM> (UE <NUM>), illustrated as UE <NUM>, UE <NUM>, and UE <NUM>. Each UE <NUM> can communicate with base stations <NUM> (illustrated as base stations <NUM>, <NUM>, <NUM>, and <NUM>) through wireless communication links <NUM> (wireless link <NUM>), illustrated as wireless links <NUM> and <NUM>. For simplicity, the UE <NUM> is implemented as a smartphone but may be implemented as any suitable computing or electronic device, such as a mobile communication device, modem, cellular phone, gaming device, navigation device, media device, laptop computer, desktop computer, tablet computer, smart appliance, vehicle-based communication system, or an Internet-of-Things (IoT) device such as a sensor or an actuator. The base stations <NUM> (e.g., an Evolved Universal Terrestrial Radio Access Network Node B, E-UTRAN Node B, evolved Node B, eNodeB, eNB, Next Generation Node B, gNode B, gNB, or the like) may be implemented in a macrocell, microcell, small cell, picocell, or the like, or any combination thereof.

The base stations <NUM> communicate with the UE <NUM> through the wireless links <NUM> and <NUM>, which may be implemented as any suitable type of wireless link. The wireless links <NUM> and <NUM> include control and data communication, such as downlink of data and control information communicated from the base stations <NUM> to the UE <NUM>, uplink of other data and control information communicated from the UE <NUM> to the base stations <NUM>, or both. The wireless links <NUM> may include one or more wireless links (e.g., radio links) or bearers implemented using any suitable communication protocol or standard, or combination of communication protocols or standards, such as 3rd Generation Partnership Project Long-Term Evolution (3GPP LTE), Fifth Generation New Radio (<NUM> NR), and so forth. Multiple wireless links <NUM> may be aggregated in a carrier aggregation to provide a higher data rate for the UE <NUM>. Multiple wireless links <NUM> from multiple base stations <NUM> may be configured for Coordinated Multipoint (CoMP) communication with the UE <NUM>, as well as dual connectivity, such as single-RAT LTE-LTE or NR-NR dual connectivity or Multi-Radio Access Technology (Multi-RAT) Dual Connectivity (MR-DC). MR-DC includes E-UTRA-NR Dual Connectivity (EN-DC), NG-RAN E-UTRA-NR Dual Connectivity (NGEN-DC), and NR-E-UTRA Dual Connectivity (NE-DC).

The base stations <NUM> are collectively a Radio Access Network <NUM> (e.g., RAN, Evolved Universal Terrestrial Radio Access Network, E-UTRAN, <NUM> NR RAN or NR RAN). The RANs <NUM> are illustrated as an NR RAN <NUM> and an E-UTRAN <NUM>. The base stations <NUM> and <NUM> in the NR RAN <NUM> are connected to a Fifth Generation Core <NUM> (5GC <NUM>) network. The base stations <NUM> and <NUM> in the E-UTRAN <NUM> are connected to an Evolved Packet Core <NUM> (EPC <NUM>). Optionally or additionally, the base station <NUM> may connect to both the 5GC <NUM> and EPC <NUM> networks.

The base stations <NUM> and <NUM> connect, at <NUM> and <NUM> respectively, to the 5GC <NUM> through an NG2 interface for control-plane signaling and using an NG3 interface for user-plane data communications. The base stations <NUM> and <NUM> connect, at <NUM> and <NUM> respectively, to the EPC <NUM> using an S1 interface for control-plane signaling and user-plane data communications. Optionally or additionally, if the base station <NUM> connects to the 5GC <NUM> and EPC <NUM> networks, the base station <NUM> connects to the 5GC <NUM> using an NG2 interface for control-plane signaling and through an NG3 interface for user-plane data communications, at <NUM>.

In addition to connections to core networks, the base stations <NUM> may communicate with each other. For example, the base stations <NUM> and <NUM> communicate through an Xn interface at <NUM> and the base stations <NUM> and <NUM> communicate through an X2 interface at <NUM>.

The 5GC <NUM> includes an Access and Mobility Management Function <NUM> (AMF <NUM>), which provides control-plane functions, such as registration and authentication of multiple UE <NUM>, authorization, and mobility management in the <NUM> NR network. The EPC <NUM> includes a Mobility Management Entity <NUM> (MME <NUM>), which provides control-plane functions, such as registration and authentication of multiple UE <NUM>, authorization, or mobility management in the E-UTRA network. The AMF <NUM> and the MME <NUM> communicate with the base stations <NUM> in the RANs <NUM> and also communicate with multiple UE <NUM>, using the base stations <NUM>.

<FIG> illustrates an example device diagram <NUM> of the user equipment <NUM> and the base stations <NUM>. The user equipment <NUM> and the base stations <NUM> may include additional functions and interfaces that are omitted from <FIG> for the sake of clarity. The user equipment <NUM> includes antennas <NUM>, a radio frequency front end <NUM> (RF front end <NUM>), an LTE transceiver <NUM>, and a <NUM> NR transceiver <NUM> for communicating with base stations <NUM> in the RAN <NUM>. The RF front end <NUM> of the user equipment <NUM> can couple or connect the LTE transceiver <NUM> and the <NUM> NR transceiver <NUM> to the antennas <NUM> to facilitate various types of wireless communication. The antennas <NUM> of the user equipment <NUM> may include an array of multiple antennas that are configured similarly to or differently from each other. The antennas <NUM> and the RF front end <NUM> can be tuned to, and/or be tunable to, one or more frequency bands defined by the 3GPP LTE and <NUM> NR communication standards and implemented by the LTE transceiver <NUM> and/or the <NUM> NR transceiver <NUM>. Additionally, the antennas <NUM>, the RF front end <NUM>, the LTE transceiver <NUM>, and/or the <NUM> NR transceiver <NUM> may be configured to support beamforming for the transmission and reception of communications with the base stations <NUM>. By way of example and not limitation, the antennas <NUM> and the RF front end <NUM> can be implemented for operation in sub-gigahertz bands, sub-<NUM> bands, and/or above <NUM> bands that are defined by the 3GPP LTE and <NUM> NR communication standards.

The user equipment <NUM> also includes processor(s) <NUM> and computer-readable storage media <NUM> (CRM <NUM>). The processor <NUM> may be a single core processor or a multiple core processor composed of a variety of materials, such as silicon, polysilicon, high-K dielectric, copper, and so on. The computer-readable storage media described herein excludes propagating signals. CRM <NUM> may include any suitable memory or storage device such as random-access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM (NVRAM), read-only memory (ROM), or Flash memory useable to store device data <NUM> of the user equipment <NUM>. The device data <NUM> includes user data, multimedia data, beamforming codebooks, applications, and/or an operating system of the user equipment <NUM>, which are executable by processor(s) <NUM> to enable user-plane communication, control-plane signaling, and user interaction with the user equipment <NUM>.

In some implementations, the CRM <NUM> may also include a handover manager <NUM>. The handover manager <NUM> can communicate with the antennas <NUM>, the RF front end <NUM>, the LTE transceiver <NUM>, and/or the <NUM> NR transceiver <NUM> to monitor the quality of the wireless communication links <NUM>. Based on this monitoring, the handover manager <NUM> can determine to trigger a handover.

The device diagram for the base stations <NUM>, shown in <FIG>, includes a single network node (e.g., a gNode B). The functionality of the base stations <NUM> may be distributed across multiple network nodes or devices and may be distributed in any fashion suitable to perform the functions described herein. The base stations <NUM> include antennas <NUM>, a radio frequency front end <NUM> (RF front end <NUM>), one or more LTE transceivers <NUM>, and/or one or more <NUM> NR transceivers <NUM> for communicating with the UE <NUM>. The RF front end <NUM> of the base stations <NUM> can couple or connect the LTE transceivers <NUM> and/or the <NUM> NR transceivers <NUM> to the antennas <NUM> to facilitate various types of wireless communication. The antennas <NUM> of the base stations <NUM> may include an array of multiple antennas that are configured similarly to or differently from each other. The antennas <NUM> and the RF front end <NUM> can be tuned to, and/or be tunable to, one or more frequency band defined by the 3GPP LTE and <NUM> NR communication standards, and implemented by the LTE transceivers <NUM> and one or more <NUM> NR transceivers <NUM>. Additionally, the antennas <NUM>, the RF front end <NUM>, the LTE transceivers <NUM>, and/or one or more <NUM> NR transceivers <NUM> may be configured to support beamforming, such as Massive-MIMO, for the transmission and reception of communications with the UE <NUM>.

The base stations <NUM> also include processor(s) <NUM> and computer-readable storage media <NUM> (CRM <NUM>). The processor <NUM> may be a single core processor or a multiple core processor composed of a variety of materials, such as silicon, polysilicon, high-K dielectric, copper, and so on. CRM <NUM> may include any suitable memory or storage device such as random-access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM (NVRAM), read-only memory (ROM), or Flash memory useable to store device data <NUM> of the base stations <NUM>. The device data <NUM> includes network scheduling data, radio resource management data, beamforming codebooks, applications, and/or an operating system of the base stations <NUM>, which are executable by processor(s) <NUM> to enable communication with the user equipment <NUM>.

CRM <NUM> also includes a base station manager <NUM>. Alternately or additionally, the base station manager <NUM> may be implemented in whole or part as hardware logic or circuitry integrated with or separate from other components of the base stations <NUM>. In at least some aspects, the base station manager <NUM> configures the LTE transceivers <NUM> and the <NUM> NR transceivers <NUM> for communication with the user equipment <NUM>, as well as communication with a core network, such as the core network <NUM>, and routing user-plane and control-plane data for joint communication. Additionally, the base station manager <NUM> may allocate air interface resources and schedule communications for the UE <NUM> and base stations <NUM> when the base station <NUM> is acting as a master base station for the base stations <NUM>.

The base stations <NUM> include an inter-base station interface <NUM>, such as an Xn and/or X2 interface, which the base station manager <NUM> configures to exchange user-plane and control-plane data between other base stations <NUM>, to manage the communication of the base stations <NUM> with the user equipment <NUM>. The base stations <NUM> include a core network interface <NUM> that the base station manager <NUM> configures to exchange user-plane and control-plane data with core network functions and/or entities.

<FIG> illustrates an example block diagram <NUM> of a wireless network stack model <NUM> (stack <NUM>). The stack <NUM> characterizes a communication system for the example environment <NUM>, in which various aspects of central unit-distributed unit architecture can be implemented. The stack <NUM> includes a user plane <NUM> and a control plane <NUM>. Upper layers of the user plane <NUM> and the control plane <NUM> share common lower layers in the stack <NUM>. Wireless devices, such as the UE <NUM> or the base station <NUM>, implement each layer as an entity for communication with another device using the protocols defined for the layer. For example, a UE <NUM> uses a Packet Data Convergence Protocol (PDCP) entity to communicate to a peer PDCP entity in a base station <NUM> using the PDCP.

The shared lower layers include a physical (PHY) layer <NUM>, a Media Access Control (MAC) layer <NUM>, a Radio Link Control (RLC) layer <NUM>, and a PDCP layer <NUM>. The PHY layer <NUM> provides hardware specifications for devices that communicate with each other. As such, the PHY layer <NUM> establishes how devices connect to each other, assists in managing how communication resources are shared among devices, and the like.

The MAC layer <NUM> specifies how data is transferred between devices. Generally, the MAC layer <NUM> provides a way in which data packets being transmitted are encoded and decoded into bits as part of a transmission protocol.

The RLC layer <NUM> provides data transfer services to higher layers in the stack <NUM>. Generally, the RLC layer <NUM> provides error correction, packet segmentation and reassembly, and management of data transfers in various modes, such as acknowledged, unacknowledged, or transparent modes.

The PDCP layer <NUM> provides data transfer services to higher layers in the stack <NUM>. Generally, the PDCP layer <NUM> provides transfer of user plane <NUM> and control plane <NUM> data, header compression, ciphering, and integrity protection.

Above the PDCP layer <NUM>, the stack splits into the user-plane <NUM> and the control-plane <NUM>. Layers of the user plane <NUM> include an optional Service Data Adaptation Protocol (SDAP) layer <NUM>, an Internet Protocol (IP) layer <NUM>, a Transmission Control Protocol/User Datagram Protocol (TCP/UDP) layer <NUM>, and an application layer <NUM>, which transfers data using the wireless link <NUM>. The optional SDAP layer <NUM> is present in <NUM> NR networks. The SDAP layer <NUM> maps a Quality of Service (QoS) flow for each data radio bearer and marks QoS flow identifiers in uplink and downlink data packets for each packet data session. The IP layer <NUM> specifies how the data from the application layer <NUM> is transferred to a destination node. The TCP/UDP layer <NUM> is used to verify that data packets intended to be transferred to the destination node reached the destination node, using either TCP or UDP for data transfers by the application layer <NUM>. In some implementations, the user plane <NUM> may also include a data services layer (not shown) that provides data transport services to transport application data, such as IP packets including web browsing content, video content, image content, audio content, or social media content.

The control plane <NUM> includes a Radio Resource Control (RRC) layer <NUM> and a Non-Access Stratum (NAS) layer <NUM>. The RRC layer <NUM> establishes and releases connections and radio bearers, broadcasts system information, or performs power control. The RRC layer <NUM> also controls a resource control state of the UE <NUM> and causes the UE <NUM> to perform operations according to the resource control state. Example resource control states include a connected state (e.g., an RRC connected state) or a disconnected state, such as an inactive state (e.g., an RRC inactive state) or an idle state (e.g., an RRC idle state). In general, if the UE <NUM> is in the connected state, the connection with the base station <NUM> is active. In the inactive state, the connection with the base station <NUM> is suspended. If the UE <NUM> is in the idle state, the connection with the base station <NUM> is released. Generally, the RRC layer <NUM> supports 3GPP access but does not support non-3GPP access (e.g., Wireless Local Area Network (WLAN) communications).

The NAS layer <NUM> provides support for mobility management (e.g., using a Fifth-Generation Mobility Management (5GMM) layer <NUM>) and packet data bearer contexts (e.g., using a Fifth-Generation Session Management (5GSM) layer <NUM>) between the UE <NUM> and entities or functions in the core network, such as the Access and Mobility Management Function <NUM> (AMF <NUM>) of the 5GC <NUM> or the like. The NAS layer <NUM> supports both 3GPP access and non-3GPP access.

In the UE <NUM>, each layer in both the user plane <NUM> and the control plane <NUM> of the stack <NUM> interacts with a corresponding peer layer or entity in the base station <NUM>, a core network entity or function, and/or a remote service, to support user applications and control operation of the UE <NUM> in the RAN <NUM>.

<FIG> illustrates an example system <NUM> generally related to a system including a distributed base station implemented using a central node-distributed node architecture in accordance with one or more aspects of central unit-distributed unit architecture. In the system <NUM>, the base station <NUM> is illustrated as a non-distributed base station and the base station <NUM> is illustrated as a distributed base station implemented using a central node-distributed node architecture. The base station <NUM> includes a gNB-Central Unit (gNB-CU) <NUM> and multiple gNB Distributed-Units (gNB-DU) <NUM>, illustrated as gNB-DU <NUM> and <NUM>. Although two gNB-DUs <NUM> are illustrated for the sake of clarity in <FIG>, any suitable number of gNB-DUs can be interfaces to the gNB-CU <NUM>.

The base stations <NUM> and <NUM> communicate through an Xn-C interface <NUM> for control-plane communications. In the base station <NUM>, implemented using the central node-distributed node architecture, the Xn-C interface <NUM> is terminated by the gNB-CU <NUM>. The base stations <NUM> and <NUM> connect, at <NUM> and <NUM> respectively, to the 5GC <NUM> through an NG interface for control-plane signaling.

In the central node-distributed node architecture, the gNB-CU <NUM> is a logical node hosting the RRC layer <NUM>, the SDAP layer <NUM>, and the PDCP layer <NUM> entities of the gNB or the RRC layer <NUM> and the PDCP layer <NUM> entities of an en-gNB (e.g., a gNB connected to an evolved packet core) that controls the operation of one or more gNB-DUs <NUM>. The gNB-CU <NUM> includes an F1 interface to communicate with the gNB-DUs <NUM>, shown at <NUM> and <NUM>. Although described as logical nodes, the gNB-CU <NUM> and/or the gNB-DUs <NUM> devices may include any suitable components described with respect to the base station <NUM> in <FIG>.

The gNB-DUs <NUM> are logical nodes hosting the RLC layer <NUM>, MAC layer <NUM>, and PHY layer <NUM> protocols of the gNB or en-gNB. The operation of the gNB-DUs <NUM> is partly controlled by gNB-CU <NUM>. One gNB-CU <NUM> supports one or multiple cells in the RAN <NUM>, but a single cell is only supported by a single gNB-DU <NUM>. Each gNB-DU <NUM> terminates the F1 interface with the gNB-CU <NUM> that serves as the central unit for that gNB-DU <NUM>. Each gNB-DU <NUM> connects operationally to only one gNB-CU <NUM>. Alternatively or optionally, for resiliency in network operations, a gNB-DU <NUM> may be connected to multiple gNB-CUs <NUM> using any suitable implementation, for example, network interconnection hardware and/or software that provides failover for a gNB-DU <NUM> to backup gNB-CU <NUM> if a primary gNB-CU <NUM> fails or becomes unavailable to the gNB-DU <NUM>.

In another example of the central node-distributed node architecture, for E-UTRA-NR dual connectivity (EN-DC), the gNB-CU <NUM> terminates the S1-U and X2-C interfaces for the base station <NUM> (e.g., an en-gNB). The gNB-CU <NUM> and connected gNB-DUs <NUM> are only visible to other base stations <NUM> and the 5GC <NUM> or EPC <NUM> as a gNB.

<FIG> illustrates an example of user equipment (UE) context establishment in a base station <NUM>, generally related to a UE Context Setup procedure in accordance with one or more aspects of central unit-distributed unit architecture. The purpose of the UE Context Setup procedure is to establish the UE Context including a signaling radio bearer (SRB), a data radio bearer (DRB), or the like for a UE <NUM> and uses UE-associated signaling.

The gNB-CU <NUM> initiates the UE Context Setup procedure by sending a UE Context Setup Request message <NUM> to the gNB-DU <NUM>. If the gNB-DU <NUM> successfully establishes the UE context, the gNB-DU <NUM> replies to the gNB-CU <NUM> with UE Context Setup Response <NUM>. If the gNB-DU <NUM> fails to successfully establish the UE context, such as failing to establish the DRB and/or the SRB, the gNB-DU <NUM> includes a cause value in the UE Context Setup Response <NUM> to enable the gNB-CU <NUM> to determine the reason for the failure to establish the UE context.

For example, CU to DU RRC Information and DU to CU RRC Information are used to exchange RRC information over the F1 interface during UE context management procedures. CU to DU RRC Information include the UE-CapabilityRAT-ContainerList IE and the CG-ConfigInfo IE. DU to CU RRC Information include the CellGroupConfig IE. In EN-DC, the gNB-CU receives the UE-CapabilityRAT-ContainerList IE and the CG-ConfigInfo IE from the master eNB (MeNB) and forwards those IEs to the gNB-DU as RRC containers, using the F1 interface. Also, in EN-DC, the gNB-DU generates the CellGroupConfig IE as defined in 3GPP TS <NUM> and sends it to the gNB-CU in the CU to DU RRC Information, using the F1 interface. The gNB-CU further generates the secondary cell group (SCG) radio configuration (e.g., CG-Config message) based on the received information from the gNB-DU. By way of reference, the UE-CapabilityRAT-ContainerList IE is defined in 3GPP TS <NUM> section <NUM>. <NUM>, the CG-Config message (which is the renamed SCG-Config message) and CG-ConfigInfo message (which is the renamed SCG-ConfigInfo message) are defined in 3GPP TS <NUM> section <NUM>. <NUM>, and the CellGroupConfig IE is defined in 3GPP TS <NUM> section <NUM>.

In E-UTRA-NR dual connectivity (EN-DC), a CellGroupConfig Information Element (IE) is used to configure a master cell group (MCG) and/or a secondary cell group (SCG) to the UE. For example, in EN-DC, the master cell group is E-UTRA and the secondary cell group is <NUM> NR. A cell group includes a MAC layer <NUM> entity, a set of logical channels with associated RLC layer <NUM> entities, a primary cell (SpCell), and one or more secondary cells (SCells).

A master base station <NUM> (MeNB) that is managing dual connectivity for the UE <NUM> can send a configuration message (e.g., a SCG-ConfigInfo message, a CG-ConfigInfo message, or a CellGroupConfigInfo message) to a secondary base station (SgNB) in the dual-connectivity communication with the UE <NUM> to perform actions such as establishing, modifying, or releasing an SCG. The message may include additional information, such as information to assist the SgNB to set a secondary cell group (SCG) configuration. In the central node-distributed node architecture, the gNB-CU <NUM> can send the message to a gNB-DU <NUM> to request the gNB-DU <NUM> to perform any of these actions (establish, modify, or release an SCG).

When EN-DC communication is established between the RAN <NUM> and the UE <NUM>, a master base station for EN-DC (MeNB) is an E-UTRA base station, and a base station in the Secondary Cell Group (SCG) is a <NUM> NR base station (SgNB). In preparation for the handover of the UE <NUM> to a target MeNB with secondary node change, the source MeNB sends a Handover Preparation Information message (e.g., a Handover Request message including the HandoverPreparationInformation message) to the target MeNB that includes UE capability information and the target MeNB adds a target SgNB using an SgNB Addition Preparation procedure. In the central node-distributed node architecture, the target SgNB-CU <NUM> sends the Handover Preparation Information message (e.g., HandoverPreparationInformation message) to the target SgNB-DU <NUM>.

In response to receiving the Handover Preparation Information message, the target MeNB generates an RRC Reconfiguration (e.g., RRCConnectionReconfiguration) message to perform the handover. The RRCConnectionReconfiguration message includes MCG and SCG configuration. The target MeNB sends the RRC Reconfiguration message to the source MeNB in a Handover Request Acknowledge message.

In one example, the target MeNB does not understand the MCG portion of the source RRC configuration but the target SgNB understands the SCG part of the source RRC configuration. In this example, the MeNB (master node, MN) decides to use full configuration and sets an LTE fullconfig flag in an LTE RRCConnectionReconfiguration message to release both the MCG and the SCG configuration. Additionally, the MeNB does not include a current dedicated SCG configuration (e.g., the sourceConfigSCG in an sgNB addition request). In other words, for the SgNB Addition Request to be sent to the SgNB, the target MeNB generates a configuration information (e.g., CG-ConfigInfo) which does not include the received current dedicated SCG configuration from the source MeNB.

In another example, the target MeNB understands the MCG part of the source RRC configuration but the target SgNB does not understand the SCG part of the RRC configuration. In this example, the SN indicates to the MN that it has applied full SCG configuration and indicates impacted bearers in a drb-toReleaseList. The MN sets an en-DC-release flag to TRUE in the LTE RRCConnectionReconfiguration message sent to the UE <NUM>.

Upon network role transition there is a need to exchange configurations or signaling from the source node to target node to help the target node prepare follow-up configurations. There are two Multi-RAT Dual Connectivity operation-related aspects: Secondary Node Change (MN/SN initiated) and Inter-Master Node handover with or without a Secondary Node change.

In the Secondary Node Change (MN or SN initiated) aspect, the Master node (eNB or gNB) sends a configuration message (e.g., an SgNB Addition Request) that includes configuration information (e.g., the SCG-ConfigInfo message, the CellGroupConfigInfo message, or the CG-ConfigInfo message) to the CU of the target secondary base station. The configuration information further contains a current dedicated SCG configuration (e.g., the sourceConfigSCG IE). The CU of target secondary base station decides whether to apply a full configuration or a delta configuration based on the configuration information received in the configuration message.

In one aspect, if the CU decides to perform the delta configuration, the CU sends a UE Context Setup Request message that includes a current dedicated SCG configuration (e.g., the sourceConfigSCG IE), included in the received configuration information, to the corresponding DU(s) using the F1 interface. After receiving the UE Context Setup Request message from the CU, each of the DU(s) generates the CellGroupConfig IE based on the received current dedicated SCG configuration (e.g., sourceConfigSCG IE), included in the received configuration information, and sends it in a UE Context Setup Response message to the CU using the F1 interface. The CU further generates the SCG radio configuration (e.g., CG-Config message) based on the received information from the DU(s). The CU of target Secondary node sends an SgNB Addition Request Acknowledge message that includes the configuration (e.g., CG-Config message) to the Master node.

In another example, if the CU decides to perform a full configuration, the CU does not include the current dedicated SCG configuration (e.g., the sourceConfigSCG IE) from the received configuration information to be included in the UE Context Setup Request message to the corresponding DU(s) using the F1 interface. This can be achieved by the CU generating a configuration information according to the received configuration information except the current dedicated SCG configuration, or that the CU takes the received configuration information but removes the current dedicated SCG configuration from it. After receiving the UE Context Setup Request message from the CU, each of the DU(s) generates the CellGroupConfig IE and sends it to the CU using the F1 interface.

The CU further generates the SCG radio configuration (e.g., CG-Config message) based on the received information from the DU(s). The CU of target Secondary node sends an SgNB Addition Request Acknowledge message that includes the configuration (e.g., CG-Config message) to the Master node. After receiving the message from CU of target Secondary node, the Master node sends an RRC message (e.g., an RRCReconfiguration message or an RRCConnectionReconfiguration message) to the UE <NUM> that includes the configuration information from target Secondary node.

In another aspect, an inter-master node handover is configured with or without a secondary node change. For example, the source Master node sends a Handover Request message to the target Master node. The target Master node sends an SgNB Addition Request message that includes the configuration information (e.g., the SCG-ConfigInfo message, the CellGroupConfigInfo message, or the CG-ConfigInfo message) to the CU of target Secondary node. The CU of target Secondary node decides whether to apply the full configuration or the delta configuration based on the received configuration information.

For example, assuming that the CU determines to perform the delta configuration, the CU sends a UE Context Setup Request message that includes the current dedicated SCG configuration (e.g., the sourceConfigSCG IE) in the received configuration information to the corresponding DU(s) using the F1 interface.

After receiving the message from the CU, the DU(s) generates the CellGroupConfig IE based on the received current dedicated SCG configuration (e.g., sourceConfigSCG IE) in the received configuration information and sends it in the UE Context Setup Response message to the CU using the F1 interface. The CU further generates the SCG radio configuration (e.g., CG-Config message) based on the received information from the DU(s). The CU of target Secondary node sends an SgNB Addition Request Acknowledge message that includes the SCG radio configuration (e.g., CG-Config message) to the Master node.

In another example, the CU determines to perform the full configuration. The CU does not include the current dedicated SCG configuration (e.g., the sourceConfigSCG IE) from the received configuration information in the UE Context Setup Request message to the corresponding DU(s) using the F1 interface.

After receiving the message from the CU, the DU(s) generates the CellGroupConfig IE and sends it to the CU using the F1 interface. The CU further generates the SCG radio configuration (e.g., CG-Config message) based on the received information from the DU(s). The CU of target Secondary node sends an SgNB Addition Request Acknowledge message including the SCG radio configuration (e.g., CG-Config message) to the Master node. After receiving the message from the CU of target Secondary node, the Master node sends an RRC message (e.g., an RRCReconfiguration message or an RRCConnectionReconfiguration message), including the configuration information from target Secondary node, to the UE.

In a further aspect, the source node sends a Handover Request message that includes the HandoverPreparationInformation message to the CU of target node. The CU of the target node decides whether to apply a full configuration or a delta configuration based on the received configuration information used in the source node (e.g., the sourceConfig IE).

For example, if the CU decides to perform the delta configuration, the CU sends a UE Context Setup Request message that includes a configuration information used in the source node (e.g., the sourceConfig IE) in the received HandoverPreparationInformation message to the corresponding DU(s) using the F1 interface. After receiving the message from the CU, the DU(s) generates a CellGroupConfig IE based on the received configuration information used in the source node (e.g., the sourceConfig IE) and sends it in the UE Context Setup Response to the CU using the F1 interface.

In another example, if the CU decides to perform a full configuration, the CU does not include the configuration information used in the source node (e.g., the sourceConfig IE) from the received HandoverPreparationInformation message in the UE Context Setup Request message to the corresponding DU(s) using the F1 interface. This can be achieved by the CU to generate a HandoverPreparationInformation message according to the received HandoverPreparation-Information message except the configuration information used in the source node, or that the CU takes the received HandoverPreparationInformation message but removes the configuration information used in the source node from it. After receiving the message from the CU, the DU(s) generates the CellGroupConfig IE and sends it to the CU using the F1 interface.

The CU of the target node further generates the HandoverCommand message that includes the received information from the DU(s) and sends a Handover Request Acknowledge message to the Master node. After receiving the HandoverCommand message from CU of the target node, the source node sends an RRC message (e.g., an RRCReconfiguration message or an RRCConnectionReconfiguration message), that includes the configuration information from target node, to the UE <NUM>.

Example methods <NUM> and <NUM> are described with reference to <FIG> and <FIG> in accordance with one or more aspects of central unit-distributed unit architecture. The order in which the method blocks are described are not intended to be construed as a limitation, and any number of the described method blocks can be skipped or combined in any order to implement a method or an alternate method. Generally, any of the components, modules, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Some operations of the example methods may be described in the general context of executable instructions stored on computer-readable storage memory that is local and/or remote to a computer processing system, and implementations can include software applications, programs, functions, and the like. Alternatively or in addition, any of the functionality described herein can be performed, at least in part, by one or more hardware logic components, such as, and without limitation, Field-programmable Gate Arrays (FPGAs), Application-specific Integrated Circuits (ASICs), Application-specific Standard Products (ASSPs), System-on-a-chip systems (SoCs), Complex Programmable Logic Devices (CPLDs), and the like.

<FIG> illustrates example method(s) <NUM> of central unit-distributed unit architecture as generally related to delta and full configuration for secondary cell group configuration. At block <NUM>, a CU (e.g., the gNB-CU <NUM>) of a base station (e.g., the base station <NUM>) receives a configuration message (e.g., the an SgNB Addition Request message) including configuration information (e.g., an SCG-ConfigInfo message, a CellGroupConfigInfo message, or a CG-ConfigInfo message) from a master node of a dual-connectivity communication with a UE (e.g., UE <NUM>). The configuration information further contains a Current Dedicated SCG Configuration (e.g., sourceConfigSCG IE). The CU includes the configuration information in a CU to DU RRC Information IE for a UE Context Setup Request Message.

At block <NUM>, the CU determines whether to use a delta configuration or a full configuration. This can be based on the received configuration information (e.g., SCG-ConfigInfo message, CellGroupConfigInfo message, or CG-ConfigInfo message). If the CU determines to use a delta configuration, at block <NUM>, the CU includes the Current Dedicated SCG Configuration in the configuration information for the UE Context Setup Request Message. If the CU determines to use a full configuration at block <NUM>, the CU does not include the Current Dedicated SCG Configuration from the configuration information for the UE Context Setup Request Message. This can be achieved by the CU generating a configuration information according to the received configuration information except the current dedicated SCG configuration, or that the CU takes the received configuration information but removes the current dedicated SCG configuration from it.

At block <NUM>, the CU generates the User Equipment (UE) Context Setup Request message. At block <NUM>, the CU sends the UE Context message to a DU (e.g., the gNB-DU <NUM>) of the base station. At block <NUM>, the CU receives cell-group configuration (CellGroupConfig IE) generated by the DU.

At block <NUM>, the CU generates a secondary node configuration using the received cell-group configuration and, at block <NUM> the CU sends the secondary-cell-group configuration (e.g., CG-Config message) in a configuration response message to the master node.

<FIG> illustrates example method(s) <NUM> of central unit-distributed unit architecture as generally related to delta and full configuration for a master base station handover. At block <NUM>, a CU (e.g., the gNB-CU <NUM>) of a target base station (e.g., the base station <NUM>) receives a Handover Request message including configuration information (e.g., HandoverPreparationInformation message) from a source base station. The configuration information further contains a Current Configuration (e.g., sourceConfig IE). The CU includes the configuration information in a CU to DU RRC Information IE for a UE Context Setup Request Message.

At block <NUM>, the CU determines whether to use a delta configuration or a full configuration. This can be based on the received current configuration information (e.g., sourceConfig IE). If the CU determines to use a delta configuration, at block <NUM>, the CU includes the Current Configuration information in the configuration information for the UE Context Setup Request Message. If the CU determines to use a full configuration at block <NUM>, the CU does not include the Current Configuration from the configuration information for the UE Context Setup Request Message. This can be achieved by the CU to generate a HandoverPreparationInformation message according to the received HandoverPreparation-Information message except the configuration information used in the source node, or that the CU takes the received HandoverPreparationInformation message but removes the configuration information used in the source node from it.

At block <NUM>, the CU generates a Handover Command using the received cell-group configuration and, at block <NUM> the CU sends the Handover Command to the source base station in a Handover Request Acknowledge message.

Claim 1:
A method for determining a user equipment, UE, context by a central unit, CU, of a base station engaged as a secondary base station in dual-connectivity communication with a first UE, the method comprising:
receiving, at the CU of the base station from a master node of the dual-connectivity communication, a first configuration message including a first configuration information;
based on the received first configuration information, determining a first configuration type;
based on the determined first configuration type, generating a first UE Context Setup Request message for the first UE;
sending, by the CU, the generated first UE Context Setup Request message to a Distributed Unit, DU,
of the base station, the generated first UE Context Setup Request effective to direct the DU to generate a first cell-group configuration;
receiving the first generated cell-group configuration;
generating a secondary-cell-group configuration using the received first cell-group configuration; and
sending the secondary-cell-group configuration in a configuration response message to the master node to configure the first UE.