MANAGING SIDELINK COMMUNICATION

A method of obtaining sidelink configuration in a CU of a distributed base station includes receiving sidelink information related to sidelink communications at a UE operating in a first cell (1602); initiating handover procedure or a cell change procedure so that the UE utilizes a radio resource on a second cell associated with a target node, the target node corresponding to a DU of the distributed base station or another base station (1604); transmitting, to the target node, a request to set up a context for the UE, the request including the sidelink information (1606); and receiving, from the target node, a response to the request, the response including a sidelink configuration for the UE (1608).

FIELD OF THE DISCLOSURE

This disclosure relates generally to wireless communications and, more particularly, to sidelink communication operations.

BACKGROUND

In telecommunication systems, the Packet Data Convergence Protocol (PDCP) sublayer of the radio protocol stack provides services such as transfer of user-plane data, ciphering, integrity protection, etc. For example, the PDCP layer defined for the Evolved Universal Terrestrial Radio Access (EUTRA) radio interface (see 3GPP specification TS 36.323) and New Radio (NR) (see 3GPP specification TS 38.323) provides sequencing of protocol data units (PDUs) in the uplink direction (from a user device, also known as a user equipment (UE), to a base station) as well as in the downlink direction (from the base station to the UE). Further, the PDCP sublayer provides services for signaling radio bearers (SRBs) to the Radio Resource Control (RRC) sublayer. The PDCP sublayer also provides services for data radio bearers (DRBs) to a Service Data Adaptation Protocol (SDAP) sublayer or a protocol layer such as an Internet Protocol (IP) layer, an Ethernet protocol layer, and an Internet Control Message Protocol (ICMP) layer. Generally speaking, the UE and a base station can use SRBs to exchange RRC messages as well as non-access stratum (NAS) messages, and can use DRBs to transport data on a user plane.

UEs can use several types of SRBs and DRBs. When operating in dual connectivity (DC), the cells associated with the base station operating as the master node (MN) define a master cell group (MCG), and the cells associated with the base station operating as the secondary node (SN) define the secondary cell group (SCG). So-called SRB1 resources carry RRC messages, which in some cases include NAS messages over the dedicated control channel (DCCH), and SRB2 resources support RRC messages that include logged measurement information or NAS messages, also over the DCCH but with lower priority than SRB1 resources. More generally, SRB1 and SRB2 resources allow the UE and the MN to exchange RRC messages related to the MN and embed RRC messages related to the SN, and also can be referred to as MCG SRBs. SRB3 resources allow the UE and the SN to exchange RRC messages related to the SN, and can be referred to as SCG SRBs. Split SRBs allow the UE to exchange RRC messages directly with the MN via lower layer resources of the MN and the SN. Further, DRBs terminated at the MN and using the lower-layer resources of only the MN can be referred as MCG DRBs, DRBs terminated at the SN and using the lower-layer resources of only the SN can be referred as SCG DRBs, and DRBs terminated at the MCG but using the lower-layer resources of the MN, the SN, or both the MN and the SN can be referred to as split DRBs.

The UE in some scenarios can concurrently utilize resources of multiple nodes (e.g., base stations or components of a distributed base station) of a radio access network (RAN), interconnected by a backhaul. When these network nodes support different radio access technologies (RATs), this type of connectivity is referred to as Multi-Radio Dual Connectivity (MR-DC). When a UE operates in MR-DC, one base station operates as the MN that covers a primary cell (PCell), and the other base station operates as the SN that covers a primary secondary cell (PSCell). The UE communicates with the MN (via the PCell) and the SN (via the PSCell). In other scenarios, the UE utilizes resources of one base station at a time. One base station and/or the UE determines that the UE should establish a radio connection with another base station. For example, one base station can determine to hand the UE over to the second base station, and initiate a handover procedure. The UE in other scenarios can concurrently utilize resources of a RAN node (e.g., a single base station or a component of a distributed base station), interconnected by a backhaul.

In some cases, a UE can communicate with another UE using a so-called sidelink, or a radio link that directly interconnects a pair of UEs without a base station. Sidelink communications can conform for example to vehicle-to-everything (V2X) sidelink communication protocols specified in 3GPP specification TS 38.300 v16.2.0 (2020 July) section 16.9. Although the UEs exchange sidelink data directly, a base station can allocate, or facilitate allocation of, radio resources for sidelink communication in a licensed spectrum, unlicensed spectrum (e.g., within WLAN frequencies which the base station announces via a system information broadcast). Moreover, the licensed spectrum can include Citizens Broadband Radio Service (CBRS) frequencies in some geographic regions or licensed shared access (LSA) frequencies in other geographic regions.

Currently, it is not clear how a distributed base station can support certain operations related to sidelink configuration. For example, when a central unit (CU) determines that a UE should handover to another cell associated with a new distributed unit (DU) or a new base station, and when the UE has previously provided information for sidelink communications (e.g., one or more frequencies the UE prefers), the CU cannot always properly support these two procedures. More generally, a CU cannot always properly support a handover, a cell change, or DC operations concurrently with sidelink configurations.

Further, it is not clear how CU should support sidelink configurations where different cells involved in DC, handover, cell change, etc. support different radio access technologies (RATs).

SUMMARY

A distributed base station of this disclosure receives, at a CU from a DU, UE information relevant to sidelink communications, and determines that the UE should utilize radio resources of another DU or base station, or a “target node” more generally. The CU can base this determination on a concurrent handover procedure or a cell change procedure, for example, or on the frequency which the UE prefers for sidelink communications. The CU provides the UE information to the target node along with the information related to the procedure: for example, the CU provides information relevant to handover along with the UE information for sidelink communications in a manner than allows the UE to generate a configuration in view of both factors.

One example embodiment of these techniques is a method of obtaining sidelink configuration in a CU of a distributed base station. The method includes receiving sidelink information related to sidelink communications at a UE operating in a first cell; determining that the UE should utilize a radio resource on a second cell associated with a target node, the target node corresponding to a DU of the distributed base station or another base station; transmitting the sidelink information to the target node; and receiving, from the target node, a sidelink configuration for the UE.

Another example embodiment of these techniques is a method of generating sidelink configuration in a DU of a distributed base station. The method includes receiving, from a CU of the distributed base station, sidelink information related to sidelink communications at a UE operating in a first cell; generating the sidelink configuration for the UE based on the sidelink information; and transmitting the sidelink configuration to the CU.

DETAILED DESCRIPTION OF THE DRAWINGS

FIG.1Adepicts an example wireless communication system100that can implement the sidelink configuration and management techniques of this disclosure. The wireless communication system100includes UEs102,103, and base stations104,106A,106B that are connected to a core network (CN)110. The base stations104,106A,106B can be any suitable type, or types, of base stations, such as an evolved node B (eNB), a next-generation eNB (ng-eNB), or a 5G Node B (gNB), for example. As a more specific example, the base station104can be an eNB or a gNB, and the base stations106A and106B can be gNBs. The base stations form a radio access network (RAN)105.

The base station104supports a cell124, the base station106A supports a cell126A, and the base station106B supports a cell126B. The base station106A may additionally support a cell125A. The cell124partially overlaps with both of cells126A and126B, such that the UE102can be in range to communicate with base station104while simultaneously being in range to communicate with base station106A or106B (or in range to detect or measure the signal from both base stations106A or106B, etc.). The overlap can make it possible for the UE102to hand over between cells (e.g., from cell124to cell126A or126B) or base stations (e.g., from base station104to base station106A or base station106B) before the UE102experiences radio link failure, for example. Moreover, the overlap allows the various dual connectivity (DC) scenarios discussed below. For example, the UE102can communicate in DC with the base station104(operating as an MN) and the base station106A (operating as an SN) and, upon completing a handover, can communicate with the base station106B (operating as an MN). As another example, the UE102can communicate in DC with the base station104(operating as an MN) and the base station106A (operating as an SN) and, upon completing an SN change, can communicate with the base station104(operating as an MN) and the base station106B (operating as an SN).

More particularly, when the UE102is in DC with the base station104and the base station106A, the base station104operates as a master eNB (MeNB), a master ng-eNB (Mng-eNB), or a master gNB (MgNB), and the base station106A operates as a secondary gNB (SgNB) or a secondary ng-eNB (Sng-eNB). In implementations and scenarios where the UE102is in SC with the base station104but is capable of operating in DC, the base station104operates as an MeNB, an Mng-eNB or an MgNB, and the base station106A operates as a candidate SgNB (C-SgNB) or a candidate Sng-eNB (C-Sng-eNB). Although various scenarios are described below in which the base station104operates as an MN and the base station106A (or106B) operates as an SN or T-SN, any of the base stations104,106A,106B generally can operate as an MN, an SN or a T-SN in different scenarios. Thus, in some implementations, the base station104, the base station106A, and the base station106B can implement similar sets of functions and each support MN, SN, and T-SN operations.

In operation, the UE102can use a radio bearer (e.g., a DRB or an SRB) that at different times terminates at an MN (e.g., the base station104) or an SN (e.g., the base station106A). For example, after handover to the base station106B, the UE102can use a radio bearer (e.g., a DRB or an SRB) that at different times terminates at the base station106B. The UE102can apply one or more security keys when communicating on the radio bearer, in the uplink (from the UE102to a base station) and/or downlink (from a base station to the UE102) direction.

In some scenarios, the UE102performs sidelink communications (e.g., for V2X or a proximity service) with the UE103via a sidelink128. The sidelink communication can be NR sidelink communication and/or V2X sidelink communication. When the UE102is within the area of coverage of the RAN105, one or more base stations of the RAN105can configure and control the sidelink communication via dedicated signaling (e.g., an RRC reconfiguration message) or broadcast system information (e.g., system information block(s)).

When the UE102operates in the RRC_CONNECTED state, the UE102can send a SidelinkUEInformation message to the RAN105to request or release sidelink resources for the sidelink communication and/or report QoS information for each destination in the sidelink communication. For example, the RAN105provides RRCReconfiguration to the UE102in order to provide the UE with dedicated sidelink configuration after the RAN105receives the SidelinkUEInformation message. The RRCReconfiguration can include a sidelink radio bearer (SLRB) configuration for NR sidelink communication as well as sidelink scheduling configuration or resource pool configuration. If UE102has received an SLRB configuration via a system information broadcast, the UE102should continue using the configuration to perform sidelink data transmissions and receptions until the UE102receives a new configuration via the RRCReconfiguration. During handover, the UE102performs sidelink communications (e.g., transmission and/or reception) based on configuration of the exceptional transmission resource pool or configured sidelink grant Type1and/or reception resource pool of a target cell as provided in a handover command message.

The base station104includes processing hardware130, which can include one or more general-purpose processors (e.g., central processing units (CPUs) and a computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processor(s), and/or special-purpose processing units. The processing hardware130in the example ofFIG.1Aimplements a base station sidelink controller132configured to manage or control sidelink configurations and procedures. For example, the base station sidelink controller132can be configured to support RRC messaging associated with sidelink configuration and procedures. Further, when the base station104is distributed (seeFIG.1Bbelow), the base station sidelink controller132can include a CU component133A operating in the CU and a respective DU component133B operating in each of the DUs. The CU component133A and the DU component133B can communicate via a dedicated interface illustrated inFIG.1B.

The processing hardware130also includes a base station Uu link controller134that is configured to manage or control a Uu link (i.e., a link between the UE102and the base station104). For example, the base station Uu link controller134can be configured to support RRC messaging associated with RRC procedures for managing or controlling radio resources for the UE102to communicate with the base station104, and/or to support the necessary operations when the base station104operates as an MN, as discussed below.

The base station106A includes processing hardware140, which can include one or more general-purpose processors (e.g., CPUs) and a computer-readable memory storing machine-readable instructions executable on the general-purpose processor(s), and/or special-purpose processing units. The processing hardware140in the example implementation inFIG.1Aincludes a base station sidelink controller142that is configured to manage or control sidelink configurations and procedures. For example, the base station sidelink controller142can be configured to support RRC messaging associated with sidelink configuration and procedures. The processing hardware140includes a base station Uu link controller144that is configured to manage or control a Uu link (i.e., a link between the UE102and the base station104). For example, the base station Uu link controller144can be configured to support RRC messaging associated with RRC procedures for managing or controlling radio resources for the UE102to communicate with the base station104, and/or to support the necessary operations when the base station104operates as an MN or SN, as discussed below.

The UE102includes processing hardware150, which can include one or more general-purpose processors (e.g., CPUs) and a computer-readable memory storing machine-readable instructions executable on the general-purpose processor(s), and/or special-purpose processing units. The processing hardware150in the example implementation inFIG.1Aincludes a UE sidelink controller152that is configured to manage or control sidelink configurations and procedures. For example, the UE sidelink controller152can be configured to support RRC messaging associated with sidelink configuration and procedures. The processing hardware150includes a UE Uu link controller154that is configured to manage or control a Uu link (i.e., a link between the UE102and the RAN105) according configuration parameters received from the RAN105. For example, the UE Uu link controller152can be configured to support RRC messaging associated with RRC procedures for managing or controlling radio resources in accordance with any of the implementations discussed below.

The CN110can be an evolved packet core (EPC)111or a fifth-generation core (5GC)160, both of which are depicted inFIG.1A. The base station104can be an eNB supporting an Si interface for communicating with the EPC111, an ng-eNB supporting an NG interface for communicating with the 5GC160, or as a gNB that supports the NR radio interface as well as an NG interface for communicating with the 5GC160. The base station106A can be an EN-DC gNB (en-gNB) with an Si interface to the EPC111, an en-gNB that does not connect to the EPC111, a gNB that supports the NR radio interface and an NG interface to the 5GC160, or a ng-eNB that supports an EUTRA radio interface and an NG interface to the 5GC160. To directly exchange messages with each other during the scenarios discussed below, the base stations104,106A, and106B can support an X2 or Xn interface.

Among other components, the EPC111can include a Serving Gateway (SGW)112, a Mobility Management Entity (MME)114and a Packet Data Network (PDN) Gateway (PGW)116. The S-GW112and/or PGW116is/are generally configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., and the MME114is configured to manage authentication, registration, paging, and other related functions. The 5GC160includes a User Plane Function (UPF)162and an Access and Mobility Management (AMF)164, and/or Session Management Function (SMF)166. The UPF162is generally configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., the AMF164is configured to manage authentication, registration, paging, and other related functions, and the SMF166is configured to manage PDU sessions.

Generally, the wireless communication network100can include any suitable number of base stations supporting NR cells and/or EUTRA cells. More particularly, the EPC111or the 5GC160can be connected to any suitable number of base stations supporting NR cells and/or EUTRA cells. Although the examples below refer specifically to specific CN types (EPC, 5GC) and RAT types (5G NR and EUTRA), in general the techniques of this disclosure can also apply to other suitable radio access and/or core network technologies such as sixth generation (6G) radio access and/or 6G core network or 5G NR-6G DC, for example.

In different configurations or scenarios of the wireless communication system100, the base station104can operate as an MeNB, an Mng-eNB, or an MgNB, the base station106B can operate as an MeNB, an Mng-eNB, an MgNB, an SgNB, or an Sng-eNB, and the base station106A can operate as an SgNB or an Sng-eNB. The UE102can communicate with the base station104and the base station106A or106B via the same radio access technology (RAT), such as EUTRA or NR, or via different RATs.

When the base station104is an MeNB and the base station106A is an SgNB, the UE102can be in EUTRA-NR DC (EN-DC) with the MeNB104and the SgNB106A. When the base station104is an Mng-eNB and the base station106A is an SgNB, the UE102can be in next generation (NG) EUTRA-NR DC (NGEN-DC) with the Mng-eNB104and the SgNB106A. When the base station104is an MgNB and the base station106A is an SgNB, the UE102can be in NR-NR DC (NR-DC) with the MgNB104and the SgNB106A. When the base station104is an MgNB and the base station106A is a Sng-eNB, the UE102can be in NR-EUTRA DC (NE-DC) with the MgNB104and the Sng-eNB106A.

FIG.1Bdepicts an example distributed implementation of any one or more of the base stations104,106A,106B. In this implementation, the base station104,106A, or106B includes a centralized unit (CU)172and one or more distributed units (DUs)174. The CU172and the DU(s)174can communicate via a dedicated interface176(e.g., Fs-U for user plane, Fs-C for control plane).

The CU172includes processing hardware, such as one or more general-purpose processors (e.g., CPUs) and a computer-readable memory storing machine-readable instructions executable on the general-purpose processor(s), and/or special-purpose processing units. The CU172can include the processing hardware130or140ofFIG.1A. In an example implementation, the processing hardware of the CU172includes the CU module133A of the base station sidelink controller132.

Each of the DUs174also includes processing hardware that can include one or more general-purpose processors (e.g., CPUs) and computer-readable memory storing machine-readable instructions executable on the one or more general-purpose processors, and/or special-purpose processing units. For example, the processing hardware can include a medium access control (MAC) controller configured to manage or control one or more MAC operations or procedures (e.g., a random access procedure), and a radio link control (RLC) controller configured to manage or control one or more RLC operations or procedures when the base station (e.g., base station106A) operates as a MN or an SN. The process hardware can also include a physical layer controller configured to manage or control one or more physical layer operations or procedures. In an example implementation, the processing hardware of each DU174includes the DU module133B of the base station sidelink controller132.

FIG.2Aillustrates, in a simplified manner, an example protocol stack200according to which the UE102can communicate with an eNB/ng-eNB or a gNB (e.g., one or more of the base stations104,106A,106B).

In the example stack200, a physical layer (PHY)202A of EUTRA provides transport channels to the EUTRA MAC sublayer204A, which in turn provides logical channels to the EUTRA RLC sublayer206A. The EUTRA RLC sublayer206A in turn provides RLC channels to the EUTRA PDCP sublayer208and, in some cases, to the NR PDCP sublayer210. Similarly, the NR PHY202B provides transport channels to the NR MAC sublayer204B, which in turn provides logical channels to the NR RLC sublayer206B. The NR RLC sublayer206B in turn provides RLC channels to the NR PDCP sublayer210. The UE102, in some implementations, supports both the EUTRA and the NR stack as shown inFIG.2A, to support handover between EUTRA and NR base stations and/or to support DC over EUTRA and NR interfaces. Further, as illustrated inFIG.2A, the UE102can support layering of NR PDCP210over EUTRA RLC206A.

The EUTRA PDCP sublayer208and the NR PDCP sublayer210receive packets (e.g., from an Internet Protocol (IP) layer, layered directly or indirectly over the PDCP layer208or210) that can be referred to as service data units (SDUs), and output packets (e.g., to the RLC layer206A or206B) that can be referred to as protocol data units (PDUs). Except where the difference between SDUs and PDUs is relevant, this disclosure for simplicity refers to both SDUs and PDUs as “packets.”

On a control plane, the EUTRA PDCP sublayer208and the NR PDCP sublayer210can provide SRBs to exchange RRC messages, for example. On a user plane, the EUTRA PDCP sublayer208and the NR PDCP sublayer210can provide DRBs to support data exchange.

In scenarios where the UE102operates in EUTRA/NR DC (EN-DC), with the base station104operating as an MeNB and the base station106A operating as an SgNB, the wireless communication system100can provide the UE102with an MN-terminated bearer that uses EUTRA PDCP sublayer208, or an MN-terminated bearer that uses NR PDCP sublayer210. The wireless communication system100in various scenarios can also provide the UE102with an SN-terminated bearer, which uses only the NR PDCP sublayer210. The MN-terminated bearer can be an MCG bearer or a split bearer. The SN-terminated bearer can be an SCG bearer or a split bearer. The MN-terminated bearer can be an SRB (e.g., SRB1 or SRB2) or a DRB. The SN-terminated bearer can be an SRB or a DRB.

FIG.2Billustrates, in a simplified manner, an example protocol stack250for sidelink communication between the UE102and the UE103.

In the example stack250, a physical layer (PHY)252provides transport channels to the MAC sublayer254, which in turn provides logical channels to the RLC sublayer256. The RLC sublayer256in turn provides RLC channels to the PDCP sublayer258. In some implementations, the example stack250can comply to EUTRA or NR.

The PDCP sublayer258receive packets (e.g., from an Internet Protocol (IP) layer, layered directly or indirectly over the PDCP layer258) that can be referred to as service data units (SDUs), and output packets (e.g., to the RLC layer256) that can be referred to as protocol data units (PDUs). Except where the difference between SDUs and PDUs is relevant, this disclosure for simplicity refers to both SDUs and PDUs as “packets”. On a control plane, the PDCP sublayer258can provide one or more sidelink SRBs to exchange RRC messages between the UEs102and103, for example. On a user plane, the PDCP sublayer258can provide sidelink one or more DRBs to support data exchange between the UEs102and103.

Now referring toFIGS.3A-4C, the UE102in some scenarios UE information for sidelink to a CU via a source DU of a distributed base station, and then the UE102or the base station initiates a process of connecting the UE102to a different DU, or “target” DU. The CU of this disclosure provides, to the target DU, both the UE information for sidelink and information related to the procedure for connecting to the cell of the target DU. More particularly,FIG.3Apertains to single connectivity and dual connectivity scenarios in which the UE102transmits UE information for sidelink to a CU via a source DU using an RRC message and then changes the connection to a target DU.FIGS.3B-3Dillustrate handover scenarios in which the UE102transmits UE information for sidelink to a CU via a source DU and then performs a handover to a target DU, to which the CU provides the relevant handover and sidelink information.FIGS.4A-4Cthen illustrate handover scenarios in which the UE102transmits UE information for sidelink to a source base station and then performs a handover to a target base station including a target DU and a target CU.

Referring first to a scenario300A ofFIG.3A, the base station106A includes a DU174A, a DU174B and a CU172. Initially, the UE102communicates302A with the CU172via a source DU (S-DU)174, e.g., on cell125A. In some implementations, the UE102is in single connectivity (SC) with the base station106A. In other implementations, the UE102is in dual connectivity (DC) with base106A and base station104(not shown inFIG.3A), where the base station106A can operate as a MN or SN.

The UE102at some point transmits304A UE information for sidelink to the S-DU174A, which in turn transmits306A the UE information for sidelink to the CU172. The S-DU174A in this case tunnels the UE information to the CU172without processing this information. After receiving the UE information for sidelink, the CU172can transmit308A a request to set up a context of the UE, e.g., a UE Context Modification Request message, to the S-DU174A. The request can include the UE information for sidelink. The S-DU174A then generates first sidelink configuration(s) for the UE102according to the UE information for sidelink.

After receiving the first sidelink configuration(s), the CU172performs338A an RRC procedure (e.g., an RRC reconfiguration procedure) to send the first sidelink configuration(s) to the UE102. For example, the CU172sends an RRC message including the first sidelink configuration(s) to the S-DU174A, which in turn transmits the RRC message to the UE102. The UE102can use the first sidelink configuration(s) to perform sidelink communicate with the UE103. In some implementations, the UE102can transmit an RRC response message to the S-DU174A which in turn sends the RRC response message to the CU172. In some implementations, the RRC message and the RRC response message can be a RRCReconfiguration message and a RRCReconfigurationComplete message. The events304A,306A,308A,310A and338A are collectively referred to inFIG.3Aas a sidelink configuration procedure350A.

After receiving the UE information for sidelink, the CU172can determine312A that the UE102should transition from the S-DU174A to the T-DU174B (e.g., configure the UE102to perform handover or a PSCell change to the T-DU174B from the S-DU174A). In some implementations, the CU172may make the determination in response to one or more measurement results that exceeds (e.g., above or below) one or more predetermined thresholds, or calculating a filtered result (from the measurement result(s)) that is above (or below) a predetermined threshold. The one or more measurement results may indicate that the UE102should transition to cell126A operated by the T-DU174B. The CU172can receive the one or more measurement results from the S-DU174A, which in turn can receive these measurement results from the UE102. Alternatively, the S-DU174A can generate the one or more measurement results by measuring transmissions from the UE102.

In response to the determination312A, the CU172transmits314A a UE Context Setup Request message including the UE information for sidelink to the T-DU174B. The T-DU174B can generate second sidelink configuration(s) for the UE102according to the UE information for sidelink. The T-DU174B transmits316A a UE Context Setup Response message to the CU172in response to the UE Context Setup Request message. The T-DU174B can include a T-DU configuration and the second sidelink configuration(s) in the UE Context Setup Response message. Alternatively, after receiving the UE information for sidelink, the T-DU174B can transmit a UE Context Modification Required message including the second sidelink configuration(s) to the CU172, and the CU172can transmit a UE Context Modification Confirm message in response. In this case, the T-DU174B may not include the second sidelink configuration(s) in the UE Context Setup Response message.

Depending on the implementation, the CU172may or may include a S-DU configuration in the UE Context Setup Request message. In some implementations, the T-DU174B can generate the T-DU configuration which augments the S-DU configuration. In other implementations, the T-DU174B can generate the T-DU configuration which is a complete configuration not based on the S-DU configuration.

In some implementations, the S-DU174A can generate the first sidelink configuration(s) according to the UE information for sidelink. Similarly, the T-DU174B can generate the second sidelink configuration(s) according the UE information for sidelink. Depending on the implementation, the CU172might include or might exclude the first sidelink configuration(s) in the UE Context Setup Request message. In some implementations, the T-DU174B can generate the second sidelink configuration(s) which augments the first sidelink configuration(s). In other implementations, the T-DU174B can generate the second sidelink configuration(s) which are complete configuration(s) not based on the first sidelink configuration(s).

After receiving the second sidelink configuration(s), the CU172transmits320A an RRC reconfiguration message including the second sidelink configuration(s) to the T-DU174B, which in turn transmits322A the RRC reconfiguration message to the UE102. The UE102can use the second sidelink configuration(s) to perform sidelink communication with the UE103(seeFIG.1A). The UE102may perform324A a random access procedure with the T-DU174B in response to the RRC reconfiguration message. During or after the random access procedure, the UE102can transmit326A an RRC reconfiguration complete message to the T-DU174B which in turn sends328A the RRC reconfiguration complete message to the CU172. After performing the random access procedure or transmitting the RRC reconfiguration complete message, the UE102communicates330A with the CU via the T-DU174B according to configuration parameters in the T-DU configuration or RRC reconfiguration message.

In some implementations, the CU172might not include the UE information for sidelink in the UE Context Setup Request message at event314A. Instead, the CU172can transmit332A a UE Context Modification Request message including the UE information for sidelink to the T-DU174B after event314A. For example, the CU172can send332A the UE Context Modification Request message after the UE hands over to the T-DU174B. After receiving the UE information for sidelink, the T-DU174B can generate second sidelink configuration(s) for the UE102according to the UE information for sidelink. The T-DU174B transmits334A a UE Context Modification Response message including the second sidelink configuration(s) to the CU172in response to the UE Context Modification Request message. Alternatively, after receiving the UE information for sidelink, the T-DU174B can send a UE Context Modification Required message including the second sidelink configuration(s) to the CU172, and the CU172can transmit a UE Context Modification Confirm message in response. In this alternative, the T-DU174B may not include the second sidelink configuration(s) in the UE Context Modification Response message334A. Then the T-DU174B can perform a336A an RRC procedure to send the second sidelink configuration(s) via the T-DU174B, similar to the RRC procedure338A.

In some implementations, the UE102performs the random access procedure via the cell126A with the T-DU174B according to configuration parameters in the RRC reconfiguration message or the T-DU configuration. In some implementations, the random access procedure can be a two-step or four-step random access procedure. In other implementations, the random access procedure can be a contention-based random access procedure or a contention-free random access procedure.

In some implementations, the S-DU174A can generate at least one non-sidelink configuration parameter for the UE102according to (e.g., based on or considering) the UE information for sidelink, include the at least one non-sidelink configuration parameter in a S-DU configuration and transmit310A the S-DU configuration to the CU172in the UE Context Modification Response or the UE Context Modification Complete message described above. The CU172can send the S-DU configuration to the UE102via the S-DU174A in the RRC message during the RRC procedure338A. Alternatively, the CU172can perform another RRC procedure to send the S-DU configuraiton to the UE via the S-DU174A, similar to the RRC procedure338A.

Similarly, the T-DU174B can generate at least one non-sidelink configuration parameter for the UE102according to (e.g., based on or considering) the UE information for sidelink, include the at least one non-sidelink configuration parameter in the T-DU configuration and transmit334A the T-DU configuration to the CU172in the UE Context Setup Response, the UE Context Modification Response or the UE Context Modification Complete message described above. When the message is UE Context Setup Response, the CU172can transmit the T-DU configuration to the UE102via the T-DU174B in the RRC reconfiguration message320A. When the message is UE Context Modification Response or UE Context Modification Confirm message, the CU172can transmit the T-DU configuraiton to the UE via the T-DU174B during the RRC procedure336A, similar to the RRC procedure338A. Alternatively, the CU172can perform another RRC procedure (different from the RRC procedure336A) to transmit the T-DU configuration to the UE via the T-DU174B, similar to the RRC procedure338A.

In some implementations, the at least one non-sidelink configuration parameter may reduce the chances of collision of the sidelink communication from uplink communication or downlink communication for the UE102. For example, the uplink communication includes physical uplink shared channel (PUSCH) transmissions, physical uplink control channel (PUCCH), transmissions of channel state information (CSI) and/or transmissions of sounding reference signal(s). In another example, the downlink communication includes physical downlink shared channel (PDSCH) transmissions, physical downlink control channel (PDCCH) and/or transmissions of reference signal(s) (e.g., CSI-RS). In other implementations, the at least one non-sidelink configuration parameter may include a discontinous reception (DRX) configuration which directs the sidelink communication (i.e., sidelink transmissions or receptions) to occur at off-durations in DRX cycles configured by the DRX configuration. In yet other implementations, the at least one non-sidelink configuration parameter may include a measurement gap configuration which makes the sidelink communication occur at slots in gaps configured by the measurement gap configuration. In yet other implementations, the at least one non-sidelink configuration parameter may include a measurement gap configuration which makes the sidelink communication occur at slots not in gaps configured by the measurement gap configuration.

In some implementations, the at least one non-sidelink configuration parameter may configure the uplink communication and sidelink communication on the same carrier frequency. In other implementations, the at least one non-sidelink configuration parameter may configure the uplink communication and sidelink communication on different carrier frequencies.

In some implementations, the at least one non-sidelink configuration parameter may configure the uplink communication and sidelink communication on the same bandwidth part (BWP). In other implementations, the at least one non-sidelink configuration parameter may configure the uplink communication and sidelink communication on different BWPs.

In some implementations, the UE information for sidelink can include sidelink traffic related information such as traffic pattern information (e.g., TrafficPatternInfoListSL-r14 or TrafficPatternInfoListSL-v1530). For example, the sidelink traffic related information can include traffic characteristics of sidelink logical channel(s) that are setup for V2X sidelink communication.

In some implementations, the UE102transmits the UE information for sidelink to request or release sidelink resources and/or report QoS information for one or more destinations or sidelink radio bearer(s) in the sidelink communication. For example, the UE information for sidelink can include frequency information indicating at least one carrier frequency on which the UE102prefers to transmit V2X sidelink communication (e.g., sidelink packets). In another example, the UE information for sidelink can include frequency information of at least one carrier frequency on which the UE103is interested to receive V2X sidelink communication (e.g., sidelink packets). In such a case, the carrier frequency information of the UE102and the carrier frequency information of the UE103should indicate the same carrier frequency where the UE102can perform sidelink communication with the UE103. In yet another example, the UE information for sidelink can include at least one destination identity. In still another example, the UE information for sidelink can include UE capabilities for sidelink. Further, the UE information for sidelink can indicate RLC mode(s) for sidelink radio bearer(s). The UE information for sidelink also can include synchronization reference(s).

If the UE information for sidelink indicates release of sidelink resources or the sidelink communication for a carrier frequency, the first or second sidelink configuration(s) may indicate to the UE102to release sidelink resources or the sidelink communication for the carrier frequency. If the UE information for sidelink indicates release of sidelink resources or the sidelink communication for all carrier frequencies, the first or second sidelink configuration(s) may indicate to the UE102to release sidelink resources or the sidelink communication for all carrier frequencies for the sidelink communication.

In some implementations, the UE102transmits304A an RRC message including the UE information for sidelink to the S-DU174A and the CU172may include the RRC message in in the UE Context Modification Request or UE Context Setup Request message described above. The RRC message can be an EUTRA RRC message or a NR RRC message. For example, the RRC message can be a SidelinkUEInformation message, a SidelinkUEInformationNR message, a UEAssistanceInformation message, or a MeasurementReport message conforming to 3GPP specification 36.331 or 38.331. If the base station106A is a gNB and the RRC message is an EUTRA RRC message, the UE102can transmit304A a NR RRC container message (e.g., a ULlnformationTransferIRAT message) including the EUTRA RRC message to the gNB106A via the S-DU174A. The gNB extracts the EUTRA RRC message from the NR RRC container message.

If the base station106A is a gNB and the RRC message is an EUTRA RRC message, the CU172can include the EUTRA RRC message in a first field (e.g., tag the EUTRA RRC message with the first field name) in the UE Context Modification Request or UE Context Setup Request message described above. If the base station106A is a gNB and the RRC message is an NR RRC message, the CU172can include the NR RRC message in a second field (e.g., tag the NR RRC message with the second field name) in the UE Context Modification Request or UE Context Setup Request message described above. Thus, the S-DU174A or T-DU174B can determine the RRC message is an EUTRA RRC message or NR RRC message according to the first field or second field. In some implementations the CU172includes the RRC message in an RRC container IE (e.g., a HandoverPreparationInformation or CG-ConfigInfo IE) and includes the RRC container IE in the field. In other implementations the CU172includes the RRC message in the field without using an RRC container IE.

In some implementations, the RRC reconfiguration message and RRC reconfiguration complete are RRCReconfiguration message and RRCReconfigurationComplete message, respectively. The RRC reconfiguration message may include a field or IE (e.g., reconfigurationWithSync or ReconfigurationWithSync) indicating handover or PSCell change. In some implementations, the S-DU configuration or T-DU configuration can be a CellGroupConfigIE or include configurations in the CellGroupConfigIE.

In some implementations, the first or second sidelink configuration(s) can configuration parameters for NR or EUTRA sidelink communication, e.g., even the base station106A is a gNB. In some implementations, the first or second sidelink configuration(s) include configuration parameters in a SL-PHY-MAC-RLC-ConfigIE (e.g., SL-PHY-MAC-RLC-Config-r16 IE) conforming to 3GPP specification 38.331. In other implementations, the first or second sidelink configuration(s) include configuration parameters in a SL-ConfigDedicatedEUTRA-Info IE (e.g., SL-ConfigDedicatedEUTRA-Info-r16 IE) conforming to 3GPP specification 38.331. In some implementations, the first sidelink configuration(s) can be a first SL-PHY-MAC-RLC-Config IE (e.g., SL-PHY-MAC-RLC-Config-r16 IE) conforming to 3GPP specification 38.331, or a first SL-ConfigDedicatedEUTRA-Info IE (e.g., SL-ConfigDedicatedEUTRA-Info-r16 IE) conforming to 3GPP specification 38.331. In other implementations, the second sidelink configuration(s) can be a second SL-PHY-MAC-RLC-Config IE (e.g., SL-PHY-MAC-RLC-Config-r16 IE) conforming to 3GPP specification 38.331, or a second SL-ConfigDedicatedEUTRA-Info IE (e.g., SL-ConfigDedicatedEUTRA-Info-r16 IE) conforming to 3GPP specification 38.331.

In some implementations, the SL-ConfigDedicatedEUTRA-Info IE may include a RRCConnectionReconfiguration message conforming to 3GPP LTE specification 36.331. In some implementations, the SL-ConfigDedicatedEUTRA-Info IE may include one or more SL-TimeOffsetEUTRA-r16 IEs (e.g., SL-TimeOffsetEUTRA-r16 IE) conforming to 3GPP NR specification 38.331. For example, the SL-ConfigDedicatedEUTRA-Info IE may include a sl-TimeOffsetEUTRA-List-r16 field including the one or more TimeOffsetEUTRA-r16 IEs.

In some implementations, the S-DU174A generates the first sidelink configuration(s) for EUTRA sidelink communication, if the UE information for sidelink is for EUTRA or the S-DU174A receives an EUTRA RRC message including the UE information for sidelink in the UE Context Modification Request message. In other implementations, the S-DU174A generates the first sidelink configuration(s) for NR sidelink communication, if the UE information for sidelink is for NR or the S-DU174A receives an NR RRC message including the UE information for sidelink in the UE Context Modification Request message.

In some implementations, the T-DU174B generates the second sidelink configuration(s) for EUTRA sidelink communication, if the UE information for sidelink is for EUTRA or the T-DU174B receives an EUTRA RRC message including the UE information for sidelink in the UE Context Modification Request message. In other implementations, the T-DU174B generates the second sidelink configuration(s) for NR sidelink communication, if the UE information for sidelink is for NR or the T-DU174B receives an NR RRC message including the UE information for sidelink in the UE Context Modification Request message.

Now referring toFIG.3B, the UE102in a scenario300B initially communicates302B with the CU172via the S-DU174A, and then the UE102and the base station106A perform350B a sidelink configuration procedure, similar to events302A and350A discussed previously. The CU172then determines312B that the UE102should perform a handover to the T-DU174B. In response to this determination, the CU172generates312B a HandoverPreparationInformation IE with a Sidelink UE Information (SUI) IE. In some implementations, the CU172can generate the SUI IE based on the UE information for sidelink received during the sidelink configuration procedure350B. In other implementations, the UE information for sidelink includes or is the SUI IE. That is, the CU172receives the SUI IE from the UE102at the sidelink configuration procedure350B and includes the SUI IE in the HandoverPreparationInformation IE.

The CU172then transmits314B a request to set up a UE context, e.g., in the form of a UE Context Setup Request message. The request includes a HandoverPreparationInformation IE with sidelink information for the UE. In particular, the HandoverPreparationInformation message can include the SUI IE. The T-DU174B receives314B the UE Context Setup Request message and, because this message includes the HandoverPreparationInformation IE with sidelink-related UE information, the T-DU174B regards event314B as indication of V2X sidelink information.

The T-DU174B transmits316B a UE Context Setup Response message to the CU172in response to the UE Context Setup Request message, similar to event316A discussed previously. The CU172then generates318B a handover command including the T-DU configuration and the sidelink configuration(s) and transmits320B the handover command to the S-DU174A, which in turn forwards332B the handover command to the UE102via the radio interface.

The UE102performs324B a random access procedure with the T-DU174B, similar to event324A, and transmits326B a handover complete message to the T-DU174B. The T-DU174B forwards328B the handover complete message to the CU172. Thus, events320B-328B are generally similar to events320A-328A discussed previously, but involve handover messages rather than RRC reconfiguration messages. After performing the random access procedure, the UE102communicates330B with the CU via the T-DU174B according to configuration parameters in the T-DU configuration or RRC reconfiguration message.

In some implementations, the handover command and handover complete messages can be RRC reconfiguration and RRC reconfiguration complete messages, respectively as described forFIG.3A.

In a scenario300C ofFIG.3C, events302C and350C are similar to events302A,302B and350A,350B, respectively. The CU172determines342that the UE102should perform a handover to the T-DU174B and generates a HandoverPreparationInformation IE. However, unlike the scenario ofFIG.3B, the CU172here does not include the SUI IE in the HandoverPreparationInformation IE.

Instead, the CU172provides the SUI IE to the target T-DU174B after receiving the handover complete message. In particular, the CU172, the S-DU174A, the T-DU174B, and the UE102perform a handover procedure at events320C-328C similar to events320B-328B (but without the SUI IE as noted above), and the UE102can begin to communicate330C with the CU via the T-DU174B according to configuration parameters in the T-DU configuration or RRC reconfiguration message. The CU172then transmits332C a UE Context Modification Request message including a CG-ConfigInfo IE, which in turn includes the SUI IE. The T-DU174B transmits334C a UE Context Modification Response message including the sidelink configuration(s) to the CU172, in response to the UE Context Modification Request message.

Now referring toFIG.3D, events302C and350C are similar to events302A-C and350A-C, respectively. The CU172determines362that the UE102should perform a handover to the T-DU174B and generates a HandoverPreparationInformation IE, generates a CG-ConfigInfo IE that includes the SUI IE, and includes the CG-ConfigInfo IE with the SUI IE in the HandoverPreparationInformation IE. The CU172then transmits364a UE Context Setup Request message including the generated HandoverPreparationInformation IE to the T-DU174B. Subsequent events316D-330D are similar to events316B-330B, respectively, discussed previously with reference toFIG.3B.

InFIG.4A, a scenario400A begins with the UE102communicating402with an S-BS104. The UE102transmits404a SUI IE to the S-BS104using a suitable RRC message, for example. The S-BS104then determines412that the UE104should perform a handover to the T-DU174of the base station106A. The S-BS104generates412a HandoverPreparationInformation IE that includes the SUI IE and transmits405a Handover Request message with the HandoverPreparationInformation IE (which in turn includes the SUI IE) to the target CU (T-CU)172.

Similar to event314A, the T-CU172transmits414A to the T-DU174a UE Context Setup Request message that includes a HandoverPreparationInformation IE with sidelink information for the UE. The T-DU174B receives414A the UE Context Setup Request message and, because this message includes the HandoverPreparationInformation IE with sidelink-related UE information, the T-DU174B regards event414A as indication of V2X sidelink information.

The T-DU174B transmits416A a UE Context Setup Response message to the CU172in response to the UE Context Setup Request message, similar to event316B discussed previously. The CU172then generates418A a handover command including the T-DU configuration and the sidelink configuration(s) and transmits421to the S-BS104a Handover Request Acknowledgement message responsive to the handover request405. The Handover Request Acknowledgement message includes a handover command, which the S-BS104forwards422to the UE102using an appropriate RRC message.

The UE102performs424A a random access procedure with the T-DU174, similar to event324, and transmits426A a handover complete message to the T-DU174B. The T-DU174B forwards428A the handover complete message to the CU172, and the UE102communicates430A with the CU via the T-DU174B according to configuration parameters in the T-DU configuration or RRC reconfiguration message.

Referring toFIG.4B, a scenario400B is generally similar to the scenario300C ofFIG.3C, but here the UE102performs a handover to another base station rather than another DU within the same base station. After events402-405discussed previously, the T-CU172does not include the SUI IE in the HandoverPreparationInformation IE and transmits444a UE Context Setup Request message with the HandoverPreparationInformation IE and without the SUI IE to the T-DU174. The T-DU174B then transmits416B to the T-CU172a UE Context Setup Response message, which is similar to the message of event416A but excludes sidelink configurations(s). After events421-430discussed previously with reference toFIG.4A, the CU172then transmits432a UE Context Modification Request message including a CG-ConfigInfo IE, which in turn includes the SUI IE. The T-DU174B transmits434a UE Context Modification Response message including the sidelink configuration(s) to the CU172, in response to the UE Context Modification Request message.

Now referring to a scenario400C ofFIG.4C, after events402-405discussed previously, the CU172generates464a HandoverPreparationInformation IE, generates a CG-ConfigInfo IE that includes the SUI IE, and includes the CG-ConfigInfo IE with the SUI IE in the HandoverPreparationInformation IE and sends it465in a UE Context Setup Request message. Event416C is similar to event416B ofFIG.4B, and subsequent events are similar to those ofFIG.4A, with like reference numbers referring to similar events.

Next,FIG.5illustrates a set of scenarios500in which the CU172initially communicates502with the UE102in single connectivity or dual connectivity. The base station106A operates as both an MN and an SN, with the MN including a CU (e.g., the CU172) and a first DU (e.g., a DU174A of the one or more DUs174, referred to herein as a master DU (M-DU)174A) of the base station106A, and the SN including the same CU and a second, different DU (e.g., a DU174B of the one or more DUs174, referred to herein as a secondary DU (S-DU)174B) of the base station106A. Events in the scenario500similar to those discussed previously with respect to the scenario300A are labeled with similar reference numbers (e.g., with event302A corresponding to event502, event304corresponding to event504).

Initially, the UE102communicates502in SC with the CU172via the M-DU174A. Alternatively, the UE102communicates502in DC with the CU172via the M-DU174A and the S-DU174B. The UE102in SC or DC then transmits504UE information for sidelink to the M-DU174A, which in turn transmits506the UE information for sidelink communication to the CU172.

The CU172determines507that it should transmit the UE information for sidelink to the M-DU174A or the S-DU174B. If the CU172determines it should send the UE information for sidelink to the M-DU174A, the CU172transmits508a first interface message including the UE information for sidelink to the M-DU174A. In response, the M-DU174A can transmit510a second interface message including first sidelink configuration(s) to the CU172. In some implementations, the first interface message can be a UE Context Modification Request message similar to the UE Context Modification Request message308A. The second interface message can be a UE Context Modification Response message similar to the UE Context Modification Response message310A or the UE Context Modification Required message described forFIG.3A.

If the CU172instead determines to send the UE information for sidelink to the S-DU174B, the CU172transmits514a third interface message including the UE information for sidelink to the S-DU174B. In response, the S-DU174B can send516a fourth interface message including second sidelink configuration(s) to the CU172. In some implementations, the third interface message can be a UE Context Modification Request message similar to the UE Context Modification Request message308A or314A. The fourth interface message can be a UE Context Modification Response message similar to the UE Context Modification Response message310A or316A, or the UE Context Modification Required message described forFIG.3A.

The CU172can perform538an RRC reconfiguration to send the first or second sidelink configuration(s) to the UE102via the M-DU174A. Alternatively, the CU172can perform538an RRC reconfiguration to send the first or second sidelink configuration(s) to the UE102via the S-DU174B. As described forFIG.3A, the CU172can include a DU configuration (e.g., a M-DU configuration or a S-DU configuration) in an RRC reconfiguration message in the RRC reconfiguration procedure, in addition to the (first or second) sidelink configuration(s). Implementations of the DU configuration can refer to the description of generating the T-DU configuration forFIG.3A.

In some implementations, the CU172can determine that it should send the UE information for sidelink to the M-DU174A if the CU172determines that the UE102can only perform sidelink communication on a carrier frequency operated by the M-DU174A. Similarly, the CU172can determine it should transmit the UE information for sidelink to the M-DU174A if the CU172is configured to determine that the UE102can only perform sidelink communication on a carrier frequency operated by the S-DU174A. In other implementations, the CU172can indicate a carrier frequency on which the UE102prefers to perform V2X sidelink communication according to frequency information in the UE information for sidelink as described forFIG.3A.

If the CU172determines that the carrier frequency is associated with a cell of the M-DU174A, the CU172transmits508the UE information for sidelink to the M-DU174A. If the CU172determines that the carrier frequency is operated by the S-DU174B, the CU172transmits514the UE information for sidelink to the S-DU174B. In yet other implementations, the CU172determines that it should send the UE information for sidelink to the M-DU174A or S-DU174B based on the M-DU174A or S-DU174B from which the CU172receives the UE information for sidelink. If the CU172receives the UE information for sidelink from the M-DU174A, the CU172transmits508the UE information for sidelink to the M-DU174A. On the other hand, if the CU172receives the UE information for sidelink from the S-DU174B, the CU172transmits514the UE information for sidelink to the S-DU174B.

Referring toFIG.6, a scenario600involves a distributed MN104with a CU172A and a DU174A, as well as a distributed SN106A with a CU172B and a DU174B. The UE102initially communicates602with SC with the MN104or in DC with the MN104and the SN106A. The UE102in SC or DC then transmits604communication UE information for sidelink communication.

In response, the CU172determines605whether it should transmit the received UE information for sidelink to the SN106A. To this end, the CU172can consider factors similar to those discussed previously with reference to event507ofFIG.5. When the CU172determines that the DU174A can support the sidelink configuration, the SN106A transmits608a first interface message with the UE information to the DU174A and receives610a second interface message with the sidelink configuration in response. Otherwise, the CU172transmits an SN request with the UE information to the CU172B. The SN request can be for example a request to an SN node or a request to modify the SN node. The CU172B transmits614a third interface message with the UE information to the DU174B and receives616a fourth interface message with the sidelink configuration(s) in response. The CU172B then transmits617an SN request acknowledgement, responsive to event607, to the CU172A. The UE102and the CU172A then perform an RRC reconfiguration procedure.

Several example methods that a DU and a CU of this disclosure can implement are considered next. Each of these methods can be implemented using suitable processing hardware such as for example one or more processors configured to execute instructions stored on a non-transitory computer-readable medium.

Referring first toFIG.7, an example method700for generating sidelink configuration based on a UE information received from a CU can be implemented in the DU174A,174B, or another suitable DU. At block702, the DU receives UE information for sidelink for a UE. The DU can receive this information from a CU such as the CU172A or172B for example. At block704, the DU generates sidelink configuration(s) for the UE according to the received UE information. The DU then sends the sidelink configuration(s) to the CU.

FIG.8is a flow diagram of an example method800in a CU, such as the CU172A or172B, for selecting a DU for configuring sidelink resources to a UE, with the selection based on whether UE sidelink information arrives from a UE or another base station. The method800begins at block802, where the CU receives UE information for sidelink communication for a UE. If the CU determines at block804that the UE information for sidelink communication arrived via an SRB, and thus at the same base station in which the CU operates, the flow proceeds to block806. Otherwise, the block proceeds to block810. The CU in this case can determine that the UE information for sidelink communication arrived in a container IE, and thus in an interface message from another base station.

At block806, the CU generates a first interface that includes a CG-ConfigInfo IE with the UE information for sidelink communication. More specifically, the UE information for sidelink communication can be a SUI IE for example. Next, at block808, the CU sends the first interface message to a first DU. Otherwise, at block810, the CU does not generate a CG-ConfigInfo IE with UE information for sidelink communication. At block812, the CU generates a second interface message with a container IE. The CU then sends the second interface message to a second DU. The first DU can operate for example within the same base station as the CU, and the second DU can operate in a different base station.

Referring toFIG.9, a CU can implement a method900to select a DU for configuring sidelink resources to a UE, with the selection based on whether the UE is performing a handover. The method900begins at block902, where the CU receives UE information for sidelink communication for a UE.

At block904, the CU determines whether it should initiate a handover for the UE. When no handover is necessary, the flow proceeds to block906, where the CU generates a first interface that includes a CG-ConfigInfo IE with the UE information for sidelink communication, similar to block806. The CU then sends the first interface message to a first DU, at block908.

When the CU determines that the UE should perform a handover, the flow proceeds to block910, where the CU generates a second interface message with a HandoverPreparationInformation IE that includes the UE information for sidelink communication (e.g., a SUI IE). At block912, the CU sends the second interface message to a second DU. The first and second DUs can operate in the same distributed base station or different distributed base stations.

FIG.10is a flow diagram of an example method1000in a CU for configuring a DU to perform a handover of a UE concurrently with sidelink configuration of the UE. At block1002, the CU receives UE information for sidelink communication for a UE. Next, at block1004, the CU determines the UE should perform a handover to a target cell. At block1006, the CU generates a first interface message with a HandoverPreparationInformation IE to support the handover procedure, and a CG-ConfigInfo IE that includes the UE information for sidelink communication. At block1008, the CU sends the first interface message to a DU. At block1010, the CU receives a second interface message in response. The second interface message includes a CellGroupConfig IE from the DU, to support the handover operation.

Now referring toFIG.11, an example method1100in a DU for processing handover preparation information and a cell group configuration (including sidelink information for a UE) begins at block1102. The DU receives a first interface message including a HandoverPreparationInformation IE and a CG-ConfigInfo IE for a UE, from a CU. At block1104, the DU generates a CellGroupConfig IE for a handover operation, responsive to the HandoverPreparationInformation IE. At block1106, the DU sends a second interface message including the CellGroupConfig IE to the CU.

FIG.12illustrates an example method1200for generating an interface message, which can be implemented in a CU. At block1202, the CU receives UE information for sidelink communication for a UE. At block1204, the CU determines whether it should send the UE information for sidelink communication to a first DU or, alternatively, to a second DU or another base station. If the CU determines it should the UE information for sidelink communication to the first DU, the CU sends a first interface message including the UE information for sidelink communication to the first DU. Otherwise, at block1208, the CU sends a second interface message including the UE information for sidelink communication to the second DU or another base station. Thus, according to the method1200, the CU selects a format for formatting an interface message depending on the target network node.

Referring toFIG.13, a CU can implement an example method1300for selecting a field in which the CU transmits the UE information for sidelink communication. At block1302, the CU receives UE information for sidelink communication for a UE. At block1304, the CU determines whether the UE information for sidelink communication conforms to a first RAT or a second RAT. When the UE information conforms to the first RAT, the CU includes the UE information for sidelink communication in a first field (block1306). Otherwise, when the UE information for sidelink communication conforms to the second RAT, the flow proceeds to block1308, where the CU includes the UE information for sidelink communication in a second field. At block1310, the CU then sends an interface message that includes the first field or the second field to the DU.

Next,FIG.14illustrates a flow diagram of an example method1400in a DU for generating sidelink configuration in view of a RAT to which UE information for sidelink communications conforms. At block1402, the DU receives, from a CU, UE information for sidelink communication for a UE. At block1404, the DU determines whether the UE information for sidelink communication conforms to a first RAT or a second RAT. When the UE information conforms to the first RAT, the DU at block1406generates a sidelink configuration that conforms to the first RAT as well a sidelink configuration that conforms to the second RAT. The DU then sends an interface message including both sidelink configurations to the CU, at block1410. Otherwise, when the UE information conforms to the second RAT, the DU at block1406generates only a sidelink configuration that conforms to the second RAT. The flow then similarly proceeds to block1410.

FIG.15is illustrates an example method1500in a CU for generating an RRC message with sidelink configuration in two different formats conforming to two respective RATs. At block1502, the CU receives a first sidelink configuration that conforms to the first RAT, from a DU. At block1504, the CU generates a second sidelink configuration that conforms to the second RAT. At block1506, the CU sends an RRC message includes the first sidelink configuration and the second sidelink configuration to the UE.

Finally,FIG.16illustrates an example method1600in a CU for managing sidelink communications.

At block1602, the CU receives sidelink information related to sidelink communications at a UE operating in a first cell (e.g., event306A ofFIG.3A,350BofFIG.3B,350CofFIG.3C,350DofFIG.3D,405ofFIGS.4A-C,506ofFIG.5;604ofFIG.6).

At block1604, the CU determines that the UE should utilize a radio resource on a second cell associated with a target node, the target node corresponding to a DU of the distributed base station or another base station (e.g., events312A ofFIG.3A,312BofFIG.3B,342ofFIG.3C,362ofFIG.3D,414ofFIG.4A,418ofFIGS.4B and4C,507ofFIG.5,605ofFIG.6).

At block1606, the CU transmits the sidelink information to the target node (e.g., event314A ofFIG.3A,314BofFIG.3B,332ofFIG.3C,364ofFIG.3D,414ofFIG.4A,432ofFIG.4B,464ofFIG.4C,508or514ofFIG.5,608or607ofFIG.6).

At block1608, the CU receives, from the target node, a sidelink configuration for the UE (e.g., event316A ofFIG.3A,316BofFIG.3B,334ofFIG.3C,316ofFIG.3D,416ofFIG.4A,434ofFIG.4B,416ofFIG.4C,510or516ofFIG.5,610or616ofFIG.6).

The following description may be applied to the description above.

In some implementations, “message” is used and can be replaced by “information element (IE)”. In some implementations, “IE” is used and can be replaced by “field”.

A user device in which the techniques of this disclosure can be implemented (e.g., the UE102) can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media-streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an internet-of-things (IoT) device or a mobile-internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

Certain embodiments are described in this disclosure as including logic or a number of components or modules. Modules may can be software modules (e.g., code, or machine-readable instructions stored on non-transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently configured (e.g., as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), a digital signal processor (DSP), etc.) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) may be driven by cost and time considerations.

When implemented in software, the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. The software can be executed by one or more general-purpose processors or one or more special-purpose processors.

The following list of examples reflects a variety of the embodiments explicitly contemplated by the present disclosure.

Example 1. A method of obtaining sidelink configuration in a central unit (CU) of a distributed base station comprises receiving, by one or more processors, sidelink information related to sidelink communications at a UE operating in a first cell; determining, by the one or more processors, that the UE should utilize a radio resource on a second cell associated with a target node, the target node corresponding to a distributed unit (DU) of the distributed base station or another base station; transmitting, by the one or more processors, the sidelink information to the target node; and receiving, by the one or more processors and from the target node, a sidelink configuration for the UE.

Example 2. The method of example 1, wherein determining that the UE should utilize the radio resource on the second cell includes initiating a handover procedure or a cell change procedure.

Example 3. The method of example 2, wherein transmitting the sidelink information to the target node includes transmitting a request to set up a context for the UE, the request including the sidelink information; and receiving the sidelink configuration includes receiving, from the target node, a response to the request, the response including (i) a target DU (T-DU) configuration and (ii) the sidelink configuration.

Example 4. The method of example 3, further comprising: generating, by the one or more processors, a radio resource control (RRC) reconfiguration command for the UE, the RRC reconfiguration command including the T-DU configuration and the sidelink configuration; and transmitting, by the one or more processors, the command to the UE via a source DU.

Example 5. The method of example 3, wherein the request includes a handover preparation information message, the message including a Sidelink UE Information (SUI) information element (IE) to convey the sidelink information.

Example 6. The method of example 5, wherein the SUI IE is included in a CG-ConfigInfo IE.

Example 7. The method of any of example 5 or 6, further comprising: generating, by the one or more processors, a handover command including the T-DU configuration and the sidelink configuration; and transmitting, by the one or more processors, the handover command to the UE via a source DU.

Example 8. The method of example 2, further comprising: transmitting, to the target node, a request to set up a context for the UE, the requesting including a handover preparation information message; and in response to receiving an indication that the UE has completed a handover from the first cell to the second cell: transmitting, to the target node, a request to modify a context for the UE, the request including a SUI IE to convey the sidelink information.

Example 9. The method of any of examples 2-4 or 6-8, wherein: receiving the sidelink information includes receiving the sidelink information from a first DU of the distributed base station; and transmitting the sidelink information to the target node includes transmitting the sidelink information to a second DU of the distributed base station.

Example 10. The method of any of examples 2, 3, or 5-8, wherein: receiving the sidelink information includes receiving a handover request with the handover preparation information from a base station other than the distributed base station.

Example 11. The method any of the preceding examples, wherein the sidelink information includes an indication of at least one frequency on which the UE prefers to transmit and/or receive sidelink data.

Example 12. The method of example 1, wherein: receiving the sidelink information includes receiving the sidelink information from the UE via a source DU of the distributed base station; and determining that the UE should utilize the radio resource on the second cell includes: determining, based on the sidelink information, that a frequency on which the UE prefers to transmit and/or receive sidelink data is associated with the second cell.

Example 13. The method of example 12, wherein the target node is another DU of the distributed base station.

Example 14. The method of example 12, wherein the target node is associated with another base station.

Example 15. The method of example 12, wherein transmitting the sidelink information includes transmitting a request to add or modify a secondary node (SN), so that the UE operates in DC with the distributed base station operating as master node (MN) and the SN.

Example 16. The method of example 1, wherein the receiving the sidelink information includes: determining whether the sidelink information was received at the distributed base station via a signaling radio bearer (SRB); and further comprising: in response to determining that the sidelink information was received at the distributed base station via an SRB: generating a first interface message with a CG-ConfigInfo IE including the sidelink information, and selecting a first DU as the target node; in response to determining that the sidelink information was not received at the distributed base station via an SRB: generating a second interface message with a container IE including the sidelink information, and selecting a second DU as the target node.

Example 17. The method of any of the preceding examples, further comprising: formatting an interface message for transmission to the target node in accordance with whether the sidelink information conforms to a first radio access technology (RAT) or a second RAT.

Example 18. The method of example 1, wherein: the sidelink configuration is a first sidelink configuration conforming to a first RAT; the method further comprising: generating, by the one or more processors, a second sidelink configuration that conforms to a second RAT; and generating, by the one or more processors, an RRC message including the first sidelink configuration and the second sidelink configuration, for transmission to the UE.

Example 19. A method of generating sidelink configuration in a distributed unit (DU) of a distributed base station comprises: receiving, by one or more processors and from a CU of the distributed base station, sidelink information related to sidelink communications at a UE operating in a first cell; generating, by the one or more processors, the sidelink configuration for the UE based on the sidelink information; and transmitting, by the one or more processors, the sidelink configuration to the CU.

Example 20. The method of example 20, wherein generating the sidelink configuration includes: in response to determining that the sidelink information conforms to a first RAT: generating (i) a first instance of the sidelink configuration, conforming to the first RAT, and (ii) a second instance of the sidelink configuration, conforming to a second RAT, for transmission to the CU; and in response to determining that the sidelink information conforms to a second RAT: generating only one instance of the sidelink configuration, conforming to the second RAT, for transmission to the CU.

Example 21. The method of example 20, wherein: receiving the sidelink information includes receiving a first interface message including handover preparation information and a CG-ConfigInfo IE with the sidelink information; and generating the sidelink configuration includes generating a cell group information IE for a handover operation.

Example 22. A base station comprising processing hardware and configured to implement a method according to any of the preceding examples.