WO2024010828A1 - Enhanced mobile integrated access and backhaul for wireless communications - Google Patents

Enhanced mobile integrated access and backhaul for wireless communications Download PDF

Info

Publication number
WO2024010828A1
WO2024010828A1 PCT/US2023/026958 US2023026958W WO2024010828A1 WO 2024010828 A1 WO2024010828 A1 WO 2024010828A1 US 2023026958 W US2023026958 W US 2023026958W WO 2024010828 A1 WO2024010828 A1 WO 2024010828A1
Authority
WO
WIPO (PCT)
Prior art keywords
mlab
donor
node
cell
lab
Prior art date
Application number
PCT/US2023/026958
Other languages
French (fr)
Inventor
Ziyi Li
Sudeep Palat
Jaemin HAN
Yi Guo
Youn Hyoung Heo
Xun Tang
Original Assignee
Intel Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corporation filed Critical Intel Corporation
Publication of WO2024010828A1 publication Critical patent/WO2024010828A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02—Terminal devices
    • H04W88/04—Terminal devices adapted for relaying to or from another terminal or user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/20—Selecting an access point
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/16—Interfaces between hierarchically similar devices
    • H04W92/20—Interfaces between hierarchically similar devices between access points

Definitions

  • This disclosure generally relates to systems and methods for wireless communications and, more particularly, to mobile integrated access and backhaul.
  • Wireless devices are becoming widely prevalent and are increasingly using wireless channels.
  • the 3 rd Generation Partnership Program (3GPP) is developing one or more standards for wireless communications.
  • FIG. 1 is a network diagram illustrating an example network environment, in accordance with one or more example embodiments of the present disclosure.
  • FIG. 2 illustrates a flow diagram of a mobile integrated access and backhaul (mlAB) topology integration using an enhanced setup response, in accordance with one or more example embodiments of the present disclosure.
  • mlAB mobile integrated access and backhaul
  • FIG. 3A illustrates an example velocity-based cell selection and reselection for radio resource control idle (RRC_IDLE) and RRC inactive (RRC_INACTIVE) user equipment before and after moving out of a mlAB, in accordance with one or more example embodiments of the present disclosure.
  • RRC_IDLE radio resource control idle
  • RRC_INACTIVE RRC inactive
  • FIG. 3B illustrates an example velocity-based cell selection and reselection for the RRC_IDLE and the RRC_INACTIVE user equipment of FIG. 3A before and after moving into the mlAB of FIG. 3A, in accordance with one or more example embodiments of the present disclosure.
  • FIG. 3C illustrates an example velocity-based cell selection and reselection for the RRC_IDLE and the RRC_INACTIVE user equipment of FIG. 3 A while moving together with the mlAB of FIG. 3A, in accordance with one or more example embodiments of the present disclosure.
  • FIG. 3D illustrates an example velocity-based cell selection and reselection for the RRC_IDLE and the RRC_INACTIVE user equipment of FIG. 3 A while the mlAB of FIG. 3 A moves between lAB-donors, in accordance with one or more example embodiments of the present disclosure.
  • FIG. 4 illustrates a flow diagram of a mlAB message flow, in accordance with one or more example embodiments of the present disclosure.
  • FIG. 5A illustrates a flow diagram of a mlAB message flow for physical cell identifier (PCI) management, in accordance with one or more example embodiments of the present disclosure.
  • PCI physical cell identifier
  • FIG. 5B illustrates a flow diagram of a mlAB message flow for PCI management, in accordance with one or more example embodiments of the present disclosure.
  • FIG. 6A illustrates a flow diagram of a mlAB message flow for IAB transport migration, in accordance with one or more example embodiments of the present disclosure.
  • FIG. 6B illustrates a flow diagram of a mlAB traffic flow for a conditional mlAB distributed unit resource configuration, in accordance with one or more example embodiments of the present disclosure.
  • FIG. 6C illustrates a flow diagram of a mlAB traffic flow for a conditional mlAB distributed unit resource configuration, in accordance with one or more example embodiments of the present disclosure.
  • FIG. 6D illustrates a flow diagram of a mlAB traffic flow for a user equipment handover, in accordance with one or more example embodiments of the present disclosure.
  • FIG. 7A illustrates a flow diagram of a mlAB traffic flow for a user equipment handover, in accordance with one or more example embodiments of the present disclosure.
  • FIG. 7B illustrates a flow diagram of a mlAB traffic flow for a user equipment handover, in accordance with one or more example embodiments of the present disclosure.
  • FIG. 8 illustrates a flow diagram of illustrative process for mlAB management, in accordance with one or more example embodiments of the present disclosure.
  • FIG 9. illustrates a network, in accordance with one or more example embodiments of the present disclosure.
  • FIG. 10 schematically illustrates a wireless network, in accordance with one or more example embodiments of the present disclosure.
  • FIG. 11 is a block diagram illustrating components, in accordance with one or more example embodiments of the present disclosure.
  • one option is to deploy an IAB node into a moving vehicle (i.e. mobile IAB, mlAB), where the connectivity for users/devices could be improved in different environments, e.g. for passengers in buses, car/taxi, or trains, ad-hoc/professional personnel or equipment.
  • a moving vehicle i.e. mobile IAB, mlAB
  • the connectivity for users/devices could be improved in different environments, e.g. for passengers in buses, car/taxi, or trains, ad-hoc/professional personnel or equipment.
  • RRC_IDLE or RRC_INACTIVE state radio resource control RRC protocol either idle or inactive
  • the onboarded users can still detect other gNBs’ signaling.
  • those users are supposed to camp on the cell of mobile lAB-node rather than other gNBs, so that the unnecessary cell reselection can be avoided. Therefore, how to perform cell selection and cell reselection for RRC_IDLE/INACITVE UEs on mlAB-node is important and different than a normal UE who camps on a normal cell.
  • a mobile lAB-node can only perform topology integration to the lAB-node or IAB -donor which supports new functionalities used by mobile lAB-node, e.g. group mobility, etc.
  • the differentiation between an I AB -node supporting a ml AB -node as a child node and an IAB- node that does not support a mlAB-node as child node needs to be considered.
  • a new information element (IE) “miab-support” is introduced to be broadcasted by an IAB-node/I AB -donor to support mlAB-node integration.
  • IE information element
  • a velocity-based cell selection and reselection is proposed to avoid IDLE/INACTIVE UEs camped on a mlAB-node with unnecessary measurement and cell reselection.
  • the proposed solution can reduce the power consumption for IDLE/INACTIVE UEs who camp on mlAB-node by avoiding them keeping the measurement to gNB surrounding mlAB-node.
  • the enhanced techniques herein can help the mobile lAB-node to integrate into a suitable parent lAB-node/IAB-donor to provide services.
  • the enhanced techniques herein identify a mobile I AB node integration.
  • a mobile lAB-node within the IAB topology, new functionalities are introduced to be supported at an lAB-donor, e.g. supporting full migration of a mlAB-node, supporting group mobility of a mlAB-node and its served UEs, etc.
  • An “iab- support” IE introduced in 3GPP Release 16 may not fully represent the functionalities required by a mlAB-node.
  • Such functionalities required by a mlAB-node may not be supported in an IAB node or an lAB-donor.
  • An mlAB-node may not select a suitable parent lAB-node based on the existing identification “iab-support.”
  • the identification “miab-support” may also be provided by the fixed lAB-node, so that the mlAB- node or another fixed IAB node can read such information from the fixed lAB-node’s DU.
  • This field combines both the support of IAB and the cell status for I AB. If the field is present, the cell supports IAB and the cell is also considered as a candidate for cell
  • trackingAreaList Indicates Tracking Area Code to which the cell indicated by cellidentity field belongs. The absence of the field indicates that the cell only supports PSCell/SCell functionality (per PLMN).
  • This field combines both the support of IAB and the cell status for mobile IAB. If the field is present, the cell support mobile IAB and the cell is also considered as a candidate for cell (re)selection for mobile lAB-node; if the field is absent, the cell does not support mobile IAB and/or the cell is barred for mobile lAB-node.
  • cell status and cell reservation are indicated in the MIB or SIB1 message as specified in TS38.331 by means of following fields, with miab-Support being new: ⁇ skip irrelevant content> miab-Support (IE type: "true")
  • SIB1 message Indicated in SIB1 message. In case of multiple PLMNs or NPNs indicated in SIB1, this field is specified per PLMN or per SNPN.
  • an lAB-donor supports functionalities for mobile lAB-node’s integration can be configured by core network over NG interface.
  • a new IE is proposed to he configured in NG Setup Response message from AMF to NG-RAN node, indicating the lAB- donor can support mobile lAB-node’s integration and provide services accordingly.
  • 3GPP TS 38.413 defines a NG Setup Response, which is a message sent by the AMF to the transfer application layer information for an NG-C interface instance. The direction is AMF to NG RAN node. Table 1 below shows an example of the NG Setup Response message, with the mobile IAB supported element being new.
  • a mobile IAB-node supports integration/cell (re)selection of another fixed or mobile IAB-node
  • “miab-support” and/or “iab-support” can be broadcasted in its SIB. Otherwise, mobile IAB -DU should not broadcast “miab-support” and “iab-support” as cell bar information.
  • the network may also identify whether the integrated IAB-node is a stationary IAB-node or a mobile IAB-node. It is proposed that, during initial access, the mobile IAB-node also sends an indication to the network, indicating it is a mlAB-node, e.g. “mlAB-Nodelndication” in RRCSetupComplete message. The lAB-donor may further send this indication to CN over NG interface, and a “mlAB-authorized” IE can be configured by CN during initial context setup for mlAB-MT.
  • the cell selection and reselection for RRC_Idle and RRC_Inactive UEs may be velocity based.
  • a RRC_IDLE/INACTIVE UEs there are multiple possible scenarios and corresponding expected UE behavior need to be considered: (1).
  • a RRC_IDLE/IN ACTIVE UE moves out of a vehicle with a mlAB-node, the UE is expected to (re)select a normal cell to camp on (before moving out of the vehicle - red line, after moving out of the vehicle - blue line).
  • a RRC_IDLE/INACTIVE UE gets onboard a vehicle with a mlAB-node, the UE is expected to (re)select the cell of mlAB-node to camp on.
  • a RRC_IDLE/INACTIVE UE is within the vehicle with a mlAB-node and moves together with the vehicle (e.g., the relative speed between UE and mlAB-node is zero).
  • the UE is expected not to perform any cell reselection to other mlAB-node or gNB (UE-mlAB link remains unchanged as UE is inside the moving vehicle - green line, but mlAB-node is moved from one lAB-donor to another - red line to blue line).
  • a RRC_IDLE/INACTIVE UE is within the vehicle with multiple mlAB-nodes (e.g. a train with multiple carriages, each carriage has one/more mlAB-node based on coverage), the UE is moving inside the vehicle from the coverage of one mlAB-node to another, the UE is expected to perform cell reselection and camp on another mlAB-node.
  • the RRC_IDLE/INACTIVE UE may be important for the RRC_IDLE/INACTIVE UE to know the cell information so that it can camp on the suitable cell without unnecessary measurement and cell reselection.
  • the RRC_IDLE/INACTIVE UE will change the cell it camps on from mlAB-node to gNB or from gNB to mlAB-node when the vehicle is not moving and the user is moving outside/inside the vehicle, respectively.
  • the UE should not perform any cell reselection or can only select mlAB-node for cell reselection when the vehicle is moving.
  • a mlAB-node s velocitybased cell (re)selection method is proposed to optimize cell (re)selection of RRC_IDLE/INACTIVE UEs.
  • the mlAB-node is proposed to support measurement of its velocity and provide its velocity information as part of the broadcast information in SIB.
  • velocity information provided in SIB1: (1) velocity information provided in OCTET STRING, following the definition in TS37.355.
  • velocity information provided in separate IES including horizontal speed of the mlAB, vertical speed of the mlAB (if applicable), uncertain of the horizontal and/or vertical speed, horizontal and/or vertical direction of moving vehicle, etc.
  • Velocity information provided at a granular level, e.g., as high, medium, low. Alternatively, velocity information can also be sent over paging message.
  • a velocity threshold/minimum velocity of mlAB-cell is also proposed to be broadcasted in mlAB’s optionally.
  • the mlAB cell can consider its velocity and threshold together and broadcast an indication whether velocity is below or above the threshold.
  • a new cell identification “miab-cell” is also proposed to be broadcasted by the mlAB-node’s DU.
  • the SIB1 may be modified as shown below:
  • SIBl-vl800-IEs :: SEQUENCE ⁇ miab-Cell-rl8 ENUMERATED ⁇ true ⁇ OPTIONAL, - Need R miab-Cell-Velocity-rl8 OCTET STRING OPTIONAL, -Need R miab-Cell-Velocity-threshold Velocity Threshold OPTIONAL, nonCriticalExtension SEQUENCE ⁇ ⁇
  • Velocity Threshold is an integer.
  • a RRC_IDLE/IN ACTIVE UE for a RRC_IDLE/IN ACTIVE UE’s initial cell selection process, there is no difference between a normal UE and a UE attempt to camp on a mobile lAB-node.
  • the UE shall start to scan all RF channels in the NR bands according to its capability and select a suitable cell on a frequency. Once a suitable cell is found, this cell shall be selected, no matter it is a mlAB-cell or a normal cell.
  • the UE can determine whether the selected cell is a mlAB cell or not, the mlAB-cell’s velocity (horizontal and/or vertical (if applicable)), and related velocity information based on the broadcasted information of this suitable cell.
  • the cell reselection priorities may be based on a mobility state of the UE.
  • a mobility state of the UE For inter-frequency cell reselection when mlAB is deployed in a different frequency: If the current cell the UE camps on is a normal cell (i.e. gNB): (1) When the UE is in normal-mobility or medium-mobility state, the UE shall apply the priorities based on cell reselection priority provided either in dedicated signaling or in system information from current cell. The UE shall consider mlAB-cells as lowest priority, the mlAB-cells with zero or low velocity.
  • the UE When the UE is in High-mobility state (as determined by the rate of cell crossing), it indicates that the UE performs cell reselection frequently within a short period, i.e. a UE on the moving vehicle is not camped on the mlAB-cell provided by the moving vehicle, and is performing cell reselection among gNBs outside of the moving vehicle.
  • the UE shall consider the mlAB -cells (no matter velocity is zero or not) to be the highest priority for cell reselection (i.e. higher than any other network configured priority) if there is a mlAB-cell visible to the UE.
  • the UE may also determine whether to consider a mlAB-cell as highest priority during inter-frequency cell reselection based on implementation.
  • the velocity information of miab-cell may be exchanged from miab-cell’s donor CU to the normal gNB over Xn interface, so that the normal cell can include such information in its SIB.
  • when the current cell the UE camps on is a mlAB-cell: When the UE is in normal-mobility or medium-mobility state, the UE shall consider mlAB- cells whose velocity is not zero or larger than velocity threshold to be the highest priority for cell reselection.
  • the UE can also consider a mlAB-cell always as highest priority if it currently camps on a mobile lAB-cell or read “mlAB-cell” indication in SIB1.
  • mlAB-cell s velocity is larger than velocity threshold, the UE may choose not to perform intra-frequency measurement among non-mlAB-cells or cells with equal/lower priority for inter-frequency case.
  • one bit indication representing velocity of mlAB-cell larger than certain threshold is configured true: (l a) if mlAB-cell fulfils Srxlev > SlntraSearchP and Squal > SlntraSearchQ for intra-frequency (Srxlev > SnonlntraSearchP and Squal > SnonintraSearchQ for inter-frequency), then if mlAB-cell velocity indication is set to true, the UE may choose not to perform intra-frequency measurement among non-mlAB -cells or cells with equal/lower priority for inter-frequency case.
  • mlAB-cell if mlAB-cell’s velocity indication is set to true, the UE may choose not to perform intra-frequency measurement among non-mlAB-cells or cells with equal/lower priority for inter-frequency case.
  • velocity granular level is broadcasted by mlAB-cell: (lb) if mlAB-cell fulfils Srxlev > SlntraSearchP and Squal > SlntraSearchQ for intra-frequency (Srxlev > SnonlntraSearchP and Squal > SnonintraSearchQ for inter-frequency), then if mlAB-cell is in high/medium velocity level, the UE may choose not to perform intra-frequency measurement among non-mlAB -cells or cells with equal/lower priority for inter-frequency case. (2b) If mlAB-cell is in low velocity level, the UE may choose not to perform intra-frequency measurement among non-mlAB -cells or cells with equal/lower priority for inter-frequency case.
  • the present disclosure provides intra-frequency and equal priority inter-frequency cell reselection criteria. If the UE is currently camped on a mlAB-cell whose velocity is zero or lower than velocity threshold or low velocity level (for scenario 1), the UE shall perform cell ranking among normal cells (cells without “miab-cell” in SIB1) according to the cell-ranking criterion defined in TS38.304. The UE will not consider miab- cells during cell ranking. If the highest-ranking cell is better than the serving mlAB-cell according to the cell reselection criteria during a time interval, the new cell can be selected.
  • the UE if the UE is currently camped on a mlAB-cell whose velocity is not zero or larger than velocity threshold or high/medium velocity level (for scenario 3/4), the UE only considers cell reselection among mlAB-cells with same/similar velocity or same velocity level (i.e. cell with miab-cell broadcasted in its SIB1).
  • the UE may additionally: (Option 1) Rank the cells based on the R criteria defined in TS38.304 and calculate R values using averaged RSRP results among neighbouring mlAB-cells.
  • a measurement threshold is configured to the UE in current mlAB-ceH’ s system information, the UE then calculates the velocity gap between mlAB-cell and each mlAB-cell that are above the measurement threshold.
  • the UE shall perform cell reselection to the mlAB-cell with smallest velocity gap if the new cell is better than the serving mlAB-cell during a time interval.
  • Velocity gap abs(current mlAB-ceH’s velocity - neighbouring mlAB-cell’s velocity); mlAB-cell’s velocity here is the relative speed to a certain angle.
  • (Option 3) calculate velocity gap between mlAB-cell and each neighboring mlAB-cell that fulfil cell selection criterion.
  • a velocity gap threshold is configured to the UE in current mlAB-cell’ s system information. The UE first ranks the cells based on the R criteria defined in TS38.304. Then the neighboring mlAB-cell which is larger than velocity gap will be removed from the cell reselection list. In the end, the UE shall perform cell reselection to the highest ranked cell in the remaining neighboring mlAB-cells if the new cell is better than the serving mlAB-cell during a time interval.
  • (Option 4) perform cell ranking following TS38.304 among mlAB-cells with same/similar velocity or same velocity level.
  • the velocity gap threshold and measurement threshold can be configured to the UE over SIB2 or SIB3/4 of the current cell.
  • a mlAB-node may broadcast a single bit indication to let UE know whether the UE can stop or reduce measurement related to handover in connected, cell reselection in Idle and perform cell reselection between a fixed gNB and mlAB if necessary.
  • This single bit indication can be based whether mlAB is moving or not. If mlAB- node is moving, the UE may not perform cell reselection between fixed and mlAB nodes.
  • This indication can be broadcast or sent to the UE in dedicated signaling. The broadcast can be in SIB or the information can be sent in a Paging message.
  • Relative distance between mlAB-node and UE is quite small compared with the ellipse of the Earth, mlAB-node and the UE are assumed to be in the same horizontal plane.
  • Relative distance square root of ((degreesLatitude of mlAB-node - degreesLatitude of UE) 2 + (degreesLongitude of mlAB-node - degreesLongitude of UE) 2 + (height of mlAB-node - height of UE) 2 ).
  • Option 1 The UE performs cell-ranking criterion first based on measurement result among all neighboring cells that fulfil the cell selection criterion.
  • the UE is configured with a measurement threshold over system information. Based on the ranking results, the UE filters the neighboring cells that are above measurement threshold and performs cell reselection to the lowest relative distance cell, if the new cell is better than the serving cell.
  • Option 2 The UE first calculates the relative distance between each neighboring mlAB-cell that fulfill the cell selection criterion.
  • a relative distance threshold is configured to the UE over system information.
  • the UE first filters out the neighboring cells that are above threshold, then perform cell-ranking criterion for the remaining neighboring cells.
  • the UE shall perform cell reselection to the highest ranked cell, if the new cell is better than the serving cell.
  • location information can also be sent over paging message.
  • SIB modification may be optimized.
  • velocity (and/or location information) of the mlAB-node is broadcasted in SIB1
  • velocity/measurement related thresholds of neighboring cell reselection are also configured in SIB2/3/4.
  • the modification period co-efficiency of system information can be n2/n4/n8/nl6, and the shortest paging cycle is 32rf.
  • This configured velocity change threshold can also be broadcasted together with velocity of mlAB-node in its system information, e.g. “miab-Cell-Velocity-ModificationRange”, so that the UE knows a rough range of mlAB-node’s velocity.
  • the mlAB-cell update its velocity information in SIB when the velocity level is changed, e.g. from high to medium, etc.
  • L3 filtering may also be applied to velocity of mlAB-cell, where lAB-donor CU provides related configuration to mlAB-MT over RRC signaling or to mlAB-DU over FlAP.An example of changes is shown as below, with the miab-Cell-Velocity-ModificationRange being new:
  • SIBl-vl800-IEs :: SEQUENCE ⁇ miab-Cell-rl 8 ENUMERATED ⁇ true ⁇ OPTIONAL, - Need R miab-Cell-Velocity-rl8 OCTET STRING OPTIONAL, -Need R miab-Cell-Velocity-threshold Velocity Threshold OPTIONAL, miab-Cell-Velocity-ModificationRange INTEGRER (0, 1, ... 1024)
  • Table 2 below shows the GNB DU resource configuration defined by TS38.473 at Section 9.2.9.3, with the new velocity modification range added.
  • Table 2 GNB DU resource configuration defined by TS38.473 at Section 9.2.9.3
  • the mlAB-DU is proposed to update such information only when it performs topology migration towards a new parent lAB-node (either intra-topology or inter-topology). Similar to a velocity modification range, a location modification range can also be used when location information of mlAB-node is broadcasted in system information of a mlAB-node.
  • mlAB node identification and authorization may be performed.
  • the mobile lAB-node may also need to provide a mobile IAB- node indication to core network, indicating it is a mobile lAB-node rather a fixed lAB-node, so that the CN can provide enhanced services (e.g. tracking area update, etc.) accordingly.
  • the mlAB-MT sends mobile IAB -indication “miab-Nodelndication” in RRCSetupComplete to the RAN node when integrating with its parent IAB -node/IAB -donor.
  • the IAB -donor should send Mobile IAB Node Indication message to AMF in INITIAL UE MESSAGE over NG interface.
  • AMF/MME may perform authorization and send “MIAB- Authorized” indication to NG-RAN node (i.e. lAB-donor) over INITIAL CONTEXT SETUP REQUEST or CONTEXT MODIFICATION REQUEST message for lAB-MT’s UE context setup/update.
  • a ml AB node may be configured with a service time during which period the mlAB-cell can provide communication to UEs. Beyond the service time, mlAB-cell doesn’t need to provide service to UEs.
  • mlAB-node is turned off beyond service time, i.e. not broadcasting any information for UE to select. During its service time, it starts to broadcast SIB information as well as its service time (e.g. service time is part of SIB) for UE to select.
  • SIB information as well as its service time (e.g. service time is part of SIB) for UE to select.
  • Another option is that mlAB-node always broadcast its SIB information, including service time. When UE performs cell selection and the corresponding mlAB-cell is beyond its service time, the UE will not select it.
  • the UE can perform cell selection and camp on the mlAB-cell if the cell selection criteria is met.
  • the UE does not need to perform measurement to intra/inter frequency cells.
  • the UE can start measurement to intra/inter- frequency neighboring cells when the time is close to the end of ml AB -cell’s service time or after mlAB-cell’s service time.
  • start measurement for cell reselection can also be broadcasted by mlAB-cell.
  • the mlAB -cells with longer service time may be considered with higher priority during cell reselection.
  • mlAB mobile lAB-node
  • the deployed mobile lAB-node needs to migrate between different lAB-donor CUs.
  • the UEs also move together with the connected mlAB.
  • the UE does not need to perform handover procedure as normal.
  • the mlAB and its served UEs can perform handover towards the new lAB-donor CU simultaneously, i.e. handover of the UEs connecting to mlAB depends on the migration of the mlAB.
  • the present disclosure provides a method to support full migration of a mobile IAB- node together with its served UEs from one lAB-donor CU to another, by changing both Uu and Fl termination.
  • the mlAB moves around, due to moving out of the coverage of source lAB-donor CU, it needs to migrate from lAB-donor CUI to lAB-donor CU2 completely, i.e. both Uu termination of mlAB-MT and Fl termination of mlAB-DU change to the new lAB-donor CU.
  • the mlAB’s served UEs considering the security keys of the connected UEs are changed when moving from lAB-donor CUI to IAB- donor CU2, also need to perform handover procedure under the new lAB-donor CU, although the target cell that those UEs are connected to are still under the same mlAB-DU.
  • An example handover process is defined below.
  • Step 1 The source lAB-donor CU configures the measurement procedure to mobile IAB-MT, and optionally configures measurement procedure to mlAB-node’s served UEs.
  • the mlAB-MT reports according to the measurement configuration. If configured, the served UEs may also report according to the measurement configuration if applicable and mlAB-node may group them and send Group UL RRC Message Transfer to the source lAB-donor CU or send separately for the received served UEs’ measurement report.
  • Step 2 The source lAB-donor CU decides to handover the mlAB-node and its served UEs, based on MeasurementReport and RRM information of mlAB-MT.
  • Step 3 The source lAB-donor CU issues separate or a Group Handover Request message to the target lAB-donor CU passing transparent RRC containers of mlAB-MT and its served UEs with necessary information to prepare the handover of mlAB-MT and served UEs at the target side.
  • the information includes at least the target cell ID, C-RNTI of the mlAB- MT and its served UEs in the source lAB-donor CU, RRC configuration, etc of mlAB-MT and its served UEs.
  • the target lAB-donor CU may not request UE context setup towards mobile IAB- DU.
  • the RRC containers e.g. the part configured by DU, for example, cell group configuration
  • each served UE received in separate or group handover request message may be reused by the target lAB-donor CU.
  • Step 4 Admission Control may be performed by the target lAB-donor CU for mlAB- MT and its served UEs.
  • the target lAB-donor CU may reject some of the served UEs or some DRBs of the served UEs if it cannot be supported.
  • Step 5 The source lAB-donor CU sends a mlAB-DU resource coordination request to the target lAB-donor CU, including a request to use the same cell identity, cell configuration, etc. This step can also be performed before step 4 or as part of step 3.
  • the source lAB-donor CU also send the existing PCI value(s) used by mlAB-DU cell(s) to target IAB -donor CU to check if there could be a PCI(s) conflict.
  • Step 6 The target lAB-donor CU sends a mlAB-DU resource coordination response to the source lAB-donor CU, including the response of using the same cell identity, cell configuration and DU resource configuration, etc. If different cell identity and DU related configuration, etc are used, it also includes the new configuration of mlAB-DU in the target lAB-donor CU.
  • the target lAB-donor CU check if PCI value(s) used by mlAB-DU cell(s) is conflicted with existing PCI values used by neighboring cells under itself (i.e. cells under the target lAB-donor CU, including one that HO was requested and its neighboring cells). If conflicted, either inform the selected new PCI to mlAB-DU or inform mlAB-DU to select a new PCI by itself within the pre-configured list.
  • Step 7 If different cell identity and configuration is used for mlAB-DU, the source lAB-donor CU sends a gNB-DU RESOURCE CONFIGURATION message to the mlAB-DU, including the updated activated cell information and cell resource configuration, etc.
  • the mlAB-DU should temporarily stores the related configuration and execute after sending RRCReconfiguration messages to all served UEs (i.e. step 21). This step can also be performed before step 12 or as part of step 8.
  • the PCI update in Steps 5-7, or parts of it, may be skipped if the source lAB-donor CU, based on Xn connectivity and neighbor relation with the neighboring NG-RAN nodes, is certain that there would no PCI collision when the full migration of this mlAB node happens toward a specific target cell.
  • the source lAB-donor CU once an mlAB node is attached to it, could be configured to inform the neighboring NG-RAN nodes of the updated served cell information including the cells served by this mlAB node, so that any possible PCI confliction (by the full migration of this mlAB node) could be detected in advance and the PCI values of the cells of the neighboring NG-RAN node who detected potential PCI confliction could be re-assigned in advance (so that the full migration could happen toward this NG-RAN node without having to re-assign PCI values to the mlAB-DU).
  • the served cell update indication message toward the neighboring NG-RAN node over XnAP e.g. NG-RAN NODE CONFIGURATION UPDATE message
  • an indicator could be defined for the included served cell information to distinguish that this specific served cell information is from mlAB node (not a regular cell), so that it can be taken into account by the receiving peer.
  • Step 8 The target lAB-donor CU prepares the handover with L1/L2 and sends the Group Handover Request Acknowledge to the source lAB-donor CU, which includes transparent containers to be sent to the mlAB-MT and its served UEs as their corresponding RRC message to perform handover.
  • target lAB-donor CU may generate handover acknowledgement:
  • mlAB-DU may already provide the served UEs’ DU contexts for the target side when it triggers the collocated mlAB-MT HO.
  • the target lAB-donor CU sends UE context setup request to the mlAB-DU via some path, (e.g. via source lAB-donor CU), since Fl tunnel between target lAB-donor CU and mlAB-DU is not established.
  • the mlAB-DU provides UE context setup response over the same path (e.g. via source lAB-donor CU).
  • Option 3 The source lAB-donor CU generates it autonomously without contacting DU based on some information in the CU.
  • Step 9 The source lAB-donor CU triggers the Uu handover for mlAB-MT by sending an RRCReconfiguration message to IAB-MT, containing the information required to access the target cell in the target lAB-donor CU: at least target cell ID, new C-RNTI, security algorithm identifiers for selected security algorithms. It can also include a set of dedicated RRC configuration, RACH resources, the association between RACH resources and SSBs, etc.
  • Step 10 The source lAB-donor CU sends the SN STATUS TRANSFER message of mlAB-MT to the target lAB-donor CU to convey the uplink PDCP SN receiver status and the downlink PDCP SN transmitter status of DRBs of mlAB-MT for which PDCP status preservation applies.
  • Step 12 The source lAB-donor CU may release BH RLC channels and BAP-sublayer routing entries on the source path between source parent lAB-node of the migrating mlAB- node and the source lAB-donor DU. Step 12 may be executed after step 17.
  • Steps 9/12 could be done by one shot, e.g. via F1AP UE Context Modification procedure.
  • Step 13 The IAB-MT synchronizes to the target lAB-donor CU and completes the RRC handover procedure by sending RRCReconfigurationComplete message to target lAB- donor CU.
  • the IAB-MT releases the source resources and configurations and stops DL/UL reception/transmission towards the source lAB-donor CU directly.
  • Step 14 The source lAB-donor CU sends the GROUP SN STATUS TRANSFER message of served UEs’ of mlAB-node to the target lAB-donor CU to convey the uplink PDCP SN receiver status and the downlink PDCP SN transmitter status of DRBs of served UEs of mlAB-node for which PDCP status preservation applies.
  • the target may inform the source that the HO of mlAB was successful (e.g. HO SUCCESS message) so that the source can be safe to trigger GROUP SN STATUS TRANSER message for its served UEs.
  • Step 15a The target lAB-donor CU sends a PATH SWTICH REQUEST message to AMF to trigger 5GC to switch the DL data path towards the target lAB-donor CU for the MT and establish an NG-C interface instance towards the target lAB-donor CU. This step can be performed in parallel with step 18.
  • Step 16a 5GC switches the DL data path towards the target lAB-donor CU.
  • the UPF sends one or more "end marker" packets on the old path to the source lAB-donor CU per PDU session/tunnel and then can release any U-plane/TNL resources towards the source lAB-donor CU.
  • the AMF confirms the PATH SWITCH REQUEST message with the PATH SWITCH REQUEST ACKNOWLEDGE message for mlAB-MT. This step can be performed in parallel with step 18.
  • Step 16b 5GC switches the DL data path of the served UEs of mlAB-node and mlAB- MT towards the target lAB-donor CU.
  • the UPF sends one or more "end marker" packets on the old path to the source lAB-donor CU per PDU session/tunnel and then can release any U- plane/TNL resources towards the source lAB-donor CU.
  • the AMF confirms the GROUP PATH SWITCH REQUEST message with the GROUP PATH SWITCH REQUEST ACKNOWLEDGE message for the served UEs of mlAB-node and mlAB-MT. This step can be performed in parallel with step 18.
  • Step 17 The target lAB-donor CU sends a UE CONTEXT RELEASE message to inform the source gNB about the success of the handover of mlAB-MT.
  • the source gNB can then release radio and C-plane related resources associated to the mlAB-MT’ s UE context. Any ongoing data forwarding may continue.
  • Step 18 If PCI is not changed, the target lAB-donor CU configures BH RLC channels and BAP sublayer routing entries on the target path between the migrating mlAB-node and target lAB-donor DU, etc.
  • the Fl-C connection between the migrating mlAB-node and the source lAB-donor CU may be switched to the target path using the new TNL address information of the migrating mlAB-node.
  • the migrating lAB-node may report the new TNL address information it wants to use for each Fl-U tunnel and non-UP traffic type to the source lAB-donor-CU via the gNB-DU CONFIGURATION UPDATE message. Otherwise, if PCI is changed by target lAB-donor CU, step 18 performs after step 21 (step 19/20 may be skipped).
  • Step 19 If step 15b and step 16b is performed, the target lAB-donor CU resumes DL traffic transmission of mlAB-node’ s served UEs to mlAB-DU.
  • Step 20 If step 15b and step 16b is performed, the mlAB-DU temporarily stores the received DL data for its served UEs from the target lAB-donor CU.
  • Step 21 The mlAB-DU triggers the Uu handover of its served UEs by sending RRCReconfiguration messages stored at step 11 to the served UEs.
  • the RRCReconfiguration messages for the served UE also includes a RACH-less handover configuration, including a pre-allocated RRC configured UL grant, target TA, etc.
  • step 7 If different cell identity and resource configuration is used for mlAB-DU in step 7, the mlAB-DU adopts the new cell identity and gNB-DU Resource Configuration from target lAB- donor CU after step 21 . Otherwise, if different cell identity is used by mlAB-DU, step 18-20 are performed after sending RRCReconfiguration message to served UEs in step 21.
  • Step 22 If RACH-less handover is not configured to the served UEs, the UEs synchronize to the target cell via RACH procedure and completes the RRC handover procedure by sending RRCReconfigurationComplete message to target gNB. If RACH-less handover is configured to the served UEs, the UEs skip RACH and send the RRCReconfigurationComplete message directly to the target gNB in the pre-allocated UL grant.
  • Step 23 The mlAB-DU sends a Group UL RRC MESSAGE TRANSFER message to the target lAB-donor CU to convey the received RRCReconfigurationComplete messages from its served UEs.
  • Step 24a If step 15a/16a is performed, the target lAB-donor CU sends a GROUP PATH SWTICH REQUEST message to AMF to trigger 5GC to switch the DL data path of the served UEs of mlAB-node towards the target lAB-donor CU and establish an NG-C interface instance towards the target lAB-donor CU. 5GC switches the DL data path of the served UEs of mlAB- node towards the target lAB-donor CU.
  • the UPF sends one or more "end marker" packets on the old path to the source lAB-donor CU per PDU session/tunnel and then can release any U- plane/TNL resources towards the source lAB-donor CU.
  • the AMF confirms the GROUP PATH SWITCH REQUEST message with the GROUP PATH SWITCH REQUEST ACKNOWLEDGE message for the served UEs of mlAB-node and mlAB-MT.
  • Step 24b If step 15b/16b is performed, the mlAB-DU resumes DL traffic towards the served UEs by starting to send stored DL traffic at step 19.
  • Step 25 The target lAB-donor CU resumes UL/DL traffic towards the served UES of mlAB-node.
  • Step 26 The target lAB-donor CU sends a GROUP UE CONTEXT RELEASE message to inform the source gNB about the success of the handover of served UEs.
  • the source gNB can then release radio and C-plane related resources associated to the served UEs’ context. Any ongoing data forwarding may continue.
  • a mlAB-DU resource coordination between source and target lAB-donor CU are provided.
  • the source lAB-donor CU coordinates with the target lAB-donor CU via Xn interface, where the message is proposed to include I) the purpose/cause of requesting resource coordination 2) whether the source lAB- donor CU requests to reuse the same PCI and resource allocation for the migrating lAB-node 3) mlAB-DU’s resource information allocated by source lAB-donor CU 4) cell group configuration of mlAB-DU (i.e.
  • gNB-DU System Information including physical cell group configuration, MAC cell group configuration, RLC bearer information, etc., either as a RRC container or with specific IES defined in Xn message corresponding to IEs in CellGroupConfig in TS38.331.
  • the cause can be set to “resource optimization” or a new event; if resource coordination is for inter-donor CU full migration purpose, the cause can be set to “handover desirable for radio reasons” or a new event.
  • the proposed new field “reuse source mlAB-DU resource configuration” can be set to true without including boundary node cells’ and parent nodes’ information, this also indicates that the same cell group configuration is used in the target lAB-donor CU for the migrating mlAB-DU; otherwise, the target lAB-donor CU should set the new field “reuse source mlAB-DU resource configuration” to false and indicates mlAB-DU’s resource configuration in the target lAB-donor CU to the source lAB-donor CU.
  • the source lAB-donor CU will release the Fl towards mlAB-node, and mlAB-DU request to setup Fl connection to the target IAB- donor CU, where the new configuration of mlAB-DU in target IAB -donor CU is configured.
  • the target IAB -donor CU allocates the same PCI and resource configuration to the mlAB-node, all served UEs performs intra-cell handover with security key change during mlAB-node’s migration, i.e. MasterKeyChange is present and keySetChangelndicator may be set to true in the corresponding RRCReconfiguration message.
  • masterCellGroup of the served UEs i.e. master cell is mlAB-DU cell
  • the existing IAB RESOURCE COORDINATION REQUEST/RESPONSE message is proposed to extend its usage from resource multiplexing to inter-donor CU full migration and include information listed above.
  • a new IAB FULL MIGRATION RESOURCE COORDINATION REQUEST/RESPONSE can be defined and used for mlAB-node’s resource coordination during inter-donor CU full migration for information listed above.
  • An example of enhancement to existing IAB resource coordination procedure is shown below with the enhancements underlined:
  • the purpose of the IAB Resource Coordination procedure is to exchange the semi-static radio resource configuration pertaining to a boundary lAB-node, between the Fl -terminating lAB-donor-CU and the non-Fl -terminating lAB- donor CU of a boundary lAB-node, for the purpose of resource multiplexing and inter-donor CU full migration.
  • the procedure can be initiated by the
  • mlAB-node i.e. mlAB-MT
  • the velocity of mlAB-node can either be measured over GNSS or based on the number of handed-over cell during a certain period.
  • a new event “velocity” e.g. Event V 1 is proposed to be used to configure mlAB-MT to report its velocity to lAB-donor CU.
  • the ml AB -MT may: consider the entering condition for this event to be satisfied when condition VI-
  • Vm is velocity of the mlAB-node, not taking into account any offsets.
  • Hys is the hysteresis parameter for this event (i.e. hysteresis as defined within reportConfigNR for this event).
  • Thresh is the threshold parameter of this event (i.e. as defined within reportConfigNR for this event).
  • This mlAB velocity information could be used by the donor CU to configure the RRC Connected UEs with applicable measurement configuration to aid mobility to and from mlAB node. It could also be used to identify the UEs moving to or from an mlAB node and trigger a HO for these UEs.
  • RRC_CONNECTED UEs following configurations are considered from the network side to decide handover of the legacy UEs between gNBs and mlAB-node:
  • the UEs performs measurement and report measurement result to the network according to gNB’s configuration (e.g. event A5 triggered measurement report, etc).
  • gNB e.g. event A5 triggered measurement report, etc.
  • the reported measurement result of mlAB-node is expected to be better than connected gNB.
  • the measurement report e.g. RSRP, RSRQ, SINR
  • gNB decides to handover the UE to mlAB-node.
  • the lAB-donor CU deactivates the measurement configuration of neighbouring normal gNBs for the served UEs under a mlAB-node via RRC signaling (e.g. RRCReconfiguration message during handover from gNB to mlAB-node).
  • RRC signaling e.g. RRCReconfiguration message during handover from gNB to mlAB-node.
  • mlAB-MT when mlAB-MT’s velocity is lower than certain threshold, it triggers mlAB-MT reports its current velocity to lAB-donor CU. Since the mlAB- node is getting slower (i.e. going to stop), there might be some UEs need to get off the vehicle and handover to the normal gNB.
  • lAB-donor CU may configure the served UEs of mlAB-node with measurement configuration towards neighbouring normal gNBs. Based on the measurement results, the network can decide handover the UEs moving out of the vehicle to normal gNB. Scenario 4: move together with the vehicle, change from one mlAB-node to another mlAB-node on the same vehicle
  • the lAB-donor CU may configure the served UE of a mlAB-node to perform measurement for other mlAB-nodes which are served by the same lAB-donor CU or with the same velocity. Based on the measurement report and/or the mlAB velocity, the UE can be handed- over from one mlAB-node to another.
  • lAB-donor CU can: add normal gNB cells in excludeCellsToAddModList of MeasObjectNR add mlAB-node with the same lAB-donor CU in allowedCellsToAddModList of MeasObjectNR
  • the lAB-donor CU can ignore the measurement reports from the served UEs, unless it receives measurement report from mlAB-MT when its velocity is lower than certain threshold or zero.
  • a mlAB-DU is proposed to send its collocated lAB-MT’s velocity to the served UEs. This could be via RRC, MAC CE or physical layer signaling.
  • the served UEs Upon receiving the velocity information from mlAB-DU, it is considered as part of a new measurement event for the served UEs to report its measurement result to the network. Otherwise, the served UEs don’t need to send measurement report to the network.
  • EventV2 can be defined as below:
  • the UE shall:
  • Vm is velocity of the connected mlAB-node, not taking into account any offsets.
  • Hys is the hysteresis parameter for this event (i.e. hysteresis as defined within reportConfigNR for this event)
  • Thresh is the threshold parameter of this event (i.e. as defined within reportConfigNR for this event)
  • the velocity is only sent to the served UEs when mlAB-node’s velocity is zero or the average velocity is below certain threshold over a certain duration. Both velocity threshold and duration can be configured by lAB-donor CU over Fl interface to mlAB-DU.
  • CondEventV2 a conditional handover event
  • Event V2 also applies to CondEvent V2.
  • the served UEs can be configured both CondEventV2 and another CondEvent as conditional execution conditions for normal gNB. When both conditions are met, the served UEs can perform CHO and select the normal gNB.
  • One of these conditional events can be the mlAB velocity and could be based on the absolute velocity or an indication, based for example, on velocity of the mlAB.
  • the lAB-donor CU should not configure other mlAB-cells served under another lAB-donor CU.
  • the candidate mlAB-cell is also configured with two CondEvent (i.e. CondEventV2 and another CondEvent). If CondEventV2 is not met, while the other configured CondEvent is met, the served UEs can perform CHO and select the mlAB-cell for HO (handover).
  • the served UEs via MAC CE or physical layer signaling.
  • the measurement report from the served UE and conditional handover event are decided based on the relative distance between UE and mlAB-node. For example, EventDl and CondEventDl as defined in TS38.331.
  • TA timing advance
  • conditional handover there may be a timing advance (TA)-based handover and conditional handover.
  • TA of the served UEs is proposed as a new measurement event and conditional handover event.
  • TA of the served UE When UE is moving together with mlAB-node (without moving inside the vehicle), TA of the served UE is unchanged or the change is under certain threshold. However, when UE moves inside the vehicle from one mlAB-node to another or UE moves from mlAB-node to gNB, the TA of the served UE under the current serving cell is becoming larger. Therefore, TA of the UE is proposed to be a new measurement event for served UE to send its measurement report to network. If the event of timing advance (e.g. EventTAl) is met, the UE can send measurement report including neighbouring cells’ measurement to the network for handover. Otherwise, the UE can hold the measurement results or not perform measurement to other neighbouring cells.
  • event of timing advance e.g. EventTAl
  • EventTAl can be defined as below:
  • the UE shall:
  • TA is timing advance of the served UE, not taking into account any offsets.
  • Hys is the hysteresis parameter for this event (i.e. hysteresis as defined within reportConfigNR for this event)
  • Thresh is the threshold parameter of this event (i.e. as defined within reportConfigNR for this event)
  • conditional handover event can also be introduced, e.g. CondEventTAl.
  • CondEventTAl The definition of Event TAI also applies to CondEvent TAI.
  • the served UEs can be configured both CondEventTAl and another CondEvent as conditional execution conditions for normal gNB. When both conditions are met, the served UEs can perform CHO and, for example, select the normal gNB.
  • an indication-based measurement there may be an indication-based measurement.
  • an indicator for activating/deactivating measurements of neighboring gNBs could be defined in system information and broadcasted by an mlAB-node so that, when it is set to "on", the UEs connected through this mlAB-node stop such measurements and only performs when the indicator is set to "off".
  • the indicator in system information can be set accordingly by the mlAB-DU based on its own velocity or pre-planned trajectory configured by OAM.
  • the UEs connected through this mlAB-node could be configured by the lAB-donor- CU to perform measurements only at some specific time intervals in future (e.g. when the vehicle is expected to stop for people hops in or out) without the lAB-donor-CU having to activate/deactivate measurements for the UEs on the fly based on the velocity of the mlAB- node.
  • the PCI of mlAB-DU cell might be changed due to collision. It is proposed that the source IAB -donor CU to negotiate with target lAB-donor CU before Fl setup of mlAB-DU, same for the gNB-DU resource configuration. If the same resource and PCI can be used, mlAB-DU can directly re-use the existing PCI value and serving cell information to request Fl setup towards target lAB-donor CU in step 18 of Figure 1 before sending RRCReconfiguration messages to the served UEs.
  • the mlAB-DU cell should temporarily store the received new PCI and gNB-DU resource configuration from source lAB-donor CU in step 7 and only use it after sending RRCReconfiguration messages to the served UEs. Therefore, mlAB-DU should request Fl setup using new PCI value and configured gNB-DU resource configuration from target lAB-donor CU after sending RRCReconfiguation message to the served UEs.
  • Fl setup procedure can proceed and new PCI value can be assigned to mlAB-DU via Fl SETUP RESPONSE before sending RRCReconfiguration to the served UEs.
  • the mlAB-DU starts to use new PCI values for its cells after sending RRCReconfiguration message to the UEs.
  • the timer for successful HO T304 has to be configured appropriately to allow UE to perform a successful RACH after the mlAB DU has updated the configuration based on Fl setup procedure.
  • DL user data may be pre-sent and stored at a mlAB DU before RRCReconfiguration is complete for UEs served by mlAB’s.
  • RRCReconfiguration is complete for UEs served by mlAB’s.
  • PCI and gNB-DU resource configuration unchanged scenario it is proposed to resume served UEs’ DL traffic before the completion of RRC reconfiguration of the served UEs towards the target lAB-donor CU.
  • the handover procedure of served UEs i.e. served UEs to receive RRCReconfiguration message from source lAB-donor CU
  • the served UEs may experience DL traffic service interruption since mlAB-node performs full migration procedure.
  • target lAB-donor CU To reduce DL service interruption, it is proposed to allow target lAB-donor CU to sends the served UEs’ DL traffic to mlAB-node right after successful Fl setup between mlAB-node and itself, where served UEs’ DL traffic is temporarily stored at the mlAB-node.
  • a Group SN Status Transfer message of served UEs are sent by the source lAB-donor CU to the target lAB-donor CU before RRCReconfiguration messages are received by the served UEs.
  • the Group Path Switch procedure of the served UEs may also be triggered before successful handover, where it allows the target lAB-donor CU to receive expected served UEs’ traffic earlier and meanwhile resume UEs’ DL traffic.
  • the mlAB-node After a mlAB-node receives successful RACH from the served UEs (including RACH- less, 4-step RACH, 2-step RACH), the mlAB-node starts to transmit the stored DL traffic to the corresponding served UEs.
  • RACH-less handover of mlAB nodeserved UEs.
  • RACH-less handover is proposed to be supported for the served UEs.
  • the target lAB-donor CU configures the served UEs with RACH-less configuration, including UL grant and TA. Because the mlAB node of the serving UEs does not change during the mlAB HO procedure, the previous UE configuration, including TA is likely to be valid even after the mlAB HO procedure. Hence it is sufficient to simply perform a change of security keys as part of this HO procedure. The change of security keys can be done with only impacting the user plane. Identification of the user data with the old and new keys can be done using either new C-RNTI or after a L2 reset of the MAC and RLC. An RRC or MAC signaling could be used for this purpose.
  • the deployed mobile lAB-node (mlAB) needs to migrate between different lAB-donor CUs. Meanwhile, the UEs also move together with the connected mlAB. However, since the UEs are inside the vehicle and its connection can be still maintained towards the same mlAB, the UE does not need to perform handover procedure as normal. The mlAB and its served UEs can perform handover towards the new IAB -donor CU simultaneously, i.e. handover of the UEs connecting to mlAB depends on the migration of the ml AB.
  • a mlAB-node should be able to provide service continuously to its served UEs. Therefore, reducing service interruption and reduce signaling overhead towards served UEs during mlAB’s full migration is important in improving system performance.
  • the present disclosure proposes several solutions to reduce service interruption for the served UEs, by considering 1) redirecting traffic from target lAB-donor CU to source lAB-donor CU when served UEs are still generating UL data with source security keys; 2) conditional DU resource configuration for mobile IAB-DU; 3) conditional handover configuration for served UEs; 4) establish dual Fl termination between mobile IAB-DU and source/target lAB-donor CU during full migration of mobile lAB-node. Solutions to solve PCI collision of mobile IAB-DU are also proposed. The proposed solutions herein can optimize network performance in terms of reducing service interruption and avoid PCI collision during mobile lAB-node migrating between different lAB-donor CUs.
  • Option 1 Reserve unique mlAB-DU cell PCI space for each lAB-donor CU managed by the same OAM (Unchanged PCI of mlAB-node).
  • OAM reserves a space for PCI allocation towards mlAB-nodes.
  • Each lAB-donor CU managed by the same OAM is configured with a specific/unique range of PCI values that can be allocated for the cells of mlAB-nodes, which does not overlap with each other.
  • one lAB-donor CU cannot use a PCI value from the values that has been assigned to the other lAB-donor CUfor the cells of mlAB-nodes.
  • PCI 0-199 are reserved by 0AM for mlAB-nodes under the same PLMN, and lAB-donor CU 1-10 of the same 0AM share the same reserved PCI space.
  • NCGI space for each lAB-donor CU is shown as below in Table 3.
  • a unique PCI is selected by lAB-donor CUI to the mlAB-node and configured via Fl setup or gNB-CU Configuration Update.
  • mlAB-node moves to another lAB-donor CU (e.g. lAB-donor CU3), the PCI of mlAB-node is proposed to be unchanged.
  • 0AM may configure the PCI for the mlAB directly.
  • Each mlAB node is provided with a unique PCI that will not conflict with another PCI in the whole PLMN.
  • Option 2 Reserved PCI space for each mlAB-DU by 0AM (unchanged PCI of mlAB- node within a geographical area).
  • a list of reserved PCIs is configured to mlAB-DU by 0AM.
  • the list of PCIs configured towards the mlAB-DU is not overlapped with other gNBs or other mlAB- DUs.
  • Each PCI in the configured list can either be mapped to one lAB-donor CU or a configured geographical area (e.g. area ID).
  • the PCI of mlAB will not be changed/conflicted if mlAB-node is inside the corresponding lAB-donor CU or geographical area.
  • the target lAB-donor CU When migrating from one lAB-donor CU to another lAB-donor CU, if PCI collision is detected by the target lAB-donor CU, the target lAB-donor CU will inform the mlAB-node about the PCI collision.
  • the target lAB-donor CU can also send available or used PCI list of the target lAB-donor CU to the mlAB-DU for reference.
  • the mlAB-node shall then select another reserved PCI from the reserved list which maps to the selected target lAB-donor CU or corresponding geographical area.
  • mlAB- DU's cells reuse the existing PCI values assigned by the source lAB-donor CU.
  • the PCI values are assigned based on geographical areas, it can be mapped to the tracking area of mlAB-MT.
  • the PCI values of the cells of the mlAB-DU can be updated by itself.
  • the cell identity of mlAB-node in each lAB-donor CU is assigned by OAM without further optimization.
  • mlAB-node full migration, if PCI collision is detected by the target lAB-donor CU, centralized and distributed PCI assignment used by SON are used to solve PCI collision with other gNB/mlAB-DU cells.
  • Option 4 PCI negotiation between two lAB-donor CU.
  • the PCI update may be skipped if the source lAB-donor CU, based on Xn connectivity and neighbor relation with the neighboring NG-RAN nodes, is certain that there would no PCI collision when the full migration of this mlAB node happens toward a specific target cell.
  • the source lAB-donor CU once an mlAB node is attached to it, could be configured to inform the neighboring NG-RAN nodes of the updated served cell information including the cells served by this mlAB node, so that any possible PCI conflict (by the full migration of this mlAB node) could be detected in advance and the PCI values of the cells of the neighboring NG-RAN node who detected potential PCI confliction could be re-assigned in advance (so that the full migration could happen toward this NG-RAN node without having to re-assign PCI values to the mlAB-DU).
  • the served cell update indication message toward the neighboring NG-RAN node over XnAP e.g. NG-RAN NODE CONFIGURATION UPDATE message
  • an indicator could be defined for the included served cell information to distinguish that this specific served cell information is from mlAB node (not a regular cell), so that it can be taken into account by the receiving peer.
  • the RRC Reconfiguration messages of mlAB’s served UEs are sent after mlAB-MT’ s successful RACH. Therefore, the mlAB’s served UEs are still using the security keys configured by source lAB-donor CU before they receive their RRCReconfiguration messages from mobile IAB-DU.
  • Target lAB-donor CU receives packets generated by the UE with source lAB-donor CU configured security key.
  • Option 1 Mobile lAB-node to discard any UL packets received from UE during the period (release of BAP route between mlAB and source IAB -donor ⁇ -> mlAB sends RRCReconfiguration messages to its served UEs).
  • Option 2 mlAB stops UL grant to its served UEs after release of BAP route towards source IAB -donor and resumes UL grant after successful RACH of its served UEs to stop UE from sending UL data.
  • Option 3 Redirect packets via target lAB-donor CU
  • the target lAB-donor After receiving the RRCReconfigurationComplete message from the mobile lAB-node, the target lAB-donor initiates IAB TRANSPORT MIGRATION MANAGEMENT REQUEST to the source lAB-donor.
  • a tunnel is established between target lAB-donor CU and source lAB-donor CU to allow target lAB-donor CU to redirect any received packets (PDCP PDUs) to source lAB-donor CU.
  • mlAB After receiving the RRCReconfiguration message from mlAB, mlAB’s served UEs perform RACH (if RACH is configured) and/or send RRCReconfigurationComplete message to mlAB.
  • an indication of the received UL packets is introduced to help network understand whether the packets are generated with the security key of source lAB-donor CU or with the new security keys from the target lAB-donor CU.
  • the indication is proposed to be added in the BAP header (a new field parameter in BAP data PDU) at mobile IAB-MT if the packets are received from the served UE during the following period:
  • an END MARKER control PDU is generated by mlAB’s BAP layer and is forwarded to the target lAB-donor CU, indicating it stops receiving any packets with source security key.
  • the source lAB-donor CU may indicate the target lAB-donor CU that it is safe to deliver UL packets received from the target lAB-donor DU from there.
  • the decrypted packets can also be sent from the source CU to the target CU for re-ordering if the PDCP SN of the received packets has gaps.
  • the target lAB-donor CU can trigger the release of established IP tunnel any time after it receives an end-maker control PDU from mobile lAB-node.
  • the new S/T field indicates whether the corresponding BAP PDU carries a packet to be redirected to source lAB-donor CU by target lAB-donor DU or to be forwarded to target lAB-donor CU.
  • Table 5 shows an example of the S/T field.
  • This message is sent by an Fl -terminating lAB-donor-CU to a non-Fl-terminating lAB-donor- CU of a boundary lAB-node or sent by a target lAB-donor CU to the source lAB-donor CU of a mobile lAB-node, for the purpose of setting up, modifying, or releasing (e.g., for the purpose of revoking) the configuration for the migration of boundary and descendant node traffic between two lAB-donor-CUs.
  • This message is sent by the non-Fl-terminating lAB-donor-CU to the Fl -terminating lAB- donor-CU of a boundary lAB-node or sent by a source lAB-donor CU to the target lAB-donor CU of a mobile lAB-node to provide inter-donor transport related configurations for the offloaded traffic.
  • non-Fl-terminating donor CU Fl-terminating donor CU or source lAB-donor CU to target lAB-donor CU.
  • the lAB-donor CU that is responsible for conditional DU resource configuration is the corresponding lAB-donor CU of CHO candidate cell for the mlAB-MT.
  • the source lAB-donor CU can send PCI value and gNB-DU resource configuration, together with mlAB-MT CHO request, to the candidate, indicating a request of conditional mlAB-DU migration.
  • the candidate lAB-donor CU first performs admission control to mlAB- MT. If resource for mlAB-MT can be reserved, it then checks whether the requested same PCI and gNB-DU resource configuration can be reserved or not.
  • the candidate lAB-donor CU sends response to source lAB-donor CU with confirmation of using the same PCI and gNB-DU configuration by mlAB-DU when the collocated mlAB-MT performs CHO towards it. Moreover, an indication of using the same configuration/PCI should be included in the corresponding CHO configuration message.
  • the candidate lAB-donor CU sends the updated PCI and/or gNB-DU resource configuration to source lAB-donor CU, together with CHO configuration of mlAB-MT.
  • Option 1 The conditional mlAB-DU resource configuration over F1AP.
  • a conditional DU resource configuration procedure over F1AP is proposed in this option.
  • a Source lAB-donor CU configures mlAB-DU with a list of candidate lAB-donor CU, each item has its own identity (e.g. condDUReconfigld) corresponding to the condReconfigld of mlAB- MT. If the same lAB-donor CU is used by mlAB-MT’s CHO candidate cell, one condDUReconfigld is mapped to multiple condReconfigld of mlAB-MT.
  • the source lAB-donor CU set “same configuration” into “true” and send conditional DU resource message to mlAB-DU, together with collocated mlAB-MT’s conditional mobility information.
  • the source IAB- donor CU set “same configuration” into “false” and send the reserved conditional DU resource information to mlAB-DU over conditional DU resource configuration message, together with collocated mlAB-MT’s conditional mobility information.
  • the mlAB-DU adopts the conditional DU resource configuration of CondDUReconfigld corresponding to CondReconfigld.
  • Option 2 The conditional mlAB-DU resource configuration over RRC signaling
  • the lAB-donor CU can also use CondReconfig message to carry conditional DU resource configuration and send it to the mlAB-MT over RRC signaling.
  • CondReconfigToAddModList for the collocated mlAB-DU’s conditional DU configuration, e.g. condDUReconfig.
  • conditional DU resource request/response procedure To request conditional DU resource configuration, a new conditional DU resource request/response procedure is proposed over Xn interface. Alternatively, a new IE “conditional DU resource request/response” is introduced in HANDOVER REQUEST/RESPONSE message.
  • a new PCI of a mlAB-DU may be configured for served UEs during RRCReconfiguration.
  • the PCI of mlAB-DU might be changed during mlAB- node’s full migration due to PCI collision.
  • the cell in mlAB-DU with new PCI value is treated as a conditional handover cell to the served UEs.
  • Fl termination change it is proposed to setup Fl interface between mlAB-DU and target lAB-donor CU before releasing Fl interface between mlAB-DU and source lAB-donor CU.
  • the mlAB-DU is configured by two lAB-donor CU with different TNL addresses, etc. If same PCI and DU resource configuration can be used by mlAB-DU, a shared BAP/RLC/MAC/PHY can be used at mlAB- DU, while connecting to separate TNL protocol stacks (GTP-u, etc). If different PCI and DU resource configuration is configured to mlAB-DU by different donor CU, mlAB-DU holds two separate BAP/RLC/MAC/PHY layers as well as TNL.
  • Target lAB-donor CU may send an indication to source lAB-donor CU to release its Fl tunnel towards mobile IAB-DU.
  • the separate or group handover procedure of served UEs can perform after successful mlAB-node’s full migration (after mlAB-MT successful HO and mlAB-DU successful Fl setup).
  • source lAB- donor CU then performs handover procedure for the served UEs, and the Fl tunnel between mlAB-DU and source lAB-donor CU is released after successful separate or group handover of served UEs.
  • FIG. 1 is a network diagram illustrating an example network environment 100, in accordance with one or more example embodiments of the present disclosure.
  • Wireless network 100 may include one or more UEs 120 and one or more RANs 102 (e.g., gNBs), which may communicate in accordance with 3GPP communication standards.
  • the UE(s) 120 may be mobile devices that are non- stationary (e.g., not having fixed locations) or may be stationary devices.
  • the UEs 120 and the RANs 102 may include one or more computer systems similar to that of FIGs. 3-5.
  • One or more illustrative UE(s) 120 and/or RAN(s) 102 may be operable by one or more user(s) 110.
  • a UE may take on multiple distinct characteristics, each of which shape its function.
  • a single addressable unit might simultaneously be a portable UE, a quality-of-service (QoS) UE, a dependent UE, and a hidden UE.
  • the UE(s) 120 (e.g., 124, 126, or 128) and/or RAN(s) 102 may include any suitable processor-driven device including, but not limited to, a mobile device or a non-mobile, e.g., a static device.
  • UE(s) 120 may include, a software enabled AP (SoftAP), a personal computer (PC), a wearable wireless device (e.g., bracelet, watch, glasses, ring, etc.), a desktop computer, a mobile computer, a laptop computer, an ultrabookTM computer, a notebook computer, a tablet computer, a server computer, a handheld computer, a handheld device, an internet of things (loT) device, a sensor device, a PDA device, a handheld PDA device, an on-board device, an off-board device, a hybrid device (e.g., combining cellular phone functionalities with PDA device functionalities), a consumer device, a vehicular device, a non-vehicular device, a mobile or portable device, a non-mobile or non-portable device, a mobile phone, a cellular telephone, a PCS device, a PDA device which incorporates a wireless communication device, a mobile or portable GPS device, a DVB device, a relatively small computing device
  • the term “Internet of Things (loT) device” is used to refer to any object (e.g., an appliance, a sensor, etc.) that has an addressable interface (e.g., an Internet protocol (IP) address, a Bluetooth identifier (ID), a near-field communication (NFC) ID, etc.) and can transmit information to one or more other devices over a wired or wireless connection.
  • An loT device may have a passive communication interface, such as a quick response (QR) code, a radio-frequency identification (RFID) tag, an NFC tag, or the like, or an active communication interface, such as a modem, a transceiver, a transmitter-receiver, or the like.
  • QR quick response
  • RFID radio-frequency identification
  • An loT device can have a particular set of attributes (e.g., a device state or status, such as whether the loT device is on or off, open or closed, idle or active, available for task execution or busy, and so on, a cooling or heating function, an environmental monitoring or recording function, a lightemitting function, a sound-emitting function, etc.) that can be embedded in and/or controlled/monitored by a central processing unit (CPU), microprocessor, ASIC, or the like, and configured for connection to an loT network such as a local ad-hoc network or the Internet.
  • a device state or status such as whether the loT device is on or off, open or closed, idle or active, available for task execution or busy, and so on, a cooling or heating function, an environmental monitoring or recording function, a lightemitting function, a sound-emitting function, etc.
  • loT devices may include, but are not limited to, refrigerators, toasters, ovens, microwaves, freezers, dishwashers, dishes, hand tools, clothes washers, clothes dryers, furnaces, air conditioners, thermostats, televisions, light fixtures, vacuum cleaners, sprinklers, electricity meters, gas meters, etc., so long as the devices are equipped with an addressable communications interface for communicating with the loT network.
  • loT devices may also include cell phones, desktop computers, laptop computers, tablet computers, personal digital assistants (PDAs), etc.
  • the loT network may be comprised of a combination of “legacy” Internet-accessible devices (e.g., laptop or desktop computers, cell phones, etc.) in addition to devices that do not typically have Internet-connectivity (e.g., dishwashers, etc.).
  • “legacy” Internet-accessible devices e.g., laptop or desktop computers, cell phones, etc.
  • devices that do not typically have Internet-connectivity e.g., dishwashers, etc.
  • Any of the UE(s) 120 may be configured to communicate with each other via one or more communications networks 130 and/or 135 wirelessly or wired.
  • the UE(s) 120 may also communicate peer-to-peer or directly with each other with or without the RAN(s) 102.
  • Any of the communications networks 130 and/or 135 may include, but not limited to, any one of a combination of different types of suitable communications networks such as, for example, broadcasting networks, cable networks, public networks (e.g., the Internet), private networks, wireless networks, cellular networks, or any other suitable private and/or public networks.
  • any of the communications networks 130 and/or 135 may have any suitable communication range associated therewith and may include, for example, cellular networks.
  • any of the communications networks 130 and/or 135 may include any type of medium over which network traffic may be carried including, but not limited to, coaxial cable, twisted-pair wire, optical fiber, a hybrid fiber coaxial (HFC) medium, microwave terrestrial transceivers, radio frequency communication mediums, white space communication mediums, ultra-high frequency communication mediums, satellite communication mediums, or any combination thereof.
  • any of the UE(s) 120 (e.g., UE 124, 126, 128) and RAN(s) 102 may include one or more communications antennas.
  • the one or more communications antennas may be any suitable type of antennas corresponding to the communications protocols used by the UE(s) 120 (e.g., UEs 124, 126 and 128), and RAN(s) 102.
  • suitable communications antennas include cellular antennas, 3GPP family of standards compatible antennas, directional antennas, non-directional antennas, dipole antennas, folded dipole antennas, patch antennas, multiple-input multiple-output (MIMO) antennas, omnidirectional antennas, quasi-omnidirectional antennas, or the like.
  • the one or more communications antennas may be communicatively coupled to a radio component to transmit and/or receive signals, such as communications signals to and/or from the UEs 120 and/or RAN(s) 102.
  • Any of the UE(s) 120 may be configured to perform directional transmission and/or directional reception in conjunction with wirelessly communicating in a wireless network.
  • Any of the UE(s) 120 e.g., UE 124, 126, 128), and RAN(s) 102 may be configured to perform such directional transmission and/or reception using a set of multiple antenna arrays (e.g., DMG antenna arrays or the like). Each of the multiple antenna arrays may be used for transmission and/or reception in a particular respective direction or range of directions.
  • Any of the UE(s) 120 (e.g., UE 124, 126, 128), and RAN(s) 102 may be configured to perform any given directional transmission towards one or more defined transmit sectors. Any of the UE(s) 120 (e.g., UE 124, 126, 128), and RAN(s) 102 may be configured to perform any given directional reception from one or more defined receive sectors.
  • MIMO beamforming in a wireless network may be accomplished using RF beamforming and/or digital beamforming.
  • UE 120 and/or RAN(s) 102 may be configured to use all or a subset of its one or more communications antennas to perform MIMO beamforming.
  • any of the UE 120 may include any suitable radio and/or transceiver for transmitting and/or receiving radio frequency (RF) signals in the bandwidth and/or channels corresponding to the communications protocols utilized by any of the UE(s) 120 and RAN(s) 102 to communicate with each other.
  • the radio components may include hardware and/or software to modulate and/or demodulate communications signals according to pre-established transmission protocols.
  • the radio components may further have hardware and/or software instructions to communicate via one or more 3GPP protocols and using 3GPP bandwidths.
  • the radio component may include any known receiver and baseband suitable for communicating via the communications protocols.
  • the radio component may further include a low noise amplifier (LNA), additional signal amplifiers, an analog-to-digital (A/D) converter, one or more buffers, and digital baseband.
  • LNA low noise amplifier
  • A/D analog-to-digital converter
  • one or more of the UE 120 may exchange frames 140 with the RANs 102.
  • the frames 140 may include messages between mlABs 150, the UEs 120, the RANs 102, and the like, related to mlAB integration, cell selection and reselection, and the like as described herein.
  • FIG. 2 illustrates a flow diagram of a mobile integrated access and backhaul (mlAB) topology integration 200 using an enhanced setup response, in accordance with one or more example embodiments of the present disclosure.
  • mlAB mobile integrated access and backhaul
  • the mlAB topology integration 200 may include a mlAB-node 202, a lAB-donor 204, and a core network (CN) 206.
  • the CN 206 may send a next generation (NG) setup response 208 (including a mlAB supported IE indicating mlAB support) to the lAB- donor 204.
  • the lAB-donor 204 may send the mlAB support 210 indicator in SIB 1 .
  • the mlAB node 202 and the lAB-donor 204 then may perform a topology integration as described above.
  • a RAN 302 and a mlAB 304 are shown.
  • a UE 306 with RRCJDLE or RRCJNACTIVE is on the mlAB 304, and moves out of the mlAB 304 on the right side of FIG. 3A, when the UE 306 is expected to select or reselect a normal cell on which to camp.
  • FIG. 3B illustrates an example velocity-based cell selection and reselection for the RRC_IDLE and the RRC_INACTIVE user equipment 306 of FIG. 3 A before and after moving into the mlAB 304 of FIG. 3A, in accordance with one or more example embodiments of the present disclosure.
  • FIG. 3D illustrates an example velocity-based cell selection and reselection for the RRC_IDLE and the RRC_INACTIVE user equipment 306 of FIG. 3 A while the mlAB 304 of FIG. 3A moves between lAB-donors, in accordance with one or more example embodiments of the present disclosure.
  • the UE 306 is moving inside the mlAB 304 from coverage of one mlAB node to another.
  • FIG. 4 illustrates a flow diagram of a mlAB message flow 400, in accordance with one or more example embodiments of the present disclosure.
  • FIG. 5A illustrates a flow diagram of a mlAB message flow 500 for physical cell identifier (PCI) management, in accordance with one or more example embodiments of the present disclosure.
  • PCI physical cell identifier
  • the mlAB message flow 500 may include a mlAB 502, a lAB- donor 504, a lAB-donor 506, and an 0AM 508.
  • the 0AM 508 may reserve 510 PCI spaces for lAB-donor CUs for the mlAB 502.
  • the 0AM 508 may assign 512 unique PCIs for the mlAB 502 under the lAB-donor 506.
  • the 0AM 508 may assign 514 unique PCIs for the mlAB 502 under the lAB-donor 504.
  • the mlAB 502 may perform a IAB-MT setup 516 with the lAB-donor 504.
  • the lAB-donor 504 and the lAB-donor 506 may assign a temporary PCI for the mlAB initial integration.
  • the mlAB 502 use a Fl setup 520 using the temporary PCI.
  • the lAB-donor 504 may detect the Fl setup, and may reallocate a new PCI.
  • the lAB-donor 504 may send a gNB-CU configuration update 524 to the mlAB 502, which may use 526 the new unique PCI.
  • FIG. 5B illustrates a flow diagram of a mlAB message flow 550 for PCI management, in accordance with one or more example embodiments of the present disclosure.
  • the mlAB message flow 550 may include the 0AM 508 of FIG. 5A reserving 552 PCI spaces for lAB-donor CUs for the mlAB 502 of FIG. 5A.
  • the 0AM 508 may assign 554 unique PCIs for the mlAB 502.
  • the mlAB 502 perform an IAB-MT setup 556 with the lAB-donor 504, and the lAB-donor 504 may establish 558 a BH RLC CH with the mlAB 502.
  • the mlAB 502 may select one assigned PCI from a configured list, and may perform a Fl setup 562 using the assigned PCI with the lAB-donor 504.
  • the mlAB 502 may send a mlAB-MT HO request 564 to the lAB-donor 506, which may respond to the lAB-donor 504 with a HO ACK 566.
  • the lAB-donor 504 may perform RRCReconfiguration 568 with the mlAB 502.
  • the mlAB 502 may perform a Fl setup 570 using the existing PCI.
  • the lAB- donor 506 may detect a PCI collision, and may inform 574 the mlAB 502 with PCI list and request selection of a non-conflicting PCI.
  • the mlAB 502 may select a new assigned PCI from the configured list, and may provide a gNB-DU configuration update 578 to the lAB-donor 506.
  • FIG. 6A illustrates a flow diagram of a mlAB message flow 600 for IAB transport migration, in accordance with one or more example embodiments of the present disclosure.
  • the message flow 600 includes a UE 602, a UE 604, a UE 606, a mlAB 608, an lAB- donor 610, and an lAB-donor 612 performing steps 614-644, which represent at least a subset of the steps described above with respect to TS38.423 for an IAB transport migration management request.
  • FIG. 6B illustrates a flow diagram of a mlAB traffic flow for a conditional mlAB distributed unit resource configuration 650, in accordance with one or more example embodiments of the present disclosure.
  • the mlAB-DU resource configuration 650 may include a mlAB- DU 652 and an lAB-donor CU 654, which may send a conditional DU resource configuration 656 (e.g., the conditional mlAB-DU resource configuration over F1AP described above).
  • a conditional DU resource configuration 656 e.g., the conditional mlAB-DU resource configuration over F1AP described above.
  • FIG. 6C illustrates a flow diagram of a mlAB traffic flow for a conditional mlAB distributed unit resource configuration 660, in accordance with one or more example embodiments of the present disclosure.
  • the conditional mlAB distributed unit resource configuration 660 may include a source lAB-donor 662 and a target lAB-donor 664.
  • the source lAB-donor 662 may send a conditional DU resource request 666
  • the target lAB-donor 664 may respond with a conditional DU resource response (e.g., as described above for the conditional mlAB- DU resource configuration over RRC signaling).
  • FIG. 6D illustrates a flow diagram of a mlAB traffic flow 670 for a user equipment handover, in accordance with one or more example embodiments of the present disclosure.
  • the mlAB traffic flow 670 may include the UE 602, the UE 604, the UE 606, the mlAB 608, the lAB-donor 610, and the lAB-donor 612 of FIG. 6A, and includes an AMF 672.
  • the mlAB traffic flow 670 includes steps 614-682, representing at least a portion of Steps 1-26 of the handover described above.
  • FIG. 7A illustrates a flow diagram of a mlAB traffic flow 700 for a user equipment handover, in accordance with one or more example embodiments of the present disclosure.
  • the mlAB traffic flow 700 may include the UE 602, the UE 604, the UE 606, the mlAB 608, the lAB-donor 610, and the lAB-donor 612 of FIG. 6A, performing steps 614-618 and steps 702-708, representing at least a portion of the Fl setup of the mlAB- DU toward a target lAB-donor CU as described above.
  • FIG. 7B illustrates a flow diagram of a mlAB traffic flow for a user equipment handover, in accordance with one or more example embodiments of the present disclosure.
  • the mlAB traffic flow 750 may include the UE 602, the UE 604, the UE 606, the mlAB 608, the lAB-donor 610, and the lAB-donor 612 of FIG. 6A, performing steps 614-618 and steps 702-704, representing at least a portion of the alternative Fl setup of the mlAB-DU toward a target lAB-donor CU as described above.
  • FIG. 8 illustrates a flow diagram of illustrative process for mlAB management 800, in accordance with one or more example embodiments of the present disclosure.
  • a mlAB node may decode a first mlAB support indication received from a first mlAB donor, the first mlAB support indication indicating that the first mlAB donor is configured to serve the mlAB node as a mlAB donor.
  • the mlAB node may decode a second mlAB support indication received from a second mlAB donor, the second mlAB support indication indicating that the second mlAB donor is configured to serve the mlAB node as the mlAB donor.
  • the mlAB node may select the first mlAB donor or the second mlAB donor as the mlAB donor based on the first mlAB support indication or the second mlAB support indication.
  • the communication of mlAB support capabilities, selection of a mlAB donor, handovers, and configurations may be performed according to the embodiments described above.
  • FIG. 9 illustrates a network 900 in accordance with various embodiments.
  • the network 900 may operate in a manner consistent with 3GPP technical specifications for LTE or 5G/NR systems.
  • 3GPP technical specifications for LTE or 5G/NR systems 3GPP technical specifications for LTE or 5G/NR systems.
  • the example embodiments are not limited in this regard and the described embodiments may apply to other networks that benefit from the principles described herein, such as future 3GPP systems, or the like.
  • the network 900 may include a UE 902, which may include any mobile or non-mobile computing device designed to communicate with a RAN 904 via an over-the-air connection.
  • the UE 902 may be communicatively coupled with the RAN 904 by a Uu interface.
  • the UE 902 may be, but is not limited to, a smartphone, tablet computer, wearable computer device, desktop computer, laptop computer, in-vehicle infotainment, in-car entertainment device, instrument cluster, head-up display device, onboard diagnostic device, dashtop mobile equipment, mobile data terminal, electronic engine management system, electronic/engine control unit, electronic/engine control module, embedded system, sensor, microcontroller, control module, engine management system, networked appliance, machine-type communication device, M2M or D2D device, loT device, etc.
  • the network 900 may include a plurality of UEs coupled directly with one another via a sidelink interface.
  • the UEs may be M2M/D2D devices that communicate using physical sidelink channels such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc.
  • the UE 902 may additionally communicate with an AP 906 via an over-the-air connection.
  • the AP 906 may manage a WLAN connection, which may serve to offload some/all network traffic from the RAN 904.
  • the connection between the UE 902 and the AP 906 may be consistent with any IEEE 802.11 protocol, wherein the AP 906 could be a wireless fidelity (Wi-Fi®) router.
  • the UE 902, RAN 904, and AP 906 may utilize cellular- WLAN aggregation (for example, LWA/LWIP).
  • Cellular-WLAN aggregation may involve the UE 902 being configured by the RAN 904 to utilize both cellular radio resources and WLAN resources.
  • the RAN 904 may include one or more access nodes, for example, AN 908.
  • AN 908 may terminate air-interface protocols for the UE 902 by providing access stratum protocols including RRC, PDCP, RLC, MAC, and LI protocols.
  • the AN 308 may enable data/voice connectivity between CN 920 and the UE 902.
  • the AN 908 may be implemented in a discrete device or as one or more software entities running on server computers as part of, for example, a virtual network, which may be referred to as a CRAN or virtual baseband unit pool.
  • the AN 908 be referred to as a BS, gNB, RAN node, eNB, ng- eNB, NodeB, RSU, TRxP, TRP, etc.
  • the AN 908 may be a macrocell base station or a low power base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.
  • the RAN 904 may be coupled with one another via an X2 interface (if the RAN 904 is an LTE RAN) or an Xn interface (if the RAN 904 is a 5G RAN).
  • the X2/Xn interfaces which may be separated into control/user plane interfaces in some embodiments, may allow the ANs to communicate information related to handovers, data/context transfers, mobility, load management, interference coordination, etc.
  • the ANs of the RAN 904 may each manage one or more cells, cell groups, component carriers, etc. to provide the UE 902 with an air interface for network access.
  • the UE 902 may be simultaneously connected with a plurality of cells provided by the same or different ANs of the RAN 904.
  • the UE 902 and RAN 904 may use carrier aggregation to allow the UE 902 to connect with a plurality of component carriers, each corresponding to a Pcell or Scell.
  • a first AN may be a master node that provides an MCG and a second AN may be secondary node that provides an SCG.
  • the first/second ANs may be any combination of eNB, gNB, ng-eNB, etc.
  • the RAN 904 may provide the air interface over a licensed spectrum or an unlicensed spectrum.
  • the nodes may use LAA, eLAA, and/or feLAA mechanisms based on CA technology with PCells/Scells.
  • the nodes Prior to accessing the unlicensed spectrum, the nodes may perform medium/carrier-sensing operations based on, for example, a listen-before-talk (LBT) protocol.
  • LBT listen-before-talk
  • the UE 902 or AN 908 may be or act as a RSU, which may refer to any transportation infrastructure entity used for V2X communications.
  • An RSU may be implemented in or by a suitable AN or a stationary (or relatively stationary) UE.
  • An RSU implemented in or by: a UE may be referred to as a “UE-type RSU”; an eNB may be referred to as an “eNB-type RSU”; a gNB may be referred to as a “gNB-type RSU”; and the like.
  • an RSU is a computing device coupled with radio frequency circuitry located on a roadside that provides connectivity support to passing vehicle UEs.
  • the RSU may also include internal data storage circuitry to store intersection map geometry, traffic statistics, media, as well as applications/software to sense and control ongoing vehicular and pedestrian traffic.
  • the RSU may provide very low latency communications required for high speed events, such as crash avoidance, traffic warnings, and the like. Additionally or alternatively, the RSU may provide other cellular/WLAN communications services.
  • the components of the RSU may be packaged in a weatherproof enclosure suitable for outdoor installation, and may include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller or a backhaul network.
  • the RAN 904 may be an LTE RAN 910 with eNBs, for example, eNB 912.
  • the LTE RAN 910 may provide an LTE air interface with the following characteristics: SCS of 15 kHz; CP-OFDM waveform for DL and SC-FDMA waveform for UL; turbo codes for data and TBCC for control; etc.
  • the LTE air interface may rely on CSI- RS for CSI acquisition and beam management; PDSCH/PDCCH DMRS for PDSCH/PDCCH demodulation; and CRS for cell search and initial acquisition, channel quality measurements, and channel estimation for coherent demodulation/detection at the UE.
  • the LTE air interface may operating on sub-6 GHz bands.
  • the RAN 904 may be an NG-RAN 914 with gNBs, for example, gNB 916, or ng-eNBs, for example, ng-eNB 918.
  • the gNB 916 may connect with 5G-enabled UEs using a 5G NR interface.
  • the gNB 916 may connect with a 5G core through an NG interface, which may include an N2 interface or an N3 interface.
  • the ng-eNB 918 may also connect with the 5G core through an NG interface, but may connect with a UE via an LTE air interface.
  • the gNB 916 and the ng-eNB 918 may connect with each other over an Xn interface.
  • the NG interface may be split into two parts, an NG user plane (NG-U) interface, which carries traffic data between the nodes of the NG-RAN 914 and a UPF 948 (e.g., N3 interface), and an NG control plane (NG-C) interface, which is a signaling interface between the nodes of the NG-RAN 914 and an AMF 944 (e.g., N2 interface).
  • NG-U NG user plane
  • N-C NG control plane
  • the NG-RAN 914 may provide a 5G-NR air interface with the following characteristics: variable SCS; CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL; polar, repetition, simplex, and Reed-Muller codes for control and LDPC for data.
  • the 5G-NR air interface may rely on CSI-RS, PDSCH/PDCCH DMRS similar to the LTE air interface.
  • the 5G-NR air interface may not use a CRS, but may use PBCH DMRS for PBCH demodulation; PTRS for phase tracking for PDSCH; and tracking reference signal for time tracking.
  • the 5G- NR air interface may operating on FR1 bands that include sub-6 GHz bands or FR2 bands that include bands from 24.25 GHz to 52.6 GHz.
  • the 5G-NR air interface may include an SSB that is an area of a downlink resource grid that includes PSS/SSS/PBCH.
  • the 5G-NR air interface may utilize BWPs for various purposes.
  • BWP can be used for dynamic adaptation of the SCS.
  • the UE 902 can be configured with multiple BWPs where each BWP configuration has a different SCS. When a BWP change is indicated to the UE 902, the SCS of the transmission is changed as well.
  • Another use case example of BWP is related to power saving.
  • multiple BWPs can be configured for the UE 902 with different amount of frequency resources (for example, PRBs) to support data transmission under different traffic loading scenarios.
  • a BWP containing a smaller number of PRBs can be used for data transmission with small traffic load while allowing power saving at the UE 902 and in some cases at the gNB 916.
  • a BWP containing a larger number of PRBs can be used for scenarios with higher traffic load.
  • the RAN 904 is communicatively coupled to CN 920 that includes network elements to provide various functions to support data and telecommunications services to customers/subscribers (for example, users of UE 902).
  • the components of the CN 920 may be implemented in one physical node or separate physical nodes.
  • NFV may be utilized to virtualize any or all of the functions provided by the network elements of the CN 920 onto physical compute/storage resources in servers, switches, etc.
  • a logical instantiation of the CN 920 may be referred to as a network slice, and a logical instantiation of a portion of the CN 920 may be referred to as a network sub-slice.
  • the CN 920 may be an LTE CN 922, which may also be referred to as an EPC.
  • the LTE CN 922 may include MME 924, SGW 926, SGSN 928, HSS 930, PGW 932, and PCRF 934 coupled with one another over interfaces (or “reference points”) as shown. Functions of the elements of the LTE CN 922 may be briefly introduced as follows.
  • the MME 924 may implement mobility management functions to track a current location of the UE 902 to facilitate paging, bearer activation/deactivation, handovers, gateway selection, authentication, etc.
  • the SGW 926 may terminate an SI interface toward the RAN and route data packets between the RAN and the LTE CN 922.
  • the SGW 926 may be a local mobility anchor point for inter- RAN node handovers and also may provide an anchor for inter-3 GPP mobility. Other responsibilities may include lawful intercept, charging, and some policy enforcement.
  • the SGSN 928 may track a location of the UE 902 and perform security functions and access control. In addition, the SGSN 928 may perform inter-EPC node signaling for mobility between different RAT networks; PDN and S-GW selection as specified by MME 924; MME selection for handovers; etc.
  • the S3 reference point between the MME 924 and the SGSN 928 may enable user and bearer information exchange for inter-3GPP access network mobility in idle/active states.
  • the HSS 930 may include a database for network users, including subscription-related information to support the network entities’ handling of communication sessions.
  • the HSS 930 can provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, etc.
  • An S6a reference point between the HSS 930 and the MME 924 may enable transfer of subscription and authentication data for authenticating/authorizing user access to the LTE CN 920.
  • the PGW 932 may terminate an SGi interface toward a data network (DN) 936 that may include an application/content server 938.
  • the PGW 932 may route data packets between the LTE CN 922 and the data network 936.
  • the PGW 932 may be coupled with the SGW 926 by an S 5 reference point to facilitate user plane tunneling and tunnel management.
  • the PGW 932 may further include a node for policy enforcement and charging data collection (for example, PCEF).
  • the SGi reference point between the PGW 932 and the data network 936 may be an operator external public, a private PDN, or an intra-operator packet data network, for example, for provision of IMS services.
  • the PGW 932 may be coupled with a PCRF 934 via a Gx reference point.
  • the PCRF 934 is the policy and charging control element of the LTE CN 922.
  • the PCRF 934 may be communicatively coupled to the app/content server 938 to determine appropriate QoS and charging parameters for service flows.
  • the PCRF 932 may provision associated rules into a PCEF (via Gx reference point) with appropriate TFT and QCI.
  • the CN 920 may be a 5GC 940.
  • the 5GC 940 may include an AUSF 942, AMF 944, SMF 946, UPF 948, NSSF 950, NEF 952, NRF 954, PCF 956, UDM 958, and AF 960 coupled with one another over interfaces (or “reference points”) as shown.
  • Functions of the elements of the 5GC 940 may be briefly introduced as follows.
  • the AUSF 942 may store data for authentication of UE 902 and handle authentication- related functionality.
  • the AUSF 942 may facilitate a common authentication framework for various access types.
  • the AUSF 942 may exhibit an Nausf service-based interface.
  • the AMF 944 may allow other functions of the 5GC 940 to communicate with the UE 902 and the RAN 904 and to subscribe to notifications about mobility events with respect to the UE 902.
  • the AMF 944 may be responsible for registration management (for example, for registering UE 902), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization.
  • the AMF 944 may provide transport for SM messages between the UE 902 and the SMF 946, and act as a transparent proxy for routing SM messages.
  • AMF 944 may also provide transport for SMS messages between UE 902 and an SMSF.
  • AMF 944 may interact with the AUSF 942 and the UE 902 to perform various security anchor and context management functions.
  • AMF 944 may be a termination point of a RAN CP interface, which may include or be an N2 reference point between the RAN 904 and the AMF 944; and the AMF 944 may be a termination point of NAS (Nl) signaling, and perform NAS ciphering and integrity protection.
  • AMF 944 may also support NAS signaling with the UE 902 over an N3 IWF interface.
  • the SMF 946 may be responsible for SM (for example, session establishment, tunnel management between UPF 948 and AN 908); UE IP address allocation and management (including optional authorization); selection and control of UP function; configuring traffic steering at UPF 948 to route traffic to proper destination; termination of interfaces toward policy control functions; controlling part of policy enforcement, charging, and QoS; lawful intercept (for SM events and interface to LI system); termination of SM parts of NAS messages; downlink data notification; initiating AN specific SM information, sent via AMF 944 over N2 to AN 908; and determining SSC mode of a session.
  • SM may refer to management of a PDU session, and a PDU session or “session” may refer to a PDU connectivity service that provides or enables the exchange of PDUs between the UE 902 and the data network 936.
  • the UPF 948 may act as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point of interconnect to data network 936, and a branching point to support multi-homed PDU session.
  • the UPF 948 may also perform packet routing and forwarding, perform packet inspection, enforce the user plane part of policy rules, lawfully intercept packets (UP collection), perform traffic usage reporting, perform QoS handling for a user plane (e.g., packet filtering, gating, UL/DL rate enforcement), perform uplink traffic verification (e.g., SDF-to-QoS flow mapping), transport level packet marking in the uplink and downlink, and perform downlink packet buffering and downlink data notification triggering.
  • UPF 948 may include an uplink classifier to support routing traffic flows to a data network.
  • the NSSF 950 may select a set of network slice instances serving the UE 902.
  • the NSSF 950 may also determine allowed NSSAI and the mapping to the subscribed S-NSSAIs, if needed.
  • the NSSF 950 may also determine the AMF set to be used to serve the UE 902, or a list of candidate AMFs based on a suitable configuration and possibly by querying the NRF 954.
  • the selection of a set of network slice instances for the UE 902 may be triggered by the AMF 944 with which the UE 902 is registered by interacting with the NSSF 950, which may lead to a change of AMF.
  • the NSSF 950 may interact with the AMF 944 via an N22 reference point; and may communicate with another NSSF in a visited network via an N31 reference point (not shown). Additionally, the NSSF 950 may exhibit an Nnssf service-based interface.
  • the NEF 952 may securely expose services and capabilities provided by 3GPP network functions for third party, internal exposure/re-exposure, AFs (e.g., AF 960), edge computing or fog computing systems, etc.
  • the NEF 952 may authenticate, authorize, or throttle the AFs.
  • NEF 952 may also translate information exchanged with the AF 960 and information exchanged with internal network functions. For example, the NEF 952 may translate between an AF-Service-Identifier and an internal 5GC information.
  • NEF 952 may also receive information from other NFs based on exposed capabilities of other NFs. This information may be stored at the NEF 952 as structured data, or at a data storage NF using standardized interfaces. The stored information can then be re-exposed by the NEF 952 to other NFs and AFs, or used for other purposes such as analytics. Additionally, the NEF 952 may exhibit an Nnef service-based interface.
  • the NRF 954 may support service discovery functions, receive NF discovery requests from NF instances, and provide the information of the discovered NF instances to the NF instances. NRF 954 also maintains information of available NF instances and their supported services. As used herein, the terms “instantiate,” “instantiation,” and the like may refer to the creation of an instance, and an “instance” may refer to a concrete occurrence of an object, which may occur, for example, during execution of program code. Additionally, the NRF 954 may exhibit the Nnrf service-based interface.
  • the PCF 956 may provide policy rules to control plane functions to enforce them, and may also support unified policy framework to govern network behavior.
  • the PCF 956 may also implement a front end to access subscription information relevant for policy decisions in a UDR of the UDM 958.
  • the PCF 956 exhibit an Npcf service-based interface.
  • the UDM 958 may handle subscription-related information to support the network entities’ handling of communication sessions, and may store subscription data of UE 902. For example, subscription data may be communicated via an N8 reference point between the UDM 958 and the AMF 944.
  • the UDM 958 may include two parts, an application front end and a UDR.
  • the UDR may store subscription data and policy data for the UDM 958 and the PCF 956, and/or structured data for exposure and application data (including PFDs for application detection, application request information for multiple UEs 902) for the NEF 952.
  • the Nudr service-based interface may be exhibited by the UDR 921 to allow the UDM 958, PCF 956, and NEF 952 to access a particular set of the stored data, as well as to read, update (e.g., add, modify), delete, and subscribe to notification of relevant data changes in the UDR.
  • the UDM may include a UDM-FE, which is in charge of processing credentials, location management, subscription management and so on. Several different front ends may serve the same user in different transactions.
  • the UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing, user identification handling, access authorization, registration/mobility management, and subscription management.
  • the UDM 958 may exhibit the Nudm service-based interface.
  • the AF 960 may provide application influence on traffic routing, provide access to NEF, and interact with the policy framework for policy control.
  • the 5GC 940 may enable edge computing by selecting operator/3 rd party services to be geographically close to a point that the UE 902 is attached to the network. This may reduce latency and load on the network.
  • the 5GC 940 may select a UPF 948 close to the UE 902 and execute traffic steering from the UPF 948 to data network 936 via the N6 interface. This may be based on the UE subscription data, UE location, and information provided by the AF 960. In this way, the AF 960 may influence UPF (re)selection and traffic routing.
  • the network operator may permit AF 960 to interact directly with relevant NFs. Additionally, the AF 960 may exhibit an Naf service-based interface.
  • the data network 936 may represent various network operator services, Internet access, or third party services that may be provided by one or more servers including, for example, application/content server 938.
  • FIG. 10 schematically illustrates a wireless network 1000 in accordance with various embodiments.
  • the wireless network 1000 may include a UE 1002 in wireless communication with an AN 1004.
  • the UE 1002 and AN 1004 may be similar to, and substantially interchangeable with, like-named components described elsewhere herein.
  • the UE 1002 may be communicatively coupled with the AN 1004 via connection 1006.
  • the connection 1006 is illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols such as an LTE protocol or a 5G NR protocol operating at mmWave or sub-6GHz frequencies.
  • the UE 1002 may include a host platform 1008 coupled with a modem platform 1010.
  • the host platform 1008 may include application processing circuitry 1012, which may be coupled with protocol processing circuitry 1014 of the modem platform 1010.
  • the application processing circuitry 1012 may run various applications for the UE 1002 that source/sink application data.
  • the application processing circuitry 1012 may further implement one or more layer operations to transmit/receive application data to/from a data network. These layer operations may include transport (for example UDP) and Internet (for example, IP) operations
  • the protocol processing circuitry 1014 may implement one or more of layer operations to facilitate transmission or reception of data over the connection 1006.
  • the layer operations implemented by the protocol processing circuitry 1014 may include, for example, MAC, RLC, PDCP, RRC and NAS operations.
  • the modem platform 1010 may further include digital baseband circuitry 1016 that may implement one or more layer operations that are “below” layer operations performed by the protocol processing circuitry 1014 in a network protocol stack. These operations may include, for example, PHY operations including one or more of HARQ-ACK functions, scrambling/descrambling, encoding/decoding, layer mapping/de-mapping, modulation symbol mapping, received symbol/bit metric determination, multi-antenna port precoding/decoding, which may include one or more of space-time, space-frequency or spatial coding, reference signal generation/detection, preamble sequence generation and/or decoding, synchronization sequence generation/detection, control channel signal blind decoding, and other related functions.
  • PHY operations including one or more of HARQ-ACK functions, scrambling/descrambling, encoding/decoding, layer mapping/de-mapping, modulation symbol mapping, received symbol/bit metric determination, multi-antenna port precoding/decoding, which may
  • the modem platform 1010 may further include transmit circuitry 1018, receive circuitry 1020, RF circuitry 1022, and RF front end (RFFE) 1024, which may include or connect to one or more antenna panels 1026.
  • the transmit circuitry 1018 may include a digital-to-analog converter, mixer, intermediate frequency (IF) components, etc.
  • the receive circuitry 1020 may include an analog-to-digital converter, mixer, TF components, etc.
  • the RF circuitry 1022 may include a low-noise amplifier, a power amplifier, power tracking components, etc.
  • RFFE 1024 may include filters (for example, surface/bulk acoustic wave filters), switches, antenna tuners, beamforming components (for example, phase-array antenna components), etc.
  • transmit/receive components may be specific to details of a specific implementation such as, for example, whether communication is TDM or FDM, in mmWave or sub-6 gHz frequencies, etc.
  • the transmit/receive components may be arranged in multiple parallel transmit/receive chains, may be disposed in the same or different chips/modules, etc.
  • the protocol processing circuitry 1014 may include one or more instances of control circuitry (not shown) to provide control functions for the transmit/receive components.
  • a UE reception may be established by and via the antenna panels 1026, RFFE 1024, RF circuitry 1022, receive circuitry 1020, digital baseband circuitry 1016, and protocol processing circuitry 1014.
  • the antenna panels 1026 may receive a transmission from the AN 1004 by receive-beamforming signals received by a plurality of antennas/antenna elements of the one or more antenna panels 1026.
  • a UE transmission may be established by and via the protocol processing circuitry 1014, digital baseband circuitry 1016, transmit circuitry 1018, RF circuitry 1022, RFFE 1024, and antenna panels 1026.
  • the transmit components of the UE 1004 may apply a spatial filter to the data to be transmitted to form a transmit beam emitted by the antenna elements of the antenna panels 1026.
  • the AN 1004 may include a host platform 1028 coupled with a modem platform 1030.
  • the host platform 1028 may include application processing circuitry 1032 coupled with protocol processing circuitry 1034 of the modem platform 1030.
  • the modem platform may further include digital baseband circuitry 1036, transmit circuitry 1038, receive circuitry 1040, RF circuitry 1042, RFFE circuitry 1044, and antenna panels 1046.
  • the components of the AN 1004 may be similar to and substantially interchangeable with like- named components of the UE 1002.
  • the components of the AN 1008 may perform various logical functions that include, for example, RNC functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling.
  • FIG. 1 1 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein.
  • Figure 11 shows a diagrammatic representation of hardware resources 1100 including one or more processors (or processor cores) 1110, one or more memory/storage devices 1120, and one or more communication resources 1130, each of which may be communicatively coupled via a bus 1140 or other interface circuitry.
  • a hypervisor 1102 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize the hardware resources 1100.
  • the processors 1110 may include, for example, a processor 1112 and a processor 1114.
  • the processors 1110 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radio-frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.
  • CPU central processing unit
  • RISC reduced instruction set computing
  • CISC complex instruction set computing
  • GPU graphics processing unit
  • DSP such as a baseband processor, an ASIC, an FPGA, a radio-frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.
  • the memory/storage devices 1120 may include main memory, disk storage, or any suitable combination thereof.
  • the memory/storage devices 1120 may include, but are not limited to, any type of volatile, non-volatile, or semi-volatile memory such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), Flash memory, solid-state storage, etc.
  • DRAM dynamic random access memory
  • SRAM static random access memory
  • EPROM erasable programmable read-only memory
  • EEPROM electrically erasable programmable read-only memory
  • Flash memory solid-state storage, etc.
  • the communication resources 1130 may include interconnection or network interface controllers, components, or other suitable devices to communicate with one or more peripheral devices 1104 or one or more databases 1106 or other network elements via a network 1108.
  • the communication resources 1130 may include wired communication components (e.g., for coupling via USB, Ethernet, etc.), cellular communication components, NFC components, Bluetooth® (or Bluetooth® Low Energy) components, Wi-Fi® components, and other communication components.
  • Instructions 1150 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 1110 to perform any one or more of the methodologies discussed herein.
  • the instructions 1150 may reside, completely or partially, within at least one of the processors 1110 (e.g., within the processor’s cache memory), the memory/storage devices 1120, or any suitable combination thereof.
  • any portion of the instractions 1 150 may be transferred to the hardware resources 1 100 from any combination of the peripheral devices 1104 or the databases 106. Accordingly, the memory of processors 1110, the memory/storage devices 1120, the peripheral devices 1104, and the databases 1106 are examples of computer-readable and machine-readable media.
  • Example 1 may include an apparatus of a mobile integrated access and backhaul (mlAB) node, the apparatus comprising processing circuitry coupled to storage for storing information associated with mlAB, the processing circuitry configured to: decode a first mlAB support indication received from a first mlAB donor, the first mlAB support indication indicating that the first mlAB donor is configured to serve the mlAB node as a mlAB donor; decode a second mlAB support indication received from a second mlAB donor, the second mlAB support indication indicating that the second mlAB donor is configured to serve the mlAB node as the mlAB donor; and select the first mlAB donor or the second mlAB donor as the mlAB donor based on the first mlAB support indication or the second mlAB support indication.
  • mlAB mobile integrated access and backhaul
  • Example 2 may include the apparatus of example 1 and/or any other example herein, wherein at least one of unified access control or a cell bar are not applied in the selection of the first mlAB donor or the second mlAB donor.
  • Example 3 may include the apparatus of example 1 and/or any other example herein, wherein the first mlAB support indication is based on a Fl-C connection between a network node centralized unit and a network node distribution unit.
  • Example 4 may include the apparatus of example 1 and/or any other example herein, wherein the processing circuitry is further configured to encode a mlAB node indication, to be transmitted to the first mlAB donor in a radio resource control setup complete message, indicating that the mlAB node is mobile.
  • Example 5 may include the apparatus of example 1 and/or any other example herein, wherein the processing circuitry is further configured to detect a neighboring mlAB cell based on a mlAB cell indication in an information element or based on an information element comprising an intra frequency mlAB cell list or an inter frequency mlAB cell list.
  • Example 6 may include the apparatus of example 1 and/or any other example herein, wherein the processing circuitry is further configured to reserve a unique mlAB distribution unit cell physical cell identifier (PCI) space for respective IAB donor centralized units managed by a same operations, administration, and maintenance (OAM).
  • PCI physical cell identifier
  • Example 7 may include the apparatus of example 6 and/or any other example herein, wherein the processing circuitry is further configured to: decode an indication, received from the OAM, that the mlAB node used a conflicting PCI; and select an updated PCI based on the indication received from the OAM.
  • Example 8 may include the apparatus of example 1 and/or any other example herein, wherein the processing circuitry is further configured to configure, during a radio resource control reconfiguration, an updated PCI for user equipment served by the mlAB node.
  • Example 9 may include the apparatus of example 1 and/or any other example herein, wherein the processing circuitry is further configured to handover one or more user equipment to a target IAB donor without using a random access channel (RACH).
  • RACH random access channel
  • Example 10 may include the apparatus of example 1 and/or any other example herein, wherein the selection of the first mlAB donor or the second mlAB donor is based on a velocity of the mlAB node relative to the first mlAB donor or the second mlAB donor, or based on a location of the mlAB node relative to the first mlAB donor or the second mlAB donor.
  • Example 11 may include a computer-readable storage medium comprising instructions to cause processing circuitry of a mobile integrated access and backhaul (mlAB) node, upon execution of the instructions by the processing circuitry, to: decode a first mlAB support indication received from a first mlAB donor, the first mlAB support indication indicating that the first mlAB donor is configured to serve the mlAB node as a mlAB donor; decode a second mlAB support indication received from a second mlAB donor, the second mlAB support indication indicating that the second mlAB donor is configured to serve the mlAB node as the mlAB donor; and select the first mlAB donor or the second mlAB donor as the mlAB donor based on the first mlAB support indication or the second mlAB support indication.
  • mlAB mobile integrated access and backhaul
  • Example 12 may include the apparatus of example 11 and/or any other example herein, wherein at least one of unified access control or a cell bar are not applied in the selection of the first mlAB donor or the second mlAB donor.
  • Example 13 may include the apparatus of example 11 and/or any other example herein, wherein the first mlAB support indication is based on a Fl-C connection between a network node centralized unit and a network node distribution unit.
  • Example 14 may include the apparatus of example 11 and/or any other example herein, wherein execution of the instructions further causes the processing circuitry to encode a mlAB node indication, to be transmitted to the first mlAB donor in a radio resource control setup complete message, indicating that the mlAB node is mobile.
  • Example 15 may include the apparatus of example 1 1 and/or any other example herein, wherein execution of the instructions further causes the processing circuitry to detect a neighboring mlAB cell based on a mlAB cell indication in an information element or based on an information element comprising an intra frequency mlAB cell list or an inter frequency mlAB cell list.
  • Example 16 may include the apparatus of example 11 and/or any other example herein, wherein execution of the instructions further causes the processing circuitry to reserve a unique mlAB distribution unit cell physical cell identifier (PCI) space for respective IAB donor centralized units managed by a same operations, administration, and maintenance (OAM).
  • PCI physical cell identifier
  • Example 17 may include the apparatus of example 16 and/or any other example herein, wherein execution of the instructions further causes the processing circuitry to: decode an indication, received from the OAM, that the mlAB node used a conflicting PCI; and select an updated PCI based on the indication received from the OAM.
  • Example 18 may include the apparatus of example 11 and/or any other example herein, wherein execution of the instructions further causes the processing circuitry to configure, during a radio resource control reconfiguration, an updated PCI for user equipment served by the mlAB node.
  • Example 19 may include the apparatus of example 11 and/or any other example herein, wherein execution of the instructions further causes the processing circuitry to handover one or more user equipment to a target IAB donor without using a random access channel (RACH).
  • RACH random access channel
  • Example 20 may include a method for mobile integrated access and backhaul (mlAB) management, the method comprising: decoding, by processing circuitry of a mlAB node, a first mlAB support indication received from a first mlAB donor, the first mlAB support indication indicating that the first mlAB donor is configured to serve the mlAB node as a mlAB donor; decoding, by the processing circuitry, a second mlAB support indication received from a second mlAB donor, the second mlAB support indication indicating that the second mlAB donor is configured to serve the mlAB node as the mlAB donor; and selecting, by the processing circuitry, the first mlAB donor or the second mlAB donor as the mlAB donor based on the first mlAB support indication or the second mlAB support indication.
  • mlAB mobile integrated access and backhaul
  • Example 21 may include the apparatus of example 20 and/or any other example herein, wherein at least one of unified access control or a cell bar are not applied in the selection of the first mlAB donor or the second mlAB donor.
  • Example 22 may include the apparatus of example 20 and/or any other example herein, further comprising encoding a mlAB node indication, to be transmitted to the first mlAB donor in a radio resource control setup complete message, indicating that the mlAB node is mobile.
  • Example 23 may include the apparatus of example 20 and/or any other example herein, wherein the first mlAB support indication is based on a Fl-C connection between a network node centralized unit and a network node distribution unit.
  • Example 24 may include an apparatus comprising means for: decoding, by a mlAB node, a first mlAB support indication received from a first mlAB donor, the first mlAB support indication indicating that the first mlAB donor is configured to serve the mlAB node as a mlAB donor; decoding, by the processing circuitry, a second mlAB support indication received from a second mlAB donor, the second mlAB support indication indicating that the second mlAB donor is configured to serve the mlAB node as the mlAB donor; and selecting, by the processing circuitry, the first mlAB donor or the second mlAB donor as the mlAB donor based on the first mlAB support indication or the second mlAB support indication.
  • Example 25 may include one or more non-transitory computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of a method described in or related to any of examples 1-24, or any other method or process described herein
  • Example 26 may include an apparatus comprising logic, modules, and/or circuitry to perform one or more elements of a method described in or related to any of examples 1-24, or any other method or process described herein.
  • Example 27 may include a method, technique, or process as described in or related to any of examples 1-24, or portions or parts thereof.
  • Example 28 may include an apparatus comprising: one or more processors and one or more computer readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1-24, or portions thereof.
  • Example 29 may include a method of communicating in a wireless network as shown and described herein.
  • Example 30 may include a system for providing wireless communication as shown and described herein.
  • Example 31 may include a device for providing wireless communication as shown and described herein.
  • At least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, and/or methods as set forth in the example section below.
  • the baseband circuitry as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below.
  • circuitry associated with a UE, base station, network element, etc. as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below in the example section.
  • the word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.
  • the terms “computing device,” “user device,” “communication station,” “station,” “handheld device,” “mobile device,” “wireless device” and “user equipment” (UE) as used herein refers to a wireless communication device such as a cellular telephone, a smartphone, a tablet, a netbook, a wireless terminal, a laptop computer, a femtocell, a high data rate (HDR) subscriber station, an access point, a printer, a point of sale device, an access terminal, or other personal communication system (PCS) device.
  • HDR high data rate
  • the device may be either mobile or stationary.
  • the term “communicate” is intended to include transmitting, or receiving, or both transmitting and receiving. This may be particularly useful in claims when describing the organization of data that is being transmitted by one device and received by another, but only the functionality of one of those devices is required to infringe the claim. Similarly, the bidirectional exchange of data between two devices (both devices transmit and receive during the exchange) may be described as “communicating,” when only the functionality of one of those devices is being claimed.
  • the term “communicating” as used herein with respect to a wireless communication signal includes transmitting the wireless communication signal and/or receiving the wireless communication signal.
  • a wireless communication unit which is capable of communicating a wireless communication signal, may include a wireless transmitter to transmit the wireless communication signal to at least one other wireless communication unit, and/or a wireless communication receiver to receive the wireless communication signal from at least one other wireless communication unit.
  • AP access point
  • An access point may also be referred to as an access node, a base station, an evolved node B (eNodeB), or some other similar terminology known in the art.
  • An access terminal may also be called a mobile station, user equipment (UE), a wireless communication device, or some other similar terminology known in the art.
  • Embodiments disclosed herein generally pertain to wireless networks. Some embodiments may relate to wireless networks that operate in accordance with one of the IEEE 802.11 standards.
  • Some embodiments may be used in conjunction with various devices and systems, for example, a personal computer (PC), a desktop computer, a mobile computer, a laptop computer, a notebook computer, a tablet computer, a server computer, a handheld computer, a handheld device, a personal digital assistant (PDA) device, a handheld PDA device, an onboard device, an off-board device, a hybrid device, a vehicular device, a non- vehicular device, a mobile or portable device, a consumer device, a non-mobile or non-portable device, a wireless communication station, a wireless communication device, a wireless access point (AP), a wired or wireless router, a wired or wireless modem, a video device, an audio device, an audio-video (A/V) device, a wired or wireless network, a wireless area network, a wireless video area network (WVAN), a local area network (LAN), a wireless LAN (WLAN), a personal area network (PAN), a wireless PAN (WPAN),
  • Some embodiments may be used in conjunction with one way and/or two-way radio communication systems, cellular radio-telephone communication systems, a mobile phone, a cellular telephone, a wireless telephone, a personal communication system (PCS) device, a PDA device which incorporates a wireless communication device, a mobile or portable global positioning system (GPS) device, a device which incorporates a GPS receiver or transceiver or chip, a device which incorporates an RFID element or chip, a multiple input multiple output (MIMO) transceiver or device, a single input multiple output (SIMO) transceiver or device, a multiple input single output (MISO) transceiver or device, a device having one or more internal antennas and/or external antennas, digital video broadcast (DVB) devices or systems, multistandard radio devices or systems, a wired or wireless handheld device, e.g., a smartphone, a wireless application protocol (WAP) device, or the like.
  • WAP wireless application protocol
  • Some embodiments may be used in conjunction with one or more types of wireless communication signals and/or systems following one or more wireless communication protocols, for example, radio frequency (RF), infrared (IR), frequency-division multiplexing (FDM), orthogonal FDM (OFDM), time-division multiplexing (TDM), time-division multiple access (TDMA), extended TDMA (E-TDMA), general packet radio service (GPRS), extended GPRS, code-division multiple access (CDMA), wideband CDMA (WCDMA), CDMA 2000, single-carrier CDMA, multi-carrier CDMA, multi-carrier modulation (MDM), discrete multi- tone (DMT), Bluetooth®, global positioning system (GPS), Wi-Fi, Wi-Max, ZigBee, ultra- wideband (UWB), global system for mobile communications (GSM), 2G, 2.5G, 3G, 3.5G, 4G, fifth generation (5G) mobile networks, 3 GPP, long term evolution (LTE), LTE advanced, enhanced data rates for G
  • Embodiments according to the disclosure are in particular disclosed in the attached claims directed to a method, a storage medium, a device and a computer program product, wherein any feature mentioned in one claim category, e.g., method, can be claimed in another claim category, e.g., system, as well.
  • the dependencies or references back in the attached claims are chosen for formal reasons only. However, any subject matter resulting from a deliberate reference back to any previous claims (in particular multiple dependencies) can be claimed as well, so that any combination of claims and the features thereof are disclosed and can be claimed regardless of the dependencies chosen in the attached claims.
  • These computer-executable program instructions may be loaded onto a special-purpose computer or other particular machine, a processor, or other programmable data processing apparatus to produce a particular machine, such that the instructions that execute on the computer, processor, or other programmable data processing apparatus create means for implementing one or more functions specified in the flow diagram block or blocks.
  • These computer program instructions may also be stored in a computer-readable storage media or memory that may direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable storage media produce an article of manufacture including instruction means that implement one or more functions specified in the flow diagram block or blocks.
  • certain implementations may provide for a computer program product, comprising a computer- readable storage medium having a computer-readable program code or program instructions implemented therein, said computer-readable program code adapted to be executed to implement one or more functions specified in the flow diagram block or blocks.
  • the computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational elements or steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions that execute on the computer or other programmable apparatus provide elements or steps for implementing the functions specified in the flow diagram block orblocks.
  • blocks of the block diagrams and flow diagrams support combinations of means for performing the specified functions, combinations of elements or steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that each block of the block diagrams and flow diagrams, and combinations of blocks in the block diagrams and flow diagrams, may be implemented by special-purpose, hardware-based computer systems that perform the specified functions, elements or steps, or combinations of special-purpose hardware and computer instructions.
  • conditional language such as, among others, “can,” “could,” “might,” or “may,” unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain implementations could include, while other implementations do not include, certain features, elements, and/or operations. Thus, such conditional language is not generally intended to imply that features, elements, and/or operations are in any way required for one or more implementations or that one or more implementations necessarily include logic for deciding, with or without user input or prompting, whether these features, elements, and/or operations are included or are to be performed in any particular implementation.
  • circuitry refers to, is part of, or includes hardware components such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group), an Application Specific Integrated Circuit (ASIC), a field-programmable device (FPD) (e.g., a field-programmable gate array (FPGA), a programmable logic device (PLD), a complex PLD (CPLD), a high-capacity PLD (HCPLD), a structured ASIC, or a programmable SoC), digital signal processors (DSPs), etc., that are configured to provide the described functionality.
  • FPD field-programmable device
  • FPGA field-programmable gate array
  • PLD programmable logic device
  • CPLD complex PLD
  • HPLD high-capacity PLD
  • DSPs digital signal processors
  • the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality.
  • the term “circuitry” may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) with the program code used to carry out the functionality of that program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuitry.
  • processor circuitry refers to, is part of, or includes circuitry capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, or recording, storing, and/or transferring digital data.
  • Processing circuitry may include one or more processing cores to execute instructions and one or more memory structures to store program and data information.
  • processor circuitry may refer to one or more application processors, one or more baseband processors, a physical central processing unit (CPU), a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, and/or any other device capable of executing or otherwise operating computer-executable instructions, such as program code, software modules, and/or functional processes.
  • Processing circuitry may include more hardware accelerators, which may be microprocessors, programmable processing devices, or the like.
  • the one or more hardware accelerators may include, for example, computer vision (CV) and/or deep learning (DL) accelerators.
  • CV computer vision
  • DL deep learning
  • application circuitry and/or “baseband circuitry” may be considered synonymous to, and may be referred to as, “processor circuitry.”
  • interface circuitry refers to, is part of, or includes circuitry that enables the exchange of information between two or more components or devices.
  • interface circuitry may refer to one or more hardware interfaces, for example, buses, I/O interfaces, peripheral component interfaces, network interface cards, and/or the like.
  • user equipment refers to a device with radio communication capabilities and may describe a remote user of network resources in a communications network.
  • the term “user equipment” or “UE” may be considered synonymous to, and may be referred to as, client, mobile, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, etc.
  • the term “user equipment” or “UE” may include any type of wireless/wired device or any computing device including a wireless communications interface.
  • network element refers to physical or virtualized equipment and/or infrastructure used to provide wired or wireless communication network services.
  • network element may be considered synonymous to and/or referred to as a networked computer, networking hardware, network equipment, network node, router, switch, hub, bridge, radio network controller, RAN device, RAN node, gateway, server, virtualized VNF, NFVI, and/or the like.
  • computer system refers to any type interconnected electronic devices, computer devices, or components thereof. Additionally, the term “computer system” and/or “system” may refer to various components of a computer that are communicatively coupled with one another. Furthermore, the term “computer system” and/or “system” may refer to multiple computer devices and/or multiple computing systems that are communicatively coupled with one another and configured to share computing and/or networking resources.
  • appliance refers to a computer device or computer system with program code (e.g., software or firmware) that is specifically designed to provide a specific computing resource.
  • program code e.g., software or firmware
  • a “virtual appliance” is a virtual machine image to be implemented by a hypervisor-equipped device that virtualizes or emulates a computer appliance or otherwise is dedicated to provide a specific computing resource.
  • resource refers to a physical or virtual device, a physical or virtual component within a computing environment, and/or a physical or virtual component within a particular device, such as computer devices, mechanical devices, memory space, processor/CPU time, processor/CPU usage, processor and accelerator loads, hardware time or usage, electrical power, input/output operations, ports or network sockets, channel/link allocation, throughput, memory usage, storage, network, database and applications, workload units, and/or the like.
  • a “hardware resource” may refer to compute, storage, and/or network resources provided by physical hardware element(s).
  • a “virtualized resource” may refer to compute, storage, and/or network resources provided by virtualization infrastructure to an application, device, system, etc.
  • network resource or “communication resource” may refer to resources that are accessible by computer devices/systems via a communications network.
  • system resources may refer to any kind of shared entities to provide services, and may include computing and/or network resources. System resources may be considered as a set of coherent functions, network data objects or services, accessible through a server where such system resources reside on a single host or multiple hosts and are clearly identifiable.
  • channel refers to any transmission medium, either tangible or intangible, which is used to communicate data or a data stream.
  • channel may be synonymous with and/or equivalent to “communications channel,” “data communications channel,” “transmission channel,” “data transmission channel,” “access channel,” “data access channel,” “link,” “data link,” “carrier,” “radiofrequency carrier,” and/or any other like term denoting a pathway or medium through which data is communicated.
  • link refers to a connection between two devices through a RAT for the purpose of transmitting and receiving information.
  • instantiate refers to the creation of an instance.
  • An “instance” also refers to a concrete occurrence of an object, which may occur, for example, during execution of program code.
  • Coupled may mean two or more elements are in direct physical or electrical contact with one another, may mean that two or more elements indirectly contact each other but still cooperate or interact with each other, and/or may mean that one or more other elements are coupled or connected between the elements that are said to be coupled with each other.
  • directly coupled may mean that two or more elements are in direct contact with one another.
  • communicatively coupled may mean that two or more elements may be in contact with one another by a means of communication including through a wire or other interconnect connection, through a wireless communication channel or link, and/or the like.
  • information element refers to a structural element containing one or more fields.
  • field refers to individual contents of an information element, or a data element that contains content.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

This disclosure describes systems, methods, and devices for mobile integrated access and backhaul (mIAB) management. A mIAB node may decode a first mIAB support indication received from a first mIAB donor, the first mIAB support indication indicating that the first mIAB donor is configured to serve the mIAB node as a mIAB donor; decode a second mIAB support indication received from a second mIAB donor, the second mIAB support indication indicating that the second mIAB donor is configured to serve the mIAB node as the mIAB donor; and select the first mIAB donor or the second mIAB donor as the mIAB donor based on the first mIAB support indication or the second mIAB support indication.

Description

ENHANCED MOBILE INTEGRATED ACCESS AND BACKHAUL FOR WIRELESS COMMUNICATIONS
CROSS-REFERENCE TO RELATED PATENT APPLICATIONIS)
This application claims the benefit of U.S. Provisional Application No. 63/358,792, filed July 6, 2022, U.S. Provisional Application No. 63/358,818, filed July 6, 2022, U.S. Provisional Application No. 63/358,819, filed July 6, 2022, and U.S. Provisional Application No. 63/422,362, filed November 3, 2022, the disclosures of which are incorporated herein by reference as if set forth in full.
TECHNICAL FIELD
This disclosure generally relates to systems and methods for wireless communications and, more particularly, to mobile integrated access and backhaul.
BACKGROUND
Wireless devices are becoming widely prevalent and are increasingly using wireless channels. The 3rd Generation Partnership Program (3GPP) is developing one or more standards for wireless communications.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a network diagram illustrating an example network environment, in accordance with one or more example embodiments of the present disclosure.
FIG. 2 illustrates a flow diagram of a mobile integrated access and backhaul (mlAB) topology integration using an enhanced setup response, in accordance with one or more example embodiments of the present disclosure.
FIG. 3A illustrates an example velocity-based cell selection and reselection for radio resource control idle (RRC_IDLE) and RRC inactive (RRC_INACTIVE) user equipment before and after moving out of a mlAB, in accordance with one or more example embodiments of the present disclosure.
FIG. 3B illustrates an example velocity-based cell selection and reselection for the RRC_IDLE and the RRC_INACTIVE user equipment of FIG. 3A before and after moving into the mlAB of FIG. 3A, in accordance with one or more example embodiments of the present disclosure.
FIG. 3C illustrates an example velocity-based cell selection and reselection for the RRC_IDLE and the RRC_INACTIVE user equipment of FIG. 3 A while moving together with the mlAB of FIG. 3A, in accordance with one or more example embodiments of the present disclosure.
FIG. 3D illustrates an example velocity-based cell selection and reselection for the RRC_IDLE and the RRC_INACTIVE user equipment of FIG. 3 A while the mlAB of FIG. 3 A moves between lAB-donors, in accordance with one or more example embodiments of the present disclosure.
FIG. 4 illustrates a flow diagram of a mlAB message flow, in accordance with one or more example embodiments of the present disclosure.
FIG. 5A illustrates a flow diagram of a mlAB message flow for physical cell identifier (PCI) management, in accordance with one or more example embodiments of the present disclosure.
FIG. 5B illustrates a flow diagram of a mlAB message flow for PCI management, in accordance with one or more example embodiments of the present disclosure.
FIG. 6A illustrates a flow diagram of a mlAB message flow for IAB transport migration, in accordance with one or more example embodiments of the present disclosure.
FIG. 6B illustrates a flow diagram of a mlAB traffic flow for a conditional mlAB distributed unit resource configuration, in accordance with one or more example embodiments of the present disclosure.
FIG. 6C illustrates a flow diagram of a mlAB traffic flow for a conditional mlAB distributed unit resource configuration, in accordance with one or more example embodiments of the present disclosure.
FIG. 6D illustrates a flow diagram of a mlAB traffic flow for a user equipment handover, in accordance with one or more example embodiments of the present disclosure.
FIG. 7A illustrates a flow diagram of a mlAB traffic flow for a user equipment handover, in accordance with one or more example embodiments of the present disclosure.
FIG. 7B illustrates a flow diagram of a mlAB traffic flow for a user equipment handover, in accordance with one or more example embodiments of the present disclosure.
FIG. 8 illustrates a flow diagram of illustrative process for mlAB management, in accordance with one or more example embodiments of the present disclosure.
FIG 9. illustrates a network, in accordance with one or more example embodiments of the present disclosure.
FIG. 10 schematically illustrates a wireless network, in accordance with one or more example embodiments of the present disclosure. FIG. 11 is a block diagram illustrating components, in accordance with one or more example embodiments of the present disclosure.
DETAILED DESCRIPTION
The following description and the drawings sufficiently illustrate specific embodiments to enable those skilled in the art to practice them. Other embodiments may incorporate structural, logical, electrical, process, algorithm, and other changes. Portions and features of some embodiments may be included in, or substituted for, those of other embodiments. Embodiments set forth in the claims encompass all available equivalents of those claims.
Wireless devices may operate as defined by technical standards. For cellular telecommunications, the 3rd Generation Partnership Program (3GPP) define communication techniques, including an integrated access and backhaul (IAB). IAB was defined in Release 16 of 3GPP within TS 38.401, and uses the increased capacity of higher frequency bands in 5G to provide an alternative to optical cell site backhaul. IAB allows multi-hop backhauling using the same frequencies as user equipment (UE) or a dedicated frequency. IAB antenna systems include IAB nodes and IAB donors. IAB donors terminate backhaul traffic from IAB nodes, which may be backhaul endpoints or relays between the endpoints and an IAB donor. 3GPP Release 17 defines IAB for coverage and capacity enhancement options, including for FR2 (frequency range 2: the millimeter wave 6GHz and higher) of 5G.
In 3GPP Rel-18, one option is to deploy an IAB node into a moving vehicle (i.e. mobile IAB, mlAB), where the connectivity for users/devices could be improved in different environments, e.g. for passengers in buses, car/taxi, or trains, ad-hoc/professional personnel or equipment.
Assuming the on-boarded users are in RRC_IDLE or RRC_INACTIVE state (radio resource control RRC protocol either idle or inactive), when the vehicle is moving, the onboarded users can still detect other gNBs’ signaling. However, those users are supposed to camp on the cell of mobile lAB-node rather than other gNBs, so that the unnecessary cell reselection can be avoided. Therefore, how to perform cell selection and cell reselection for RRC_IDLE/INACITVE UEs on mlAB-node is important and different than a normal UE who camps on a normal cell.
In one or more embodiments, to support new functionalities used by mobile lAB-nodes, a mobile lAB-node can only perform topology integration to the lAB-node or IAB -donor which supports new functionalities used by mobile lAB-node, e.g. group mobility, etc. The differentiation between an I AB -node supporting a ml AB -node as a child node and an IAB- node that does not support a mlAB-node as child node needs to be considered.
In one or more embodiments, the enhanced techniques herein help the RRC_IDLE/INACTIVE UEs avoid unnecessary measurement/cell reselection when it is camped on a mobile lAB-node. Additionally, a new identification may be broadcasted by the lAB-nodes/IAB-donors who support mobile lAB-node functionalities.
In one or more embodiments, a new information element (IE) “miab-support” is introduced to be broadcasted by an IAB-node/I AB -donor to support mlAB-node integration. Additionally, a velocity-based cell selection and reselection is proposed to avoid IDLE/INACTIVE UEs camped on a mlAB-node with unnecessary measurement and cell reselection. The proposed solution can reduce the power consumption for IDLE/INACTIVE UEs who camp on mlAB-node by avoiding them keeping the measurement to gNB surrounding mlAB-node. The enhanced techniques herein can help the mobile lAB-node to integrate into a suitable parent lAB-node/IAB-donor to provide services.
In one or more embodiments, the enhanced techniques herein identify a mobile I AB node integration. By introducing a mobile lAB-node within the IAB topology, new functionalities are introduced to be supported at an lAB-donor, e.g. supporting full migration of a mlAB-node, supporting group mobility of a mlAB-node and its served UEs, etc. An “iab- support” IE introduced in 3GPP Release 16 may not fully represent the functionalities required by a mlAB-node. Such functionalities required by a mlAB-node may not be supported in an IAB node or an lAB-donor. An mlAB-node may not select a suitable parent lAB-node based on the existing identification “iab-support.”
In one or more embodiments, to allow a mobile lAB-node to select a suitable IAB- donor, a new identification “miab-support” is proposed to be broadcasted by the lAB-donor, and supports new functionalities to be able to serve a mlAB-node as an lAB-donor. This new identification can be considered as a new cell bar IE and broadcasted in a PLMN- IdentitylnfoList of SIB1 (system information block 1 - transmitted on a downlink shared channel (DL-SCH) and including information for evaluating when a UE is allowed to access a cell and defining the scheduling of other system information). If the cell is a NPN cell, it is also included in NPN-IdentityInfolist-rl6. Separate indication could also be provided in case of network sharing.
In one or more embodiments, when multiple hops are supported between a mlAB-node and an lAB-donor (i.e. the mlAB-node selects a fixed lAB-node as its direct parent), the identification “miab-support” may also be provided by the fixed lAB-node, so that the mlAB- node or another fixed IAB node can read such information from the fixed lAB-node’s DU. The fixed lAB-node that is connected to an lAB-donor that does not broadcast the new “miab- support” indication should not broadcast this new "miab- support" indication because the IAB- donor may not support integration/cell (re)selection of a mlAB-node. Only the fixed lAB-node who is the direct parent of a mlAB-node may need to broadcast this information. A fixed IAB- node in the middle who only plays as an intermediate lAB-node between the parent of the mlAB-node and the lAB-donor does not need to broadcast this information. This indication can be included in the SIB information of the corresponding fixed lAB-node DU and configured by the lAB-donor CU.
In one or more embodiments, an example of “miab-support” in SIB1 is shown below. The “miab-Support-rl8 ENUMERATED {true} OPTIONAL - Need S” portion is new with respect to 3 GPP TS 38.304:
PLMN -Id entitylnfoList
The IE PLMN-IdentitylnfoList includes a list of PLMN identity information.
PLMN-Id entitylnfoList information element
- ASN1START
- TAG-PLMN-IDENTITYINFOLIST-START
PLMN-IdentitylnfoList :: = SEQUENCE (SIZE (L.maxPLMN)) OF PLMN-Identitylnfo PLMN-Identitylnfo ::= SEQUENCE { plmn-IdcntityList SEQUENCE (SIZE (L.maxPLMN)) OF PLMN-Idcntity, tracking AreaCode Tracking AreaCode OPTIONAL, -- Need R ranac RAN-AreaCode OPTIONAL, -- Need R cellidentity Cellidentity, cellReservedForOperatorUse ENUMERATED {reserved, notReserved},
• • •?
[[ iab-Support-r!6 ENUMERATED {true} OPTIONAL - Need S
]],
[[ trackingAreaList-rl7 SEQUENCE (SIZE (L.maxTAC-rl7)) OF TrackingAreaCode OPTIONAL —
Need R
11,
[[ miab-Support-r!8 ENUMERATED {true} OPTIONAL - Need S
U }
- TAG-PLMN-IDENTITYINFOLIST-STOP
- ASN1STOP
In addition, the miab- support below is new in the PLMN-Identifyinglnfo field descriptions below with respect to 3GPP TS 38.304:
PLMN -Identityinfo field descriptions cellReservedForOperatorUse
Indicates whether the cell is reserved for operator use (per PLMN), as defined in
TS 38.304. This field is ignored by IAB-MT. iab-Support
This field combines both the support of IAB and the cell status for I AB. If the field is present, the cell supports IAB and the cell is also considered as a candidate for cell
(re)selection for lAB-node; if the field is absent, the cell does not support IAB and/or the cell is barred for lAB-node. trackingAreaCode
Indicates Tracking Area Code to which the cell indicated by cellidentity field belongs. The absence of the field indicates that the cell only supports PSCell/SCell functionality (per PLMN). trackingAreaList
List of Tracking Areas to which the cell indicated by cellidentity field belongs. If this field is present, the UE shall ignore trackingAreaCode, if present. Total number of TACs across different PLMNs of the cell cannot exceed max TA C. miab-Support
This field combines both the support of IAB and the cell status for mobile IAB. If the field is present, the cell support mobile IAB and the cell is also considered as a candidate for cell (re)selection for mobile lAB-node; if the field is absent, the cell does not support mobile IAB and/or the cell is barred for mobile lAB-node. In 3GPP TS 38.304, cell status and cell reservation are indicated in the MIB or SIB1 message as specified in TS38.331 by means of following fields, with miab-Support being new: <skip irrelevant content> miab-Support (IE type: "true")
Indicated in SIB1 message. In case of multiple PLMNs or NPNs indicated in SIB1, this field is specified per PLMN or per SNPN.
Similar as 3GPP Rel-16 and Rel-17 lAB-MTs, the following restrictions and cell bars may also not applicable for mobile lAB-MTs, including:
(1) UAC (unified access control)
(2) ignores the cellBarred, cellReservedForOperatorUse, cellReservedForFutureUse, and intraFreqReselection (i.e. treats intraFreqReselection as if it was set to allowed) as defined in TS 38.331.
(3) ignores cellReservedForOtherUse for cell barring determination (i.e. NPN capable IAB-MT considers cellReservedForOtherUse for determination of an NPN-only cell) as defined in TS 38.331.
Moreover, whether an lAB-donor supports functionalities for mobile lAB-node’s integration can be configured by core network over NG interface. A new IE is proposed to he configured in NG Setup Response message from AMF to NG-RAN node, indicating the lAB- donor can support mobile lAB-node’s integration and provide services accordingly.
An example of “Mobile IAB Support” IE in NG interface is shown as below. 3GPP TS 38.413 defines a NG Setup Response, which is a message sent by the AMF to the transfer application layer information for an NG-C interface instance. The direction is AMF to NG RAN node. Table 1 below shows an example of the NG Setup Response message, with the mobile IAB supported element being new.
Table 1: NG Setup Response
Figure imgf000009_0001
In one or more embodiments, when a fixed I AB node (who may potentially be a parent of mlAB nodes) is attached to an lAB-donor (who supports mlAB), the fixed IAB node may be configured during a Fl Setup that the lAB-donor that it is setting up the Fl-C connection with supports mlAB, and thus the fixed IAB node may broadcast “miab-support.” Such configuration can be via the Fl SETUP RESPONSE message, as similarly for the above case of the lAB-donor over NG SETUP RESPONSE message from the AMF. Alternatively, the “miab-support” broadcasted by the fixed lAB-node mentioned above can also be directly encoded by an lAB-donor CU in the system information of a fixed IAB-node’ s cell.
In one or more embodiments, if a mobile IAB-node supports integration/cell (re)selection of another fixed or mobile IAB-node, “miab-support” and/or “iab-support” can be broadcasted in its SIB. Otherwise, mobile IAB -DU should not broadcast “miab-support” and “iab-support” as cell bar information.
In one or more embodiments, to allow full migration of a mlAB-node, the network may also identify whether the integrated IAB-node is a stationary IAB-node or a mobile IAB-node. It is proposed that, during initial access, the mobile IAB-node also sends an indication to the network, indicating it is a mlAB-node, e.g. “mlAB-Nodelndication” in RRCSetupComplete message. The lAB-donor may further send this indication to CN over NG interface, and a “mlAB-authorized” IE can be configured by CN during initial context setup for mlAB-MT.
In one or more embodiments, the cell selection and reselection for RRC_Idle and RRC_Inactive UEs may be velocity based. For a RRC_IDLE/INACTIVE UEs, there are multiple possible scenarios and corresponding expected UE behavior need to be considered: (1). A RRC_IDLE/IN ACTIVE UE moves out of a vehicle with a mlAB-node, the UE is expected to (re)select a normal cell to camp on (before moving out of the vehicle - red line, after moving out of the vehicle - blue line). (2) A RRC_IDLE/INACTIVE UE gets onboard a vehicle with a mlAB-node, the UE is expected to (re)select the cell of mlAB-node to camp on. (3) A RRC_IDLE/INACTIVE UE is within the vehicle with a mlAB-node and moves together with the vehicle (e.g., the relative speed between UE and mlAB-node is zero). The UE is expected not to perform any cell reselection to other mlAB-node or gNB (UE-mlAB link remains unchanged as UE is inside the moving vehicle - green line, but mlAB-node is moved from one lAB-donor to another - red line to blue line). (4) A RRC_IDLE/INACTIVE UE is within the vehicle with multiple mlAB-nodes (e.g. a train with multiple carriages, each carriage has one/more mlAB-node based on coverage), the UE is moving inside the vehicle from the coverage of one mlAB-node to another, the UE is expected to perform cell reselection and camp on another mlAB-node. In one or more embodiments, it may be important for the RRC_IDLE/INACTIVE UE to know the cell information so that it can camp on the suitable cell without unnecessary measurement and cell reselection. For above four listed scenarios, it is observed that, in scenario (1) and (2), the RRC_IDLE/INACTIVE UE will change the cell it camps on from mlAB-node to gNB or from gNB to mlAB-node when the vehicle is not moving and the user is moving outside/inside the vehicle, respectively. The UE should not perform any cell reselection or can only select mlAB-node for cell reselection when the vehicle is moving.
In one or more embodiments, based on the above observation, a mlAB-node’s velocitybased cell (re)selection method is proposed to optimize cell (re)selection of RRC_IDLE/INACTIVE UEs. In the present disclosure, the mlAB-node is proposed to support measurement of its velocity and provide its velocity information as part of the broadcast information in SIB. There are following ways of providing velocity information in SIB1: (1) velocity information provided in OCTET STRING, following the definition in TS37.355. (2) velocity information provided in separate IES, including horizontal speed of the mlAB, vertical speed of the mlAB (if applicable), uncertain of the horizontal and/or vertical speed, horizontal and/or vertical direction of moving vehicle, etc. (3) Velocity information provided at a granular level, e.g., as high, medium, low. Alternatively, velocity information can also be sent over paging message.
In one or more embodiments, a velocity threshold/minimum velocity of mlAB-cell is also proposed to be broadcasted in mlAB’s optionally. Alternatively, the mlAB cell can consider its velocity and threshold together and broadcast an indication whether velocity is below or above the threshold. Additionally, to differentiate a cell of mlAB-node and a normal cell of gNB, a new cell identification “miab-cell” is also proposed to be broadcasted by the mlAB-node’s DU.
In one or more embodiments, the SIB1 may be modified as shown below:
- SIB1
-ASN1 START
-TAG-SIB 1 -START irrelevant part skipped>
SIBl-vl800-IEs ::= SEQUENCE { miab-Cell-rl8 ENUMERATED {true} OPTIONAL, - Need R miab-Cell-Velocity-rl8 OCTET STRING OPTIONAL, -Need R miab-Cell-Velocity-threshold Velocity Threshold OPTIONAL, nonCriticalExtension SEQUENCE { }
} miab-Cell-Velocity-rl8
Parameter type Velocity defined in TS 37.355. The first/leftmost bit of the first octet contains the most significant bit. miab-Cell-Velocity-threshold
This field indicates the minimum velocity value of mobile lAB-node where the UE considers it is moving. Velocity Threshold is an integer.
In one or more embodiments, for a RRC_IDLE/IN ACTIVE UE’s initial cell selection process, there is no difference between a normal UE and a UE attempt to camp on a mobile lAB-node. The UE shall start to scan all RF channels in the NR bands according to its capability and select a suitable cell on a frequency. Once a suitable cell is found, this cell shall be selected, no matter it is a mlAB-cell or a normal cell. The UE can determine whether the selected cell is a mlAB cell or not, the mlAB-cell’s velocity (horizontal and/or vertical (if applicable)), and related velocity information based on the broadcasted information of this suitable cell.
In one or more embodiments, the cell reselection priorities may be based on a mobility state of the UE. For inter-frequency cell reselection when mlAB is deployed in a different frequency: If the current cell the UE camps on is a normal cell (i.e. gNB): (1) When the UE is in normal-mobility or medium-mobility state, the UE shall apply the priorities based on cell reselection priority provided either in dedicated signaling or in system information from current cell. The UE shall consider mlAB-cells as lowest priority, the mlAB-cells with zero or low velocity. (2) When the UE is in High-mobility state (as determined by the rate of cell crossing), it indicates that the UE performs cell reselection frequently within a short period, i.e. a UE on the moving vehicle is not camped on the mlAB-cell provided by the moving vehicle, and is performing cell reselection among gNBs outside of the moving vehicle. The UE shall consider the mlAB -cells (no matter velocity is zero or not) to be the highest priority for cell reselection (i.e. higher than any other network configured priority) if there is a mlAB-cell visible to the UE. Alternatively, The UE may also determine whether to consider a mlAB-cell as highest priority during inter-frequency cell reselection based on implementation. The velocity information of miab-cell may be exchanged from miab-cell’s donor CU to the normal gNB over Xn interface, so that the normal cell can include such information in its SIB. In one or more embodiments, when the current cell the UE camps on is a mlAB-cell: When the UE is in normal-mobility or medium-mobility state, the UE shall consider mlAB- cells whose velocity is not zero or larger than velocity threshold to be the highest priority for cell reselection. This will allow a UE in the moving vehicle with mlAB node to avoid reselecting a fixed cell. Alternatively, the UE can also consider a mlAB-cell always as highest priority if it currently camps on a mobile lAB-cell or read “mlAB-cell” indication in SIB1.
In one or more embodiments, measurement rules may be applied to limit when measurements are taken. A velocity threshold is configured to the UE indicating when to perform intra-frequency/inter-frequency measurement, with following options: (1) if mlAB- Cell fulfils Srxlev > SlntraSearchP and Squal > SlntraSearchQ for infra-frequency (Srxlev > SnonlntraSearchP and Squai > SnonintraSearchQ for inter- frequency), then if mlAB-cell’ s velocity is larger than velocity threshold, the UE may choose not to perform intra-frequency measurement among non-mlAB-cells or cells with equal/lower priority for inter-frequency case. (2): If mlAB-cell’ s velocity is larger than velocity threshold, the UE may choose not to perform intra-frequency measurement among non-mlAB-cells or cells with equal/lower priority for inter-frequency case. Alternatively, if one bit indication representing velocity of mlAB-cell larger than certain threshold is configured true: (l a) if mlAB-cell fulfils Srxlev > SlntraSearchP and Squal > SlntraSearchQ for intra-frequency (Srxlev > SnonlntraSearchP and Squal > SnonintraSearchQ for inter-frequency), then if mlAB-cell velocity indication is set to true, the UE may choose not to perform intra-frequency measurement among non-mlAB -cells or cells with equal/lower priority for inter-frequency case. (2a) if mlAB-cell’s velocity indication is set to true, the UE may choose not to perform intra-frequency measurement among non-mlAB-cells or cells with equal/lower priority for inter-frequency case. Alternatively, if velocity granular level is broadcasted by mlAB-cell: (lb) if mlAB-cell fulfils Srxlev > SlntraSearchP and Squal > SlntraSearchQ for intra-frequency (Srxlev > SnonlntraSearchP and Squal > SnonintraSearchQ for inter-frequency), then if mlAB-cell is in high/medium velocity level, the UE may choose not to perform intra-frequency measurement among non-mlAB -cells or cells with equal/lower priority for inter-frequency case. (2b) If mlAB-cell is in low velocity level, the UE may choose not to perform intra-frequency measurement among non-mlAB -cells or cells with equal/lower priority for inter-frequency case.
In one or more embodiments, the present disclosure provides intra-frequency and equal priority inter-frequency cell reselection criteria. If the UE is currently camped on a mlAB-cell whose velocity is zero or lower than velocity threshold or low velocity level (for scenario 1), the UE shall perform cell ranking among normal cells (cells without “miab-cell” in SIB1) according to the cell-ranking criterion defined in TS38.304. The UE will not consider miab- cells during cell ranking. If the highest-ranking cell is better than the serving mlAB-cell according to the cell reselection criteria during a time interval, the new cell can be selected.
In one or more embodiments, if the UE is currently camped on a normal gNB (for scenario 2), the UE shall perform cell ranking among normal cells (cells without “miab-cell” in SIB1) and neighbouring mlAB-cells whose velocity is zero or lower than velocity threshold or low velocity level according to the cell-ranking criterion defined in TS38.304. The velocity information of miab-cell(s) may be exchanged from miab-cell’ s donor CU to the gNB over Xn interface and included in the normal gNB’s SIB. If the highest-ranking cell is better than the serving mlAB-cell according to the cell reselection criteria during a time interval, the new cell can be selected.
In one or more embodiments, if the UE is currently camped on a mlAB-cell whose velocity is not zero or larger than velocity threshold or high/medium velocity level (for scenario 3/4), the UE only considers cell reselection among mlAB-cells with same/similar velocity or same velocity level (i.e. cell with miab-cell broadcasted in its SIB1). The UE may additionally: (Option 1) Rank the cells based on the R criteria defined in TS38.304 and calculate R values using averaged RSRP results among neighbouring mlAB-cells. A measurement threshold is configured to the UE in current mlAB-ceH’ s system information, the UE then calculates the velocity gap between mlAB-cell and each mlAB-cell that are above the measurement threshold. The UE shall perform cell reselection to the mlAB-cell with smallest velocity gap if the new cell is better than the serving mlAB-cell during a time interval. Velocity gap = abs(current mlAB-ceH’s velocity - neighbouring mlAB-cell’s velocity); mlAB-cell’s velocity here is the relative speed to a certain angle. For example: mlAB-ceH’s velocity 1 = horizontal speed * cos(mIAB-cell’s bearing angle); mlAB-cell’s velocity 2 = horizontal speed * sin(mIAB -cell’s bearing angle). Therefore, the velocity gap is calculated as: Velocity gap = root of [(current mlAB-cell’s velocity 1 - neighbouring mlAB-cell’s velocity 1)A2 + (current mlAB-cell’s velocity 1 - neighbouring mlAB-cell’s velocity 1)A2] .
In one or more embodiments, (Option 2) calculate velocity gap between mlAB-cell and each neighbouring mlAB-cell that fulfil cell selection criterion. A velocity gap threshold is configured to the UE in current mlAB-cell’s system information. The UE first ranks the mlAB- cells based on the velocity gap, then perform another round of ranking to the mlAB -cells that are below velocity gap threshold based on the R criteria defined in TS38.304. The UE shall perform cell reselection to the highest ranked cell if the new cell is better than the serving mlAB-cell during a time interval. In one or more embodiments, (Option 3) calculate velocity gap between mlAB-cell and each neighboring mlAB-cell that fulfil cell selection criterion. A velocity gap threshold is configured to the UE in current mlAB-cell’ s system information. The UE first ranks the cells based on the R criteria defined in TS38.304. Then the neighboring mlAB-cell which is larger than velocity gap will be removed from the cell reselection list. In the end, the UE shall perform cell reselection to the highest ranked cell in the remaining neighboring mlAB-cells if the new cell is better than the serving mlAB-cell during a time interval.
In one or more embodiments, (Option 4) perform cell ranking following TS38.304 among mlAB-cells with same/similar velocity or same velocity level.
In one or more embodiments, the velocity gap threshold and measurement threshold can be configured to the UE over SIB2 or SIB3/4 of the current cell.
In one or more embodiments, for intra-frequency and inter-frequency mobile IAB neighboring cell list in SIB3/4, the neighbouring mlAB-cell can be indicated with following two options: (1) the existing IE “intraFreqNeighCellList” “interFreqNeighCellList” with a new field “mlAB-cell” indication in “intraFreqNeighCelllnfo” and “interFreqNeighCelllnfo” and (2) using a new IE “intraFreqNeighMIABCellList” and “interFreqNeighMIABCellList” for neighbouring mlAB-cells specifically.
In one or more embodiments, a mlAB-node may broadcast cell selection/reselection parameters in a way that the UE measures and averages the received signal quality of the nearby cells over a longer period, so that the signal strength of the nearby gNB's cells in Scenarios 3 and 4 could become naturally lower than the cells of mlABs, without relying on velocity information broadcast from mlAB's cells or changing cell selection/reselection priorities/handling. Another option is to have the measured value remains valid for a longer period before reselecting a cell.
In one or more embodiments, a mlAB-node may broadcast a single bit indication to let UE know whether the UE can stop or reduce measurement related to handover in connected, cell reselection in Idle and perform cell reselection between a fixed gNB and mlAB if necessary. This single bit indication can be based whether mlAB is moving or not. If mlAB- node is moving, the UE may not perform cell reselection between fixed and mlAB nodes. This indication can be broadcast or sent to the UE in dedicated signaling. The broadcast can be in SIB or the information can be sent in a Paging message.
In one or more embodiments, cell selection and reselection may be location-based for RRC_IDLE and RRC_IN ACTIVE UEs. A mlAB-node may provide location measurement. Together with, or instead of, velocity of a mlAB-node, the location information can be broadcasted by mlAB-node in its SIB. If the UE has the capability to perform location measurement and location information of the UE is available, the UE can then calculate the relative distance between mlAB-node and itself.
Becuase the relative distance between mlAB-node and UE is quite small compared with the ellipse of the Earth, mlAB-node and the UE are assumed to be in the same horizontal plane. Relative distance between mlAB-node and the UE (if available) is calculated as: Relative distance = square root of ((degreesLatitude of mlAB-node - degreesLatitude of UE)2 + (degreesLongitude of mlAB-node - degreesLongitude of UE)2).
If mlAB-node and UE are with different height, the relative distance is calculated as: Relative distance = square root of ((degreesLatitude of mlAB-node - degreesLatitude of UE)2 + (degreesLongitude of mlAB-node - degreesLongitude of UE)2 + (height of mlAB-node - height of UE)2).
For cell reselection criteria, two options can be considered for the UEs: (Option 1): The UE performs cell-ranking criterion first based on measurement result among all neighboring cells that fulfil the cell selection criterion. The UE is configured with a measurement threshold over system information. Based on the ranking results, the UE filters the neighboring cells that are above measurement threshold and performs cell reselection to the lowest relative distance cell, if the new cell is better than the serving cell. (Option 2): The UE first calculates the relative distance between each neighboring mlAB-cell that fulfill the cell selection criterion. A relative distance threshold is configured to the UE over system information. The UE first filters out the neighboring cells that are above threshold, then perform cell-ranking criterion for the remaining neighboring cells. The UE shall perform cell reselection to the highest ranked cell, if the new cell is better than the serving cell. Alternatively, location information can also be sent over paging message.
In one or more embodiments, SIB modification may be optimized. As in some of the above embodiments, velocity (and/or location information) of the mlAB-node is broadcasted in SIB1, and velocity/measurement related thresholds of neighboring cell reselection are also configured in SIB2/3/4. When the mlAB-node is moving, the velocity of mlAB-node changes frequently, also the neighboring cell information also changes accordingly. This requires UE to wake up and read SIB information frequently, which may eventually cause huge power consumption at the UE side. As defined in TS38.331, the modification period co-efficiency of system information can be n2/n4/n8/nl6, and the shortest paging cycle is 32rf. Therefore, the shortest SIB modification period can be supported is: 10ms * 2 * 32 = 640ms = 0.64s. It is possible that the mlAB-node’s velocity changes very frequently, as it is not guaranteed to always move in a uniform speed. However, it is not necessary for the mlAB-cell to change its SIB information every time whenever the velocity changes. It is proposed that the mlAB-cell only updates its velocity information and modifies its SIB1 if the velocity’s change is larger than a certain threshold. This threshold can be configured to the ml AB -DU by lAB-donor CU or decided by mlAB-node itself by implementation. This configured velocity change threshold can also be broadcasted together with velocity of mlAB-node in its system information, e.g. “miab-Cell-Velocity-ModificationRange”, so that the UE knows a rough range of mlAB-node’s velocity. Alternatively, the mlAB-cell update its velocity information in SIB when the velocity level is changed, e.g. from high to medium, etc. Additionally, L3 filtering may also be applied to velocity of mlAB-cell, where lAB-donor CU provides related configuration to mlAB-MT over RRC signaling or to mlAB-DU over FlAP.An example of changes is shown as below, with the miab-Cell-Velocity-ModificationRange being new:
- SIB1
— ASN1 START
-TAG-SIB 1-START
<irrelevant part skipped>
SIBl-vl800-IEs ::= SEQUENCE { miab-Cell-rl 8 ENUMERATED {true} OPTIONAL, - Need R miab-Cell-Velocity-rl8 OCTET STRING OPTIONAL, -Need R miab-Cell-Velocity-threshold Velocity Threshold OPTIONAL, miab-Cell-Velocity-ModificationRange INTEGRER (0, 1, ... 1024)
OPTIONAL, nonCriticalExtension SEQUENCE { }
}
Table 2 below shows the GNB DU resource configuration defined by TS38.473 at Section 9.2.9.3, with the new velocity modification range added. Table 2: GNB DU resource configuration defined by TS38.473 at Section 9.2.9.3
Figure imgf000018_0001
As for SIB2/3/4 modification for cell reselection, the mlAB-DU is proposed to update such information only when it performs topology migration towards a new parent lAB-node (either intra-topology or inter-topology). Similar to a velocity modification range, a location modification range can also be used when location information of mlAB-node is broadcasted in system information of a mlAB-node.
In one or more embodiments, mlAB node identification and authorization may be performed. As mobile lAB-node may provide different capabilities compared with stationary lAB-node in Rel-16/Rel-17, the mobile lAB-node may also need to provide a mobile IAB- node indication to core network, indicating it is a mobile lAB-node rather a fixed lAB-node, so that the CN can provide enhanced services (e.g. tracking area update, etc.) accordingly. The mlAB-MT sends mobile IAB -indication “miab-Nodelndication” in RRCSetupComplete to the RAN node when integrating with its parent IAB -node/IAB -donor. The IAB -donor should send Mobile IAB Node Indication message to AMF in INITIAL UE MESSAGE over NG interface. After receiving the indication, AMF/MME may perform authorization and send “MIAB- Authorized” indication to NG-RAN node (i.e. lAB-donor) over INITIAL CONTEXT SETUP REQUEST or CONTEXT MODIFICATION REQUEST message for lAB-MT’s UE context setup/update.
In one or more embodiments, a ml AB node may be configured with a service time during which period the mlAB-cell can provide communication to UEs. Beyond the service time, mlAB-cell doesn’t need to provide service to UEs. One option is that mlAB-node is turned off beyond service time, i.e. not broadcasting any information for UE to select. During its service time, it starts to broadcast SIB information as well as its service time (e.g. service time is part of SIB) for UE to select. Another option is that mlAB-node always broadcast its SIB information, including service time. When UE performs cell selection and the corresponding mlAB-cell is beyond its service time, the UE will not select it. Otherwise, the UE can perform cell selection and camp on the mlAB-cell if the cell selection criteria is met. During the service time of mlAB-cell, the UE does not need to perform measurement to intra/inter frequency cells. For cell reselection, the UE can start measurement to intra/inter- frequency neighboring cells when the time is close to the end of ml AB -cell’s service time or after mlAB-cell’s service time. When to start measurement for cell reselection can also be broadcasted by mlAB-cell. The mlAB -cells with longer service time may be considered with higher priority during cell reselection.
Another challenge with mlABs is when the vehicle is moving around, the deployed mobile lAB-node (mlAB) needs to migrate between different lAB-donor CUs. Meanwhile, the UEs also move together with the connected mlAB. However, since the UEs are inside the vehicle and its connection can be still maintained towards the same mlAB, the UE does not need to perform handover procedure as normal. The mlAB and its served UEs can perform handover towards the new lAB-donor CU simultaneously, i.e. handover of the UEs connecting to mlAB depends on the migration of the mlAB.
The present disclosure provides a method to support full migration of a mobile IAB- node together with its served UEs from one lAB-donor CU to another, by changing both Uu and Fl termination. In one example, there may be three UEs connecting to the mobile lAB-node and moving together with the mlAB. When the mlAB moves around, due to moving out of the coverage of source lAB-donor CU, it needs to migrate from lAB-donor CUI to lAB-donor CU2 completely, i.e. both Uu termination of mlAB-MT and Fl termination of mlAB-DU change to the new lAB-donor CU. During this procedure, the mlAB’s served UEs, considering the security keys of the connected UEs are changed when moving from lAB-donor CUI to IAB- donor CU2, also need to perform handover procedure under the new lAB-donor CU, although the target cell that those UEs are connected to are still under the same mlAB-DU. An example handover process is defined below.
Step 1: The source lAB-donor CU configures the measurement procedure to mobile IAB-MT, and optionally configures measurement procedure to mlAB-node’s served UEs. The mlAB-MT reports according to the measurement configuration. If configured, the served UEs may also report according to the measurement configuration if applicable and mlAB-node may group them and send Group UL RRC Message Transfer to the source lAB-donor CU or send separately for the received served UEs’ measurement report.
Step 2: The source lAB-donor CU decides to handover the mlAB-node and its served UEs, based on MeasurementReport and RRM information of mlAB-MT.
Step 3: The source lAB-donor CU issues separate or a Group Handover Request message to the target lAB-donor CU passing transparent RRC containers of mlAB-MT and its served UEs with necessary information to prepare the handover of mlAB-MT and served UEs at the target side. The information includes at least the target cell ID, C-RNTI of the mlAB- MT and its served UEs in the source lAB-donor CU, RRC configuration, etc of mlAB-MT and its served UEs.
Note: since the source and target DU is the same for served UEs after handover (i.e. mlAB-DU), the target lAB-donor CU may not request UE context setup towards mobile IAB- DU. The RRC containers (e.g. the part configured by DU, for example, cell group configuration) of each served UE received in separate or group handover request message may be reused by the target lAB-donor CU.
Step 4: Admission Control may be performed by the target lAB-donor CU for mlAB- MT and its served UEs. The target lAB-donor CU may reject some of the served UEs or some DRBs of the served UEs if it cannot be supported.
Step 5: The source lAB-donor CU sends a mlAB-DU resource coordination request to the target lAB-donor CU, including a request to use the same cell identity, cell configuration, etc. This step can also be performed before step 4 or as part of step 3. The source lAB-donor CU also send the existing PCI value(s) used by mlAB-DU cell(s) to target IAB -donor CU to check if there could be a PCI(s) conflict.
Step 6: The target lAB-donor CU sends a mlAB-DU resource coordination response to the source lAB-donor CU, including the response of using the same cell identity, cell configuration and DU resource configuration, etc. If different cell identity and DU related configuration, etc are used, it also includes the new configuration of mlAB-DU in the target lAB-donor CU. The target lAB-donor CU check if PCI value(s) used by mlAB-DU cell(s) is conflicted with existing PCI values used by neighboring cells under itself (i.e. cells under the target lAB-donor CU, including one that HO was requested and its neighboring cells). If conflicted, either inform the selected new PCI to mlAB-DU or inform mlAB-DU to select a new PCI by itself within the pre-configured list.
Step 7: If different cell identity and configuration is used for mlAB-DU, the source lAB-donor CU sends a gNB-DU RESOURCE CONFIGURATION message to the mlAB-DU, including the updated activated cell information and cell resource configuration, etc. The mlAB-DU should temporarily stores the related configuration and execute after sending RRCReconfiguration messages to all served UEs (i.e. step 21). This step can also be performed before step 12 or as part of step 8.
The PCI update in Steps 5-7, or parts of it, may be skipped if the source lAB-donor CU, based on Xn connectivity and neighbor relation with the neighboring NG-RAN nodes, is certain that there would no PCI collision when the full migration of this mlAB node happens toward a specific target cell.
Alternatively, the source lAB-donor CU, once an mlAB node is attached to it, could be configured to inform the neighboring NG-RAN nodes of the updated served cell information including the cells served by this mlAB node, so that any possible PCI confliction (by the full migration of this mlAB node) could be detected in advance and the PCI values of the cells of the neighboring NG-RAN node who detected potential PCI confliction could be re-assigned in advance (so that the full migration could happen toward this NG-RAN node without having to re-assign PCI values to the mlAB-DU). For this, in the served cell update indication message toward the neighboring NG-RAN node over XnAP (e.g. NG-RAN NODE CONFIGURATION UPDATE message), an indicator could be defined for the included served cell information to distinguish that this specific served cell information is from mlAB node (not a regular cell), so that it can be taken into account by the receiving peer.
Step 8: The target lAB-donor CU prepares the handover with L1/L2 and sends the Group Handover Request Acknowledge to the source lAB-donor CU, which includes transparent containers to be sent to the mlAB-MT and its served UEs as their corresponding RRC message to perform handover.
There may be several options for target lAB-donor CU to generate handover acknowledgement:
Option 1: mlAB-DU may already provide the served UEs’ DU contexts for the target side when it triggers the collocated mlAB-MT HO.
Option 2: The target lAB-donor CU sends UE context setup request to the mlAB-DU via some path, (e.g. via source lAB-donor CU), since Fl tunnel between target lAB-donor CU and mlAB-DU is not established. The mlAB-DU provides UE context setup response over the same path (e.g. via source lAB-donor CU).
Option 3: The source lAB-donor CU generates it autonomously without contacting DU based on some information in the CU.
Step 9: The source lAB-donor CU triggers the Uu handover for mlAB-MT by sending an RRCReconfiguration message to IAB-MT, containing the information required to access the target cell in the target lAB-donor CU: at least target cell ID, new C-RNTI, security algorithm identifiers for selected security algorithms. It can also include a set of dedicated RRC configuration, RACH resources, the association between RACH resources and SSBs, etc.
Step 10: The source lAB-donor CU sends the SN STATUS TRANSFER message of mlAB-MT to the target lAB-donor CU to convey the uplink PDCP SN receiver status and the downlink PDCP SN transmitter status of DRBs of mlAB-MT for which PDCP status preservation applies.
Step 11: The source lAB-donor CU sends Group DL RRC Message Transfer messages to mlAB-node, which includes transparent containers to be sent to the served UEs to perform handover. The mlAB-node temporarily stores the received RRC containers of its served UEs at its mlAB-DU.
Step 12: The source lAB-donor CU may release BH RLC channels and BAP-sublayer routing entries on the source path between source parent lAB-node of the migrating mlAB- node and the source lAB-donor DU. Step 12 may be executed after step 17.
Steps 9/12 could be done by one shot, e.g. via F1AP UE Context Modification procedure.
Step 13: The IAB-MT synchronizes to the target lAB-donor CU and completes the RRC handover procedure by sending RRCReconfigurationComplete message to target lAB- donor CU. The IAB-MT releases the source resources and configurations and stops DL/UL reception/transmission towards the source lAB-donor CU directly. Step 14: The source lAB-donor CU sends the GROUP SN STATUS TRANSFER message of served UEs’ of mlAB-node to the target lAB-donor CU to convey the uplink PDCP SN receiver status and the downlink PDCP SN transmitter status of DRBs of served UEs of mlAB-node for which PDCP status preservation applies.
Before step 14, the target may inform the source that the HO of mlAB was successful (e.g. HO SUCCESS message) so that the source can be safe to trigger GROUP SN STATUS TRANSER message for its served UEs.
Step 15a: The target lAB-donor CU sends a PATH SWTICH REQUEST message to AMF to trigger 5GC to switch the DL data path towards the target lAB-donor CU for the MT and establish an NG-C interface instance towards the target lAB-donor CU. This step can be performed in parallel with step 18.
Step 15b: Alternatively, the target lAB-donor CU sends a GROUP PATH SWTICH REQUEST message to AMF to trigger 5GC to switch the DL data path of the served UEs of mlAB-node and mlAB-MT towards the target lAB-donor CU and establish an NG-C interface instance towards the target lAB-donor CU. This step can be performed in parallel with step 18.
Step 16a: 5GC switches the DL data path towards the target lAB-donor CU. The UPF sends one or more "end marker" packets on the old path to the source lAB-donor CU per PDU session/tunnel and then can release any U-plane/TNL resources towards the source lAB-donor CU. The AMF confirms the PATH SWITCH REQUEST message with the PATH SWITCH REQUEST ACKNOWLEDGE message for mlAB-MT. This step can be performed in parallel with step 18.
Step 16b: 5GC switches the DL data path of the served UEs of mlAB-node and mlAB- MT towards the target lAB-donor CU. The UPF sends one or more "end marker" packets on the old path to the source lAB-donor CU per PDU session/tunnel and then can release any U- plane/TNL resources towards the source lAB-donor CU. The AMF confirms the GROUP PATH SWITCH REQUEST message with the GROUP PATH SWITCH REQUEST ACKNOWLEDGE message for the served UEs of mlAB-node and mlAB-MT. This step can be performed in parallel with step 18.
Step 17: The target lAB-donor CU sends a UE CONTEXT RELEASE message to inform the source gNB about the success of the handover of mlAB-MT. The source gNB can then release radio and C-plane related resources associated to the mlAB-MT’ s UE context. Any ongoing data forwarding may continue.
Step 18: If PCI is not changed, the target lAB-donor CU configures BH RLC channels and BAP sublayer routing entries on the target path between the migrating mlAB-node and target lAB-donor DU, etc. The Fl-C connection between the migrating mlAB-node and the source lAB-donor CU may be switched to the target path using the new TNL address information of the migrating mlAB-node. The migrating lAB-node may report the new TNL address information it wants to use for each Fl-U tunnel and non-UP traffic type to the source lAB-donor-CU via the gNB-DU CONFIGURATION UPDATE message. Otherwise, if PCI is changed by target lAB-donor CU, step 18 performs after step 21 (step 19/20 may be skipped).
Step 19: If step 15b and step 16b is performed, the target lAB-donor CU resumes DL traffic transmission of mlAB-node’ s served UEs to mlAB-DU.
Step 20: If step 15b and step 16b is performed, the mlAB-DU temporarily stores the received DL data for its served UEs from the target lAB-donor CU.
Step 21: The mlAB-DU triggers the Uu handover of its served UEs by sending RRCReconfiguration messages stored at step 11 to the served UEs. The RRCReconfiguration messages for the served UE also includes a RACH-less handover configuration, including a pre-allocated RRC configured UL grant, target TA, etc.
If different cell identity and resource configuration is used for mlAB-DU in step 7, the mlAB-DU adopts the new cell identity and gNB-DU Resource Configuration from target lAB- donor CU after step 21 . Otherwise, if different cell identity is used by mlAB-DU, step 18-20 are performed after sending RRCReconfiguration message to served UEs in step 21.
Step 22: If RACH-less handover is not configured to the served UEs, the UEs synchronize to the target cell via RACH procedure and completes the RRC handover procedure by sending RRCReconfigurationComplete message to target gNB. If RACH-less handover is configured to the served UEs, the UEs skip RACH and send the RRCReconfigurationComplete message directly to the target gNB in the pre-allocated UL grant.
Step 23: The mlAB-DU sends a Group UL RRC MESSAGE TRANSFER message to the target lAB-donor CU to convey the received RRCReconfigurationComplete messages from its served UEs.
Step 24a: If step 15a/16a is performed, the target lAB-donor CU sends a GROUP PATH SWTICH REQUEST message to AMF to trigger 5GC to switch the DL data path of the served UEs of mlAB-node towards the target lAB-donor CU and establish an NG-C interface instance towards the target lAB-donor CU. 5GC switches the DL data path of the served UEs of mlAB- node towards the target lAB-donor CU. The UPF sends one or more "end marker" packets on the old path to the source lAB-donor CU per PDU session/tunnel and then can release any U- plane/TNL resources towards the source lAB-donor CU. The AMF confirms the GROUP PATH SWITCH REQUEST message with the GROUP PATH SWITCH REQUEST ACKNOWLEDGE message for the served UEs of mlAB-node and mlAB-MT.
Step 24b: If step 15b/16b is performed, the mlAB-DU resumes DL traffic towards the served UEs by starting to send stored DL traffic at step 19.
Step 25: The target lAB-donor CU resumes UL/DL traffic towards the served UES of mlAB-node.
Step 26: The target lAB-donor CU sends a GROUP UE CONTEXT RELEASE message to inform the source gNB about the success of the handover of served UEs. The source gNB can then release radio and C-plane related resources associated to the served UEs’ context. Any ongoing data forwarding may continue.
In the following embodiments, we further introduce optimizations of the proposed solution of mlAB’s served UE’s handover during mlAB-node’s inter-donor CU migration.
In one or more embodiments, a mlAB-DU resource coordination between source and target lAB-donor CU are provided. During mlAB-node’s migration, the source lAB-donor CU coordinates with the target lAB-donor CU via Xn interface, where the message is proposed to include I) the purpose/cause of requesting resource coordination 2) whether the source lAB- donor CU requests to reuse the same PCI and resource allocation for the migrating lAB-node 3) mlAB-DU’s resource information allocated by source lAB-donor CU 4) cell group configuration of mlAB-DU (i.e. served cell information and gNB-DU System Information), including physical cell group configuration, MAC cell group configuration, RLC bearer information, etc., either as a RRC container or with specific IES defined in Xn message corresponding to IEs in CellGroupConfig in TS38.331.
If resource coordination is for resource multiplexing purpose, the cause can be set to “resource optimization” or a new event; if resource coordination is for inter-donor CU full migration purpose, the cause can be set to “handover desirable for radio reasons” or a new event. If the target lAB-donor CU can allocate the same PCI and resource allocation for the migrating lAB-node, the proposed new field “reuse source mlAB-DU resource configuration” can be set to true without including boundary node cells’ and parent nodes’ information, this also indicates that the same cell group configuration is used in the target lAB-donor CU for the migrating mlAB-DU; otherwise, the target lAB-donor CU should set the new field “reuse source mlAB-DU resource configuration” to false and indicates mlAB-DU’s resource configuration in the target lAB-donor CU to the source lAB-donor CU. Alternatively, if “reuse source mlAB-DU resource configuration” is set to false, the source lAB-donor CU will release the Fl towards mlAB-node, and mlAB-DU request to setup Fl connection to the target IAB- donor CU, where the new configuration of mlAB-DU in target IAB -donor CU is configured.
If the target IAB -donor CU allocates the same PCI and resource configuration to the mlAB-node, all served UEs performs intra-cell handover with security key change during mlAB-node’s migration, i.e. MasterKeyChange is present and keySetChangelndicator may be set to true in the corresponding RRCReconfiguration message. masterCellGroup of the served UEs (i.e. master cell is mlAB-DU cell) can remain unchanged during mlAB-node’ s inter-donor CU full migration, by sending serving cell information of mlAB-cells from source lAB-donor CU to target lAB-donor CU. The existing IAB RESOURCE COORDINATION REQUEST/RESPONSE message is proposed to extend its usage from resource multiplexing to inter-donor CU full migration and include information listed above. Alternatively, a new IAB FULL MIGRATION RESOURCE COORDINATION REQUEST/RESPONSE can be defined and used for mlAB-node’s resource coordination during inter-donor CU full migration for information listed above. An example of enhancement to existing IAB resource coordination procedure is shown below with the enhancements underlined:
8.5.4 IAB Resource Coordination
8.5.4.1 General
The purpose of the IAB Resource Coordination procedure is to exchange the semi-static radio resource configuration pertaining to a boundary lAB-node, between the Fl -terminating lAB-donor-CU and the non-Fl -terminating lAB- donor CU of a boundary lAB-node, for the purpose of resource multiplexing and inter-donor CU full migration. The procedure can be initiated by the
Fl -terminating or non Fl-terminating lAB-donor-CU of the boundary lAB-node.
9.1.4.6 IAB RESOURCE COORDINATION REQUEST
Direction: Fl-terminating lAB-donor-CU non-Fl-terminating lAB-donor- CU, non-Fl-terminating I AB-donorCU- ->F1 -terminating lAB-donor-CU; source lAB-donor-CU -> target lAB-donor CU
Figure imgf000026_0001
Figure imgf000027_0001
9.1.4.7 IAB RESOURCE COORDINATION RESPONSE
Direction: non-Fl-terminating lAB-donor-CU Fl -terminating IAB- donor-CU, Fl -terminating lAB-donor-CU non-Fl-terminating lAB-donor- CU; target lAB-donor CU -> source lAB-donor CU
Figure imgf000028_0001
In one or more embodiments, there may be a new event for mlAB handover and a conditional handover trigger event. For RRC_CONNECTED UEs under mlAB-node, when mlAB-node is moving around, it is expected to move together with mlAB-node, rather than frequently perform handover to other gNBs/mlAB-nodes. The RRC_CONNECTED UEs can switch from one mlAB-node to another mlAB-node if, for example, it moves inside a moving vehicle in which multiple mlAB-nodes are located. The RRC_CONNECTED UEs only need to switch between gNB and mlAB-node when it gets inside/moves outside of the vehicle. This typically happens when the mlAB node is or is almost stationary.
In one or more embodiments, there may be a new event for mlAB-MT. In this disclosure, it is proposed to let mlAB-node (i.e. mlAB-MT) measure its own velocity and report it to the lAB-donor CU via measurement report. The velocity of mlAB-node can either be measured over GNSS or based on the number of handed-over cell during a certain period. A new event “velocity” (e.g. Event V 1) is proposed to be used to configure mlAB-MT to report its velocity to lAB-donor CU. The event could be continuous or threshold triggered, for example, when the velocity is below or above a threshold that could be configured by CU or known to the mlAB through other means. This reporting could be based on the measurement configuration and reporting framework defined for NR, for example, UE is configured to also report velocity or only report velocity, and the threshold along with periodicity of reporting. The UE could use the measurement reporting procedure to report the velocity along with or independent of other RRM measurements.
The ml AB -MT may: consider the entering condition for this event to be satisfied when condition VI-
1 is fulfilled; consider the leaving condition for this event to be satisfied when condition VI-
2 is fulfilled; for this measurement, consider the NR serving cell corresponding to the associated measObjectNR associated with this event.
Inequality VI -1 (entering condition):
Vm + Hys < Thresh
Inequality VI -2 (leaving condition):
Vm - Hys > Thresh
The variables in the formula are defined as follows:
Vm is velocity of the mlAB-node, not taking into account any offsets.
Hys is the hysteresis parameter for this event (i.e. hysteresis as defined within reportConfigNR for this event).
Thresh is the threshold parameter of this event (i.e. as defined within reportConfigNR for this event). This mlAB velocity information could be used by the donor CU to configure the RRC Connected UEs with applicable measurement configuration to aid mobility to and from mlAB node. It could also be used to identify the UEs moving to or from an mlAB node and trigger a HO for these UEs.
In one or more embodiments, there may be a measurement configuration for legacy RRC_Connected UEs. For the RRC_CONNECTED UEs, following configurations are considered from the network side to decide handover of the legacy UEs between gNBs and mlAB-node:
Scenario 1: set in the vehicle
The UEs performs measurement and report measurement result to the network according to gNB’s configuration (e.g. event A5 triggered measurement report, etc). When mlAB-node is moving closer and the UE gets onboard of the vehicle, the reported measurement result of mlAB-node is expected to be better than connected gNB. Based on the measurement report (e.g. RSRP, RSRQ, SINR), gNB decides to handover the UE to mlAB-node.
Scenario 2: move together with the vehicle
Once the UE connects to a mlAB-node, as the reported velocity of mlAB-node is not zero (or IAB -donor CU does not receive measurement report from ml AB -MT), the lAB-donor CU deactivates the measurement configuration of neighbouring normal gNBs for the served UEs under a mlAB-node via RRC signaling (e.g. RRCReconfiguration message during handover from gNB to mlAB-node). There’s no measurement of normal gNB performed at the served UEs and the served UE can remain its connection to ml AB -node without handover to other gNB when it’s onboard.
Scenario 3: move out of the vehicle
As discussed earlier, when mlAB-MT’s velocity is lower than certain threshold, it triggers mlAB-MT reports its current velocity to lAB-donor CU. Since the mlAB- node is getting slower (i.e. going to stop), there might be some UEs need to get off the vehicle and handover to the normal gNB. When receiving mlAB-MT’s measurement report (including velocity) triggered by Event VI, lAB-donor CU may configure the served UEs of mlAB-node with measurement configuration towards neighbouring normal gNBs. Based on the measurement results, the network can decide handover the UEs moving out of the vehicle to normal gNB. Scenario 4: move together with the vehicle, change from one mlAB-node to another mlAB-node on the same vehicle
If there are multiple mlAB-nodes on the same vehicle, e.g. train with mlAB-nodes distributed in its carriages, when the UE moves inside the vehicle, the connected mlAB-node can be switch to another mlAB-node. Therefore, the lAB-donor CU may configure the served UE of a mlAB-node to perform measurement for other mlAB-nodes which are served by the same lAB-donor CU or with the same velocity. Based on the measurement report and/or the mlAB velocity, the UE can be handed- over from one mlAB-node to another.
To achieve measurement towards mlAB-node rather than normal gNB when UEs are onboard, lAB-donor CU can: add normal gNB cells in excludeCellsToAddModList of MeasObjectNR add mlAB-node with the same lAB-donor CU in allowedCellsToAddModList of MeasObjectNR
Alternatively, based on the information/mapping between mlAB-node and its served UEs, the lAB-donor CU can ignore the measurement reports from the served UEs, unless it receives measurement report from mlAB-MT when its velocity is lower than certain threshold or zero.
In one or more embodiments, there may be a velocity -based handover and conditional handover. A mlAB-DU is proposed to send its collocated lAB-MT’s velocity to the served UEs. This could be via RRC, MAC CE or physical layer signaling.
Upon receiving the velocity information from mlAB-DU, it is considered as part of a new measurement event for the served UEs to report its measurement result to the network. Otherwise, the served UEs don’t need to send measurement report to the network.
For example, EventV2 can be defined as below:
The UE shall:
1) consider the entering condition for this event to be satisfied when condition V2-1 is fulfilled.
2) consider the leaving condition for this event to be satisfied when condition V2-2 is fulfilled.
Inequality V2-1 (entering condition):
Vm + Hys < Thresh
Inequality V2-2 (leaving condition):
Vm - Hys > Thresh The variables in the formula are defined as follows:
Vm is velocity of the connected mlAB-node, not taking into account any offsets. Hys is the hysteresis parameter for this event (i.e. hysteresis as defined within reportConfigNR for this event)
Thresh is the threshold parameter of this event (i.e. as defined within reportConfigNR for this event)
Alternatively, to reduce the frequency of sending mlAB-DU’s velocity, the velocity is only sent to the served UEs when mlAB-node’s velocity is zero or the average velocity is below certain threshold over a certain duration. Both velocity threshold and duration can be configured by lAB-donor CU over Fl interface to mlAB-DU.
Moreover, a corresponding conditional handover event can also be introduced, e.g. CondEventV2. The definition of Event V2 also applies to CondEvent V2.
The served UEs can be configured both CondEventV2 and another CondEvent as conditional execution conditions for normal gNB. When both conditions are met, the served UEs can perform CHO and select the normal gNB. One of these conditional events can be the mlAB velocity and could be based on the absolute velocity or an indication, based for example, on velocity of the mlAB.
For mlAB-cells within the candidate cells, the lAB-donor CU should not configure other mlAB-cells served under another lAB-donor CU. The candidate mlAB-cell is also configured with two CondEvent (i.e. CondEventV2 and another CondEvent). If CondEventV2 is not met, while the other configured CondEvent is met, the served UEs can perform CHO and select the mlAB-cell for HO (handover).
In one or more embodiments, there may be a location or range-based handover and conditional handover. The served UEs via MAC CE or physical layer signaling. The measurement report from the served UE and conditional handover event are decided based on the relative distance between UE and mlAB-node. For example, EventDl and CondEventDl as defined in TS38.331.
In one or more embodiments, there may be a timing advance (TA)-based handover and conditional handover. Alternatively, TA of the served UEs is proposed as a new measurement event and conditional handover event.
When UE is moving together with mlAB-node (without moving inside the vehicle), TA of the served UE is unchanged or the change is under certain threshold. However, when UE moves inside the vehicle from one mlAB-node to another or UE moves from mlAB-node to gNB, the TA of the served UE under the current serving cell is becoming larger. Therefore, TA of the UE is proposed to be a new measurement event for served UE to send its measurement report to network. If the event of timing advance (e.g. EventTAl) is met, the UE can send measurement report including neighbouring cells’ measurement to the network for handover. Otherwise, the UE can hold the measurement results or not perform measurement to other neighbouring cells.
For example, EventTAl can be defined as below:
The UE shall:
1) consider the entering condition for this event to be satisfied when condition TA1-
1 is fulfilled.
2) consider the leaving condition for this event to be satisfied when condition TA1-
2 is fulfilled.
Inequality TAI-1 (entering condition):
TA - Hys > Thresh
Inequality TAI-2 (leaving condition):
TA + Hys < Thresh
The variables in the formula are defined as follows:
TA is timing advance of the served UE, not taking into account any offsets.
Hys is the hysteresis parameter for this event (i.e. hysteresis as defined within reportConfigNR for this event)
Thresh is the threshold parameter of this event (i.e. as defined within reportConfigNR for this event)
Moreover, a corresponding conditional handover event can also be introduced, e.g. CondEventTAl. The definition of Event TAI also applies to CondEvent TAI. The served UEs can be configured both CondEventTAl and another CondEvent as conditional execution conditions for normal gNB. When both conditions are met, the served UEs can perform CHO and, for example, select the normal gNB.
In one or more embodiments, there may be an indication-based measurement. Or, alternatively, an indicator for activating/deactivating measurements of neighboring gNBs could be defined in system information and broadcasted by an mlAB-node so that, when it is set to "on", the UEs connected through this mlAB-node stop such measurements and only performs when the indicator is set to "off". The indicator in system information can be set accordingly by the mlAB-DU based on its own velocity or pre-planned trajectory configured by OAM. In one or more embodiments, there may be a trajectory-based measurement. Or alternatively, if the vehicle that carries the mlAB-node is moving along the pre-planned trajectory, the UEs connected through this mlAB-node could be configured by the lAB-donor- CU to perform measurements only at some specific time intervals in future (e.g. when the vehicle is expected to stop for people hops in or out) without the lAB-donor-CU having to activate/deactivate measurements for the UEs on the fly based on the velocity of the mlAB- node.
In one or more embodiments, there may be a Fl setup of mlAB-DU toward a target IAB -donor CU. As discussed in Embodiment 1 above, the PCI of mlAB-DU cell might be changed due to collision. It is proposed that the source IAB -donor CU to negotiate with target lAB-donor CU before Fl setup of mlAB-DU, same for the gNB-DU resource configuration. If the same resource and PCI can be used, mlAB-DU can directly re-use the existing PCI value and serving cell information to request Fl setup towards target lAB-donor CU in step 18 of Figure 1 before sending RRCReconfiguration messages to the served UEs.
Alternatively, if PCI or gNB-DU resource configuration cannot be reserved by target lAB-donor CU (e.g. indicated in Step 7 of Figure 1), the mlAB-DU cell should temporarily store the received new PCI and gNB-DU resource configuration from source lAB-donor CU in step 7 and only use it after sending RRCReconfiguration messages to the served UEs. Therefore, mlAB-DU should request Fl setup using new PCI value and configured gNB-DU resource configuration from target lAB-donor CU after sending RRCReconfiguation message to the served UEs.
Alternatively, if PCI conflict of mobile IAB-DU happens at target, Fl setup procedure can proceed and new PCI value can be assigned to mlAB-DU via Fl SETUP RESPONSE before sending RRCReconfiguration to the served UEs. The mlAB-DU starts to use new PCI values for its cells after sending RRCReconfiguration message to the UEs. The timer for successful HO T304 has to be configured appropriately to allow UE to perform a successful RACH after the mlAB DU has updated the configuration based on Fl setup procedure.
In one or more embodiments, DL user data may be pre-sent and stored at a mlAB DU before RRCReconfiguration is complete for UEs served by mlAB’s. To reduce DL service interruption, in this embodiment, for PCI and gNB-DU resource configuration unchanged scenario, it is proposed to resume served UEs’ DL traffic before the completion of RRC reconfiguration of the served UEs towards the target lAB-donor CU.
As discussed above, the handover procedure of served UEs (i.e. served UEs to receive RRCReconfiguration message from source lAB-donor CU) should perform after successful RACH and Fl setup of mlAB-node. Therefore, according to TS38.300, the target lAB-donor CU can only resume transmission of served UEs’ DL traffic after receiving their RRCReconfigurationComplete messages. The served UEs may experience DL traffic service interruption since mlAB-node performs full migration procedure.
To reduce DL service interruption, it is proposed to allow target lAB-donor CU to sends the served UEs’ DL traffic to mlAB-node right after successful Fl setup between mlAB-node and itself, where served UEs’ DL traffic is temporarily stored at the mlAB-node.
After the source lAB-donor CU sends Group DL RRC Message Transfer message of the served UEs to mlAB-node, different from handover procedure where SN Status Transfer message is sent by a source gNB to a target after handover initiation (i.e. RRCReconfiguration message to the UE), a Group SN Status Transfer message of served UEs are sent by the source lAB-donor CU to the target lAB-donor CU before RRCReconfiguration messages are received by the served UEs. Moreover, different from triggering path switch procedure after UE’s successful handover, the Group Path Switch procedure of the served UEs may also be triggered before successful handover, where it allows the target lAB-donor CU to receive expected served UEs’ traffic earlier and meanwhile resume UEs’ DL traffic.
After a mlAB-node receives successful RACH from the served UEs (including RACH- less, 4-step RACH, 2-step RACH), the mlAB-node starts to transmit the stored DL traffic to the corresponding served UEs.
In one or more embodiments, there may be a RACH-less handover of mlAB nodeserved UEs. To reduce signaling overhead when group of served UEs performing RACH simultaneously, RACH-less handover is proposed to be supported for the served UEs. The target lAB-donor CU configures the served UEs with RACH-less configuration, including UL grant and TA. Because the mlAB node of the serving UEs does not change during the mlAB HO procedure, the previous UE configuration, including TA is likely to be valid even after the mlAB HO procedure. Hence it is sufficient to simply perform a change of security keys as part of this HO procedure. The change of security keys can be done with only impacting the user plane. Identification of the user data with the old and new keys can be done using either new C-RNTI or after a L2 reset of the MAC and RLC. An RRC or MAC signaling could be used for this purpose.
In addition, when a vehicle is moving around, the deployed mobile lAB-node (mlAB) needs to migrate between different lAB-donor CUs. Meanwhile, the UEs also move together with the connected mlAB. However, since the UEs are inside the vehicle and its connection can be still maintained towards the same mlAB, the UE does not need to perform handover procedure as normal. The mlAB and its served UEs can perform handover towards the new IAB -donor CU simultaneously, i.e. handover of the UEs connecting to mlAB depends on the migration of the ml AB.
Moreover, a mlAB-node should be able to provide service continuously to its served UEs. Therefore, reducing service interruption and reduce signaling overhead towards served UEs during mlAB’s full migration is important in improving system performance.
Because a mlAB-node fully migrates from the source lAB-donor CU to the target IAB- donor CU, the Fl termination of mlAB-DU also changes from source to target lAB-donor CU. However, if the existing PCI used by mlAB-DU is assigned by source lAB-donor CU, it is possible that the same PCI is already used by another cell at the target lAB-donor CU, where a PCI collision between mlAB-DU and existing cell happens. Therefore, solving the PCI collision during mlAB -node’s full migration for mlAB-DU is important.
In one or more embodiments, the present disclosure proposes several solutions to reduce service interruption for the served UEs, by considering 1) redirecting traffic from target lAB-donor CU to source lAB-donor CU when served UEs are still generating UL data with source security keys; 2) conditional DU resource configuration for mobile IAB-DU; 3) conditional handover configuration for served UEs; 4) establish dual Fl termination between mobile IAB-DU and source/target lAB-donor CU during full migration of mobile lAB-node. Solutions to solve PCI collision of mobile IAB-DU are also proposed. The proposed solutions herein can optimize network performance in terms of reducing service interruption and avoid PCI collision during mobile lAB-node migrating between different lAB-donor CUs.
In one or more embodiments, there may be PCI management of a mlAB node. Because a mlAB-node fully migrates from one lAB-donor CU to another lAB-donor CU, both Uu termination of mlAB-MT and Fl termination of mlAB-DU change accordingly. Following PCI management approaches are considered to avoid PCI collision during mlAB-node’s full migration:
Option 1: Reserve unique mlAB-DU cell PCI space for each lAB-donor CU managed by the same OAM (Unchanged PCI of mlAB-node).
In this proposed option, OAM reserves a space for PCI allocation towards mlAB-nodes. Each lAB-donor CU managed by the same OAM is configured with a specific/unique range of PCI values that can be allocated for the cells of mlAB-nodes, which does not overlap with each other. In other words, one lAB-donor CU cannot use a PCI value from the values that has been assigned to the other lAB-donor CUfor the cells of mlAB-nodes. For example, PCI 0-199 are reserved by 0AM for mlAB-nodes under the same PLMN, and lAB-donor CU 1-10 of the same 0AM share the same reserved PCI space. An example of NCGI space for each lAB-donor CU is shown as below in Table 3.
Table 3: Example NCGI Space for lAB-Donor CU
Figure imgf000037_0001
When a mlAB-node first integrates to one lAB-donor CU’s topology (e.g. lAB-donor CUI) for example, as part of its power up sequence, a unique PCI is selected by lAB-donor CUI to the mlAB-node and configured via Fl setup or gNB-CU Configuration Update. When mlAB-node moves to another lAB-donor CU (e.g. lAB-donor CU3), the PCI of mlAB-node is proposed to be unchanged. Since the target lAB-donor CU does not use the pre-allocated PCI space of other lAB-donor CU, the existing PCI of the migrating lAB-node will not conflict with other existing cells under the target lAB-donor CU. Hence, the PCI of mlAB-DU does not need to be changed during full migration between two lAB-donor CUs managed by the same 0AM.
In another alternative, 0AM may configure the PCI for the mlAB directly. Each mlAB node is provided with a unique PCI that will not conflict with another PCI in the whole PLMN.
Option 2: Reserved PCI space for each mlAB-DU by 0AM (unchanged PCI of mlAB- node within a geographical area).
Alternatively, a list of reserved PCIs is configured to mlAB-DU by 0AM. The list of PCIs configured towards the mlAB-DU is not overlapped with other gNBs or other mlAB- DUs. Each PCI in the configured list can either be mapped to one lAB-donor CU or a configured geographical area (e.g. area ID). The PCI of mlAB will not be changed/conflicted if mlAB-node is inside the corresponding lAB-donor CU or geographical area.
When migrating from one lAB-donor CU to another lAB-donor CU, if PCI collision is detected by the target lAB-donor CU, the target lAB-donor CU will inform the mlAB-node about the PCI collision. The target lAB-donor CU can also send available or used PCI list of the target lAB-donor CU to the mlAB-DU for reference. The mlAB-node shall then select another reserved PCI from the reserved list which maps to the selected target lAB-donor CU or corresponding geographical area. On the other hand, if PCI collision is not detected, mlAB- DU's cells reuse the existing PCI values assigned by the source lAB-donor CU.
If the PCI values are assigned based on geographical areas, it can be mapped to the tracking area of mlAB-MT. When the collocated IAB-MT moves out of the tracking area, the PCI values of the cells of the mlAB-DU can be updated by itself.
Option 3: New PCI allocation and re-allocation by OAM if PCI collision happens
In this proposed option, the cell identity of mlAB-node in each lAB-donor CU is assigned by OAM without further optimization. During mlAB-node’s full migration, if PCI collision is detected by the target lAB-donor CU, centralized and distributed PCI assignment used by SON are used to solve PCI collision with other gNB/mlAB-DU cells.
Option 4: PCI negotiation between two lAB-donor CU.
The PCI update may be skipped if the source lAB-donor CU, based on Xn connectivity and neighbor relation with the neighboring NG-RAN nodes, is certain that there would no PCI collision when the full migration of this mlAB node happens toward a specific target cell.
Or, alternatively, the source lAB-donor CU, once an mlAB node is attached to it, could be configured to inform the neighboring NG-RAN nodes of the updated served cell information including the cells served by this mlAB node, so that any possible PCI conflict (by the full migration of this mlAB node) could be detected in advance and the PCI values of the cells of the neighboring NG-RAN node who detected potential PCI confliction could be re-assigned in advance (so that the full migration could happen toward this NG-RAN node without having to re-assign PCI values to the mlAB-DU). For this, in the served cell update indication message toward the neighboring NG-RAN node over XnAP (e.g. NG-RAN NODE CONFIGURATION UPDATE message), an indicator could be defined for the included served cell information to distinguish that this specific served cell information is from mlAB node (not a regular cell), so that it can be taken into account by the receiving peer.
In one or more embodiments, there may be redirection of packets generated with source lAB-donor CU’s security key via a target lAB-donor CU before the mlAB-served UEs successful RACH. The RRC Reconfiguration messages of mlAB’s served UEs are sent after mlAB-MT’ s successful RACH. Therefore, the mlAB’s served UEs are still using the security keys configured by source lAB-donor CU before they receive their RRCReconfiguration messages from mobile IAB-DU.
There are three options to avoid target lAB-donor CU receives packets generated by the UE with source lAB-donor CU configured security key. Option 1: Mobile lAB-node to discard any UL packets received from UE during the period (release of BAP route between mlAB and source IAB -donor <-> mlAB sends RRCReconfiguration messages to its served UEs).
Option 2: mlAB stops UL grant to its served UEs after release of BAP route towards source IAB -donor and resumes UL grant after successful RACH of its served UEs to stop UE from sending UL data.
Option 3: Redirect packets via target lAB-donor CU
After receiving the RRCReconfigurationComplete message from the mobile lAB-node, the target lAB-donor initiates IAB TRANSPORT MIGRATION MANAGEMENT REQUEST to the source lAB-donor. A tunnel is established between target lAB-donor CU and source lAB-donor CU to allow target lAB-donor CU to redirect any received packets (PDCP PDUs) to source lAB-donor CU.
After receiving the RRCReconfiguration message from mlAB, mlAB’s served UEs perform RACH (if RACH is configured) and/or send RRCReconfigurationComplete message to mlAB.
To help the target lAB-donor CU distinguish the received packets and redirect to source lAB-donor CU, an indication of the received UL packets is introduced to help network understand whether the packets are generated with the security key of source lAB-donor CU or with the new security keys from the target lAB-donor CU.
The indication is proposed to be added in the BAP header (a new field parameter in BAP data PDU) at mobile IAB-MT if the packets are received from the served UE during the following period:
Starting point: successful RACH of mlAB-node itself or successful Fl setup between ml AB and target lAB-donor CU.
Stop point: 1) if RACH-less is not configured to the served UEs, upon successful RACH of each served UE at mlAB-node 2) if RACH-less is configured to the served UEs, upon mlAB receives RRC messages from each served UE.
Upon the stop point listed above, an END MARKER control PDU is generated by mlAB’s BAP layer and is forwarded to the target lAB-donor CU, indicating it stops receiving any packets with source security key.
When the target lAB-donor DU receives the packets (PDCU PDUs) from mlAB, the packets with a BAP header indicating it’s a source packet will be redirected to source IAB- donor CU over the established IP tunnel; on the other hand, if the packets with a BAP header indicating it’s a target packet, it will be transferred to the target IAB -donor CU. The tunnel from the target donor DU to the source donor CU could be direct or via the target donor CU.
If in-order delivery of UL packets toward CN is required, the source lAB-donor CU, after sending the last UL packet forwarded from the target lAB-donor DU via the tunnel, may indicate the target lAB-donor CU that it is safe to deliver UL packets received from the target lAB-donor DU from there. The decrypted packets can also be sent from the source CU to the target CU for re-ordering if the PDCP SN of the received packets has gaps.
The target lAB-donor CU can trigger the release of established IP tunnel any time after it receives an end-maker control PDU from mobile lAB-node.
An example of BAP header to differentiate packets using source security key and target security key is shown as below in Table 4.
Table 4: Example BAP Header
Figure imgf000040_0001
The new S/T field indicates whether the corresponding BAP PDU carries a packet to be redirected to source lAB-donor CU by target lAB-donor DU or to be forwarded to target lAB-donor CU. Table 5 shows an example of the S/T field.
Table 5: S/T Field
Figure imgf000040_0002
An example of END MARKER control PDU in BAP layer is shown as below in Table 6.
Table 6: END MARKER Control PDU in BAP Layer
Figure imgf000040_0003
Table 7 below shows a PDU Type, with the End Marker being new.
Table 7: PDU Type
Figure imgf000041_0002
The changes in TS38.423 related to IAB TRANSPORT MIGRATION
MANAGEMENT REQUEST is shown as below in underline:
9.1.4.2 IAB TRANSPORT MIGRATION MANAGEMENT REQUEST
This message is sent by an Fl -terminating lAB-donor-CU to a non-Fl-terminating lAB-donor- CU of a boundary lAB-node or sent by a target lAB-donor CU to the source lAB-donor CU of a mobile lAB-node, for the purpose of setting up, modifying, or releasing (e.g., for the purpose of revoking) the configuration for the migration of boundary and descendant node traffic between two lAB-donor-CUs.
Direction: Fl-terminating donor CU — > non-Fl-terminating donor CU or target lAB-donor CU to source lAB-donor CU.
9.1.4.3 IAB TRANSPORT MIGRATION MANAGEMENT RESPONSE
This message is sent by the non-Fl-terminating lAB-donor-CU to the Fl -terminating lAB- donor-CU of a boundary lAB-node or sent by a source lAB-donor CU to the target lAB-donor CU of a mobile lAB-node to provide inter-donor transport related configurations for the offloaded traffic.
Direction: non-Fl-terminating donor CU
Figure imgf000041_0001
Fl-terminating donor CU or source lAB-donor CU to target lAB-donor CU.
In one or more embodiments, there may be a CHO for a mlAB node with conditional DU resource configuration. If CHO is configured to mlAB-MT and the candidate lAB-donor CU cannot reserve the same PCI or gNB-DU resource configuration, in this embodiment, it is proposed to configure the collocated mlAB-DU with conditional DU resource configuration.
The lAB-donor CU that is responsible for conditional DU resource configuration is the corresponding lAB-donor CU of CHO candidate cell for the mlAB-MT.
If a cell of one lAB-donor CU is requested to be the CHO candidate cell of a mlAB- MT, the source lAB-donor CU can send PCI value and gNB-DU resource configuration, together with mlAB-MT CHO request, to the candidate, indicating a request of conditional mlAB-DU migration. The candidate lAB-donor CU first performs admission control to mlAB- MT. If resource for mlAB-MT can be reserved, it then checks whether the requested same PCI and gNB-DU resource configuration can be reserved or not.
If yes, the candidate lAB-donor CU sends response to source lAB-donor CU with confirmation of using the same PCI and gNB-DU configuration by mlAB-DU when the collocated mlAB-MT performs CHO towards it. Moreover, an indication of using the same configuration/PCI should be included in the corresponding CHO configuration message.
If no, the candidate lAB-donor CU sends the updated PCI and/or gNB-DU resource configuration to source lAB-donor CU, together with CHO configuration of mlAB-MT.
The Following two options are considered for conditional DU resource configuration to mlAB-DU: Option 1: The conditional mlAB-DU resource configuration over F1AP. A conditional DU resource configuration procedure over F1AP is proposed in this option. A Source lAB-donor CU configures mlAB-DU with a list of candidate lAB-donor CU, each item has its own identity (e.g. condDUReconfigld) corresponding to the condReconfigld of mlAB- MT. If the same lAB-donor CU is used by mlAB-MT’s CHO candidate cell, one condDUReconfigld is mapped to multiple condReconfigld of mlAB-MT.
If the same PCI value and gNB-DU resource configuration can be used by mlAB-DU during mlAB-MT’s CHO, the source lAB-donor CU set “same configuration” into “true” and send conditional DU resource message to mlAB-DU, together with collocated mlAB-MT’s conditional mobility information.
If different PCI value or gNB-DU resource configuration is configured, the source IAB- donor CU set “same configuration” into “false” and send the reserved conditional DU resource information to mlAB-DU over conditional DU resource configuration message, together with collocated mlAB-MT’s conditional mobility information.
Once a CHO candidate is selected by mlAB-MT, according to the selected CondReconfigld, the mlAB-DU adopts the conditional DU resource configuration of CondDUReconfigld corresponding to CondReconfigld.
Option 2: The conditional mlAB-DU resource configuration over RRC signaling
Alternatively, the lAB-donor CU can also use CondReconfig message to carry conditional DU resource configuration and send it to the mlAB-MT over RRC signaling. A new IE can be introduced to CondReconfigToAddModList for the collocated mlAB-DU’s conditional DU configuration, e.g. condDUReconfig.
To request conditional DU resource configuration, a new conditional DU resource request/response procedure is proposed over Xn interface. Alternatively, a new IE “conditional DU resource request/response” is introduced in HANDOVER REQUEST/RESPONSE message.
In one or more embodiments, a new PCI of a mlAB-DU may be configured for served UEs during RRCReconfiguration. The PCI of mlAB-DU might be changed during mlAB- node’s full migration due to PCI collision. To reduce impact to the served UEs (i.e. avoiding UE experiencing RLF, etc), it is proposed to include the new PCI value and the corresponding conditional RRCReconfiguration message configured by this new cell of mlAB-DU in the CHO candidate list for the served UEs. The cell in mlAB-DU with new PCI value is treated as a conditional handover cell to the served UEs.
In one or more embodiments, there may be a dual termination of mlAB-DU. To reduce service interruption caused by mlAB-DU Fl termination change, it is proposed to setup Fl interface between mlAB-DU and target lAB-donor CU before releasing Fl interface between mlAB-DU and source lAB-donor CU. During the procedure, the mlAB-DU is configured by two lAB-donor CU with different TNL addresses, etc. If same PCI and DU resource configuration can be used by mlAB-DU, a shared BAP/RLC/MAC/PHY can be used at mlAB- DU, while connecting to separate TNL protocol stacks (GTP-u, etc). If different PCI and DU resource configuration is configured to mlAB-DU by different donor CU, mlAB-DU holds two separate BAP/RLC/MAC/PHY layers as well as TNL.
The Fl termination towards source lAB-donor CU will be released after successful Fl setup between mlAB-DU and target lAB-donor CU. Target lAB-donor CU may send an indication to source lAB-donor CU to release its Fl tunnel towards mobile IAB-DU.
In another alternative, the separate or group handover procedure of served UEs can perform after successful mlAB-node’s full migration (after mlAB-MT successful HO and mlAB-DU successful Fl setup). After mlAB-node’s successful full migration, source lAB- donor CU then performs handover procedure for the served UEs, and the Fl tunnel between mlAB-DU and source lAB-donor CU is released after successful separate or group handover of served UEs.
The above descriptions are for purposes of illustration and are not meant to be limiting. Numerous other examples, configurations, processes, algorithms, etc., may exist, some of which are described in greater detail below. Example embodiments will now be described with reference to the accompanying figures.
FIG. 1 is a network diagram illustrating an example network environment 100, in accordance with one or more example embodiments of the present disclosure.
Wireless network 100 may include one or more UEs 120 and one or more RANs 102 (e.g., gNBs), which may communicate in accordance with 3GPP communication standards. The UE(s) 120 may be mobile devices that are non- stationary (e.g., not having fixed locations) or may be stationary devices.
In some embodiments, the UEs 120 and the RANs 102 may include one or more computer systems similar to that of FIGs. 3-5.
One or more illustrative UE(s) 120 and/or RAN(s) 102 may be operable by one or more user(s) 110. A UE may take on multiple distinct characteristics, each of which shape its function. For example, a single addressable unit might simultaneously be a portable UE, a quality-of-service (QoS) UE, a dependent UE, and a hidden UE. The UE(s) 120 (e.g., 124, 126, or 128) and/or RAN(s) 102 may include any suitable processor-driven device including, but not limited to, a mobile device or a non-mobile, e.g., a static device. For example, UE(s) 120 may include, a software enabled AP (SoftAP), a personal computer (PC), a wearable wireless device (e.g., bracelet, watch, glasses, ring, etc.), a desktop computer, a mobile computer, a laptop computer, an ultrabookTM computer, a notebook computer, a tablet computer, a server computer, a handheld computer, a handheld device, an internet of things (loT) device, a sensor device, a PDA device, a handheld PDA device, an on-board device, an off-board device, a hybrid device (e.g., combining cellular phone functionalities with PDA device functionalities), a consumer device, a vehicular device, a non-vehicular device, a mobile or portable device, a non-mobile or non-portable device, a mobile phone, a cellular telephone, a PCS device, a PDA device which incorporates a wireless communication device, a mobile or portable GPS device, a DVB device, a relatively small computing device, a non-desktop computer, a “carry small live large” (CSLL) device, an ultra mobile device (UMD), an ultra mobile PC (UMPC), a mobile internet device (MID), an “origami” device or computing device, a device that supports dynamically composable computing (DCC), a context-aware device, a video device, an audio device, an A/V device, a set-top-box (STB), a blu-ray disc (BD) player, a BD recorder, a digital video disc (DVD) player, a high definition (HD) DVD player, a DVD recorder, a HD DVD recorder, a personal video recorder (PVR), a broadcast HD receiver, a video source, an audio source, a video sink, an audio sink, a stereo tuner, a broadcast radio receiver, a flat panel display, a personal media player (PMP), a digital video camera (DVC), a digital audio player, a speaker, an audio receiver, an audio amplifier, a gaming device, a data source, a data sink, a digital still camera (DSC), a media player, a smartphone, a television, a music player, or the like. Other devices, including smart devices such as lamps, climate control, car components, household components, appliances, etc. may also be included in this list.
As used herein, the term “Internet of Things (loT) device” is used to refer to any object (e.g., an appliance, a sensor, etc.) that has an addressable interface (e.g., an Internet protocol (IP) address, a Bluetooth identifier (ID), a near-field communication (NFC) ID, etc.) and can transmit information to one or more other devices over a wired or wireless connection. An loT device may have a passive communication interface, such as a quick response (QR) code, a radio-frequency identification (RFID) tag, an NFC tag, or the like, or an active communication interface, such as a modem, a transceiver, a transmitter-receiver, or the like. An loT device can have a particular set of attributes (e.g., a device state or status, such as whether the loT device is on or off, open or closed, idle or active, available for task execution or busy, and so on, a cooling or heating function, an environmental monitoring or recording function, a lightemitting function, a sound-emitting function, etc.) that can be embedded in and/or controlled/monitored by a central processing unit (CPU), microprocessor, ASIC, or the like, and configured for connection to an loT network such as a local ad-hoc network or the Internet. For example, loT devices may include, but are not limited to, refrigerators, toasters, ovens, microwaves, freezers, dishwashers, dishes, hand tools, clothes washers, clothes dryers, furnaces, air conditioners, thermostats, televisions, light fixtures, vacuum cleaners, sprinklers, electricity meters, gas meters, etc., so long as the devices are equipped with an addressable communications interface for communicating with the loT network. loT devices may also include cell phones, desktop computers, laptop computers, tablet computers, personal digital assistants (PDAs), etc. Accordingly, the loT network may be comprised of a combination of “legacy” Internet-accessible devices (e.g., laptop or desktop computers, cell phones, etc.) in addition to devices that do not typically have Internet-connectivity (e.g., dishwashers, etc.).
Any of the UE(s) 120 (e.g., UEs 124, 126, 128), and UE(s) 120 may be configured to communicate with each other via one or more communications networks 130 and/or 135 wirelessly or wired. The UE(s) 120 may also communicate peer-to-peer or directly with each other with or without the RAN(s) 102. Any of the communications networks 130 and/or 135 may include, but not limited to, any one of a combination of different types of suitable communications networks such as, for example, broadcasting networks, cable networks, public networks (e.g., the Internet), private networks, wireless networks, cellular networks, or any other suitable private and/or public networks. Further, any of the communications networks 130 and/or 135 may have any suitable communication range associated therewith and may include, for example, cellular networks. In addition, any of the communications networks 130 and/or 135 may include any type of medium over which network traffic may be carried including, but not limited to, coaxial cable, twisted-pair wire, optical fiber, a hybrid fiber coaxial (HFC) medium, microwave terrestrial transceivers, radio frequency communication mediums, white space communication mediums, ultra-high frequency communication mediums, satellite communication mediums, or any combination thereof.
Any of the UE(s) 120 (e.g., UE 124, 126, 128) and RAN(s) 102 may include one or more communications antennas. The one or more communications antennas may be any suitable type of antennas corresponding to the communications protocols used by the UE(s) 120 (e.g., UEs 124, 126 and 128), and RAN(s) 102. Some non-limiting examples of suitable communications antennas include cellular antennas, 3GPP family of standards compatible antennas, directional antennas, non-directional antennas, dipole antennas, folded dipole antennas, patch antennas, multiple-input multiple-output (MIMO) antennas, omnidirectional antennas, quasi-omnidirectional antennas, or the like. The one or more communications antennas may be communicatively coupled to a radio component to transmit and/or receive signals, such as communications signals to and/or from the UEs 120 and/or RAN(s) 102.
Any of the UE(s) 120 (e.g., UE 124, 126, 128), and RAN(s) 102 may be configured to perform directional transmission and/or directional reception in conjunction with wirelessly communicating in a wireless network. Any of the UE(s) 120 (e.g., UE 124, 126, 128), and RAN(s) 102 may be configured to perform such directional transmission and/or reception using a set of multiple antenna arrays (e.g., DMG antenna arrays or the like). Each of the multiple antenna arrays may be used for transmission and/or reception in a particular respective direction or range of directions. Any of the UE(s) 120 (e.g., UE 124, 126, 128), and RAN(s) 102 may be configured to perform any given directional transmission towards one or more defined transmit sectors. Any of the UE(s) 120 (e.g., UE 124, 126, 128), and RAN(s) 102 may be configured to perform any given directional reception from one or more defined receive sectors.
MIMO beamforming in a wireless network may be accomplished using RF beamforming and/or digital beamforming. In some embodiments, in performing a given MIMO transmission, UE 120 and/or RAN(s) 102 may be configured to use all or a subset of its one or more communications antennas to perform MIMO beamforming.
Any of the UE 120 (e.g., UE 124, 126, 128), and RAN(s) 102 may include any suitable radio and/or transceiver for transmitting and/or receiving radio frequency (RF) signals in the bandwidth and/or channels corresponding to the communications protocols utilized by any of the UE(s) 120 and RAN(s) 102 to communicate with each other. The radio components may include hardware and/or software to modulate and/or demodulate communications signals according to pre-established transmission protocols. The radio components may further have hardware and/or software instructions to communicate via one or more 3GPP protocols and using 3GPP bandwidths. The radio component may include any known receiver and baseband suitable for communicating via the communications protocols. The radio component may further include a low noise amplifier (LNA), additional signal amplifiers, an analog-to-digital (A/D) converter, one or more buffers, and digital baseband.
In one or more embodiments, and with reference to FIG. 1, one or more of the UE 120 may exchange frames 140 with the RANs 102. The frames 140 may include messages between mlABs 150, the UEs 120, the RANs 102, and the like, related to mlAB integration, cell selection and reselection, and the like as described herein.
It is understood that the above descriptions are for purposes of illustration and are not meant to be limiting.
FIG. 2 illustrates a flow diagram of a mobile integrated access and backhaul (mlAB) topology integration 200 using an enhanced setup response, in accordance with one or more example embodiments of the present disclosure.
Referring to FIG. 2, the mlAB topology integration 200 may include a mlAB-node 202, a lAB-donor 204, and a core network (CN) 206. The CN 206 may send a next generation (NG) setup response 208 (including a mlAB supported IE indicating mlAB support) to the lAB- donor 204. The lAB-donor 204 may send the mlAB support 210 indicator in SIB 1 . The mlAB node 202 and the lAB-donor 204 then may perform a topology integration as described above.
FIG. 3A illustrates an example velocity-based cell selection and reselection 300 for radio resource control idle (RRC_IDLE) and RRC inactive (RRC_INACTIVE) user equipment before and after moving out of a mlAB, in accordance with one or more example embodiments of the present disclosure.
Referring to FIG. 3A, a RAN 302 and a mlAB 304 (e.g., shown as a bus) are shown. On the left of FIG. 3A, a UE 306 with RRCJDLE or RRCJNACTIVE is on the mlAB 304, and moves out of the mlAB 304 on the right side of FIG. 3A, when the UE 306 is expected to select or reselect a normal cell on which to camp.
FIG. 3B illustrates an example velocity-based cell selection and reselection for the RRC_IDLE and the RRC_INACTIVE user equipment 306 of FIG. 3 A before and after moving into the mlAB 304 of FIG. 3A, in accordance with one or more example embodiments of the present disclosure.
FIG. 3C illustrates an example velocity-based cell selection and reselection for the RRC_IDLE and the RRC_INACTIVE user equipment 306 of FIG. 3A while moving together with the mlAB 304 of FIG. 3 A, in accordance with one or more example embodiments of the present disclosure. Referring to FIG. 3C, the UE 306 is inside of the mlAB 304 and therefore is not shown, but the UE 306 is expected not to perform any cell reselection to another mlAB-node or gNB (e.g., RANs 322-328). The mlAB 304 may move from one mlAB node to another.
FIG. 3D illustrates an example velocity-based cell selection and reselection for the RRC_IDLE and the RRC_INACTIVE user equipment 306 of FIG. 3 A while the mlAB 304 of FIG. 3A moves between lAB-donors, in accordance with one or more example embodiments of the present disclosure.
Referring to FIG. 3D, the UE 306 is moving inside the mlAB 304 from coverage of one mlAB node to another.
FIG. 4 illustrates a flow diagram of a mlAB message flow 400, in accordance with one or more example embodiments of the present disclosure.
Referring to FIG. 4, the mlAB message flow 400 may represent mlAB-node identification and authorization with the mlAB-node 202, the lAB-donor 204, and the CN 206 of FIG. 2. The mlAB-node 202 and the lAB-donor 204 may perform cell selection at step 402. The mlAB node 202 may send a RRC Setup Complete message 404 with a mlAB-node indication to the lAB-donor 204, which then may send an initial UE message 406 to the CN 206 requesting UE context with a mlAB node indication. The CN 206 may send an authentication 408 to the lAB-donor 204, which may establish the UE context for a mlAB-MT 410.
FIG. 5A illustrates a flow diagram of a mlAB message flow 500 for physical cell identifier (PCI) management, in accordance with one or more example embodiments of the present disclosure.
Referring a to FIG. 5A, the mlAB message flow 500 may include a mlAB 502, a lAB- donor 504, a lAB-donor 506, and an 0AM 508. The 0AM 508 may reserve 510 PCI spaces for lAB-donor CUs for the mlAB 502. The 0AM 508 may assign 512 unique PCIs for the mlAB 502 under the lAB-donor 506. The 0AM 508 may assign 514 unique PCIs for the mlAB 502 under the lAB-donor 504. The mlAB 502 may perform a IAB-MT setup 516 with the lAB-donor 504. The lAB-donor 504 and the lAB-donor 506 may assign a temporary PCI for the mlAB initial integration. The mlAB 502 use a Fl setup 520 using the temporary PCI. The lAB-donor 504 may detect the Fl setup, and may reallocate a new PCI. The lAB-donor 504 may send a gNB-CU configuration update 524 to the mlAB 502, which may use 526 the new unique PCI.
FIG. 5B illustrates a flow diagram of a mlAB message flow 550 for PCI management, in accordance with one or more example embodiments of the present disclosure. Referring to FIG. 5B, the mlAB message flow 550 may include the 0AM 508 of FIG. 5A reserving 552 PCI spaces for lAB-donor CUs for the mlAB 502 of FIG. 5A. The 0AM 508 may assign 554 unique PCIs for the mlAB 502. The mlAB 502 perform an IAB-MT setup 556 with the lAB-donor 504, and the lAB-donor 504 may establish 558 a BH RLC CH with the mlAB 502. The mlAB 502 may select one assigned PCI from a configured list, and may perform a Fl setup 562 using the assigned PCI with the lAB-donor 504. The mlAB 502 may send a mlAB-MT HO request 564 to the lAB-donor 506, which may respond to the lAB-donor 504 with a HO ACK 566. The lAB-donor 504 may perform RRCReconfiguration 568 with the mlAB 502. The mlAB 502 may perform a Fl setup 570 using the existing PCI. The lAB- donor 506 may detect a PCI collision, and may inform 574 the mlAB 502 with PCI list and request selection of a non-conflicting PCI. At step 576, the mlAB 502 may select a new assigned PCI from the configured list, and may provide a gNB-DU configuration update 578 to the lAB-donor 506.
FIG. 6A illustrates a flow diagram of a mlAB message flow 600 for IAB transport migration, in accordance with one or more example embodiments of the present disclosure.
The message flow 600 includes a UE 602, a UE 604, a UE 606, a mlAB 608, an lAB- donor 610, and an lAB-donor 612 performing steps 614-644, which represent at least a subset of the steps described above with respect to TS38.423 for an IAB transport migration management request.
FIG. 6B illustrates a flow diagram of a mlAB traffic flow for a conditional mlAB distributed unit resource configuration 650, in accordance with one or more example embodiments of the present disclosure.
Referring to FIG. 6B, the mlAB-DU resource configuration 650 may include a mlAB- DU 652 and an lAB-donor CU 654, which may send a conditional DU resource configuration 656 (e.g., the conditional mlAB-DU resource configuration over F1AP described above).
FIG. 6C illustrates a flow diagram of a mlAB traffic flow for a conditional mlAB distributed unit resource configuration 660, in accordance with one or more example embodiments of the present disclosure.
Referring to FIG. 6C, the conditional mlAB distributed unit resource configuration 660 may include a source lAB-donor 662 and a target lAB-donor 664. The source lAB-donor 662 may send a conditional DU resource request 666, and the target lAB-donor 664 may respond with a conditional DU resource response (e.g., as described above for the conditional mlAB- DU resource configuration over RRC signaling). FIG. 6D illustrates a flow diagram of a mlAB traffic flow 670 for a user equipment handover, in accordance with one or more example embodiments of the present disclosure.
Referring to FIG. 6D, the mlAB traffic flow 670 may include the UE 602, the UE 604, the UE 606, the mlAB 608, the lAB-donor 610, and the lAB-donor 612 of FIG. 6A, and includes an AMF 672. The mlAB traffic flow 670 includes steps 614-682, representing at least a portion of Steps 1-26 of the handover described above.
FIG. 7A illustrates a flow diagram of a mlAB traffic flow 700 for a user equipment handover, in accordance with one or more example embodiments of the present disclosure.
Referring to FIG. 7A, the mlAB traffic flow 700 may include the UE 602, the UE 604, the UE 606, the mlAB 608, the lAB-donor 610, and the lAB-donor 612 of FIG. 6A, performing steps 614-618 and steps 702-708, representing at least a portion of the Fl setup of the mlAB- DU toward a target lAB-donor CU as described above.
FIG. 7B illustrates a flow diagram of a mlAB traffic flow for a user equipment handover, in accordance with one or more example embodiments of the present disclosure.
Referring to FIG. 7A, the mlAB traffic flow 750 may include the UE 602, the UE 604, the UE 606, the mlAB 608, the lAB-donor 610, and the lAB-donor 612 of FIG. 6A, performing steps 614-618 and steps 702-704, representing at least a portion of the alternative Fl setup of the mlAB-DU toward a target lAB-donor CU as described above.
FIG. 8 illustrates a flow diagram of illustrative process for mlAB management 800, in accordance with one or more example embodiments of the present disclosure.
At block 802, a mlAB node may decode a first mlAB support indication received from a first mlAB donor, the first mlAB support indication indicating that the first mlAB donor is configured to serve the mlAB node as a mlAB donor.
At block 804, the mlAB node may decode a second mlAB support indication received from a second mlAB donor, the second mlAB support indication indicating that the second mlAB donor is configured to serve the mlAB node as the mlAB donor.
At block 806, the mlAB node may select the first mlAB donor or the second mlAB donor as the mlAB donor based on the first mlAB support indication or the second mlAB support indication. The communication of mlAB support capabilities, selection of a mlAB donor, handovers, and configurations may be performed according to the embodiments described above.
These embodiments are not meant to be limiting.
FIG. 9 illustrates a network 900 in accordance with various embodiments. The network 900 may operate in a manner consistent with 3GPP technical specifications for LTE or 5G/NR systems. However, the example embodiments are not limited in this regard and the described embodiments may apply to other networks that benefit from the principles described herein, such as future 3GPP systems, or the like.
The network 900 may include a UE 902, which may include any mobile or non-mobile computing device designed to communicate with a RAN 904 via an over-the-air connection. The UE 902 may be communicatively coupled with the RAN 904 by a Uu interface. The UE 902 may be, but is not limited to, a smartphone, tablet computer, wearable computer device, desktop computer, laptop computer, in-vehicle infotainment, in-car entertainment device, instrument cluster, head-up display device, onboard diagnostic device, dashtop mobile equipment, mobile data terminal, electronic engine management system, electronic/engine control unit, electronic/engine control module, embedded system, sensor, microcontroller, control module, engine management system, networked appliance, machine-type communication device, M2M or D2D device, loT device, etc.
In some embodiments, the network 900 may include a plurality of UEs coupled directly with one another via a sidelink interface. The UEs may be M2M/D2D devices that communicate using physical sidelink channels such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc.
In some embodiments, the UE 902 may additionally communicate with an AP 906 via an over-the-air connection. The AP 906 may manage a WLAN connection, which may serve to offload some/all network traffic from the RAN 904. The connection between the UE 902 and the AP 906 may be consistent with any IEEE 802.11 protocol, wherein the AP 906 could be a wireless fidelity (Wi-Fi®) router. In some embodiments, the UE 902, RAN 904, and AP 906 may utilize cellular- WLAN aggregation (for example, LWA/LWIP). Cellular-WLAN aggregation may involve the UE 902 being configured by the RAN 904 to utilize both cellular radio resources and WLAN resources.
The RAN 904 may include one or more access nodes, for example, AN 908. AN 908 may terminate air-interface protocols for the UE 902 by providing access stratum protocols including RRC, PDCP, RLC, MAC, and LI protocols. In this manner, the AN 308 may enable data/voice connectivity between CN 920 and the UE 902. In some embodiments, the AN 908 may be implemented in a discrete device or as one or more software entities running on server computers as part of, for example, a virtual network, which may be referred to as a CRAN or virtual baseband unit pool. The AN 908 be referred to as a BS, gNB, RAN node, eNB, ng- eNB, NodeB, RSU, TRxP, TRP, etc. The AN 908 may be a macrocell base station or a low power base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.
In embodiments in which the RAN 904 includes a plurality of ANs, they may be coupled with one another via an X2 interface (if the RAN 904 is an LTE RAN) or an Xn interface (if the RAN 904 is a 5G RAN). The X2/Xn interfaces, which may be separated into control/user plane interfaces in some embodiments, may allow the ANs to communicate information related to handovers, data/context transfers, mobility, load management, interference coordination, etc.
The ANs of the RAN 904 may each manage one or more cells, cell groups, component carriers, etc. to provide the UE 902 with an air interface for network access. The UE 902 may be simultaneously connected with a plurality of cells provided by the same or different ANs of the RAN 904. For example, the UE 902 and RAN 904 may use carrier aggregation to allow the UE 902 to connect with a plurality of component carriers, each corresponding to a Pcell or Scell. In dual connectivity scenarios, a first AN may be a master node that provides an MCG and a second AN may be secondary node that provides an SCG. The first/second ANs may be any combination of eNB, gNB, ng-eNB, etc.
The RAN 904 may provide the air interface over a licensed spectrum or an unlicensed spectrum. To operate in the unlicensed spectrum, the nodes may use LAA, eLAA, and/or feLAA mechanisms based on CA technology with PCells/Scells. Prior to accessing the unlicensed spectrum, the nodes may perform medium/carrier-sensing operations based on, for example, a listen-before-talk (LBT) protocol.
In V2X scenarios the UE 902 or AN 908 may be or act as a RSU, which may refer to any transportation infrastructure entity used for V2X communications. An RSU may be implemented in or by a suitable AN or a stationary (or relatively stationary) UE. An RSU implemented in or by: a UE may be referred to as a “UE-type RSU”; an eNB may be referred to as an “eNB-type RSU”; a gNB may be referred to as a “gNB-type RSU”; and the like. In one example, an RSU is a computing device coupled with radio frequency circuitry located on a roadside that provides connectivity support to passing vehicle UEs. The RSU may also include internal data storage circuitry to store intersection map geometry, traffic statistics, media, as well as applications/software to sense and control ongoing vehicular and pedestrian traffic. The RSU may provide very low latency communications required for high speed events, such as crash avoidance, traffic warnings, and the like. Additionally or alternatively, the RSU may provide other cellular/WLAN communications services. The components of the RSU may be packaged in a weatherproof enclosure suitable for outdoor installation, and may include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller or a backhaul network.
In some embodiments, the RAN 904 may be an LTE RAN 910 with eNBs, for example, eNB 912. The LTE RAN 910 may provide an LTE air interface with the following characteristics: SCS of 15 kHz; CP-OFDM waveform for DL and SC-FDMA waveform for UL; turbo codes for data and TBCC for control; etc. The LTE air interface may rely on CSI- RS for CSI acquisition and beam management; PDSCH/PDCCH DMRS for PDSCH/PDCCH demodulation; and CRS for cell search and initial acquisition, channel quality measurements, and channel estimation for coherent demodulation/detection at the UE. The LTE air interface may operating on sub-6 GHz bands.
In some embodiments, the RAN 904 may be an NG-RAN 914 with gNBs, for example, gNB 916, or ng-eNBs, for example, ng-eNB 918. The gNB 916 may connect with 5G-enabled UEs using a 5G NR interface. The gNB 916 may connect with a 5G core through an NG interface, which may include an N2 interface or an N3 interface. The ng-eNB 918 may also connect with the 5G core through an NG interface, but may connect with a UE via an LTE air interface. The gNB 916 and the ng-eNB 918 may connect with each other over an Xn interface.
In some embodiments, the NG interface may be split into two parts, an NG user plane (NG-U) interface, which carries traffic data between the nodes of the NG-RAN 914 and a UPF 948 (e.g., N3 interface), and an NG control plane (NG-C) interface, which is a signaling interface between the nodes of the NG-RAN 914 and an AMF 944 (e.g., N2 interface).
The NG-RAN 914 may provide a 5G-NR air interface with the following characteristics: variable SCS; CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL; polar, repetition, simplex, and Reed-Muller codes for control and LDPC for data. The 5G-NR air interface may rely on CSI-RS, PDSCH/PDCCH DMRS similar to the LTE air interface. The 5G-NR air interface may not use a CRS, but may use PBCH DMRS for PBCH demodulation; PTRS for phase tracking for PDSCH; and tracking reference signal for time tracking. The 5G- NR air interface may operating on FR1 bands that include sub-6 GHz bands or FR2 bands that include bands from 24.25 GHz to 52.6 GHz. The 5G-NR air interface may include an SSB that is an area of a downlink resource grid that includes PSS/SSS/PBCH.
In some embodiments, the 5G-NR air interface may utilize BWPs for various purposes. For example, BWP can be used for dynamic adaptation of the SCS. For example, the UE 902 can be configured with multiple BWPs where each BWP configuration has a different SCS. When a BWP change is indicated to the UE 902, the SCS of the transmission is changed as well. Another use case example of BWP is related to power saving. In particular, multiple BWPs can be configured for the UE 902 with different amount of frequency resources (for example, PRBs) to support data transmission under different traffic loading scenarios. A BWP containing a smaller number of PRBs can be used for data transmission with small traffic load while allowing power saving at the UE 902 and in some cases at the gNB 916. A BWP containing a larger number of PRBs can be used for scenarios with higher traffic load.
The RAN 904 is communicatively coupled to CN 920 that includes network elements to provide various functions to support data and telecommunications services to customers/subscribers (for example, users of UE 902). The components of the CN 920 may be implemented in one physical node or separate physical nodes. In some embodiments, NFV may be utilized to virtualize any or all of the functions provided by the network elements of the CN 920 onto physical compute/storage resources in servers, switches, etc. A logical instantiation of the CN 920 may be referred to as a network slice, and a logical instantiation of a portion of the CN 920 may be referred to as a network sub-slice.
In some embodiments, the CN 920 may be an LTE CN 922, which may also be referred to as an EPC. The LTE CN 922 may include MME 924, SGW 926, SGSN 928, HSS 930, PGW 932, and PCRF 934 coupled with one another over interfaces (or “reference points”) as shown. Functions of the elements of the LTE CN 922 may be briefly introduced as follows.
The MME 924 may implement mobility management functions to track a current location of the UE 902 to facilitate paging, bearer activation/deactivation, handovers, gateway selection, authentication, etc.
The SGW 926 may terminate an SI interface toward the RAN and route data packets between the RAN and the LTE CN 922. The SGW 926 may be a local mobility anchor point for inter- RAN node handovers and also may provide an anchor for inter-3 GPP mobility. Other responsibilities may include lawful intercept, charging, and some policy enforcement.
The SGSN 928 may track a location of the UE 902 and perform security functions and access control. In addition, the SGSN 928 may perform inter-EPC node signaling for mobility between different RAT networks; PDN and S-GW selection as specified by MME 924; MME selection for handovers; etc. The S3 reference point between the MME 924 and the SGSN 928 may enable user and bearer information exchange for inter-3GPP access network mobility in idle/active states.
The HSS 930 may include a database for network users, including subscription-related information to support the network entities’ handling of communication sessions. The HSS 930 can provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, etc. An S6a reference point between the HSS 930 and the MME 924 may enable transfer of subscription and authentication data for authenticating/authorizing user access to the LTE CN 920.
The PGW 932 may terminate an SGi interface toward a data network (DN) 936 that may include an application/content server 938. The PGW 932 may route data packets between the LTE CN 922 and the data network 936. The PGW 932 may be coupled with the SGW 926 by an S 5 reference point to facilitate user plane tunneling and tunnel management. The PGW 932 may further include a node for policy enforcement and charging data collection (for example, PCEF). Additionally, the SGi reference point between the PGW 932 and the data network 936 may be an operator external public, a private PDN, or an intra-operator packet data network, for example, for provision of IMS services. The PGW 932 may be coupled with a PCRF 934 via a Gx reference point.
The PCRF 934 is the policy and charging control element of the LTE CN 922. The PCRF 934 may be communicatively coupled to the app/content server 938 to determine appropriate QoS and charging parameters for service flows. The PCRF 932 may provision associated rules into a PCEF (via Gx reference point) with appropriate TFT and QCI.
In some embodiments, the CN 920 may be a 5GC 940. The 5GC 940 may include an AUSF 942, AMF 944, SMF 946, UPF 948, NSSF 950, NEF 952, NRF 954, PCF 956, UDM 958, and AF 960 coupled with one another over interfaces (or “reference points”) as shown. Functions of the elements of the 5GC 940 may be briefly introduced as follows.
The AUSF 942 may store data for authentication of UE 902 and handle authentication- related functionality. The AUSF 942 may facilitate a common authentication framework for various access types. In addition to communicating with other elements of the 5GC 940 over reference points as shown, the AUSF 942 may exhibit an Nausf service-based interface.
The AMF 944 may allow other functions of the 5GC 940 to communicate with the UE 902 and the RAN 904 and to subscribe to notifications about mobility events with respect to the UE 902. The AMF 944 may be responsible for registration management (for example, for registering UE 902), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. The AMF 944 may provide transport for SM messages between the UE 902 and the SMF 946, and act as a transparent proxy for routing SM messages. AMF 944 may also provide transport for SMS messages between UE 902 and an SMSF. AMF 944 may interact with the AUSF 942 and the UE 902 to perform various security anchor and context management functions. Furthermore, AMF 944 may be a termination point of a RAN CP interface, which may include or be an N2 reference point between the RAN 904 and the AMF 944; and the AMF 944 may be a termination point of NAS (Nl) signaling, and perform NAS ciphering and integrity protection. AMF 944 may also support NAS signaling with the UE 902 over an N3 IWF interface.
The SMF 946 may be responsible for SM (for example, session establishment, tunnel management between UPF 948 and AN 908); UE IP address allocation and management (including optional authorization); selection and control of UP function; configuring traffic steering at UPF 948 to route traffic to proper destination; termination of interfaces toward policy control functions; controlling part of policy enforcement, charging, and QoS; lawful intercept (for SM events and interface to LI system); termination of SM parts of NAS messages; downlink data notification; initiating AN specific SM information, sent via AMF 944 over N2 to AN 908; and determining SSC mode of a session. SM may refer to management of a PDU session, and a PDU session or “session” may refer to a PDU connectivity service that provides or enables the exchange of PDUs between the UE 902 and the data network 936.
The UPF 948 may act as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point of interconnect to data network 936, and a branching point to support multi-homed PDU session. The UPF 948 may also perform packet routing and forwarding, perform packet inspection, enforce the user plane part of policy rules, lawfully intercept packets (UP collection), perform traffic usage reporting, perform QoS handling for a user plane (e.g., packet filtering, gating, UL/DL rate enforcement), perform uplink traffic verification (e.g., SDF-to-QoS flow mapping), transport level packet marking in the uplink and downlink, and perform downlink packet buffering and downlink data notification triggering. UPF 948 may include an uplink classifier to support routing traffic flows to a data network.
The NSSF 950 may select a set of network slice instances serving the UE 902. The NSSF 950 may also determine allowed NSSAI and the mapping to the subscribed S-NSSAIs, if needed. The NSSF 950 may also determine the AMF set to be used to serve the UE 902, or a list of candidate AMFs based on a suitable configuration and possibly by querying the NRF 954. The selection of a set of network slice instances for the UE 902 may be triggered by the AMF 944 with which the UE 902 is registered by interacting with the NSSF 950, which may lead to a change of AMF. The NSSF 950 may interact with the AMF 944 via an N22 reference point; and may communicate with another NSSF in a visited network via an N31 reference point (not shown). Additionally, the NSSF 950 may exhibit an Nnssf service-based interface.
The NEF 952 may securely expose services and capabilities provided by 3GPP network functions for third party, internal exposure/re-exposure, AFs (e.g., AF 960), edge computing or fog computing systems, etc. In such embodiments, the NEF 952 may authenticate, authorize, or throttle the AFs. NEF 952 may also translate information exchanged with the AF 960 and information exchanged with internal network functions. For example, the NEF 952 may translate between an AF-Service-Identifier and an internal 5GC information. NEF 952 may also receive information from other NFs based on exposed capabilities of other NFs. This information may be stored at the NEF 952 as structured data, or at a data storage NF using standardized interfaces. The stored information can then be re-exposed by the NEF 952 to other NFs and AFs, or used for other purposes such as analytics. Additionally, the NEF 952 may exhibit an Nnef service-based interface.
The NRF 954 may support service discovery functions, receive NF discovery requests from NF instances, and provide the information of the discovered NF instances to the NF instances. NRF 954 also maintains information of available NF instances and their supported services. As used herein, the terms “instantiate,” “instantiation,” and the like may refer to the creation of an instance, and an “instance” may refer to a concrete occurrence of an object, which may occur, for example, during execution of program code. Additionally, the NRF 954 may exhibit the Nnrf service-based interface.
The PCF 956 may provide policy rules to control plane functions to enforce them, and may also support unified policy framework to govern network behavior. The PCF 956 may also implement a front end to access subscription information relevant for policy decisions in a UDR of the UDM 958. In addition to communicating with functions over reference points as shown, the PCF 956 exhibit an Npcf service-based interface.
The UDM 958 may handle subscription-related information to support the network entities’ handling of communication sessions, and may store subscription data of UE 902. For example, subscription data may be communicated via an N8 reference point between the UDM 958 and the AMF 944. The UDM 958 may include two parts, an application front end and a UDR. The UDR may store subscription data and policy data for the UDM 958 and the PCF 956, and/or structured data for exposure and application data (including PFDs for application detection, application request information for multiple UEs 902) for the NEF 952. The Nudr service-based interface may be exhibited by the UDR 921 to allow the UDM 958, PCF 956, and NEF 952 to access a particular set of the stored data, as well as to read, update (e.g., add, modify), delete, and subscribe to notification of relevant data changes in the UDR. The UDM may include a UDM-FE, which is in charge of processing credentials, location management, subscription management and so on. Several different front ends may serve the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing, user identification handling, access authorization, registration/mobility management, and subscription management. In addition to communicating with other NFs over reference points as shown, the UDM 958 may exhibit the Nudm service-based interface.
The AF 960 may provide application influence on traffic routing, provide access to NEF, and interact with the policy framework for policy control.
In some embodiments, the 5GC 940 may enable edge computing by selecting operator/3rd party services to be geographically close to a point that the UE 902 is attached to the network. This may reduce latency and load on the network. To provide edge-computing implementations, the 5GC 940 may select a UPF 948 close to the UE 902 and execute traffic steering from the UPF 948 to data network 936 via the N6 interface. This may be based on the UE subscription data, UE location, and information provided by the AF 960. In this way, the AF 960 may influence UPF (re)selection and traffic routing. Based on operator deployment, when AF 960 is considered to be a trusted entity, the network operator may permit AF 960 to interact directly with relevant NFs. Additionally, the AF 960 may exhibit an Naf service-based interface.
The data network 936 may represent various network operator services, Internet access, or third party services that may be provided by one or more servers including, for example, application/content server 938.
FIG. 10 schematically illustrates a wireless network 1000 in accordance with various embodiments. The wireless network 1000 may include a UE 1002 in wireless communication with an AN 1004. The UE 1002 and AN 1004 may be similar to, and substantially interchangeable with, like-named components described elsewhere herein.
The UE 1002 may be communicatively coupled with the AN 1004 via connection 1006. The connection 1006 is illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols such as an LTE protocol or a 5G NR protocol operating at mmWave or sub-6GHz frequencies.
The UE 1002 may include a host platform 1008 coupled with a modem platform 1010. The host platform 1008 may include application processing circuitry 1012, which may be coupled with protocol processing circuitry 1014 of the modem platform 1010. The application processing circuitry 1012 may run various applications for the UE 1002 that source/sink application data. The application processing circuitry 1012 may further implement one or more layer operations to transmit/receive application data to/from a data network. These layer operations may include transport (for example UDP) and Internet (for example, IP) operations The protocol processing circuitry 1014 may implement one or more of layer operations to facilitate transmission or reception of data over the connection 1006. The layer operations implemented by the protocol processing circuitry 1014 may include, for example, MAC, RLC, PDCP, RRC and NAS operations.
The modem platform 1010 may further include digital baseband circuitry 1016 that may implement one or more layer operations that are “below” layer operations performed by the protocol processing circuitry 1014 in a network protocol stack. These operations may include, for example, PHY operations including one or more of HARQ-ACK functions, scrambling/descrambling, encoding/decoding, layer mapping/de-mapping, modulation symbol mapping, received symbol/bit metric determination, multi-antenna port precoding/decoding, which may include one or more of space-time, space-frequency or spatial coding, reference signal generation/detection, preamble sequence generation and/or decoding, synchronization sequence generation/detection, control channel signal blind decoding, and other related functions.
The modem platform 1010 may further include transmit circuitry 1018, receive circuitry 1020, RF circuitry 1022, and RF front end (RFFE) 1024, which may include or connect to one or more antenna panels 1026. Briefly, the transmit circuitry 1018 may include a digital-to-analog converter, mixer, intermediate frequency (IF) components, etc.; the receive circuitry 1020 may include an analog-to-digital converter, mixer, TF components, etc.; the RF circuitry 1022 may include a low-noise amplifier, a power amplifier, power tracking components, etc.; RFFE 1024 may include filters (for example, surface/bulk acoustic wave filters), switches, antenna tuners, beamforming components (for example, phase-array antenna components), etc. The selection and arrangement of the components of the transmit circuitry 1018, receive circuitry 1020, RF circuitry 1022, RFFE 1024, and antenna panels 1026 (referred generically as “transmit/receive components”) may be specific to details of a specific implementation such as, for example, whether communication is TDM or FDM, in mmWave or sub-6 gHz frequencies, etc. In some embodiments, the transmit/receive components may be arranged in multiple parallel transmit/receive chains, may be disposed in the same or different chips/modules, etc.
In some embodiments, the protocol processing circuitry 1014 may include one or more instances of control circuitry (not shown) to provide control functions for the transmit/receive components.
A UE reception may be established by and via the antenna panels 1026, RFFE 1024, RF circuitry 1022, receive circuitry 1020, digital baseband circuitry 1016, and protocol processing circuitry 1014. In some embodiments, the antenna panels 1026 may receive a transmission from the AN 1004 by receive-beamforming signals received by a plurality of antennas/antenna elements of the one or more antenna panels 1026.
A UE transmission may be established by and via the protocol processing circuitry 1014, digital baseband circuitry 1016, transmit circuitry 1018, RF circuitry 1022, RFFE 1024, and antenna panels 1026. In some embodiments, the transmit components of the UE 1004 may apply a spatial filter to the data to be transmitted to form a transmit beam emitted by the antenna elements of the antenna panels 1026.
Similar to the UE 1002, the AN 1004 may include a host platform 1028 coupled with a modem platform 1030. The host platform 1028 may include application processing circuitry 1032 coupled with protocol processing circuitry 1034 of the modem platform 1030. The modem platform may further include digital baseband circuitry 1036, transmit circuitry 1038, receive circuitry 1040, RF circuitry 1042, RFFE circuitry 1044, and antenna panels 1046. The components of the AN 1004 may be similar to and substantially interchangeable with like- named components of the UE 1002. In addition to performing data transmission/reception as described above, the components of the AN 1008 may perform various logical functions that include, for example, RNC functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling.
FIG. 1 1 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein. Specifically, Figure 11 shows a diagrammatic representation of hardware resources 1100 including one or more processors (or processor cores) 1110, one or more memory/storage devices 1120, and one or more communication resources 1130, each of which may be communicatively coupled via a bus 1140 or other interface circuitry. For embodiments where node virtualization (e.g., NFV) is utilized, a hypervisor 1102 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize the hardware resources 1100.
The processors 1110 may include, for example, a processor 1112 and a processor 1114. The processors 1110 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radio-frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.
The memory/storage devices 1120 may include main memory, disk storage, or any suitable combination thereof. The memory/storage devices 1120 may include, but are not limited to, any type of volatile, non-volatile, or semi-volatile memory such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), Flash memory, solid-state storage, etc.
The communication resources 1130 may include interconnection or network interface controllers, components, or other suitable devices to communicate with one or more peripheral devices 1104 or one or more databases 1106 or other network elements via a network 1108. For example, the communication resources 1130 may include wired communication components (e.g., for coupling via USB, Ethernet, etc.), cellular communication components, NFC components, Bluetooth® (or Bluetooth® Low Energy) components, Wi-Fi® components, and other communication components.
Instructions 1150 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 1110 to perform any one or more of the methodologies discussed herein. The instructions 1150 may reside, completely or partially, within at least one of the processors 1110 (e.g., within the processor’s cache memory), the memory/storage devices 1120, or any suitable combination thereof. Furthermore, any portion of the instractions 1 150 may be transferred to the hardware resources 1 100 from any combination of the peripheral devices 1104 or the databases 106. Accordingly, the memory of processors 1110, the memory/storage devices 1120, the peripheral devices 1104, and the databases 1106 are examples of computer-readable and machine-readable media.
The following examples pertain to further embodiments.
Example 1 may include an apparatus of a mobile integrated access and backhaul (mlAB) node, the apparatus comprising processing circuitry coupled to storage for storing information associated with mlAB, the processing circuitry configured to: decode a first mlAB support indication received from a first mlAB donor, the first mlAB support indication indicating that the first mlAB donor is configured to serve the mlAB node as a mlAB donor; decode a second mlAB support indication received from a second mlAB donor, the second mlAB support indication indicating that the second mlAB donor is configured to serve the mlAB node as the mlAB donor; and select the first mlAB donor or the second mlAB donor as the mlAB donor based on the first mlAB support indication or the second mlAB support indication.
Example 2 may include the apparatus of example 1 and/or any other example herein, wherein at least one of unified access control or a cell bar are not applied in the selection of the first mlAB donor or the second mlAB donor. Example 3 may include the apparatus of example 1 and/or any other example herein, wherein the first mlAB support indication is based on a Fl-C connection between a network node centralized unit and a network node distribution unit.
Example 4 may include the apparatus of example 1 and/or any other example herein, wherein the processing circuitry is further configured to encode a mlAB node indication, to be transmitted to the first mlAB donor in a radio resource control setup complete message, indicating that the mlAB node is mobile.
Example 5 may include the apparatus of example 1 and/or any other example herein, wherein the processing circuitry is further configured to detect a neighboring mlAB cell based on a mlAB cell indication in an information element or based on an information element comprising an intra frequency mlAB cell list or an inter frequency mlAB cell list.
Example 6 may include the apparatus of example 1 and/or any other example herein, wherein the processing circuitry is further configured to reserve a unique mlAB distribution unit cell physical cell identifier (PCI) space for respective IAB donor centralized units managed by a same operations, administration, and maintenance (OAM).
Example 7 may include the apparatus of example 6 and/or any other example herein, wherein the processing circuitry is further configured to: decode an indication, received from the OAM, that the mlAB node used a conflicting PCI; and select an updated PCI based on the indication received from the OAM.
Example 8 may include the apparatus of example 1 and/or any other example herein, wherein the processing circuitry is further configured to configure, during a radio resource control reconfiguration, an updated PCI for user equipment served by the mlAB node.
Example 9 may include the apparatus of example 1 and/or any other example herein, wherein the processing circuitry is further configured to handover one or more user equipment to a target IAB donor without using a random access channel (RACH).
Example 10 may include the apparatus of example 1 and/or any other example herein, wherein the selection of the first mlAB donor or the second mlAB donor is based on a velocity of the mlAB node relative to the first mlAB donor or the second mlAB donor, or based on a location of the mlAB node relative to the first mlAB donor or the second mlAB donor.
Example 11 may include a computer-readable storage medium comprising instructions to cause processing circuitry of a mobile integrated access and backhaul (mlAB) node, upon execution of the instructions by the processing circuitry, to: decode a first mlAB support indication received from a first mlAB donor, the first mlAB support indication indicating that the first mlAB donor is configured to serve the mlAB node as a mlAB donor; decode a second mlAB support indication received from a second mlAB donor, the second mlAB support indication indicating that the second mlAB donor is configured to serve the mlAB node as the mlAB donor; and select the first mlAB donor or the second mlAB donor as the mlAB donor based on the first mlAB support indication or the second mlAB support indication.
Example 12 may include the apparatus of example 11 and/or any other example herein, wherein at least one of unified access control or a cell bar are not applied in the selection of the first mlAB donor or the second mlAB donor.
Example 13 may include the apparatus of example 11 and/or any other example herein, wherein the first mlAB support indication is based on a Fl-C connection between a network node centralized unit and a network node distribution unit.
Example 14 may include the apparatus of example 11 and/or any other example herein, wherein execution of the instructions further causes the processing circuitry to encode a mlAB node indication, to be transmitted to the first mlAB donor in a radio resource control setup complete message, indicating that the mlAB node is mobile.
Example 15 may include the apparatus of example 1 1 and/or any other example herein, wherein execution of the instructions further causes the processing circuitry to detect a neighboring mlAB cell based on a mlAB cell indication in an information element or based on an information element comprising an intra frequency mlAB cell list or an inter frequency mlAB cell list.
Example 16 may include the apparatus of example 11 and/or any other example herein, wherein execution of the instructions further causes the processing circuitry to reserve a unique mlAB distribution unit cell physical cell identifier (PCI) space for respective IAB donor centralized units managed by a same operations, administration, and maintenance (OAM).
Example 17 may include the apparatus of example 16 and/or any other example herein, wherein execution of the instructions further causes the processing circuitry to: decode an indication, received from the OAM, that the mlAB node used a conflicting PCI; and select an updated PCI based on the indication received from the OAM.
Example 18 may include the apparatus of example 11 and/or any other example herein, wherein execution of the instructions further causes the processing circuitry to configure, during a radio resource control reconfiguration, an updated PCI for user equipment served by the mlAB node. Example 19 may include the apparatus of example 11 and/or any other example herein, wherein execution of the instructions further causes the processing circuitry to handover one or more user equipment to a target IAB donor without using a random access channel (RACH).
Example 20 may include a method for mobile integrated access and backhaul (mlAB) management, the method comprising: decoding, by processing circuitry of a mlAB node, a first mlAB support indication received from a first mlAB donor, the first mlAB support indication indicating that the first mlAB donor is configured to serve the mlAB node as a mlAB donor; decoding, by the processing circuitry, a second mlAB support indication received from a second mlAB donor, the second mlAB support indication indicating that the second mlAB donor is configured to serve the mlAB node as the mlAB donor; and selecting, by the processing circuitry, the first mlAB donor or the second mlAB donor as the mlAB donor based on the first mlAB support indication or the second mlAB support indication.
Example 21 may include the apparatus of example 20 and/or any other example herein, wherein at least one of unified access control or a cell bar are not applied in the selection of the first mlAB donor or the second mlAB donor.
Example 22 may include the apparatus of example 20 and/or any other example herein, further comprising encoding a mlAB node indication, to be transmitted to the first mlAB donor in a radio resource control setup complete message, indicating that the mlAB node is mobile.
Example 23 may include the apparatus of example 20 and/or any other example herein, wherein the first mlAB support indication is based on a Fl-C connection between a network node centralized unit and a network node distribution unit.
Example 24 may include an apparatus comprising means for: decoding, by a mlAB node, a first mlAB support indication received from a first mlAB donor, the first mlAB support indication indicating that the first mlAB donor is configured to serve the mlAB node as a mlAB donor; decoding, by the processing circuitry, a second mlAB support indication received from a second mlAB donor, the second mlAB support indication indicating that the second mlAB donor is configured to serve the mlAB node as the mlAB donor; and selecting, by the processing circuitry, the first mlAB donor or the second mlAB donor as the mlAB donor based on the first mlAB support indication or the second mlAB support indication.
Example 25 may include one or more non-transitory computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of a method described in or related to any of examples 1-24, or any other method or process described herein
Example 26 may include an apparatus comprising logic, modules, and/or circuitry to perform one or more elements of a method described in or related to any of examples 1-24, or any other method or process described herein.
Example 27 may include a method, technique, or process as described in or related to any of examples 1-24, or portions or parts thereof.
Example 28 may include an apparatus comprising: one or more processors and one or more computer readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1-24, or portions thereof.
Example 29 may include a method of communicating in a wireless network as shown and described herein.
Example 30 may include a system for providing wireless communication as shown and described herein.
Example 31 may include a device for providing wireless communication as shown and described herein.
For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, and/or methods as set forth in the example section below. For example, the baseband circuitry as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below. For another example, circuitry associated with a UE, base station, network element, etc. as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below in the example section.
The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments. The terms “computing device,” “user device,” “communication station,” “station,” “handheld device,” “mobile device,” “wireless device” and “user equipment” (UE) as used herein refers to a wireless communication device such as a cellular telephone, a smartphone, a tablet, a netbook, a wireless terminal, a laptop computer, a femtocell, a high data rate (HDR) subscriber station, an access point, a printer, a point of sale device, an access terminal, or other personal communication system (PCS) device. The device may be either mobile or stationary. As used within this document, the term “communicate” is intended to include transmitting, or receiving, or both transmitting and receiving. This may be particularly useful in claims when describing the organization of data that is being transmitted by one device and received by another, but only the functionality of one of those devices is required to infringe the claim. Similarly, the bidirectional exchange of data between two devices (both devices transmit and receive during the exchange) may be described as “communicating,” when only the functionality of one of those devices is being claimed. The term “communicating” as used herein with respect to a wireless communication signal includes transmitting the wireless communication signal and/or receiving the wireless communication signal. For example, a wireless communication unit, which is capable of communicating a wireless communication signal, may include a wireless transmitter to transmit the wireless communication signal to at least one other wireless communication unit, and/or a wireless communication receiver to receive the wireless communication signal from at least one other wireless communication unit.
As used herein, unless otherwise specified, the use of the ordinal adjectives “first,” “second,” “third,” etc., to describe a common object, merely indicates that different instances of like objects are being referred to and are not intended to imply that the objects so described must be in a given sequence, either temporally, spatially, in ranking, or in any other manner.
The term “access point” (AP) as used herein may be a fixed station. An access point may also be referred to as an access node, a base station, an evolved node B (eNodeB), or some other similar terminology known in the art. An access terminal may also be called a mobile station, user equipment (UE), a wireless communication device, or some other similar terminology known in the art. Embodiments disclosed herein generally pertain to wireless networks. Some embodiments may relate to wireless networks that operate in accordance with one of the IEEE 802.11 standards.
Some embodiments may be used in conjunction with various devices and systems, for example, a personal computer (PC), a desktop computer, a mobile computer, a laptop computer, a notebook computer, a tablet computer, a server computer, a handheld computer, a handheld device, a personal digital assistant (PDA) device, a handheld PDA device, an onboard device, an off-board device, a hybrid device, a vehicular device, a non- vehicular device, a mobile or portable device, a consumer device, a non-mobile or non-portable device, a wireless communication station, a wireless communication device, a wireless access point (AP), a wired or wireless router, a wired or wireless modem, a video device, an audio device, an audio-video (A/V) device, a wired or wireless network, a wireless area network, a wireless video area network (WVAN), a local area network (LAN), a wireless LAN (WLAN), a personal area network (PAN), a wireless PAN (WPAN), and the like.
Some embodiments may be used in conjunction with one way and/or two-way radio communication systems, cellular radio-telephone communication systems, a mobile phone, a cellular telephone, a wireless telephone, a personal communication system (PCS) device, a PDA device which incorporates a wireless communication device, a mobile or portable global positioning system (GPS) device, a device which incorporates a GPS receiver or transceiver or chip, a device which incorporates an RFID element or chip, a multiple input multiple output (MIMO) transceiver or device, a single input multiple output (SIMO) transceiver or device, a multiple input single output (MISO) transceiver or device, a device having one or more internal antennas and/or external antennas, digital video broadcast (DVB) devices or systems, multistandard radio devices or systems, a wired or wireless handheld device, e.g., a smartphone, a wireless application protocol (WAP) device, or the like.
Some embodiments may be used in conjunction with one or more types of wireless communication signals and/or systems following one or more wireless communication protocols, for example, radio frequency (RF), infrared (IR), frequency-division multiplexing (FDM), orthogonal FDM (OFDM), time-division multiplexing (TDM), time-division multiple access (TDMA), extended TDMA (E-TDMA), general packet radio service (GPRS), extended GPRS, code-division multiple access (CDMA), wideband CDMA (WCDMA), CDMA 2000, single-carrier CDMA, multi-carrier CDMA, multi-carrier modulation (MDM), discrete multi- tone (DMT), Bluetooth®, global positioning system (GPS), Wi-Fi, Wi-Max, ZigBee, ultra- wideband (UWB), global system for mobile communications (GSM), 2G, 2.5G, 3G, 3.5G, 4G, fifth generation (5G) mobile networks, 3 GPP, long term evolution (LTE), LTE advanced, enhanced data rates for GSM Evolution (EDGE), or the like. Other embodiments may be used in various other devices, systems, and/or networks.
Various embodiments are described below.
Embodiments according to the disclosure are in particular disclosed in the attached claims directed to a method, a storage medium, a device and a computer program product, wherein any feature mentioned in one claim category, e.g., method, can be claimed in another claim category, e.g., system, as well. The dependencies or references back in the attached claims are chosen for formal reasons only. However, any subject matter resulting from a deliberate reference back to any previous claims (in particular multiple dependencies) can be claimed as well, so that any combination of claims and the features thereof are disclosed and can be claimed regardless of the dependencies chosen in the attached claims. The subject- matter which can be claimed comprises not only the combinations of features as set out in the attached claims but also any other combination of features in the claims, wherein each feature mentioned in the claims can be combined with any other feature or combination of other features in the claims. Furthermore, any of the embodiments and features described or depicted herein can be claimed in a separate claim and/or in any combination with any embodiment or feature described or depicted herein or with any of the features of the attached claims.
The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.
Certain aspects of the disclosure are described above with reference to block and flow diagrams of systems, methods, apparatuses, and/or computer program products according to various implementations. It will be understood that one or more blocks of the block diagrams and flow diagrams, and combinations of blocks in the block diagrams and the flow diagrams, respectively, may be implemented by computer-executable program instructions. Likewise, some blocks of the block diagrams and flow diagrams may not necessarily need to he performed in the order presented, or may not necessarily need to be performed at all, according to some implementations.
These computer-executable program instructions may be loaded onto a special-purpose computer or other particular machine, a processor, or other programmable data processing apparatus to produce a particular machine, such that the instructions that execute on the computer, processor, or other programmable data processing apparatus create means for implementing one or more functions specified in the flow diagram block or blocks. These computer program instructions may also be stored in a computer-readable storage media or memory that may direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable storage media produce an article of manufacture including instruction means that implement one or more functions specified in the flow diagram block or blocks. As an example, certain implementations may provide for a computer program product, comprising a computer- readable storage medium having a computer-readable program code or program instructions implemented therein, said computer-readable program code adapted to be executed to implement one or more functions specified in the flow diagram block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational elements or steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions that execute on the computer or other programmable apparatus provide elements or steps for implementing the functions specified in the flow diagram block orblocks.
Accordingly, blocks of the block diagrams and flow diagrams support combinations of means for performing the specified functions, combinations of elements or steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that each block of the block diagrams and flow diagrams, and combinations of blocks in the block diagrams and flow diagrams, may be implemented by special-purpose, hardware-based computer systems that perform the specified functions, elements or steps, or combinations of special-purpose hardware and computer instructions.
Conditional language, such as, among others, “can,” “could,” “might,” or “may,” unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain implementations could include, while other implementations do not include, certain features, elements, and/or operations. Thus, such conditional language is not generally intended to imply that features, elements, and/or operations are in any way required for one or more implementations or that one or more implementations necessarily include logic for deciding, with or without user input or prompting, whether these features, elements, and/or operations are included or are to be performed in any particular implementation.
Many modifications and other implementations of the disclosure set forth herein will be apparent having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the disclosure is not to be limited to the specific implementations disclosed and that modifications and other implementations are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.
For the purposes of the present document, the following terms and definitions are applicable to the examples and embodiments discussed herein.
The term “circuitry” as used herein refers to, is part of, or includes hardware components such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) and/or memory (shared, dedicated, or group), an Application Specific Integrated Circuit (ASIC), a field-programmable device (FPD) (e.g., a field-programmable gate array (FPGA), a programmable logic device (PLD), a complex PLD (CPLD), a high-capacity PLD (HCPLD), a structured ASIC, or a programmable SoC), digital signal processors (DSPs), etc., that are configured to provide the described functionality. In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. The term “circuitry” may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) with the program code used to carry out the functionality of that program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuitry.
The term “processor circuitry” as used herein refers to, is part of, or includes circuitry capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, or recording, storing, and/or transferring digital data. Processing circuitry may include one or more processing cores to execute instructions and one or more memory structures to store program and data information. The term “processor circuitry” may refer to one or more application processors, one or more baseband processors, a physical central processing unit (CPU), a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, and/or any other device capable of executing or otherwise operating computer-executable instructions, such as program code, software modules, and/or functional processes. Processing circuitry may include more hardware accelerators, which may be microprocessors, programmable processing devices, or the like. The one or more hardware accelerators may include, for example, computer vision (CV) and/or deep learning (DL) accelerators. The terms “application circuitry” and/or “baseband circuitry” may be considered synonymous to, and may be referred to as, “processor circuitry.”
The term “interface circuitry” as used herein refers to, is part of, or includes circuitry that enables the exchange of information between two or more components or devices. The term “interface circuitry” may refer to one or more hardware interfaces, for example, buses, I/O interfaces, peripheral component interfaces, network interface cards, and/or the like.
The term “user equipment” or “UE” as used herein refers to a device with radio communication capabilities and may describe a remote user of network resources in a communications network. The term “user equipment” or “UE” may be considered synonymous to, and may be referred to as, client, mobile, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile device, etc. Furthermore, the term “user equipment” or “UE” may include any type of wireless/wired device or any computing device including a wireless communications interface. The term “network element” as used herein refers to physical or virtualized equipment and/or infrastructure used to provide wired or wireless communication network services. The term “network element” may be considered synonymous to and/or referred to as a networked computer, networking hardware, network equipment, network node, router, switch, hub, bridge, radio network controller, RAN device, RAN node, gateway, server, virtualized VNF, NFVI, and/or the like.
The term “computer system” as used herein refers to any type interconnected electronic devices, computer devices, or components thereof. Additionally, the term “computer system” and/or “system” may refer to various components of a computer that are communicatively coupled with one another. Furthermore, the term “computer system” and/or “system” may refer to multiple computer devices and/or multiple computing systems that are communicatively coupled with one another and configured to share computing and/or networking resources.
The term “appliance,” “computer appliance,” or the like, as used herein refers to a computer device or computer system with program code (e.g., software or firmware) that is specifically designed to provide a specific computing resource. A “virtual appliance” is a virtual machine image to be implemented by a hypervisor-equipped device that virtualizes or emulates a computer appliance or otherwise is dedicated to provide a specific computing resource.
The term “resource” as used herein refers to a physical or virtual device, a physical or virtual component within a computing environment, and/or a physical or virtual component within a particular device, such as computer devices, mechanical devices, memory space, processor/CPU time, processor/CPU usage, processor and accelerator loads, hardware time or usage, electrical power, input/output operations, ports or network sockets, channel/link allocation, throughput, memory usage, storage, network, database and applications, workload units, and/or the like. A “hardware resource” may refer to compute, storage, and/or network resources provided by physical hardware element(s). A “virtualized resource” may refer to compute, storage, and/or network resources provided by virtualization infrastructure to an application, device, system, etc. The term “network resource” or “communication resource” may refer to resources that are accessible by computer devices/systems via a communications network. The term “system resources” may refer to any kind of shared entities to provide services, and may include computing and/or network resources. System resources may be considered as a set of coherent functions, network data objects or services, accessible through a server where such system resources reside on a single host or multiple hosts and are clearly identifiable. The term “channel” as used herein refers to any transmission medium, either tangible or intangible, which is used to communicate data or a data stream. The term “channel” may be synonymous with and/or equivalent to “communications channel,” “data communications channel,” “transmission channel,” “data transmission channel,” “access channel,” “data access channel,” “link,” “data link,” “carrier,” “radiofrequency carrier,” and/or any other like term denoting a pathway or medium through which data is communicated. Additionally, the term “link” as used herein refers to a connection between two devices through a RAT for the purpose of transmitting and receiving information.
The terms “instantiate,” “instantiation,” and the like as used herein refers to the creation of an instance. An “instance” also refers to a concrete occurrence of an object, which may occur, for example, during execution of program code.
The terms “coupled,” “communicatively coupled,” along with derivatives thereof are used herein. The term “coupled” may mean two or more elements are in direct physical or electrical contact with one another, may mean that two or more elements indirectly contact each other but still cooperate or interact with each other, and/or may mean that one or more other elements are coupled or connected between the elements that are said to be coupled with each other. The term “directly coupled” may mean that two or more elements are in direct contact with one another. The term “communicatively coupled” may mean that two or more elements may be in contact with one another by a means of communication including through a wire or other interconnect connection, through a wireless communication channel or link, and/or the like.
The term “information element” refers to a structural element containing one or more fields. The term “field” refers to individual contents of an information element, or a data element that contains content.
Unless used differently herein, terms, definitions, and abbreviations may be consistent with terms, definitions, and abbreviations defined in 3GPP TR 21.905 vl6.0.0 (2019-06) and/or any other 3GPP standard. For the purposes of the present document, the following abbreviations (shown in Table 8) may apply to the examples and embodiments discussed herein. Table 8: Abbreviations
Figure imgf000073_0001
Figure imgf000074_0001
Figure imgf000075_0001
Figure imgf000076_0001
Figure imgf000077_0001
Figure imgf000078_0001
Figure imgf000079_0001
Figure imgf000080_0001
Figure imgf000081_0001

Claims

CLAIMS What is claimed is:
1. An apparatus of a mobile integrated access and backhaul (mlAB) node, the apparatus comprising processing circuitry coupled to storage for storing information associated with mlAB, the processing circuitry configured to: decode a first mlAB support indication received from a first mlAB donor, the first mlAB support indication indicating that the first mlAB donor is configured to serve the mlAB node as a mlAB donor; decode a second mlAB support indication received from a second mlAB donor, the second mlAB support indication indicating that the second mlAB donor is configured to serve the mlAB node as the mlAB donor; and select the first mlAB donor or the second mlAB donor as the mlAB donor based on the first mlAB support indication or the second mlAB support indication.
2. The apparatus of claim 1, wherein at least one of unified access control or a cell bar are not applied in the selection of the first mlAB donor or the second mlAB donor.
3. The apparatus of claim 1, wherein the first mlAB support indication is based on a Fl-C connection between a network node centralized unit and a network node distribution unit.
4. The apparatus of claim 1, wherein the processing circuitry is further configured to encode a mlAB node indication, to be transmitted to the first mlAB donor in a radio resource control setup complete message, indicating that the mlAB node is mobile.
5. The apparatus of claim 1, wherein the processing circuitry is further configured to detect a neighboring mlAB cell based on a mlAB cell indication in an information element or based on an information element comprising an intra frequency mlAB cell list or an inter frequency mlAB cell list.
6. The apparatus of claim 1, wherein the processing circuitry is further configured to reserve a unique mlAB distribution unit cell physical cell identifier (PCI) space for respective IAB donor centralized units managed by a same operations, administration, and maintenance (OAM).
7. The apparatus of claim 6, wherein the processing circuitry is further configured to: decode an indication, received from the OAM, that the mlAB node used a conflicting
PCI; and select an updated PCI based on the indication received from the OAM.
8. The apparatus of claim 1, wherein the processing circuitry is further configured to configure, during a radio resource control reconfiguration, an updated PCI for user equipment served by the mlAB node.
9. The apparatus of claim 1, wherein the processing circuitry is further configured to handover one or more user equipment to a target IAB donor without using a random access channel (RACH).
10. The apparatus of claim 1 , wherein the selection of the first mlAB donor or the second mlAB donor is based on a velocity of the mlAB node relative to the first mlAB donor or the second mlAB donor, or based on a location of the mlAB node relative to the first mlAB donor or the second mlAB donor.
11. A computer-readable storage medium comprising instructions to cause processing circuitry of a mobile integrated access and backhaul (mlAB) node, upon execution of the instructions by the processing circuitry, to: decode a first mlAB support indication received from a first mlAB donor, the first mlAB support indication indicating that the first mlAB donor is configured to serve the mlAB node as a mlAB donor; decode a second mlAB support indication received from a second mlAB donor, the second mlAB support indication indicating that the second mlAB donor is configured to serve the mlAB node as the mlAB donor; and select the first mlAB donor or the second mlAB donor as the mlAB donor based on the first mlAB support indication or the second mlAB support indication.
12. The computer-readable medium of claim 11, wherein at least one of unified access control or a cell bar are not applied in the selection of the first mlAB donor or the second mlAB donor.
13. The computer-readable medium of claim 11, wherein the first mlAB support indication is based on a Fl-C connection between a network node centralized unit and a network node distribution unit.
14. The computer-readable medium of claim 11, wherein execution of the instructions further causes the processing circuitry to encode a mlAB node indication, to be transmitted to the first mlAB donor in a radio resource control setup complete message, indicating that the mlAB node is mobile.
15. The computer-readable medium of claim 11, wherein execution of the instructions further causes the processing circuitry to detect a neighboring mlAB cell based on a ml AB cell indication in an information element or based on an information element comprising an intra frequency mlAB cell list or an inter frequency mlAB cell list.
16. The computer-readable medium of claim 11, wherein execution of the instructions further causes the processing circuitry to reserve a unique mlAB distribution unit cell physical cell identifier (PCI) space for respective IAB donor centralized units managed by a same operations, administration, and maintenance (OAM).
17. The computer-readable medium of claim 16, wherein execution of the instructions further causes the processing circuitry to: decode an indication, received from the OAM, that the mlAB node used a conflicting PCI; and select an updated PCI based on the indication received from the OAM.
18. The computer-readable medium of claim 11, wherein execution of the instructions further causes the processing circuitry to configure, during a radio resource control reconfiguration, an updated PCI for user equipment served by the mlAB node.
19. The computer-readable medium of claim 11, wherein execution of the instructions further causes the processing circuitry to handover one or more user equipment to a target IAB donor without using a random access channel (RACH).
20. A method for mobile integrated access and backhaul (mlAB) management, the method comprising: decoding, by processing circuitry of a mlAB node, a first mlAB support indication received from a first mlAB donor, the first mlAB support indication indicating that the first mlAB donor is configured to serve the mlAB node as a mlAB donor; decoding, by the processing circuitry, a second mlAB support indication received from a second mlAB donor, the second mlAB support indication indicating that the second mlAB donor is configured to serve the mlAB node as the mlAB donor; and selecting, by the processing circuitry, the first mlAB donor or the second mlAB donor as the mlAB donor based on the first mlAB support indication or the second mlAB support indication.
21 . The method of claim 20, wherein at least one of unified access control or a cell bar are not applied in the selection of the first mlAB donor or the second mlAB donor.
22. The method of claim 20, further comprising: encoding a mlAB node indication, to be transmitted to the first mlAB donor in a radio resource control setup complete message, indicating that the mlAB node is mobile.
23. The method of claim 20, wherein the first mlAB support indication is based on a Fl-C connection between a network node centralized unit and a network node distribution unit.
24. A computer-readable storage medium comprising instructions to perform the method of any of claims 20-23.
25. An apparatus comprising means for performing any of the methods of claims 20-23.
PCT/US2023/026958 2022-07-06 2023-07-05 Enhanced mobile integrated access and backhaul for wireless communications WO2024010828A1 (en)

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US202263358819P 2022-07-06 2022-07-06
US202263358818P 2022-07-06 2022-07-06
US202263358792P 2022-07-06 2022-07-06
US63/358,818 2022-07-06
US63/358,792 2022-07-06
US63/358,819 2022-07-06
US202263422362P 2022-11-03 2022-11-03
US63/422,362 2022-11-03

Publications (1)

Publication Number Publication Date
WO2024010828A1 true WO2024010828A1 (en) 2024-01-11

Family

ID=89454015

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2023/026958 WO2024010828A1 (en) 2022-07-06 2023-07-05 Enhanced mobile integrated access and backhaul for wireless communications

Country Status (1)

Country Link
WO (1) WO2024010828A1 (en)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210044958A1 (en) * 2019-08-08 2021-02-11 Qualcomm Incorporated Signaling to support mobile integrated access and backhaul
US20210051558A1 (en) * 2019-08-16 2021-02-18 Qualcomm Incorporated Mobility-aware access control
US20210058854A1 (en) * 2019-08-20 2021-02-25 Qualcomm Incorporated Distributed pci management for mobile iab network
US20220110047A1 (en) * 2018-12-14 2022-04-07 FG Innovation Company Limited Methods and apparatus for cell barring in wireless relay networks

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220110047A1 (en) * 2018-12-14 2022-04-07 FG Innovation Company Limited Methods and apparatus for cell barring in wireless relay networks
US20210044958A1 (en) * 2019-08-08 2021-02-11 Qualcomm Incorporated Signaling to support mobile integrated access and backhaul
US20210051558A1 (en) * 2019-08-16 2021-02-18 Qualcomm Incorporated Mobility-aware access control
US20210058854A1 (en) * 2019-08-20 2021-02-25 Qualcomm Incorporated Distributed pci management for mobile iab network

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
QUALCOMM: "Rel-18 IAB - New use cases to enhance RAN topology", 3GPP TSG RAN REL-18 WORKSHOP, RWS-210020, 7 June 2021 (2021-06-07), XP052025587 *

Similar Documents

Publication Publication Date Title
KR102627395B1 (en) Relocation of the access and mobility management function (AMF) upon network-triggering changes in the network slices supported for the user equipment.
US10772018B2 (en) Signaling design of enhanced handover support for drones in a cellular network
US11871436B2 (en) Apparatus for UE measurement delay and granularity for new radio positioning measurement
US20210368581A1 (en) Ue-to-ue relay service in 5g systems
EP4193794A1 (en) Mechanisms for efficient secondary cell group (scg) activation/de-activation and mechanisms for conditional pscell change or addition
EP4150774A1 (en) Inter-cell beam management for 5g systems
WO2022155514A1 (en) Enhanced detection and recovery for beam failure for multi-transmission points
US20210258065A1 (en) Enhanced beam management for 5g systems
US20230246689A1 (en) Support of simplified multiple input multiple output features for reduced capability user equipment in new radio systems
WO2022235525A1 (en) Enhanced collaboration between user equpiment and network to facilitate machine learning
JP2024513733A (en) Improved preconfiguration, activation, and concurrency of wireless device measurement gaps
WO2022192638A1 (en) Small base station configuration and control in 5g networks
WO2024010828A1 (en) Enhanced mobile integrated access and backhaul for wireless communications
US11751228B2 (en) Methods and apparatuses for uplink spatial relation info switch
US20240154680A1 (en) Beam management for multi-trp operation in wireless networks
WO2023086296A1 (en) Enhanced activation of pre-configured measurement gaps for wireless communications
WO2024030574A1 (en) Enhanced quality of service-level security for wireless communications
WO2024030502A1 (en) Enhanced unknown secondary cell activation for wireless communications
WO2023069758A1 (en) Enhanced medium access control element-based uplink transmission configuration indicator state switching delay with pathloss reference signal
WO2024081537A1 (en) Enhanced configuration of channel sounding signal for bandwidth stitching for wirless device positioning
JP2024513162A (en) Method and apparatus for new wireless broadcast reception
WO2023081211A1 (en) Enhanced physical uplink shared channel repetition for half duplex frequency division duplex wireless operations
WO2024010839A1 (en) Enhanced gap management for packet data convergence protocol and radio link control count for wireless communications
KR20230165763A (en) Enhanced in-user equipment prioritization for uplink transmissions
EP4193676A1 (en) Conditional handover failure reporting in minimization of drive tests (mdt)

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23836067

Country of ref document: EP

Kind code of ref document: A1