WO2021221551A1 - Detecting and resolving 2-step rach configuration conflicts - Google Patents

Detecting and resolving 2-step rach configuration conflicts Download PDF

Info

Publication number
WO2021221551A1
WO2021221551A1 PCT/SE2021/050386 SE2021050386W WO2021221551A1 WO 2021221551 A1 WO2021221551 A1 WO 2021221551A1 SE 2021050386 W SE2021050386 W SE 2021050386W WO 2021221551 A1 WO2021221551 A1 WO 2021221551A1
Authority
WO
WIPO (PCT)
Prior art keywords
conflict
rach
step rach
network node
cell
Prior art date
Application number
PCT/SE2021/050386
Other languages
French (fr)
Inventor
Pablo SOLDATI
Ali PARICHEHREHTEROUJENI
Marco BELLESCHI
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
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 Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Publication of WO2021221551A1 publication Critical patent/WO2021221551A1/en

Links

Classifications

    • 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
    • H04W74/00—Wireless channel access
    • H04W74/08—Non-scheduled access, e.g. ALOHA
    • H04W74/0833—Random access procedures, e.g. with 4-step access
    • H04W74/0841—Random access procedures, e.g. with 4-step access with collision treatment
    • 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

  • the present disclosure relates to random access in a cellular communications system and, more specifically, to 2-step random access in a cellular communications system.
  • the current Fifth Generation (5G), or New Radio (NR), Radio Access Network (RAN) (i.e., the Next Generation RAN (NG-RAN)) architecture is depicted in Figure 1 and described in Third Generation Partnership (3GPP) Technical Specification (TS) 38.401vl5.5.0 as follows:
  • the NG architecture can be further described as follows:
  • the NG-RAN consists of a set of gNBs connected to the 5GC through the NG.
  • An gNB can support FDD mode, TDD mode or dual mode operation.
  • - gNBs can be interconnected through the Xn.
  • a gNB may consist of a gNB-CU and gNB-DUs.
  • a gNB-CU and a gNB-DU is connected via F1 logical interface.
  • One gNB-DU is connected to only one gNB-CU. o NOTE: For resiliency, a gNB-DU may be connected to multiple gNB-CU by appropriate implementation.
  • NG, Xn, and FI are logical interfaces.
  • the NG-RAN is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL).
  • RNL Radio Network Layer
  • TNL Transport Network Layer
  • the NG-RAN architecture i.e. the NG-RAN logical nodes and interfaces between them, is defined as part of the RNL.
  • NG, Xn, FI the related TNL protocol and the functionality are specified.
  • the TNL provides services for user plane transport and signaling transport. If security protection for control plane and user plane data on the TNL of the NG-RAN interfaces has to be supported, Network Domain Security (NDS) / Internet Protocol (IP) (3GPP TS 33.401) is applied.
  • NDS Network Domain Security
  • IP Internet Protocol
  • a NR base station may also be connected to a Long Term Evolution (LTE) evolved Node B (eNB) via the X2 interface.
  • LTE Long Term Evolution
  • eNB evolved Node B
  • Another architectural option is where an LTE eNB connected to the Evolved Packet Core (EPC) network is connected over the X2 interface with a so called en-gNB.
  • EPC Evolved Packet Core
  • the latter is a gNB not connected directly to a core network (CN) and connected via X2 to an eNB for the sole purpose of performing dual connectivity.
  • CN core network
  • the architecture in Figure 1 can be expanded by spitting the Central Unit of the gNB (gNB-CU or CU for short) into two entities, namely, a Control Plane (CP) part (gNB- CU-CP or CU-CP for short) and a User Plane (UP) part (gNB-CU-UP or CU-UP or short), as illustrated in Figure 2.
  • CP Control Plane
  • UP User Plane
  • the CU-CP is expected to handle the Radio Resource Control (RRC) layer
  • the CU-UP will handle the Packet Data Convergence Protocol (PDCP) layer
  • the Distributed Unit (DU) of the gNB gNB-DU or DU for short
  • RLC Radio Link Control
  • MAC Medium Access Control
  • PHY Physical
  • the DU can have separate units that handle the PHY layer parts separately from the RLC layer and MAC layer parts.
  • the El interface is a logical interface. It supports the exchange of signaling information between the endpoints. From a logical standpoint, the El is a point-to- point interface between a CU-CP and a CU-UP. The El interface enables exchange of User Equipment (UE) associated information and non-UE associated information. The El interface is a control interface and is not used for user data forwarding.
  • RACH Random Access Channel
  • RACH optimization in the RACH configuration in cells is a 3GPP Release 9 Self- Organizing Network (SON) feature that is key to optimizing the system performance of a mobile network.
  • SON Self- Organizing Network
  • a poorly configured RACH may result in higher call setup and handover delays due to frequent RACH collisions, or low preamble-detection probability and limited coverage.
  • the amount of uplink resources reserved for RACH also affects the system capacity. Therefore, a network operator should carefully monitor that the RACH parameters are appropriately set, considering factors such as the RACH load, the uplink interference, the traffic patterns, and the population under the cell coverage.
  • the RACH optimization feature facilitates automatic configuration of Physical Random Access Channel (PRACH) parameters (including the PRACH resource configuration, preamble root sequence, and cyclic shift configuration) to avoid preamble collisions with neighboring cells.
  • PRACH Physical Random Access Channel
  • the principle of this automatic configuration is similar to the automatic Physical Cell Identity (PCI) configuration SON feature - the PRACH configuration information is included in the 'X2 Setup' and 'eNB Configuration Update' procedures. Therefore, whenever a new eNB is initialized and learns about its neighbors via the Automatic Neighbor Relations (ANR) function, the eNB can at the same time learn the neighboring PRACH configurations. The eNB can then select its own PRACH configuration to avoid conflicts with the PRACH configurations of the neighboring eNBs.
  • ANR Automatic Neighbor Relations
  • RACH resources configuration and allocation among different cells may be performed at the network planning phase in a centralized fashion (e.g., by Operations and Management (OAM)) or in a distributed fashion (e.g., by RAN node at gNB-CU and/or gNB-DU).
  • the network may use UE assistance information in terms of RACH report for a performed RACH procedure.
  • the task becomes more complicated given that these factors may change dynamically. For example, if the antenna tilt is changed in a cell, it will affect the rates of call arrival and handover in this cell and the surrounding cells, and therefore the RACH load per preamble in all those cells.
  • a change in transmission power settings or handover thresholds may have similar effects.
  • the RACH self optimization feature should automatically make appropriate measurements of the RACH performance and usage in all the affected cells and determine any necessary updates of the RACH parameters.
  • RACH parameters that can then be adjusted are typically the following:
  • the signaling designed for RACH optimization over X2 logical interface as well as RACH UE assistance information reporting mechanism in LTE are considered.
  • a different type of RACH procedure in NR is considered and some details on how the RACH procedure works are provided.
  • a RAN node may trigger an analysis of the information reported by the UE internally or in coordination in other RAN nodes.
  • the eNB PRACH configuration can be exchanged over X2 interface by leveraging ENB X2 Setup Request and eNB Configuration update signaling, where the PRACH Configuration IE, shown in the following table, is contained in the Served Cell Information IE. This IE indicates the PRACH resources used in neighbor cell.
  • PRACH Configuration IE shown in the following table
  • RAN nodes with cells identified as neighboring cells. Neighboring cells would be identified by Radio Resource Management (RRM) measurements provided by UEs.
  • RRM Radio Resource Management
  • a RAN node may request to set up an X2 interface or later update the configurations if changed. This will be accomplished as part of X2 Setup Request or eNB Configuration signaling which includes PRACH configuration as part of Served Cell Information IE.
  • a Uu based signaling has been defined to use a UE assistance information to detect the potential issues, and further enhance the RACH performance by performing finer optimization relying on the provided UE assistance information.
  • the report of RACH information when random access procedure is performed may be requested by the network via the UE Information procedure in RRC (see section 5.6.5 of 3GPP TS 36.331), in the case where a RACH procedure was successful. That procedure is summarized in the following excerpts from the RRC specifications (i.e., from 3GPP TS 36.331):
  • the UE information procedure is used by E-UTRAN to request the UE to report information.
  • E-UTRAN initiates the procedure by sending the UEInformationRequest message. E-UTRAN should initiate this procedure only after successful security activation.
  • the UE Upon receiving the UEInformationRequest message, the UE shall, only after successful security activation:
  • the UEInformationRequest is the command used by E-UTRAN to retrieve information from the UE.
  • SRB1 RLC-SAP AM Logical channel: DCCH Direction: E-UTRAN to UE
  • UEInformationRequest-r9 SEQUENCE ⁇ rrc-Transactionldentifier RRC- Transactionldentifier, criticalExtensions CHOICE ⁇ cl CHOICE ⁇ uelnformationRequest-r9 UEInf ormationRequest-r9-
  • UEInformationRequest-r9-IEs SEQUENCE ⁇ rach-ReportReq-r9 BOOLEAN , rlf-ReportReq-r9 BOOLEAN, nonCriticalExtension UEInf ormationRequest-v930-IEs OPTIONAL
  • the UEInformationResponse message is used by the UE to transfer the information requested by the E-UTRAN.
  • RLC-SAP AM Logical channel: DCCH Direction: UE to E-UTRAN
  • UEInformationResponse-r9-IEs SEQUENCE ⁇ rach-Report-r9 SEQUENCE ⁇ numberOfPreamblesSent-r9 NumberOfPreamblesSent- rll, contentionDetected-r9 BOOLEAN
  • Random access is described in the NR MAC specifications (i.e., 3GPP TS 38.321) and parameters are configured by RRC, e.g. in system information or handover (RRCReconfiguration with reconfigurationWithSync). Random access is triggered in many different scenarios, for example, when the UE is in RRC_IDLE or RRC_INACTIVE and wants to access a cell that the UE is camping on (i.e., transition to RRC_CONNECTED).
  • the RACH configuration is broadcasted in System Information Block 1 (SIB1), as part of the servingCellConfigCommon (with both downlink and uplink configurations), where the RACH configuration is within the uplinkConfigCommon.
  • SIB1 System Information Block 1
  • the exact RACH parameters are within what is called initialUplinkBWP, since this is the part of the uplink frequency the UE shall access and search for RACH resources.
  • RACH-ConfigGeneric :: SEQUENCE ⁇ prach-Configurationlndex INTEGER (0..255), msg1-FDM ENUMERATED ⁇ one, two, four, eight ⁇ , msg1-FrequencyStart INTEGER (0..maxNrofPhysicalResourceBlocks-1), zeroCorrelationZoneConfig INTEGER(0..15), preambleReceivedTargetPower INTEGER (-202..
  • preambleTransMax ENUMERATED ⁇ n3, n4, n5, n6, n7, n8, n10, n20, n50, n100, n200 ⁇
  • powerRampingStep ENUMERATED ⁇ dBO, dB2, dB4, dB6 ⁇
  • ra-ResponseWindow ENUMERATED ⁇ sl1 , sl2, sl4, sl8, sl10, sl20, sl40, sl80 ⁇
  • RACH-ConfigCommon SEQUENCE ⁇ rach-ConfigGeneric totalNumberOfRA-Preambles INTEGER (1..63) OPTIONAL, - Need S ssb-perRACH-OccasionAndCB-PreamblesPerSSB CHOICE ⁇ oneEighth ENUMERATED
  • OPTIONAL - Need M groupBconfigured SEQUENCE ⁇ ra-Msg3SizeGroupA ENUMERATED ⁇ b56, b144, b208, b256, b282, b480, b640, b800, b1000, b72, spare6, spare5,spare4, spare3, spare2, sparel ⁇ , messagePowerOffsetGroupB ENUMERATED ⁇ minusinfinity, dBO, dB5, dB8, dB10, dB12, dB15, dB18 ⁇ , numberOfRA-PreamblesGroupA INTEGER (1..64) ⁇ OPTIONAL, - Need R ra-ContentionResolutionTimer ENUMERATED ⁇ sf8, sf16, sf24, sf32, sf40, sf48, sf56, sf64 ⁇ , rsrp-ThresholdSSB RSRP-Range OPTIONAL, --
  • Cond L139 restrictedSetConfig ENUMERATED ⁇ unrestrictedSet, restrictedSetT ypeA, restrictedSetT ypeB ⁇ , msg3-transformPrecoder ENUMERATED ⁇ enabled ⁇
  • the RACH report to assist the network to perform RACH optimization contains an indication that collision was detected. With that information, it is clear that, at some point before that RACH procedure that has succeeded, the same UE tried to access the network and happened to have a collision. In NR, a mechanism also exists for contention resolution for contention-based random access.
  • a cell in NR is basically defined by a set of SSBs that may be transmitted in one downlink beam (typical implementation for lower frequencies, e.g. below 6 GHz) as illustrated at the top of Figure 4 or multiple downlink beams (typical implementation for lower frequencies, e.g. below 6 GHz) as illustrated at the bottom of Figure 4.
  • these SSBs carry the same PCI and a Master Information Block (MIB).
  • MIB Master Information Block
  • the SSBs For standalone operation, i.e., to support UEs camping on an NR cell, the SSBs also carry in SIB1 the RACH configuration, which comprises a mapping between the detected SSB covering the UE at a given point in time and the PRACH configuration (e.g., time, frequency, preamble, etc.) to be used.
  • the PRACH configuration e.g., time, frequency, preamble, etc.
  • RACH-ConfigCommon The mapping between RACH resources and SSBs (or CSI-RS) is also provided as part of the RACH configuration (in RACH-ConfigCommon). Two parameters are relevant here, namely:
  • #SSBs-per-PRACH-occasion 1/8, 1/4, 1/2, 1, 2, 8 or 16, which represents the number of SSBs per RACH occasion, and
  • the number of SSBs per RACH occasion is 1 and if the UE is under the coverage of a specific SSB, e.g. SSB index 2, there will be a RACH occasion for that SSB index 2. If the UE moves and is now under the coverage of another specific SSB, e.g. SSB index 5, there will be another RACH occasion for that SSB index 5, i.e. each SSB detected by a given UE would have its own RACH occasion.
  • the network upon detecting a preamble in a particular RACH occasion, the network knows exactly which SSB the UE has selected and, consequently, which downlink beam is covering the UE, so that the network can continue the downlink transmission e.g., send Random Access Response (RAR), etc.
  • That factor 1 is an indication that each SSB has its own RACH resource. That is, a preamble detected in a RACH resource indicates to the network which SSB the UE has selected i.e., which downlink beam the network should use to communicate with the UE, such as the one on which to send the RAR.
  • RAR Random Access Response
  • each SSB typically maps to multiple preambles (different cyclic shifts and Zadoff-Chu roots) within a PRACH occasion such that it is possible to receive preambles from multiple different UEs in the same RACH occasion since they may be under the coverage of the same SSB.
  • the number of SSBs per RACH occasion is 2.
  • a preamble received in that RACH occasion indicates to the network that one of the two beams is being selected by the UE.
  • either the network has means via implementation to distinguish these two beams and/or the network should perform a beam sweeping in the downlink by transmitting the RAR in both beams (e.g., either by transmitting both simultaneously or by transmitting in one, waiting for a response from the UE, and if absent, transmitting in the other).
  • the UE has selected an SSB (based on measurements performed in that cell), transmitted with initial power a selected preamble associated to the PRACH resource mapped to the selected SSB, and has not received a RAR within the RAR time window. According to the specifications, the UE may still perform preamble re-transmission (i.e., maximum number of allowed transmissions not reached).
  • the MAC entity shall:
  • 3> select a random backoff time according to a uniform distribution between 0 and the PREAMBLE BACKOFF; 3> if the criteria (as defined in subclause 5.1.2) to select contention-free Random Access Resources is met during the backoff time:
  • the MAC entity shall: l>if the Random Access procedure was initiated for beam failure recovery (as specified in subclause 5.17); and
  • the beamFailureRecoveryTimer (in subclause 5.17) is either running or not configured; and l>if the contention-free Random Access Resources for beam failure recovery request associated with any of the SSBs and/or CSI-RSs have been explicitly provided by RRC; and l>if at least one of the SSBs with SS-RSRP above rsrp-ThresholdSSB amongst the SSBs in candidateBeamRSList or the CSI-RSs with CSI-RSRP above rsrp-ThresholdCSl-RS amongst the CSI-RSs in candidateBeamRSList is available:
  • the MAC entity shall, for each Random Access Preamble: l>if PREAMBLE TRANSMISSION COUNTER is greater than one; and
  • PREAMBLE RECEIVED TARGET POWER to preambleReceivedTargetPower + DELTA PREAMBLE + (PREAMBLE POWER RAMPING_COUNTER - 1) x PREAMBLE POWER RAMPING_STEP;
  • the RA-RNTI associated with the PRACH occasion in which the Random Access Preamble is transmitted is computed as:
  • RA-RNTI 1 + s_id + 14 x t_id + 14 x 80 x f id + 14 x 80 x 8 x ul_carrier_id
  • s_id is the index of the first OFDM symbol of the PRACH occasion (0 ⁇ s_id ⁇ 14)
  • t_id is the index of the first slot of the PRACH occasion in a system frame (0 ⁇ t_id ⁇ 80)
  • f id is the index of the PRACH occasion in the frequency domain (0 ⁇ f id ⁇ 8)
  • ul carrier id is the UL carrier used for Random Access Preamble transmission (0 for NUL carrier, and 1 for SUL carrier).
  • the MAC entity shall: l>if the contention-free Random Access Preamble for beam failure recovery request was transmitted by the MAC entity:
  • Random Access Response contains a MAC subPDU with Random Access Preamble identifier corresponding to the transmitted PREAMBLE INDEX (see subclause 5.1.3):
  • Random Access Response includes a MAC subPDU with RAPID only:
  • the MAC entity may stop ra-Response Window (and hence monitoring for Random Access Response(s)) after successful reception of a Random Access Response containing Random Access Preamble identifiers that matches the transmitted PREAMBLE INDEX. HARQ operation is not applicable to the Random Access Response reception.
  • the UE may be configured to perform CFRA, e.g. during handovers. That configuration goes in the reconfigurationWithSync of IE ReconfigurationWithSync (which goes in the CellGroupConfig IE, transmitted in the RRCReconfiguration message), as shown below:
  • RACH-ConfigDedicated :: SEQUENCE ⁇ cfra CFRA OPTIONAL, - Need S ra-Prioritization OPTIONAL, -- Need N
  • CFRA :: SEQUENCE ⁇ occasions SEQUENCE ⁇ rach-ConfigGeneric ssb-perRACH-Occasion ENUMERATED ⁇ oneEighth, oneFourth, oneHalf, one, two, four, eight, sixteen ⁇ OPTIONAL - Cond SSB-CFRA
  • csirs SEQUENCE ⁇ csirs-ResourceList SEQUENCE (SIZE(1..maxRA-CSIRS-Resources)) OF CFRA-CSIRS- Resource, rsrp-ThresholdCSI-RS RSRP-Range
  • CFRA-SSB-Resource SEQUENCE ⁇ ssb SSB-lndex, ra-Preamblelndex INTEGER (0..63),
  • CFRA-CSIRS-Resource SEQUENCE ⁇ csi-RS CSI-RS-lndex, ra-OccasionList SEQUENCE (SIZE(1..maxRA-OccasionsPerCSIRS)) OF INTEGER
  • RACH resources may be mapped to beams (e.g., SSBs or CSI-RS resources that may be measured by the UE).
  • CFRA resources are also mapped to beams, and this may be done only for a subset of beams in a given target cell.
  • the UE needs to select a beam for which it has CFRA resources configured in the dedicated configuration.
  • SSBs for example, that may be found in the ssb-ResourceList which is a SEQUENCE (SIZE(l..maxRA-SSB-Resources)) OF CFRA-SSB-Resource.
  • the UE upon selecting a beam with CFRA resource (e.g., a beam from the configured list) and not receiving the RAR, the UE would keep selecting the same resource and ramp the power before retransmitting the preamble.
  • CFRA resource e.g., a beam from the configured list
  • the UE upon selecting a beam with CFRA resource (e.g., a beam from the configured list) and not receiving the RAR, the UE would keep selecting the same resource and ramp the power before retransmitting the preamble.
  • the UE has the option upon every failed attempt to select another beam. Further, that other beam may or may not be in the list of beams for CFRA. In the case the selected beam is not in the list of beams for CFRA, the UE performs CBRA.
  • the MAC entity shall: l>if the Random Access procedure was initiated for beam failure recovery (as specified in subclause 5.17); and
  • the beamFailureRecoveryTimer (in subclause 5.17) is either running or not configured; and l>if the contention-free Random Access Resources for beam failure recovery request associated with any of the SSBs and/or CSI-RSs have been explicitly provided by RRC; and l>if at least one of the SSBs with SS-RSRP above rsrp-ThresholdSSB amongst the SSBs in candidateBeamRSList or the CSI-RSs with CSI-RSRP above rsrp-ThresholdCSl-RS amongst the CSI-RSs in candidateBeamRSList is available:
  • the 2-step RACFI approach may be particularly attractive for delay-sensitive use cases, and also in unlicensed networks.
  • 2- step RACFI is attractive because the 2-step approach, unlike the 4-step approach, implies only 2 Listen Before Talk (LBT) procedures (one at UE side for msgA transmission, and one at the network side for the msgB transmission), thereby making the 2-step much faster especially in case of congested network where the UE/gNB may need to postpone several times the transmission of random access messages due to LBT failures, i.e. channel busy.
  • LBT Listen Before Talk
  • the UE may transmit data, i.e., the payload, as part of msgA, i.e., before getting a proper uplink timing alignment from the network.
  • data transmitted in msgA has not yet been link adapted by the network. This means that the probability of properly decoding the payload at the network side very much depends on how good the uplink synchronization already is at the time of sending msgA, e.g., it may depend on the cell size, and also on how good the link quality is.
  • the UE selects the 2-step RACH resources only if the estimated downlink Reference Signal Received Power (RSRP) is above a certain configurable threshold.
  • RSRP downlink Reference Signal Received Power
  • the UE can select the RACH preamble from two groups of 2-step RACH preambles, depending on the size of the payload to include in msgA.
  • the UE starts the msgB-ResponseWindow timer and starts monitoring PDCCH with the msgB Radio Network Temporary Identifier (RNTI) (msgB-RNTI).
  • RNTI Radio Network Temporary Identifier
  • the UE reattempts msgA transmission and applies power ramping.
  • the network may include a successRAR flag in the msgB to indicate that msgA (preamble+payload) decoding was successful.
  • msgA preamble+payload
  • the UE contention resolution identity included in msgB matches the one included by the UE in msgA, the random access procedure is considered successful, and the UE will use the Cell RNTI (C-RNTI) included in the msgB for successive communications with the network.
  • C-RNTI Cell RNTI
  • the network may also include in the msgB a fallback indicator to indicate to the UE to fallback to 4-step.
  • the fallback procedure may be used, for example, in case the network successfully decodes the preamble, but it is not able to decode the payload in msgA. Therefore, in case the msgB MAC Protocol Data Unit (PDU) with fallbackRAR includes a Random Access Preamble Identifier (RAPID) which matches the preamble index used by the UE in msgA, the UE continues with msg3 transmission using the uplink grant and the Temporary C-RNTI included in msgB. Hence, the UE moves the payload intended to be transmitted in msgA to the msg3 buffer, and it waits for msg4 to resolve the contention.
  • PDU MAC Protocol Data Unit
  • RAPID Random Access Preamble Identifier
  • a switch procedure is also considered in the specification.
  • the UE switches from 2-step RACH to 4-step RACH after attempting the 2-step RACH transmission a certain amount of time with no success.
  • the switch procedure implies that the UE drops the 2-step RACH resources, and restarts from 4-step msgl by selecting a new 4-step RACH resource.
  • a method performed by a first network node comprises receiving a 2-step RACH msgA from at least one wireless communication device in a cell controlled by the first network node and determining that there is a potential or actual 2-step RACH configuration conflict for the cell.
  • the method further comprises performing one or more actions responsive to determining that there is a 2-step RACH configuration conflict for the cell.
  • the first network node is enabled to efficiently detect a potential or actual 2- step RACH configuration conflict for a controlled cell, e.g., without any or with limited amount of assistance from another network node.
  • performing the one or more actions comprises transmitting, to a second network node, a 2-step RACH assistance message.
  • the 2-step RACH assistance message comprises: (a) an indication of the potential or actual 2-step RACH configuration conflict, (b) an indication that the first network node is asking for RACH assistance information, (c) information that informs the second network node of a new or updated RACH configuration for the cell, or (d) any combination of two or more of (a)-(c).
  • the 2-step RACH assistance message comprises an indication of one or more RACH resources for which there is a conflict.
  • the 2-step RACH assistance message comprises a cell identity of the cell for which the first network node detected a potential or actual 2-step RACH configuration conflict.
  • performing the one or more actions comprises determining a new or updated RACH configuration for the cell that resolves the potential or actual 2- step RACH configuration conflict. In one embodiment, performing the one or more actions further comprises configuring the cell with the new or updated RACH configuration.
  • the new or updated RACH configuration is a 2-step RACH resource configuration for the cell that resolves the potential or actual 2-step RACH configuration conflict.
  • the 2-step RACH resource configuration comprises a configuration of a set of RACH resources that is either orthogonal or non ⁇ overlapping with a set of 2-step RACH resources for which the potential or actual 2-step RACH configuration conflict was determined or non-orthogonal or partly overlapping with the set of 2-step RACH resources for which the potential or actual 2-step RACH configuration conflict was determined.
  • the new or updated RACH configuration comprises a new pool of resources for 2-step RACH in the cell that resolves the potential or actual 2-step RACH configuration conflict based on utilization of 2-step RACH resources and 4-step RACH resources within the cell.
  • determining the new or updated RACH configuration for the cell that resolves the potential or actual 2-step RACH configuration conflict comprises swapping RACH resources assigned to different bandwidth parts.
  • determining the new or updated RACH configuration for the cell that resolves the potential or actual 2-step RACH configuration conflict comprises swapping the conflicting RACH resources with RACH resources of another cell controlled by the first network node.
  • performing the one or more actions further comprises: sending, to the second network node, a request for 2-step RACH conflict assistance information and receiving, from the second network node, 2-step RACH conflict assistance information. Further, determining the new or updated RACH configuration for the cell that resolves the potential or actual 2-step RACH configuration conflict comprises determining the new or updated RACH configuration for the cell that resolves the conflict based on the 2-step RACH conflict assistance information.
  • the request for 2-step RACH conflict assistance information comprises: (a) an indication of the potential or actual 2-step RACH configuration 2-step conflict, (b) an identifier for at least the cell for which the first network node determined the potential or actual 2-step RACH configuration conflict, (c) information associated to the determining the potential or actual 2-step RACH configuration, (d) an indication of 2- step RACH resources where the potential or actual 2-step RACH configuration conflict was determined, or (e) any combination of two or more of (a) - (d).
  • the 2-step RACH conflict assistance information comprises: (i) an acknowledgement of the occurrence of an actual or potential 2-step RACH configuration conflict, (ii) an indication of a 2-step RACH resource configuration of a neighboring cell which caused the potential or actual 2-step RACH configuration conflict with the cell, (iii) an indication of recommended resources that the first network node can configure for 2-step RACH in the cell to resolve the potential or actual 2-step RACH configuration conflict, or (iv) any two or more of (i) - (iii).
  • performing the one or more actions further comprises receiving a list of RACH resources from another node, the list of RACH resources being suggested RACH resources to resolve the potential or actual 2-step RACH configuration conflict.
  • Determining the new or updated RACH configuration for the cell that resolves the potential or actual 2-step RACH configuration conflict comprises determining the new or updated RACH configuration for the cell that resolves the potential or actual 2- step RACH configuration conflict based on the received list of RACH resources.
  • performing the one or more actions further comprises sending the 2-step RACH optimization message to the second network node, the 2-step RACH optimization message comprising the new or updated RACH configuration for the cell.
  • performing the one or more actions comprises sending, to the second network node, a request for 2-step RACH conflict assistance information and receiving, from the second network node, 2-step RACH conflict assistance information, where the 2-step RACH conflict assistance information comprises a new or updated RACH configuration for at least the cell for which the potential or actual 2-step RACH configuration conflict was determined.
  • performing the one or more actions further comprise configuring the cell with the new or updated RACH configuration.
  • determining that there is a potential or actual 2-step RACH configuration conflict for the cell comprises determining that the first network node can correctly decode a RACH preamble of the 2-step RACH msgA and determining that the first network node cannot correctly decode a payload of the 2-step RACH msgA.
  • determining that there is a potential or actual 2-step RACH configuration conflict for the cell comprises obtaining statistical information associated with random access events that use a 2-step RACH procedure in which the first network node receives a 2-step RACH msgA from a wireless communication device, can decode a preamble of the msgA, but cannot decode a payload of the msgA and determining that there is a potential or actual 2-step RACH configuration conflict for the cell based on the obtained statistical information and one or more predefined or preconfigured thresholds.
  • the first network node is a Distributed Unit (DU) of a base station having a split Central Unit (CU) / DU architecture
  • the second network node is a CU of the base station.
  • a first network node is adapted to receive a 2-step RACH msgA from at least one wireless communication device in a cell controlled by the first network node and determine that there is a potential or actual 2-step RACH configuration conflict for the cell.
  • the first network node is further adapted to perform one or more actions responsive to determining that there is a 2-step RACH configuration conflict for the cell.
  • a first network node comprises processing circuitry configured to cause the first network node to receive a 2-step RACH msgA from at least one wireless communication device in a cell controlled by the first network node and determine that there is a potential or actual 2-step RACH configuration conflict for the cell.
  • the processing circuitry is further configured to cause the first network node to perform one or more actions responsive to determining that there is a 2-step RACH configuration conflict for the cell.
  • a method performed by a second network node comprises receiving, from a first network node, a request for 2-step RACH conflict assistance information, determining the 2-step RACH conflict assistance information, and transmitting the 2-step RACH conflict assistance information to the first network node.
  • the request comprises: (a) an indication of a 2-step RACH configuration conflict detected by the first network node, (b) an identifier for at least a cell for which the first network node detected the 2-step RACH configuration conflict, (c) information associated to detection of the 2-step RACH conflict, (d) an indication of 2- step RACH resources where the 2-step RACH configuration conflict was detected, or (e) any combination of two or more of (a) - (d).
  • the 2-step RACH conflict assistance information comprises: (i) an acknowledgement of the occurrence of a 2-step RACH configuration conflict, (ii) an indication of a 2-step RACH resource configuration of a neighboring cell which caused the detected 2-step RACH configuration conflict with the cell, (iii) an indication of recommended resources that the first network node can configure for 2-step RACH procedure in the cell to resolve the 2- step-RACH configuration conflict, or (iv) any two or more of (i) - (iii).
  • determining the 2-step RACH conflict assistance information comprises determining a new or updated RACH configuration for at least a cell for which a conflict is detected, the new or updated RACH configuration being a RACH configuration that resolves the conflict, wherein the 2-step RACH conflict assistance information comprises the new or updated RACH configuration that resolves the conflict.
  • the first network node is a DU of a base station having a split CU/DU architecture
  • the second network node is a CU of the base station.
  • a second network node is adapted to receive, from a first network node, a request for 2-step RACH conflict assistance information, determine the 2-step RACH conflict assistance information, and transmit the 2-step RACH conflict assistance information to the first network node.
  • a second network node comprises processing circuitry configured to cause the second network node to receive, from a first network node, a request for 2-step RACH conflict assistance information, determine the 2-step RACH conflict assistance information, and transmit the 2-step RACH conflict assistance information to the first network node.
  • Figure 1 illustrates the current Fifth Generation (5G), or New Radio (NR), Radio Access Network (RAN) (i.e., the Next Generation RAN (NG-RAN)) architecture;
  • 5G Fifth Generation
  • NR New Radio
  • RAN Radio Access Network
  • NG-RAN Next Generation RAN
  • Figure 2 illustrates an expansion of the architecture in Figure 1 in which the Central Unit of the NR base station (gNB) (i.e., the gNB-CU or CU for short) is split into two entities, namely, a Control Plane (CP) part (gNB-CU-CP or CU-CP for short) and a User Plane (UP) part (gNB-CU-UP or CU-UP or short);
  • gNB Central Unit of the NR base station
  • CP Control Plane
  • UP User Plane
  • Figure 3 is a reproduction of Figure 5.6.5.1-1 of Third Generation Partnership Project (3GPP) Technical Specification (TS) 36.331;
  • 3GPP Third Generation Partnership Project
  • TS Technical Specification
  • Figure 4 illustrates example of a cell defined by a set of Synchronization Signal Blocks (SSBs) that may be transmitted in one downlink beam (see top of Figure 4) and an example of a cell defined by a set of SSBs that may be transmitted in multiple downlink beams;
  • SSBs Synchronization Signal Blocks
  • Figure 5 illustrates an example of a one-to-one mapping between SSBs and Physical Random Access Channel (PRACH) occasions
  • Figure 6 illustrates an example in which the number of SSBs per PRACH occasion is 2;
  • Figure 7 illustrates both the 4-step random access procedure and the 2-step random access procedure
  • Figure 8 illustrates one example of a cellular communications system in which embodiments of the present disclosure may be implemented
  • Figure 9 illustrates an example of a gNB having a split CU/DU architecture
  • Figure 10 is a flow chart that illustrates a method executed by a first network node (e.g., a gNB-DU) in accordance with some embodiments of the present disclosure
  • Figure 11 illustrates the operation of a gNB-DU and a gNB-CU in accordance with some embodiments of the present disclosure
  • Figure 12 illustrates an example of how a first network node can detect a 2-step RACFI configuration conflict between neighboring cells in accordance with one embodiment of the present disclosure
  • Figure 13 illustrates the operation of a gNB-DU and a gNB-CU in accordance with some other embodiments of the present disclosure
  • Figure 14 illustrate the operation of a gNB-DU and a gNB-CU in accordance with some other embodiments of the present disclosure
  • Figure 15 is a flow chart that illustrates a method executed by a second network node in accordance with some embodiments of the present disclosure
  • Figure 16 is a flow chart that illustrates a method executed by a second network node in accordance with some other embodiments of the present disclosure.
  • Figures 17, 18, and 19 are schematic diagrams of example embodiments of a network node (e.g., the first network node or the second network node).
  • a network node e.g., the first network node or the second network node.
  • Radio Node As used herein, a "radio node” is either a radio access node or a wireless communication device.
  • Radio Access Node As used herein, a “radio access node” or “radio network node” or “radio access network node” is any node in a Radio Access Network (RAN) of a cellular communications network that operates to wirelessly transmit and/or receive signals.
  • RAN Radio Access Network
  • a radio access node examples include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), a relay node, a network node that implements part of the functionality of a base station (e.g., a network node that implements a gNB Central Unit (gNB-CU) or a network node that implements a gNB Distributed Unit (gNB-DU)) or a network node that implements part of the functionality of some other type of radio access node.
  • a base station e.g., a New Radio (NR) base station (gNB)
  • a "core network node” is any type of node in a core network or any node that implements a core network function.
  • Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Flome Subscriber Server (HSS), or the like.
  • MME Mobility Management Entity
  • P-GW Packet Data Network Gateway
  • SCEF Service Capability Exposure Function
  • HSS Flome Subscriber Server
  • a core network node examples include a node implementing an Access and Mobility Management Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.
  • AMF Access and Mobility Management Function
  • UPF User Plane Function
  • SMF Session Management Function
  • AUSF Authentication Server Function
  • NSSF Network Slice Selection Function
  • NEF Network Exposure Function
  • NRF Network Exposure Function
  • NRF Network Exposure Function
  • PCF Policy Control Function
  • UDM Unified Data Management
  • a "communication device” is any type of device that has access to an access network.
  • Some examples of a communication device include, but are not limited to: mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or Personal Computer (PC).
  • the communication device may be a portable, hand-held, computer-comprised, or vehicle- mounted mobile device, enabled to communicate voice and/or data via a wireless or wireline connection.
  • One type of communication device is a wireless communication device, which may be any type of wireless device that has access to (i.e., is served by) a wireless network (e.g., a cellular network).
  • a wireless communication device include, but are not limited to: a User Equipment device (UE) in a 3GPP network, a Machine Type Communication (MTC) device, and an Internet of Things (IoT) device.
  • UE User Equipment
  • MTC Machine Type Communication
  • IoT Internet of Things
  • Such wireless communication devices may be, or may be integrated into, a mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or PC.
  • the wireless communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless connection.
  • Network Node As used herein, a "network node” is any node that is either part of the RAN or the core network of a cellular communications network/system.
  • the NR Radio Access Technology which is part of the Next Generation Radio Access Network (NG-RAN) system, has a new structure for the configuration of Random Access Channel (RACH) resources and processes as compared to LTE.
  • RACH Random Access Channel
  • NR supports two procedures for random access, a 4-step RACH procedure like in LTE and a 2-step RACH procedure which halves and radically changes the signaling required by the UE to access the radio access network.
  • RACH resources and processes can be configured on a per beam basis.
  • Cell beams are characterized by specific reference signals and communication channels. Typically, beams signals and channels are not always available in time for a given coverage area.
  • the split architecture followed in NR and in other RATs such as the Evolved Universal Terrestrial Radio Access Network (E-UTRAN) (i.e., LTE) implies that information needed to perform RACH optimization, such as RACH configurations of cells within a neighborhood, indications on whether a possible RACH configuration conflict exists, and indication of changes of RACH configuration to solve a RACH configuration conflict need to be exchanged between the gNB Central Unit (gNB- CU) and the gNB Distributed Unit (gNB-DU) (in the specific example of NR) or in general between the Central Unit (CU) and the Distributed Unit (DU) of the specific high layer split architecture for that RAT.
  • E-UTRAN Evolved Universal Terrestrial Radio Access Network
  • the above factors create a problem when a RACH optimization solution needs to be supported because the legacy mechanisms for LTE are not re-adaptable to NR. Hence, new solutions are needed.
  • the conventional solution does not provide a solution to detect and resolve RACH configuration conflict for the 2-step RACH procedure defined for the 3GPP NG-RAN system.
  • Embodiments of a method executed by a first network node for optimizing the configuration of resources for a 2-step RACH procedure for at least a controlled cell are disclosed.
  • the method comprises:
  • a msgA associated to a 2-step RACH procedure from at least one wireless communication device in a cell (e.g., a cell controlled by the first network node, which is referred to herein as a "controlled cell");
  • the 2-step RACH optimization message comprises: (a) an indication of a RACH conflict (e.g., an actual RACH conflict or a potential RACH conflict), (b) an indication that the first network node is asking for RACH assistance information (i.e., a request for RACH assistance information), (c) information that informs the second network node of an updated RACH configuration for the cell, or (d) any combination of two or more of (a)-(c).
  • a RACH conflict e.g., an actual RACH conflict or a potential RACH conflict
  • RACH assistance information i.e., a request for RACH assistance information
  • information that informs the second network node of an updated RACH configuration for the cell i.e., a request for RACH assistance information
  • embodiments disclosed herein include:
  • PCI Physical Cell Identity
  • the first network node can solve the 2-step RACH configuration conflict independently.
  • the first network node can solve the 2-step RACH configuration conflict with assistance information from the second network node (gNB-CU).
  • the first network node indicates a possible 2-step RACH configuration conflict to the second network node, which in return determines a new 2-step RACH configuration for the controlled cell and signals it to the first network node.
  • Embodiments of a method executed by a second network node are also disclosed.
  • the method comprises:
  • a 2-step RACH conflict assistance information request from a first network node (i.e., a gNB-DU);
  • the method executed by a second network node may further comprise:
  • a first network node e.g., a gNB-DU
  • a 2-step RACH optimization message comprising a new/updated 2-step RACH resource configuration for a cell controlled by the first network node
  • a RACH configuration update message to another second network node (i.e., a neighboring gNB-CU) comprising the new/updated 2- step RACH resource configuration.
  • Such message and signals could consist of an existing message and signals in a radio system, such as the 3GPP LTE system or the 3GPP NG- RAN (NR) system, that are enhanced to carry the information disclosed herein.
  • a radio system such as the 3GPP LTE system or the 3GPP NG- RAN (NR) system, that are enhanced to carry the information disclosed herein.
  • Certain embodiments may provide one or more of the following technical advantage(s).
  • the embodiments disclosed herein allow a gNB-DU to efficiently detect a (potential) 2-step RACH configuration conflict for a controlled cell without any (or with limited amount of) assistance from the gNB-CU. Additionally, the method enables the gNB-DU to readily and efficiently optimize the 2-step RACH resource configuration for the controlled cell experiencing a configuration conflict with a neighboring cell, thereby improving the overall system performance when user devices attempt to access the controlled cell using a 2-step random access procedure.
  • the embodiments disclosed herein further enable a gNB-DU to efficiently detect and report a (potential) 2-step RACH configuration conflict for a controlled cell to the respective gNB-CU.
  • this enables the gNB-CU to efficiently verify whether the reported 2-step RACH configuration conflict exists based on additional information about the allocation of 2-step RACH resources that is available only to the gNB-CU.
  • the occurrence of a 2-step RACH configuration conflict between a cell controlled by the gNB-DU and a neighboring cell can be efficiently detected and resolved with minimal information exchange between the gNB-DU and the gNB-CU, thereby improving the system performance.
  • FIG. 8 illustrates one example of a cellular communications system 800 in which embodiments of the present disclosure may be implemented.
  • the cellular communications system 800 is a 5G System (5GS) including a NG-RAN or an Evolved Packet System (EPS) including an Evolved Universal Terrestrial Radio Access Network (E-UTRAN).
  • the RAN includes base stations 802-1 and 802-2, which in the NG-RAN include gNBs and, optionally, ng-eNBs (i.e., LTE RAN nodes connected to the 5GC) and in the LTE RAN (i.e., E-UTRAN) are referred to as eNBs, controlling corresponding (macro) cells 804-1 and 804-2.
  • 5GS 5G System
  • EPS Evolved Packet System
  • E-UTRAN Evolved Universal Terrestrial Radio Access Network
  • the RAN includes base stations 802-1 and 802-2, which in the NG-RAN include gNBs and, optionally, ng-e
  • the base stations 802-1 and 802-2 are generally referred to herein collectively as base stations 802 and individually as base station 802.
  • the (macro) cells 804-1 and 804-2 are generally referred to herein collectively as (macro) cells 804 and individually as (macro) cell 804.
  • the RAN may also include a number of low power nodes 806-1 through 806-4 controlling corresponding small cells 808-1 through 808-4.
  • the low power nodes 806-1 through 806-4 can be small base stations (such as pico or femto base stations) or Remote Radio Heads (RRHs), or the like.
  • RRHs Remote Radio Heads
  • one or more of the small cells 808-1 through 808-4 may alternatively be provided by the base stations 802.
  • the low power nodes 806-1 through 806-4 are generally referred to herein collectively as low power nodes 806 and individually as low power node 806.
  • the small cells 808-1 through 808-4 are generally referred to herein collectively as small cells 808 and individually as small cell 808.
  • the cellular communications system 800 also includes a core network 810, which in the 5GS is referred to as the 5G Core (5GC).
  • the base stations 802 (and optionally the low power nodes 806) are connected to the core network 810.
  • the base stations 802 and the low power nodes 806 provide service to wireless communication devices 812-1 through 812-5 in the corresponding cells 804 and 808.
  • the wireless communication devices 812-1 through 812-5 are generally referred to herein collectively as wireless communication devices 812 and individually as wireless communication device 812. In the following description, the wireless communication devices 812 are oftentimes UEs, but the present disclosure is not limited thereto.
  • the base stations 802 have a split architecture where each base station 802 includes a CU (which may further be split into a CU-CP and a CU-UP) and one or more DUs.
  • the base station 802 is a gNB having a split architecture as illustrated in Figure 9.
  • the base station 802 is also referred to herein as a gNB 802.
  • the gNB 802 includes a gNB-CU 900 and one or more gNB-DUs 902.
  • the gNB 802 has two gNB-DUs 902, which are denoted as gNB-DUs 902-1 and 902-2.
  • a 2-step RACH configuration conflict can occur either between two cells controlled by different gNB-DUs 902 connected to the same gNB-CU 900 or between two cells controlled by different gNB-DUs 902 connected to different gNB-CUs 900.
  • the example case of an NR RAT is considered.
  • the architecture taken into consideration is a split architecture where the gNB- CU 900 hosts high layers such as the Radio Resource Control (RRC) layer and where the gNB-DU(s) 902 hosts lower layers such as the physical (PHY) layer, the Medium Access Control (MAC) layer, and the Radio Link Control (RLC).
  • RRC Radio Resource Control
  • PHY physical
  • MAC Medium Access Control
  • RLC Radio Link Control
  • the methods described herein can be applied to any RAT that follows the same split architecture. For example, they can be applied to the E-UTRAN split architecture or to the E-UTRA split architecture.
  • Embodiments of a method executed by a first network node for optimizing the configuration of resources for a 2-step RACH procedure for at least a controlled cell are disclosed herein.
  • the method executed by the first network node comprises:
  • Step 1000 The first network node receives a 2-step RACH msgA from at least one wireless communication device 812 for a controlled cell.
  • Step 1002 The first network node detects (or determines) that there is a 2- step RACH configuration conflict (e.g., a potential conflict or an actual conflict) for the controlled cell (with a neighbor cell) based on the received msgA from the at least one wireless communication device 812 in the controlled cell.
  • a 2- step RACH configuration conflict e.g., a potential conflict or an actual conflict
  • Step 1004 The first network node determines a new or updated 2-step RACH resource configuration for the controlled cell based on the detection of the 2-step RACH configuration conflict, where the new or updated 2-step RACH resource configuration resolves the 2-step RACH configuration conflict.
  • Step 1006 (Optional): The first network node configures the controlled cell with the new/updated 2-step RACH resource configuration.
  • Step 1008 The first network node transmits to a second network node (e.g., the gNB-CU 900) a 2-step RACH assistance message.
  • the 2-step RACH assistance message is also referred to herein as a 2-step RACH optimization message.
  • the 2-step RACH assistance message comprises: (a) an indication of a RACH conflict (e.g., an actual RACH conflict or a potential RACH conflict), (b) an indication that the first network node is asking for RACH assistance information (i.e., a request for RACH assistance information), (c) information that informs the second network node of the new or updated RACH configuration for the cell, or (d) any combination of two or more of (a)-(c).
  • a RACH conflict e.g., an actual RACH conflict or a potential RACH conflict
  • RACH assistance information i.e., a request for RACH assistance information
  • information that informs the second network node of the new or updated RACH configuration for the cell i.e., a request for RACH assistance information
  • the 2-step RACH assistance message comprises the new/updated 2-step RACH resource configuration (including time/frequency and preamble resources as well as PUSCH resources used for payload part of msgA) for the controlled cell from step 1004 or an indication indicating the problematic RACH resources currently configured and associated cell identity.
  • FIG 11 shows an illustration of the method performed by the first network node in accordance with one embodiment of the present disclosure.
  • the first network node is the gNB-DU 902.
  • steps 1100 through 1108 of Figure 11 correspond to steps 1000-1008 of Figure 10.
  • the gNB-DU 902 receives a 2-step RACH msgA from at least one wireless communication device 812 for a controlled cell (step 1100) and detects a 2-step RACH configuration conflict (step 1102).
  • the gNB-DU 900 determines a new or updated 2-step RACH configuration for the cell that resolves the conflict (step 1104) and changes the 2-step RACH configuration in the cell accordingly (step 1106).
  • the gNB-DU 900 sends a 2-step RACH optimization message (also referred to herein as a 2-step RACH assistance message) to the gNB-CU 900 (step 1108).
  • a 2-step RACH optimization message also referred to herein as a 2-step RACH assistance message
  • Embodiments related to the detection of a 2-step RACH configuration conflict are disclosed below in the Section entitled “Detection of 2-step RACH Configuration Conflict at gNB-DU”.
  • Embodiments are also disclosed in the Section entitled “gNB-DU Embodiment with RACH Conflict Resolution at gNB-DU” that are related to the determination of a new pool of 2-step RACH resources resolving the 2-step RACH configuration conflict, which can be done either independently by the first network node (see Section entitled “Resolution of RACH Conflict at gNB-DU without Assistance from gNB-CU") or with receiving assistance information from a second network node (e.g., a gNB-CU, see Section entitled “Resolution of RACH Conflict at gNB-DU with Assistance from gNB-CU”).
  • the first network node detects a potential 2-step RACFI configuration conflict between the controlled cell and a neighboring cell based on statics associated to the reception of one or more 2-step RACFI msgAs from at least one wireless communication device 812.
  • the first network node upon receiving a 2-step RACFI msgA from at least one wireless communication device 812, may detect a 2-step RACFI configuration conflict by executing a method comprising the steps of:
  • This sequence of events may occur since, in case of a 2-step RACFI configuration conflict, the wireless communication device 812may have transmitted the 2-step RACFI msgA preamble using preamble resources shared by neighboring cells. Therefore, both cells sharing the conflicting RACFI resources would be able to decode the msgA preamble.
  • the msgA payload is scrambled with the physical cell identity (PCI) that the wireless communication device 812has decided to access. Thereby, if the wireless communication device 812has scrambled the msgA payload with a PCI different from the PCI of the cell controlled by the first network node, the first network node will not be able to decode the msgA payload.
  • PCI physical cell identity
  • Figure 12 illustrates an example of 2-step RACFI configuration conflict detection, wherein the first network node is represented by a gNB-DU 902.
  • Figure 12 illustrates an example of how the first network node (i.e., gNB-DU 902 in this example) can detect a 2-step RACFI configuration conflict between neighboring cells.
  • a wireless communication device 812 is trying to access a cell controlled by gNB-DU-2 (e.g., gNB-DU 902-2) and scrambles the msgA payload with the PCI of the associated cell (i.e., PCI-2).
  • the msgA preamble is common to both cells, the msgA is received also by the gNB-DU-1 (e.g., gNB-DU 902-1) (step 1200) which can decode the preamble (step 1202) but not the msgA payload (step 1204). Therefore, gNB-DU-1 can infer a possible 2-step RACH configuration conflict for its controlled cell (identified by PCI-1).
  • the gNB-DU-1 e.g., gNB-DU 902-1
  • the first network node may thereby collect statistical information associated to random access events using a 2-step RACH procedure wherein the first network node can receive a 2-step RACH msgA from a wireless communication device 812, can decode the msgA preamble, but cannot decode the msgA payload. For instance, the first network node may collect statistics of the occurrence of such events over a time (e.g., over one or more predefined time windows, which may be repeated periodically), such as maximum and/or minimum number of occurrences, the average and/or standard deviation and/or variance of the number of occurrences indicating a potential 2-step RACH configuration conflict.
  • the first network node determines a 2-step RACH configuration conflict for a controlled cell if one or more statistical information associated to the 2-step RACH procedure for said cell exceed a threshold value. For instance, the first network node determines a 2-step RACH conflict if one or more of the following cases occurs:
  • the first network node upon detecting a potential 2-step RACH resource configuration conflict for a controlled cell, the first network node (e.g., a gNB-DU 902) is enabled to determine a new pool of resources for 2-step RACH procedure to resolve the detected conflict for the controlled cell.
  • the first network node determines a 2-step RACH resource configuration for the controlled cell to resolve the conflict comprising a set of RACH resources that is:
  • the first network node determines a new pool of resources for 2-step RACH procedure of the controlled cell to resolve the detected conflict based on the utilization of 2-step RACH resources and 4-step RACH resources within the controlled cell. For instance, the first network node may determine a new set of resources for 2-step RACH based on the number of users (i.e., wireless communication devices 812) using 2-step RACH and 4-step RACH.
  • the first network node may swap the RACH resources assigned to different bandwidth parts (BWPs).
  • BWPs bandwidth parts
  • the first network node may swap the RACH resources of initial BWP and the RACH resources of the BWP used for eMBB purpose.
  • the first network node may swap the conflicting RACH resources with RACH resources of another controlled cell operating in another frequency.
  • the first network node e.g., the gNB-DU 902
  • the second network node e.g., the gNB-CU 900
  • the method executed by the first network node may further comprise:
  • Step 1300 The first network node transmits a 2-step RACH conflict assistance information request to the second network node; and • Step 1302: The first network node receives a 2-step RACH conflict assistance information response from the second network node;
  • determining the new/updated 2-step RACH resource configuration for the controlled cell in step 1104 is further based on based on the 2-step RACH conflict resolution assistance information response.
  • the 2-step RACH conflict assistance information request may comprise information associated to the detection of 2-step RACH configuration conflict for a controlled cell, such as, one or more information elements in the group of:
  • an identifier for at least a controlled cell for which the first network node detected a 2-step RACH configuration conflict such as a physical cell identity, or an RNTI, etc.
  • information associated to the 2-step RACH conflict detection such as o statistical information associated to successful detection of 2-step RACH msgA preambles transmitted by user devices within the coverage area of the controlled cell; o statistical information associated to the failed decoding of 2-step RACH msgA payload transmitted by user devices within the coverage area of the controlled cell; o statistical information on access delay probability for the given RACH resources; o an indication of the 2-step RACH resources where a conflict was detected, such as
  • the 2-step RACH conflict assistance information response may comprise one or more information elements in the group of:
  • the recommended resources may include a list of time/frequency and preamble resources (e.g., root sequence index) as well as PUSCH resources that can be configured for payload part of msgA.
  • the first network node may receive a list of RACH resources from operation and management (OAM) system and may use the suggested list of 2-step RACH resources from OAM to resolve the RACH configuration conflict.
  • OAM operation and management
  • the first network node Upon resolving 2-step RACH configuration conflict (i.e., selecting and configuration of new RACH resources), the first network node sends new configured 2- step RACH resources to the second network node indicating the resolution of 2-step RACH configuration conflict.
  • the 2-step RACH conflict assistance information request may further comprise a request for the second network node (i.e., the gNB-CU 900) to resolve the 2-step RACH configuration conflict indicated by the first network node (i.e., the gNB-DU 902) (step 1400).
  • the second network node then resolves the 2-step RACH configuration conflict for the cell (step 1402).
  • the 2-step RACH conflict assistance information response message received by the first network node may comprise a new or an updated 2-step RACH configuration for the at least one cell controlled by the first network node for which the first network node has detected a 2-step RACH configuration conflict (step 1404). Therefore, in step 1106, the first network node may configure the controlled cell with the new or updated 2-step RACH configuration indicted by the second network node. Additionally, the first network node may indicate/acknowledge to the second network that the controlled cell has been reconfigured with the indicated 2-step RACH configuration, for instance using the 2-step RACH optimization message in step 1108.
  • Embodiments of a method executed by a second network node are also disclosed. As illustrated in Figure 15, in one embodiment, the method executed by the second node comprises:
  • Step 1500 The second network node receives a 2-step RACH conflict assistance information request from a first network node (i.e., a gNB-DU 902).
  • a first network node i.e., a gNB-DU 902.
  • Step 1502 The second network node determines assistance information associated to the 2-step RACH procedure for at least one radio cell controlled by the first network node based on the 2-step RACH conflict assistance information request.
  • this assistance information includes information that is used by the first network node to resolve the 2-step RACH configuration conflict (see, e.g., the discussion related to Figure 13 above).
  • the second network node resolves the 2-step RACH configuration conflict, and the assistance information includes, e.g., an updated 2-step RACH configuration for the cell (see, e.g., the discussion related to Figure 14 above).
  • the resolving of the conflict may include exchanging information with neighbor cells or just leveraging information already available at the second network node.
  • Step 1504 The second network node transmits a 2-step RACH conflict assistance information response to the first network node comprising the 2- step RACH assistance information.
  • the second network node upon receiving the 2-step RACH conflict assistance information request from the first network node indicating a potential 2-step RACH configuration conflict for a radio cell controlled by the first network node, the second network node can verify whether a 2-step RACH configuration conflict occurs/exists with neighboring cells controlled by another second network node (e.g., neighboring cells controlled by another gNB). This can be done by exchanging RACH configuration information between among one or more second nodes (i.e., among gNBs).
  • the second network node may further determine or more types of 2-step RACH assistance information in the group of:
  • a recommended/preferred set of RACH resources that the first network node can use to resolve the detected 2-step RACH conflict. For instance, a set of RACH preambles, a set of time frequency resources, etc.;
  • a method executed by a second network node may comprise:
  • Step 1600 The second network node receives from a first network node (e.g., a gNB-DU) a 2-step RACH optimization message comprising a new/updated 2-step RACH resource configuration for a radio cell controlled by the first network node (see, e.g., step 1108); and • Step 1602: The second network node transmits a RACH configuration update message to another second network node (i.e., a neighboring gNB-CU) comprising the new/updated 2-step RACH resource configuration.
  • a first network node e.g., a gNB-DU
  • 2-step RACH optimization message comprising a new/updated 2-step RACH resource configuration for a radio cell controlled by the first network node (see, e.g., step 1108)
  • Step 1602 The second network node transmits a RACH configuration update message to another second network node (i.e., a neighboring gNB-CU) comprising the new/updated 2-step RACH resource
  • the gNB-CU 900 upon receiving a 2-step RACH configuration update from a gNB-DU 902, the gNB-CU 900 could forward the updated configuration to a neighboring gNB-CU which may have had a controlled radio cells using RACH resources overlapping (hence conflicting) with the radio cell owned by the gNB-DU.
  • FIG 17 is a schematic block diagram of a radio access node 1700 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes.
  • the radio access node 1700 may be, for example, a base station 802 or 806 or a network node that implements all or part of the functionality of the base station 802 or gNB described herein (e.g., a network node that implements a DU such as, e.g., a gNB-DU 902 or a CU such as, e.g., a gNB-CU 900, as described herein).
  • a network node that implements a DU such as, e.g., a gNB-DU 902
  • a CU such as, e.g., a gNB-CU 900, as described herein.
  • the radio access node 1700 includes a control system 1702 that includes one or more processors 1704 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory 1706, and a network interface 1708.
  • the one or more processors 1704 are also referred to herein as processing circuitry.
  • the radio access node 1700 may include one or more radio units 1710 that each includes one or more transmitters 1712 and one or more receivers 1714 coupled to one or more antennas 1716.
  • the radio access node 1700 is a network node that implements a DU such as, e.g., a gNB-DU 902.
  • the radio units 1710 may be referred to or be part of radio interface circuitry.
  • the radio unit(s) 1710 is external to the control system 1702 and connected to the control system 1702 via, e.g., a wired connection (e.g., an optical cable).
  • the radio unit(s) 1710 and potentially the antenna(s) 1716 are integrated together with the control system 1702.
  • the one or more processors 1704 operate to provide one or more functions of a radio access node 1700 as described herein (e.g., one or more functions of a DU such as, e.g., a gNB-DU 902 or one or more functions of a CU such as, e.g., a gNB-CU 900, as described herein).
  • the function(s) are implemented in software that is stored, e.g., in the memory 1706 and executed by the one or more processors 1704.
  • Figure 18 is a schematic block diagram that illustrates a virtualized embodiment of the radio access node 1700 according to some embodiments of the present disclosure. This discussion is equally applicable to other types of network nodes. Further, other types of network nodes may have similar virtualized architectures. Again, optional features are represented by dashed boxes.
  • a "virtualized" radio access node is an implementation of the radio access node 1700 in which at least a portion of the functionality of the radio access node 1700 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)).
  • the radio access node 1700 may include the control system 1702 and/or the one or more radio units 1710, as described above.
  • the control system 1702 may be connected to the radio unit(s) 1710 via, for example, an optical cable or the like.
  • the radio access node 1700 includes one or more processing nodes 1800 coupled to or included as part of a network(s) 1802.
  • Each processing node 1800 includes one or more processors 1804 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 1806, and a network interface 1808.
  • processors 1804 e.g., CPUs, ASICs, FPGAs, and/or the like
  • functions 1810 of the radio access node 1700 described herein are implemented at the one or more processing nodes 1800 or distributed across the one or more processing nodes 1800 and the control system 1702 and/or the radio unit(s) 1710 in any desired manner.
  • some or all of the functions 1810 of the radio access node 1700 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 1800.
  • additional signaling or communication between the processing node(s) 1800 and the control system 1702 is used in order to carry out at least some of the desired functions 1810.
  • the control system 1702 may not be included, in which case the radio unit(s) 1710 communicate directly with the processing node(s) 1800 via an appropriate network interface(s).
  • a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of radio access node 1700 or a node (e.g., a processing node 1800) implementing one or more of the functions 1810 of the radio access node 1700 in a virtual environment according to any of the embodiments described herein is provided.
  • a carrier comprising the aforementioned computer program product.
  • the carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).
  • FIG 19 is a schematic block diagram of the radio access node 1700 according to some other embodiments of the present disclosure.
  • the radio access node 1700 includes one or more modules 1900, each of which is implemented in software.
  • the module(s) 1900 provide the functionality of the radio access node 1700 described herein (e.g., one or more functions of a DU such as, e.g., a gNB-DU 902 or one or more functions of a CU such as, e.g., a gNB-CU 900, as described herein).
  • This discussion is equally applicable to the processing node 1800 of Figure 18 where the modules 1900 may be implemented at one of the processing nodes 1800 or distributed across multiple processing nodes 1800 and/or distributed across the processing node(s) 1800 and the control system 1702.
  • any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses.
  • Each virtual apparatus may comprise a number of these functional units.
  • These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processor (DSPs), special-purpose digital logic, and the like.
  • the processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc.
  • Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein.
  • the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.

Landscapes

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

Abstract

Systems and methods for detecting and resolving 2-step Random Access Channel (RACH) configuration conflicts are disclosed. In one embodiment, a method performed by a first network node comprises receiving a 2-step RACH msgA from at least one wireless communication device in a cell controlled by the first network node and determining that there is a potential or actual 2-step RACH configuration conflict for the cell. The method further comprises performing one or more actions responsive to determining that there is a 2-step RACH configuration conflict for the cell. In this manner, the first network node is enabled to efficiently detect a potential or actual 2-step RACH configuration conflict for a controlled cell, e.g., without any or with limited amount of assistance from another network node.

Description

DETECTING AND RESOL VING 2-STEP RACH CONFIGURA TION CONFLICTS
Related Applications
This application claims the benefit of provisional patent application serial number 63/017,979, filed April 30, 2020, the disclosure of which is hereby incorporated herein by reference in its entirety.
Technical Field
The present disclosure relates to random access in a cellular communications system and, more specifically, to 2-step random access in a cellular communications system.
Background
1 New Radio (NR) Architecture
The current Fifth Generation (5G), or New Radio (NR), Radio Access Network (RAN) (i.e., the Next Generation RAN (NG-RAN)) architecture is depicted in Figure 1 and described in Third Generation Partnership (3GPP) Technical Specification (TS) 38.401vl5.5.0 as follows:
**********START EXCERPT FROM 3GPP TS 38.401**********
The NG architecture can be further described as follows:
- The NG-RAN consists of a set of gNBs connected to the 5GC through the NG.
- An gNB can support FDD mode, TDD mode or dual mode operation.
- gNBs can be interconnected through the Xn.
- A gNB may consist of a gNB-CU and gNB-DUs. A gNB-CU and a gNB-DU is connected via F1 logical interface.
- One gNB-DU is connected to only one gNB-CU. o NOTE: For resiliency, a gNB-DU may be connected to multiple gNB-CU by appropriate implementation.
**********END EXCERPT FROM 3GPP TS 38.401**********
NG, Xn, and FI are logical interfaces. The NG-RAN is layered into a Radio Network Layer (RNL) and a Transport Network Layer (TNL). The NG-RAN architecture, i.e. the NG-RAN logical nodes and interfaces between them, is defined as part of the RNL. For each NG-RAN interface (NG, Xn, FI), the related TNL protocol and the functionality are specified. The TNL provides services for user plane transport and signaling transport. If security protection for control plane and user plane data on the TNL of the NG-RAN interfaces has to be supported, Network Domain Security (NDS) / Internet Protocol (IP) (3GPP TS 33.401) is applied.
A NR base station (gNB) may also be connected to a Long Term Evolution (LTE) evolved Node B (eNB) via the X2 interface. Another architectural option is where an LTE eNB connected to the Evolved Packet Core (EPC) network is connected over the X2 interface with a so called en-gNB. The latter is a gNB not connected directly to a core network (CN) and connected via X2 to an eNB for the sole purpose of performing dual connectivity.
The architecture in Figure 1 can be expanded by spitting the Central Unit of the gNB (gNB-CU or CU for short) into two entities, namely, a Control Plane (CP) part (gNB- CU-CP or CU-CP for short) and a User Plane (UP) part (gNB-CU-UP or CU-UP or short), as illustrated in Figure 2. So, in the split architecture option, the RAN protocol stack functionality is separated in different parts. The CU-CP is expected to handle the Radio Resource Control (RRC) layer, the CU-UP will handle the Packet Data Convergence Protocol (PDCP) layer, and the Distributed Unit (DU) of the gNB (gNB-DU or DU for short) will handle the Radio Link Control (RLC) layer, the Medium Access Control (MAC) layer, and the Physical (PHY) layer of the protocol stack. In some further split, the DU can have separate units that handle the PHY layer parts separately from the RLC layer and MAC layer parts.
As different units handle different protocol stack functionalities, there will be a need for inter-node communication between the DU, the CU-UP, and the CU-CP. This is achieved via the Fl-C interface related to control plane signaling, via the Fl-U interface related to user plane signaling for communication between CU and DU, and via the El interface for communication between CU-UP and CU-CP.
The El interface is a logical interface. It supports the exchange of signaling information between the endpoints. From a logical standpoint, the El is a point-to- point interface between a CU-CP and a CU-UP. The El interface enables exchange of User Equipment (UE) associated information and non-UE associated information. The El interface is a control interface and is not used for user data forwarding. 2 4-Step Random Access Channel (RACH) in LTE and NR 2.1 RACH Optimization Purpose
Optimization of the RACH configuration in cells is a 3GPP Release 9 Self- Organizing Network (SON) feature that is key to optimizing the system performance of a mobile network. A poorly configured RACH may result in higher call setup and handover delays due to frequent RACH collisions, or low preamble-detection probability and limited coverage. The amount of uplink resources reserved for RACH also affects the system capacity. Therefore, a network operator should carefully monitor that the RACH parameters are appropriately set, considering factors such as the RACH load, the uplink interference, the traffic patterns, and the population under the cell coverage.
The RACH optimization feature facilitates automatic configuration of Physical Random Access Channel (PRACH) parameters (including the PRACH resource configuration, preamble root sequence, and cyclic shift configuration) to avoid preamble collisions with neighboring cells. The principle of this automatic configuration is similar to the automatic Physical Cell Identity (PCI) configuration SON feature - the PRACH configuration information is included in the 'X2 Setup' and 'eNB Configuration Update' procedures. Therefore, whenever a new eNB is initialized and learns about its neighbors via the Automatic Neighbor Relations (ANR) function, the eNB can at the same time learn the neighboring PRACH configurations. The eNB can then select its own PRACH configuration to avoid conflicts with the PRACH configurations of the neighboring eNBs.
Whenever a conflict is identified, one of the cells should change its configuration, but the algorithm for selecting which cell should change and in what manner is not specified. The network operator can also combine PRACH self-optimization with manual configuration if necessary, but this is typically more prone to errors and more time consuming than automatic RACH optimization. Reporting of RACH information and failures.
RACH resources configuration and allocation among different cells may be performed at the network planning phase in a centralized fashion (e.g., by Operations and Management (OAM)) or in a distributed fashion (e.g., by RAN node at gNB-CU and/or gNB-DU). The network may use UE assistance information in terms of RACH report for a performed RACH procedure. However, the task becomes more complicated given that these factors may change dynamically. For example, if the antenna tilt is changed in a cell, it will affect the rates of call arrival and handover in this cell and the surrounding cells, and therefore the RACH load per preamble in all those cells. A change in transmission power settings or handover thresholds may have similar effects.
Whenever such a network configuration change happens, the RACH self optimization feature should automatically make appropriate measurements of the RACH performance and usage in all the affected cells and determine any necessary updates of the RACH parameters.
RACH parameters that can then be adjusted are typically the following:
• Split of RACH preambles between contention-free access, contention-based access with high payload, and contention-based access with low payload;
• RACH back-off parameter value or the RACH transmission power ramping parameters;
• Any other parameter may be adjusted if found useful by network operator.
In the following, the signaling designed for RACH optimization over X2 logical interface as well as RACH UE assistance information reporting mechanism in LTE are considered. In addition, a different type of RACH procedure in NR is considered and some details on how the RACH procedure works are provided.
2.2 RA CH Related Signaling Over X2 Interface in L TE System
Generally, a RAN node may trigger an analysis of the information reported by the UE internally or in coordination in other RAN nodes. In this regard, as a part of LTE solution, the eNB PRACH configuration can be exchanged over X2 interface by leveraging ENB X2 Setup Request and eNB Configuration update signaling, where the PRACH Configuration IE, shown in the following table, is contained in the Served Cell Information IE. This IE indicates the PRACH resources used in neighbor cell.
Figure imgf000007_0002
Figure imgf000007_0001
PRACH Configuration IE
Note that such information will be exchanged between RAN nodes with cells identified as neighboring cells. Neighboring cells would be identified by Radio Resource Management (RRM) measurements provided by UEs. Upon detection of a new neighbor, a RAN node may request to set up an X2 interface or later update the configurations if changed. This will be accomplished as part of X2 Setup Request or eNB Configuration signaling which includes PRACH configuration as part of Served Cell Information IE. In addition to the above-mentioned mechanism to exchange RACH related configuration over X2 interface as part of X2 Setup and eNB Configuration update signals, a Uu based signaling has been defined to use a UE assistance information to detect the potential issues, and further enhance the RACH performance by performing finer optimization relying on the provided UE assistance information.
2.3 Log and Reporting of UE Assistance RA CH Information in LTE
In LTE, the report of RACH information when random access procedure is performed may be requested by the network via the UE Information procedure in RRC (see section 5.6.5 of 3GPP TS 36.331), in the case where a RACH procedure was successful. That procedure is summarized in the following excerpts from the RRC specifications (i.e., from 3GPP TS 36.331):
**********START EXCERPTS FROM 3GPP TS 36.331**********
5.6.5 UE Information
5.6.5.1 General
[SEE FIG. 3]
Figure 5.6.5.1-1: UE information procedure
The UE information procedure is used by E-UTRAN to request the UE to report information.
5.6.5.2 Initiation
E-UTRAN initiates the procedure by sending the UEInformationRequest message. E-UTRAN should initiate this procedure only after successful security activation.
5.6.5.3 Reception of the UEInformationRequest message
Upon receiving the UEInformationRequest message, the UE shall, only after successful security activation:
1> if rach-ReportReq is set to true , set the contents of the rach-Report in the UEInformationResponse message as follows:
2> set the numberOfPreamblesSent to indicate the number of preambles sent by MAC for the last successfully completed random access procedure;
2> if contention resolution was not successful as specified in TS 36.321 [6] for at least one of the transmitted preambles for the last successfully completed random access procedure:
3>set the contentionDetected to true;
2> else:
3>set the contentionDetected to false; l>else:
2> submit the UEInformationResponse message to lower layers for transmission via SRB1; UEInformationRequest
The UEInformationRequest is the command used by E-UTRAN to retrieve information from the UE.
Signalling radio bearer: SRB1 RLC-SAP: AM Logical channel: DCCH Direction: E-UTRAN to UE
UEInformationRequest message
— ASN1START
UEInformationRequest-r9 ::= SEQUENCE { rrc-Transactionldentifier RRC- Transactionldentifier, criticalExtensions CHOICE { cl CHOICE { uelnformationRequest-r9 UEInf ormationRequest-r9-
IEs, spare3 NULL, spare2 NULL, sparel NULL
} , criticalExtensionsFuture SEQUENCE {}
}
}
UEInformationRequest-r9-IEs SEQUENCE { rach-ReportReq-r9 BOOLEAN , rlf-ReportReq-r9 BOOLEAN, nonCriticalExtension UEInf ormationRequest-v930-IEs OPTIONAL
}
— ASN1STOP UEInformationResponse The UEInformationResponse message is used by the UE to transfer the information requested by the E-UTRAN.
Signalling radio bearer: SRB1 or SRB2 (when logged measurement information is included) RLC-SAP: AM Logical channel: DCCH Direction: UE to E-UTRAN
UEInformationResponse message
ASN1START UEInformationResponse-r9 ::= SEQUENCE {
UEInformationResponse-r9-IEs :: SEQUENCE { rach-Report-r9 SEQUENCE { numberOfPreamblesSent-r9 NumberOfPreamblesSent- rll, contentionDetected-r9 BOOLEAN
} OPTIONAL, rlf-Report-r9 RLF-Report-r9 OPTIONAL, nonCriticalExtension UEInformationResponse-v930-IEs
OPTIONAL
NumberOfPreamblesSent-rl1 INTEGER (1..200)
— ASN1STOP
**********END EXCERPTS FROM 3GPP TS 36.331**********
2.4 RA CH configuration in NR
As in LTE, the random access procedure is described in the NR MAC specifications (i.e., 3GPP TS 38.321) and parameters are configured by RRC, e.g. in system information or handover (RRCReconfiguration with reconfigurationWithSync). Random access is triggered in many different scenarios, for example, when the UE is in RRC_IDLE or RRC_INACTIVE and wants to access a cell that the UE is camping on (i.e., transition to RRC_CONNECTED).
In NR, the RACH configuration is broadcasted in System Information Block 1 (SIB1), as part of the servingCellConfigCommon (with both downlink and uplink configurations), where the RACH configuration is within the uplinkConfigCommon. The exact RACH parameters are within what is called initialUplinkBWP, since this is the part of the uplink frequency the UE shall access and search for RACH resources.
The RACH configuration is specified in the following excerpts from 3GPP TS 38.331. **********START EXCERPT FROM 3GPP TS 38.331**********
RACH-ConfigGeneric information element
- ASN1 START
- TAG-RACH-CONFIGGENERIC-START
RACH-ConfigGeneric ::= SEQUENCE { prach-Configurationlndex INTEGER (0..255), msg1-FDM ENUMERATED {one, two, four, eight}, msg1-FrequencyStart INTEGER (0..maxNrofPhysicalResourceBlocks-1), zeroCorrelationZoneConfig INTEGER(0..15), preambleReceivedTargetPower INTEGER (-202.. -60), preambleTransMax ENUMERATED {n3, n4, n5, n6, n7, n8, n10, n20, n50, n100, n200}, powerRampingStep ENUMERATED {dBO, dB2, dB4, dB6}, ra-ResponseWindow ENUMERATED {sl1 , sl2, sl4, sl8, sl10, sl20, sl40, sl80},
}
- TAG-RACH-CONFIGGENERIC-STOP
- ASN1STOP
RACH-ConfigCommon information element
- ASN1 START
- TAG-RACH-CONFIGCOMMON-START
RACH-ConfigCommon ::= SEQUENCE { rach-ConfigGeneric totalNumberOfRA-Preambles INTEGER (1..63) OPTIONAL, - Need S ssb-perRACH-OccasionAndCB-PreamblesPerSSB CHOICE { oneEighth ENUMERATED
{n4,n8,n12,n16,n20,n24,n28,n32,n36,n40,n44,n48,n52,n56,n60,n64}, oneFourth ENUMERATED
{n4,n8,n12,n16,n20,n24,n28,n32,n36,n40,n44,n48,n52,n56,n60,n64}, oneHalf ENUMERATED
{n4,n8,n12,n16,n20,n24,n28,n32,n36,n40,n44,n48,n52,n56,n60,n64}, one ENUMERATED
{n4,n8,n12,n16,n20,n24,n28,n32,n36,n40,n44,n48,n52,n56,n60,n64}, two ENUMERATED {n4,n8,n12,n16,n20,n24,n28,n32}, four INTEGER (1..16), eight INTEGER (1..8), sixteen INTEGER (1..4)
} OPTIONAL, - Need M groupBconfigured SEQUENCE { ra-Msg3SizeGroupA ENUMERATED {b56, b144, b208, b256, b282, b480, b640, b800, b1000, b72, spare6, spare5,spare4, spare3, spare2, sparel}, messagePowerOffsetGroupB ENUMERATED { minusinfinity, dBO, dB5, dB8, dB10, dB12, dB15, dB18}, numberOfRA-PreamblesGroupA INTEGER (1..64) } OPTIONAL, - Need R ra-ContentionResolutionTimer ENUMERATED { sf8, sf16, sf24, sf32, sf40, sf48, sf56, sf64}, rsrp-ThresholdSSB RSRP-Range OPTIONAL, --
Need R rsrp-ThresholdSSB-SUL RSRP-Range OPTIONAL, -
Cond SUL prach-RootSequencelndex CHOICE {
1839 INTEGER (0..837),
1139 INTEGER (0..137)
}, msg1 -SubcarrierSpacing SubcarrierSpacing OPTIONAL, --
Cond L139 restrictedSetConfig ENUMERATED {unrestrictedSet, restrictedSetT ypeA, restrictedSetT ypeB}, msg3-transformPrecoder ENUMERATED {enabled}
OPTIONAL, - Need R
}
- TAG-RACH-CONFIGCOMMON-STOP
- ASN1STOP
********** I\jQ EXCERPT FROM 3GPP TS 38331**********
2.5 Contention-Based RACH (CBRA ) in NR
In LTE, the RACH report to assist the network to perform RACH optimization contains an indication that collision was detected. With that information, it is clear that, at some point before that RACH procedure that has succeeded, the same UE tried to access the network and happened to have a collision. In NR, a mechanism also exists for contention resolution for contention-based random access.
RACH partitioning per beam in NR
In NR, random access resource selection needs to be performed within a cell depending on measurements performed on Synchronization Signal Blocks (SSBs) or Channel State Information (CSI) Reference Signals (CSI-RSs). A cell in NR is basically defined by a set of SSBs that may be transmitted in one downlink beam (typical implementation for lower frequencies, e.g. below 6 GHz) as illustrated at the top of Figure 4 or multiple downlink beams (typical implementation for lower frequencies, e.g. below 6 GHz) as illustrated at the bottom of Figure 4. For the same cell, these SSBs carry the same PCI and a Master Information Block (MIB). For standalone operation, i.e., to support UEs camping on an NR cell, the SSBs also carry in SIB1 the RACH configuration, which comprises a mapping between the detected SSB covering the UE at a given point in time and the PRACH configuration (e.g., time, frequency, preamble, etc.) to be used. For that, each of these beams may transmit its own SSB which may be distinguished by an SSB index.
The mapping between RACH resources and SSBs (or CSI-RS) is also provided as part of the RACH configuration (in RACH-ConfigCommon). Two parameters are relevant here, namely:
• #SSBs-per-PRACH-occasion: 1/8, 1/4, 1/2, 1, 2, 8 or 16, which represents the number of SSBs per RACH occasion, and
• #CB-preambles-per-SSB preambles to each SS-block: within a RACH occasion, how many preambles are allocated.
To give a first example, if the number of SSBs per RACH occasion is 1 and if the UE is under the coverage of a specific SSB, e.g. SSB index 2, there will be a RACH occasion for that SSB index 2. If the UE moves and is now under the coverage of another specific SSB, e.g. SSB index 5, there will be another RACH occasion for that SSB index 5, i.e. each SSB detected by a given UE would have its own RACH occasion.
Hence, at the network side, upon detecting a preamble in a particular RACH occasion, the network knows exactly which SSB the UE has selected and, consequently, which downlink beam is covering the UE, so that the network can continue the downlink transmission e.g., send Random Access Response (RAR), etc. That factor 1 is an indication that each SSB has its own RACH resource. That is, a preamble detected in a RACH resource indicates to the network which SSB the UE has selected i.e., which downlink beam the network should use to communicate with the UE, such as the one on which to send the RAR. An example of this one-to-one mapping between SSBs and PRACH occasions is illustrated in Figure 5.
Note that each SSB typically maps to multiple preambles (different cyclic shifts and Zadoff-Chu roots) within a PRACH occasion such that it is possible to receive preambles from multiple different UEs in the same RACH occasion since they may be under the coverage of the same SSB. In a second example, shown in Figure 6, the number of SSBs per RACH occasion is 2. Hence, a preamble received in that RACH occasion indicates to the network that one of the two beams is being selected by the UE. So, either the network has means via implementation to distinguish these two beams and/or the network should perform a beam sweeping in the downlink by transmitting the RAR in both beams (e.g., either by transmitting both simultaneously or by transmitting in one, waiting for a response from the UE, and if absent, transmitting in the other).
Assuming now that in the first attempt the UE has selected an SSB (based on measurements performed in that cell), transmitted with initial power a selected preamble associated to the PRACH resource mapped to the selected SSB, and has not received a RAR within the RAR time window. According to the specifications, the UE may still perform preamble re-transmission (i.e., maximum number of allowed transmissions not reached).
The contention resolution in NR is shown below as described in the MAC specifications (3GPP TS 38.321):
**********START EXCERPT FROM 3GPP TS 38.321**********
5.1.5 Contention Resolution
Once Msg3 is transmitted, the MAC entity shall:
1> start the ra-ContentionResolutionTimer and restart the ra-ContentionResolutionTimer at each HARQ retransmission in the first symbol after the end of the Msg3 transmission; l>monitor the PDCCH while the ra-ContentionResolutionTimer is running regardless of the possible occurrence of a measurement gap; l>if notification of a reception of a PDCCH transmission of the SpCell is received from lower layers:
2>if the C-RNTI MAC CE was included in Msg3:
3>if the Random Access procedure was initiated for beam failure recovery (as specified in subclause 5.17) and the PDCCH transmission is addressed to the C-RNTI; or
3>if the Random Access procedure was initiated by a PDCCH order and the PDCCH transmission is addressed to the C-RNTI; or
3>if the Random Access procedure was initiated by the MAC sublayer itself or by the RRC sublayer and the PDCCH transmission is addressed to the C-RNTI and contains a UL grant for a new transmission:
4> consider this Contention Resolution successful; 4> stop ra-ContentionResolutionTimer ;
4> discard the TEMPORARY C-RNTI; 4> consider this Random Access procedure successfully completed.
2>else if the CCCH SDU was included in Msg3 and the PDCCH transmission is addressed to its TEMPORARY C-RNTI:
3>if the MAC PDU is successfully decoded:
4> stop ra-ContentionResolutionTimer ;
4> if the MAC PDU contains a UE Contention Resolution Identity MAC CE; and
4> if the UE Contention Resolution Identity in the MAC CE matches the CCCH SDU transmitted in Msg3 :
5> consider this Contention Resolution successful and finish the disassembly and demultiplexing of the MAC PDU;
5> if this Random Access procedure was initiated for SI request:
6> indicate the reception of an acknowledgement for SI request to upper layers.
5>else:
6> set the C-RNTI to the value of the TEMPORARY C-RNTI
5> discard the TEMPORARY C-RNTI;
5> consider this Random Access procedure successfully completed.
4> else:
5> discard the TEMPORARY C-RNTI
5> consider this Contention Resolution not successful and discard the successfully decoded MAC PDU.
1> if ra-ContentionResolutionTimer expires:
2> discard the TEMPORARY C-RNTI
2> consider the Contention Resolution not successful. l>if the Contention Resolution is considered not successful:
2> flush the HARQ buffer used for transmission of the MAC PDU in the Msg3 buffer;
2> increment PREAMBLE TRANSMISSION COUNTER by 1;
2> ϊ PREAMBLE TRANSMISSION COUNTER = preambleTransMax + 1 :
3> indicate a Random Access problem to upper layers.
3>if this Random Access procedure was triggered for SI request:
4> consider the Random Access procedure unsuccessfully completed.
2> if the Random Access procedure is not completed:
3> select a random backoff time according to a uniform distribution between 0 and the PREAMBLE BACKOFF; 3> if the criteria (as defined in subclause 5.1.2) to select contention-free Random Access Resources is met during the backoff time:
4> perform the Random Access Resource selection procedure (see subclause
5.1.2);
3> else:
4> perform the Random Access Resource selection procedure (see subclause
5.1.2) after the backoff time.
**********START NEXT EXCERPT FROM 3GPP TS 38.321**********
5.1.2 Random Access Resource selection The MAC entity shall: l>if the Random Access procedure was initiated for beam failure recovery (as specified in subclause 5.17); and
1> if the beamFailureRecoveryTimer (in subclause 5.17) is either running or not configured; and l>if the contention-free Random Access Resources for beam failure recovery request associated with any of the SSBs and/or CSI-RSs have been explicitly provided by RRC; and l>if at least one of the SSBs with SS-RSRP above rsrp-ThresholdSSB amongst the SSBs in candidateBeamRSList or the CSI-RSs with CSI-RSRP above rsrp-ThresholdCSl-RS amongst the CSI-RSs in candidateBeamRSList is available:
2> select an SSB with SS-RSRP above rsrp-ThresholdSSB amongst the SSBs in candidateBeamRSList or a CSI-RS with CSI-RSRP above rsrp-ThresholdCSI-RS amongst the CSI-RSs in candidateBeamRSList ;
2>if CSI-RS is selected, and there is no ra-Preamblelndex associated with the selected CSI-RS:
3> set the PREAMBLE INDEX to a ra-Preamblelndex corresponding to the SSB in candidateBeamRSList which is quasi-colocated with the selected CSI-RS as specified in TS 38.214 [7]
2> else:
3> set the PREAMBLE INDEX to a ra-Preamblelndex corresponding to the selected SSB or CSI-RS from the set of Random Access Preambles for beam failure recovery request. l>else if the ra-Preamblelndex has been explicitly provided by PDCCH; and 1> if the ra-Preamblelndex is not ObOOOOOO:
2> set the PREAMBLE INDEX to the signalled ra-PreambleIndex 2> select the SSB signalled by PDCCH. l>else if the contention-free Random Access Resources associated with SSBs have been explicitly provided in rach-ConfigDedicated and at least one SSB with SS-RSRP above rsrp-ThresholdSSB amongst the associated SSBs is available:
2> select an SSB with SS-RSRP above rsrp-ThresholdSSB amongst the associated SSBs;
2> set the PREAMBLE INDEX to a ra-Preamblelndex corresponding to the selected SSB. l>else if the contention-free Random Access Resources associated with CSI-RSs have been explicitly provided in rach-ConfigDedicated and at least one CSI-RS with CSI-RSRP above rsrp-ThresholdCSI-RS amongst the associated CSI-RSs is available:
2> select a CSI-RS with CSI-RSRP above rsrp-ThresholdCSI-RS amongst the associated CSI-RSs;
2> set the PREAMBLE INDEX to a ra-Preamblelndex corresponding to the selected CSI- RS. l>else if the Random Access procedure was initiated for SI request (as specified in TS 38.331 [5]); and l>if the Random Access Resources for SI request have been explicitly provided by RRC: 2>if at least one of the SSBs with SS-RSRP above rsrp-ThresholdSSB is available:
3 > select an SSB with SS-RSRP above rsrp-ThresholdSSB .
2> else:
3 > select any SSB.
2> select a Random Access Preamble corresponding to the selected SSB, from the Random Access Preamble(s) determined according to ra-PreambleStartlndex as specified in TS 38.331 [5];
2> set the PREAMBLE INDEX to selected Random Access Preamble. l>else (i.e. for the contention-based Random Access preamble selection):
2> if at least one of the SSBs with SS-RSRP above rsrp-ThresholdSSB is available:
3> select an SSB with SS-RSRP above rsrp-ThresholdSSB.
2> else:
3> select any SSB.
5.1.3 Random Access Preamble transmission
The MAC entity shall, for each Random Access Preamble: l>if PREAMBLE TRANSMISSION COUNTER is greater than one; and
1> if the notification of suspending power ramping counter has not been received from lower layers; and
1> if SSB or CSI-RS selected is not changed from the selection in the last Random Access Preamble transmission: 2> increment PREAMBLE POWER RAMPING_COUNTER by 1.
1> select the value of DELTA PREAMBLE according to subclause 7.3;
1 > set PREAMBLE RECEIVED TARGET POWER to preambleReceivedTargetPower + DELTA PREAMBLE + (PREAMBLE POWER RAMPING_COUNTER - 1) x PREAMBLE POWER RAMPING_STEP;
1> except for contention-free Random Access Preamble for beam failure recovery request, compute the RA-RNTI associated with the PRACH occasion in which the Random Access Preamble is transmitted;
1> instruct the physical layer to transmit the Random Access Preamble using the selected PRACH occasion, corresponding RA-RNTI (if available), PREAMBLE INDEX and PREAMBLE RECEIVED TARGET POWER.
The RA-RNTI associated with the PRACH occasion in which the Random Access Preamble is transmitted, is computed as:
RA-RNTI= 1 + s_id + 14 x t_id + 14 x 80 x f id + 14 x 80 x 8 x ul_carrier_id where s_id is the index of the first OFDM symbol of the PRACH occasion (0 < s_id < 14), t_id is the index of the first slot of the PRACH occasion in a system frame (0 < t_id < 80), f id is the index of the PRACH occasion in the frequency domain (0 < f id < 8), and ul carrier id is the UL carrier used for Random Access Preamble transmission (0 for NUL carrier, and 1 for SUL carrier).
5.1.4 Random Access Response reception
Once the Random Access Preamble is transmitted and regardless of the possible occurrence of a measurement gap, the MAC entity shall: l>if the contention-free Random Access Preamble for beam failure recovery request was transmitted by the MAC entity:
2> start the ra-Response Window configured in BeamFailureRecoveryConfig at the first PDCCH occasion as specified in TS 38.213 [6] from the end of the Random Access Preamble transmission;
2> monitor for a PDCCH transmission on the search space indicated by recoverySearchSpaceld of the SpCell identified by the C-RNTI while ra- Response Window is running. l>else:
2> start the ra-Response Window configured in RACH-ConfigCommon at the first PDCCH occasion as specified in TS 38.213 [6] from the end of the Random Access Preamble transmission;
2> monitor the PDCCH of the SpCell for Random Access Response(s) identified by the RA-RNTI while the ra-Response Window is running. l>if notification of a reception of a PDCCH transmission on the search space indicated by recoverySearchSpaceld is received from lower layers on the Serving Cell where the preamble was transmitted; and l>if PDCCH transmission is addressed to the C-RNTI; and l>if the contention-free Random Access Preamble for beam failure recovery request was transmitted by the MAC entity:
2> consider the Random Access procedure successfully completed. l>else if a downlink assignment has been received on the PDCCH for the RA-RNTI and the received TB is successfully decoded:
2>if the Random Access Response contains a MAC subPDU with Backoff Indicator:
3> set the PREAMBLE BACKOFF to value of the BI field of the MAC subPDU using Table 7.2-1, multiplied with SCALING FACTOR BI.
2> else:
3> set the PREAMBLE BACKOFF to 0 ms.
2>if the Random Access Response contains a MAC subPDU with Random Access Preamble identifier corresponding to the transmitted PREAMBLE INDEX (see subclause 5.1.3):
3> consider this Random Access Response reception successful.
2> if the Random Access Response reception is considered successful:
3>if the Random Access Response includes a MAC subPDU with RAPID only:
4> consider this Random Access procedure successfully completed;
4> indicate the reception of an acknowledgement for SI request to upper layers.
3> else:
4> apply the following actions for the Serving Cell where the Random Access Preamble was transmitted:
5> process the received Timing Advance Command (see subclause 5.2);
5> indicate the preambleReceivedTargetPower and the amount of power ramping applied to the latest Random Access Preamble transmission to lower layers (i.e. (PREAMBLE POWER RAMPING_COUNTER - 1) x PREAMBLE POWER RAMPING_STEP);
5> if the Serving Cell for the Random Access procedure is SRS-only SCell:
6> ignore the received UL grant.
5>else:
6> process the received UL grant value and indicate it to the lower layers.
4>if the Random Access Preamble was not selected by the MAC entity among the contention-based Random Access Preamble(s):
5> consider the Random Access procedure successfully completed.
4> else:
5> set the TEMPORARY C-RNTI to the value received in the Random Access Response; 5> if this is the first successfully received Random Access Response within this Random Access procedure:
6> if the transmission is not being made for the CCCH logical channel:
7> indicate to the Multiplexing and assembly entity to include a C-RNTI MAC CE in the subsequent uplink transmission.
6> obtain the MAC PDU to transmit from the Multiplexing and assembly entity and store it in the Msg3 buffer.
NOTE: If within a Random Access procedure, an uplink grant provided in the Random
Access Response for the same group of contention-based Random Access Preambles has a different size than the first uplink grant allocated during that Random Access procedure, the UE behavior is not defined.
1> if ra-Response Window configured in BeamFailureRecoveryConfig expires and if a PDCCH transmission on the search space indicated by recoverySearchSpaceld addressed to the C- RNTI has not been received on the Serving Cell where the preamble was transmitted; or
1> if ra-Response Window configured in RACH-ConfigCommon expires, and if the Random Access Response containing Random Access Preamble identifiers that matches the transmitted PREAM LE INDEX has not been received:
2> consider the Random Access Response reception not successful;
2> increment PREAMBLE TRANSMISSION COUNTER by 1;
2> ϊ PREAMBLE TRANSMISSION COUNTER = preambleTransMax + 1 :
3>if the Random Access Preamble is transmitted on the SpCell:
4> indicate a Random Access problem to upper layers;
4>if this Random Access procedure was triggered for SI request:
5> consider the Random Access procedure unsuccessfully completed.
3>else if the Random Access Preamble is transmitted on a SCell:
4> consider the Random Access procedure unsuccessfully completed.
2>if the Random Access procedure is not completed:
3> select a random backoff time according to a uniform distribution between 0 and the PREAMBLE BACKOFF,·
3>if the criteria (as defined in subclause 5.1.2) to select contention-free Random Access Resources is met during the backoff time:
4>perform the Random Access Resource selection procedure (see subclause 5.1.2); 3>else:
4> perform the Random Access Resource selection procedure (see subclause 5.1.2) after the backoff time.
The MAC entity may stop ra-Response Window (and hence monitoring for Random Access Response(s)) after successful reception of a Random Access Response containing Random Access Preamble identifiers that matches the transmitted PREAMBLE INDEX. HARQ operation is not applicable to the Random Access Response reception.
********** I\jQ EXCERPTS FROM 3GPP TS 38 321**********
2.6 Contention-Free Random Access (CFRA ) in NR and Fallback to C BRA
In NR, as in LTE, the UE may be configured to perform CFRA, e.g. during handovers. That configuration goes in the reconfigurationWithSync of IE ReconfigurationWithSync (which goes in the CellGroupConfig IE, transmitted in the RRCReconfiguration message), as shown below:
**********START EXCERPT FROM 3GPP TS 38.331**********
ReconfigurationWithSync : := SEQUENCE { spCellConfigCommon ServingCellConfigCommon OPTIONAL, -- Need M newUE-ldentity RNTI-Value, t304 ENUMERATED {ms50, ms100, ms150, ms200, ms500, ms1000, ms2000, mslOOOO}, rach-ConfigDedicated CHOICE { uplink RACH-ConfigDedicated, supplementaryUplink RACH-ConfigDedicated
} OPTIONAL, - Need N
[[ smtc SSB-MTC OPTIONAL - Need S
]]
}
RACH-ConfigDedicated information element
- ASN1 START
- TAG-RACH-CONFIG-DEDICATED-START
RACH-ConfigDedicated ::= SEQUENCE { cfra CFRA OPTIONAL, - Need S ra-Prioritization OPTIONAL, -- Need N
CFRA ::= SEQUENCE { occasions SEQUENCE { rach-ConfigGeneric ssb-perRACH-Occasion ENUMERATED {oneEighth, oneFourth, oneHalf, one, two, four, eight, sixteen} OPTIONAL - Cond SSB-CFRA
} OPTIONAL, - Need S resources CHOICE { ssb SEQUENCE { ssb-ResourceList SEQUENCE (SIZE(1..maxRA-SSB-Resources)) OF CFRA-SSB-
Resource, ra-ssb-OccasionMasklndex INTEGER (0..15)
}, csirs SEQUENCE { csirs-ResourceList SEQUENCE (SIZE(1..maxRA-CSIRS-Resources)) OF CFRA-CSIRS- Resource, rsrp-ThresholdCSI-RS RSRP-Range
}
},
[[ totalNumberOfRA-Preambles-v1530 INTEGER (1..63) OPTIONAL -- Cond Occasions
]]
}
CFRA-SSB-Resource ::= SEQUENCE { ssb SSB-lndex, ra-Preamblelndex INTEGER (0..63),
CFRA-CSIRS-Resource ::= SEQUENCE { csi-RS CSI-RS-lndex, ra-OccasionList SEQUENCE (SIZE(1..maxRA-OccasionsPerCSIRS)) OF INTEGER
(0..maxRA-Occasions-1) ra-Preamblelndex INTEGER (0..63),
}
- TAG-RACH-CONFIG-DEDICATED-STOP
- ASN1STOP
********** I\jQ EXCERPT FROM 3GPP TS 38 331**********
One difference shown above, which is already highlighted in section 2.5, is that RACH resources may be mapped to beams (e.g., SSBs or CSI-RS resources that may be measured by the UE). Hence, when CFRA resources are provided, they are also mapped to beams, and this may be done only for a subset of beams in a given target cell.
The consequence is that, to use CFRA resources, the UE needs to select a beam for which it has CFRA resources configured in the dedicated configuration. In the case of SSBs, for example, that may be found in the ssb-ResourceList which is a SEQUENCE (SIZE(l..maxRA-SSB-Resources)) OF CFRA-SSB-Resource.
If an analogy is made with LTE, i.e., if the NR solution would have been the same as LTE, upon selecting a beam with CFRA resource (e.g., a beam from the configured list) and not receiving the RAR, the UE would keep selecting the same resource and ramp the power before retransmitting the preamble. However, as in the case of NR CBRA, the UE has the option upon every failed attempt to select another beam. Further, that other beam may or may not be in the list of beams for CFRA. In the case the selected beam is not in the list of beams for CFRA, the UE performs CBRA.
Also notice that there is a fallback between CSI-RS selection to SSB selection, in case CFRA is provided for CSI-RS resources. That is shown below, as captured in the MAC specifications (3GPP TS 38.331):
**********START EXCERPT FROM 3GPP TS 38.331**********
5.1.2 Random Access Resource selection The MAC entity shall: l>if the Random Access procedure was initiated for beam failure recovery (as specified in subclause 5.17); and
1> if the beamFailureRecoveryTimer (in subclause 5.17) is either running or not configured; and l>if the contention-free Random Access Resources for beam failure recovery request associated with any of the SSBs and/or CSI-RSs have been explicitly provided by RRC; and l>if at least one of the SSBs with SS-RSRP above rsrp-ThresholdSSB amongst the SSBs in candidateBeamRSList or the CSI-RSs with CSI-RSRP above rsrp-ThresholdCSl-RS amongst the CSI-RSs in candidateBeamRSList is available:
2> select an SSB with SS-RSRP above rsrp-ThresholdSSB amongst the SSBs in candidateBeamRSList or a CSI-RS with CSI-RSRP above rsrp-ThresholdCSI-RS amongst the CSI-RSs in candidateBeamRSList ;
2>if CSI-RS is selected, and there is no ra-Preamblelndex associated with the selected CSI-RS:
3> set the PREAMBLE INDEX to a ra-Preamblelndex corresponding to the SSB in candidateBeamRSList which is quasi-colocated with the selected CSI-RS as specified in TS 38.214 [7]
2> else: 3> set the PREAMBLE INDEX to a ra-Preamblelndex corresponding to the selected SSB or CSI-RS from the set of Random Access Preambles for beam failure recovery request. l>else if the ra-Preamblelndex has been explicitly provided by PDCCH; and 1> if the ra-Preamblelndex is not ObOOOOOO:
2> set the PREAMBLE INDEX to the signalled ra-Preamblelndex,
2> select the SSB signalled by PDCCH. l>else if the contention-free Random Access Resources associated with SSBs have been explicitly provided in rach-ConfigDedicated and at least one SSB with SS-RSRP above rsrp-ThresholdSSB amongst the associated SSBs is available:
2> select an SSB with SS-RSRP above rsrp-ThresholdSSB amongst the associated SSBs;
2>set the PREAMBLE INDEX to a ra-Preamblelndex corresponding to the selected SSB. l>else if the contention-free Random Access Resources associated with CSI-RSs have been explicitly provided in rach-ConfigDedicated and at least one CSI-RS with CSI- RSRP above rsrp- ThresholdCSI-RS amongst the associated CSI-RSs is available:
2> select a CSI-RS with CSI-RSRP above rsrp- ThresholdCSI-RS amongst the associated CSI-RSs;
2>set the PREAMBLE INDEX to a ra-Preamblelndex corresponding to the selected CSI-RS. l>else if the Random Access procedure was initiated for SI request (as specified in TS 38.331 [5]); and l>if the Random Access Resources for SI request have been explicitly provided by RRC:
2>if at least one of the SSBs with SS-RSRP above rsrp-ThresholdSSB is available:
3 > select an SSB with SS-RSRP above rsrp-ThresholdSSB .
2> else:
3 > select any SSB.
2> select a Random Access Preamble corresponding to the selected SSB, from the Random Access Preamble(s) determined according to ra-PreambleStartlndex as specified in TS 38.331 [5];
2> set the PREAMBLE INDEX to selected Random Access Preamble. l>else (i.e. for the contention-based Random Access preamble selection):
2> if at least one of the SSBs with SS-RSRP above rsrp-ThresholdSSB is available:
3> select an SSB with SS-RSRP above rsrp-ThresholdSSB.
2> else: 3> select any SSB. l>if the Random Access procedure was initiated for SI request (as specified in TS 38.331 [5]); and
1> if ra-AssociationPeriodlndex and si-RequestPeriod are configured:
********** I\jQ EXCERPT FROM 3GPP TS 38 331**********
3 2-step RACH in NR
In NR, besides the classical 4-step random access procedure (which is present also in LTE), a new 2-step random access procedure has been specified as part of the 3GPP Rel-16 standard. From Figure 7, it is possible to compare the 4-step RACFI procedure and the 2-step RACFI procedure. A clear advantage of the 2-step RACFI procedure over the 4-step RACFI is that the 2-step RACFI is much faster. In particular, it is possible to show that the minimum latency that can be achieved between the PRACFI transmission until msg4 reception, i.e., contention resolution, with the 4-step RACFI is 13 subframes. As comparison, for 2-step RACFI, the minimum achievable latency is 4 subframes. This makes 2-step RACFI around 3 times faster than 4-step RACFI. Therefore, the 2-step RACFI approach may be particularly attractive for delay-sensitive use cases, and also in unlicensed networks. With respect to unlicensed networks, 2- step RACFI is attractive because the 2-step approach, unlike the 4-step approach, implies only 2 Listen Before Talk (LBT) procedures (one at UE side for msgA transmission, and one at the network side for the msgB transmission), thereby making the 2-step much faster especially in case of congested network where the UE/gNB may need to postpone several times the transmission of random access messages due to LBT failures, i.e. channel busy.
On the other hand, in 2-step RACH, the UE may transmit data, i.e., the payload, as part of msgA, i.e., before getting a proper uplink timing alignment from the network. Additionally, data transmitted in msgA has not yet been link adapted by the network. This means that the probability of properly decoding the payload at the network side very much depends on how good the uplink synchronization already is at the time of sending msgA, e.g., it may depend on the cell size, and also on how good the link quality is. Given the above, assuming that the Bandwidth Part (BWP) selected for random access procedure has both 4-step and 2-step RACH resources configured, the UE selects the 2-step RACH resources only if the estimated downlink Reference Signal Received Power (RSRP) is above a certain configurable threshold.
Similar to the 4-step RACH, the UE can select the RACH preamble from two groups of 2-step RACH preambles, depending on the size of the payload to include in msgA. At transmission of 2-step RACH, the UE starts the msgB-ResponseWindow timer and starts monitoring PDCCH with the msgB Radio Network Temporary Identifier (RNTI) (msgB-RNTI). In case no msgB is received within msgB-ResponseWindow, or in case the gNB sends in msgB a backoff indicator, the UE reattempts msgA transmission and applies power ramping. Otherwise, the network may include a successRAR flag in the msgB to indicate that msgA (preamble+payload) decoding was successful. In this case, if the UE contention resolution identity included in msgB matches the one included by the UE in msgA, the random access procedure is considered successful, and the UE will use the Cell RNTI (C-RNTI) included in the msgB for successive communications with the network.
The network may also include in the msgB a fallback indicator to indicate to the UE to fallback to 4-step. The fallback procedure may be used, for example, in case the network successfully decodes the preamble, but it is not able to decode the payload in msgA. Therefore, in case the msgB MAC Protocol Data Unit (PDU) with fallbackRAR includes a Random Access Preamble Identifier (RAPID) which matches the preamble index used by the UE in msgA, the UE continues with msg3 transmission using the uplink grant and the Temporary C-RNTI included in msgB. Hence, the UE moves the payload intended to be transmitted in msgA to the msg3 buffer, and it waits for msg4 to resolve the contention.
Finally, a switch procedure is also considered in the specification. The UE switches from 2-step RACH to 4-step RACH after attempting the 2-step RACH transmission a certain amount of time with no success. Unlike the fallback procedure, the switch procedure implies that the UE drops the 2-step RACH resources, and restarts from 4-step msgl by selecting a new 4-step RACH resource.
Summary
Systems and methods for detecting and resolving 2-step Random Access Channel (RACH) configuration conflicts are disclosed. In one embodiment, a method performed by a first network node comprises receiving a 2-step RACH msgA from at least one wireless communication device in a cell controlled by the first network node and determining that there is a potential or actual 2-step RACH configuration conflict for the cell. The method further comprises performing one or more actions responsive to determining that there is a 2-step RACH configuration conflict for the cell. In this manner, the first network node is enabled to efficiently detect a potential or actual 2- step RACH configuration conflict for a controlled cell, e.g., without any or with limited amount of assistance from another network node.
In one embodiment, performing the one or more actions comprises transmitting, to a second network node, a 2-step RACH assistance message. In one embodiment, the 2-step RACH assistance message comprises: (a) an indication of the potential or actual 2-step RACH configuration conflict, (b) an indication that the first network node is asking for RACH assistance information, (c) information that informs the second network node of a new or updated RACH configuration for the cell, or (d) any combination of two or more of (a)-(c). In one embodiment, the 2-step RACH assistance message comprises an indication of one or more RACH resources for which there is a conflict. In one embodiment, the 2-step RACH assistance message comprises a cell identity of the cell for which the first network node detected a potential or actual 2-step RACH configuration conflict.
In one embodiment, performing the one or more actions comprises determining a new or updated RACH configuration for the cell that resolves the potential or actual 2- step RACH configuration conflict. In one embodiment, performing the one or more actions further comprises configuring the cell with the new or updated RACH configuration.
In one embodiment, the new or updated RACH configuration is a 2-step RACH resource configuration for the cell that resolves the potential or actual 2-step RACH configuration conflict. In one embodiment, the 2-step RACH resource configuration comprises a configuration of a set of RACH resources that is either orthogonal or non¬ overlapping with a set of 2-step RACH resources for which the potential or actual 2-step RACH configuration conflict was determined or non-orthogonal or partly overlapping with the set of 2-step RACH resources for which the potential or actual 2-step RACH configuration conflict was determined.
In one embodiment, the new or updated RACH configuration comprises a new pool of resources for 2-step RACH in the cell that resolves the potential or actual 2-step RACH configuration conflict based on utilization of 2-step RACH resources and 4-step RACH resources within the cell.
In one embodiment, determining the new or updated RACH configuration for the cell that resolves the potential or actual 2-step RACH configuration conflict comprises swapping RACH resources assigned to different bandwidth parts.
In one embodiment, determining the new or updated RACH configuration for the cell that resolves the potential or actual 2-step RACH configuration conflict comprises swapping the conflicting RACH resources with RACH resources of another cell controlled by the first network node.
In one embodiment, performing the one or more actions further comprises: sending, to the second network node, a request for 2-step RACH conflict assistance information and receiving, from the second network node, 2-step RACH conflict assistance information. Further, determining the new or updated RACH configuration for the cell that resolves the potential or actual 2-step RACH configuration conflict comprises determining the new or updated RACH configuration for the cell that resolves the conflict based on the 2-step RACH conflict assistance information. In one embodiment, the request for 2-step RACH conflict assistance information comprises: (a) an indication of the potential or actual 2-step RACH configuration 2-step conflict, (b) an identifier for at least the cell for which the first network node determined the potential or actual 2-step RACH configuration conflict, (c) information associated to the determining the potential or actual 2-step RACH configuration, (d) an indication of 2- step RACH resources where the potential or actual 2-step RACH configuration conflict was determined, or (e) any combination of two or more of (a) - (d). In one embodiment, the 2-step RACH conflict assistance information comprises: (i) an acknowledgement of the occurrence of an actual or potential 2-step RACH configuration conflict, (ii) an indication of a 2-step RACH resource configuration of a neighboring cell which caused the potential or actual 2-step RACH configuration conflict with the cell, (iii) an indication of recommended resources that the first network node can configure for 2-step RACH in the cell to resolve the potential or actual 2-step RACH configuration conflict, or (iv) any two or more of (i) - (iii).
In one embodiment, performing the one or more actions further comprises receiving a list of RACH resources from another node, the list of RACH resources being suggested RACH resources to resolve the potential or actual 2-step RACH configuration conflict. Determining the new or updated RACH configuration for the cell that resolves the potential or actual 2-step RACH configuration conflict comprises determining the new or updated RACH configuration for the cell that resolves the potential or actual 2- step RACH configuration conflict based on the received list of RACH resources.
In one embodiment, performing the one or more actions further comprises sending the 2-step RACH optimization message to the second network node, the 2-step RACH optimization message comprising the new or updated RACH configuration for the cell.
In one embodiment, performing the one or more actions comprises sending, to the second network node, a request for 2-step RACH conflict assistance information and receiving, from the second network node, 2-step RACH conflict assistance information, where the 2-step RACH conflict assistance information comprises a new or updated RACH configuration for at least the cell for which the potential or actual 2-step RACH configuration conflict was determined. In one embodiment, performing the one or more actions further comprise configuring the cell with the new or updated RACH configuration.
In one embodiment, determining that there is a potential or actual 2-step RACH configuration conflict for the cell comprises determining that the first network node can correctly decode a RACH preamble of the 2-step RACH msgA and determining that the first network node cannot correctly decode a payload of the 2-step RACH msgA.
In one embodiment, determining that there is a potential or actual 2-step RACH configuration conflict for the cell comprises obtaining statistical information associated with random access events that use a 2-step RACH procedure in which the first network node receives a 2-step RACH msgA from a wireless communication device, can decode a preamble of the msgA, but cannot decode a payload of the msgA and determining that there is a potential or actual 2-step RACH configuration conflict for the cell based on the obtained statistical information and one or more predefined or preconfigured thresholds.
In one embodiment, the first network node is a Distributed Unit (DU) of a base station having a split Central Unit (CU) / DU architecture, and the second network node is a CU of the base station.
Corresponding embodiments of a first network node are also disclosed herein. In one embodiment, a first network node is adapted to receive a 2-step RACH msgA from at least one wireless communication device in a cell controlled by the first network node and determine that there is a potential or actual 2-step RACH configuration conflict for the cell. The first network node is further adapted to perform one or more actions responsive to determining that there is a 2-step RACH configuration conflict for the cell.
In one embodiment, a first network node comprises processing circuitry configured to cause the first network node to receive a 2-step RACH msgA from at least one wireless communication device in a cell controlled by the first network node and determine that there is a potential or actual 2-step RACH configuration conflict for the cell. The processing circuitry is further configured to cause the first network node to perform one or more actions responsive to determining that there is a 2-step RACH configuration conflict for the cell.
Embodiments of a method performed by a second network node are also disclosed. In one embodiment, a method performed by a second network node comprises receiving, from a first network node, a request for 2-step RACH conflict assistance information, determining the 2-step RACH conflict assistance information, and transmitting the 2-step RACH conflict assistance information to the first network node.
In one embodiment, the request comprises: (a) an indication of a 2-step RACH configuration conflict detected by the first network node, (b) an identifier for at least a cell for which the first network node detected the 2-step RACH configuration conflict, (c) information associated to detection of the 2-step RACH conflict, (d) an indication of 2- step RACH resources where the 2-step RACH configuration conflict was detected, or (e) any combination of two or more of (a) - (d). In one embodiment, the 2-step RACH conflict assistance information comprises: (i) an acknowledgement of the occurrence of a 2-step RACH configuration conflict, (ii) an indication of a 2-step RACH resource configuration of a neighboring cell which caused the detected 2-step RACH configuration conflict with the cell, (iii) an indication of recommended resources that the first network node can configure for 2-step RACH procedure in the cell to resolve the 2- step-RACH configuration conflict, or (iv) any two or more of (i) - (iii).
In one embodiment, determining the 2-step RACH conflict assistance information comprises determining a new or updated RACH configuration for at least a cell for which a conflict is detected, the new or updated RACH configuration being a RACH configuration that resolves the conflict, wherein the 2-step RACH conflict assistance information comprises the new or updated RACH configuration that resolves the conflict.
In one embodiment, the first network node is a DU of a base station having a split CU/DU architecture, and the second network node is a CU of the base station.
Corresponding embodiments of a second network node are also disclosed herein. In one embodiment, a second network node is adapted to receive, from a first network node, a request for 2-step RACH conflict assistance information, determine the 2-step RACH conflict assistance information, and transmit the 2-step RACH conflict assistance information to the first network node.
In one embodiment, a second network node comprises processing circuitry configured to cause the second network node to receive, from a first network node, a request for 2-step RACH conflict assistance information, determine the 2-step RACH conflict assistance information, and transmit the 2-step RACH conflict assistance information to the first network node.
Brief Description of the Drawings
The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.
Figure 1 illustrates the current Fifth Generation (5G), or New Radio (NR), Radio Access Network (RAN) (i.e., the Next Generation RAN (NG-RAN)) architecture;
Figure 2 illustrates an expansion of the architecture in Figure 1 in which the Central Unit of the NR base station (gNB) (i.e., the gNB-CU or CU for short) is split into two entities, namely, a Control Plane (CP) part (gNB-CU-CP or CU-CP for short) and a User Plane (UP) part (gNB-CU-UP or CU-UP or short);
Figure 3 is a reproduction of Figure 5.6.5.1-1 of Third Generation Partnership Project (3GPP) Technical Specification (TS) 36.331;
Figure 4 illustrates example of a cell defined by a set of Synchronization Signal Blocks (SSBs) that may be transmitted in one downlink beam (see top of Figure 4) and an example of a cell defined by a set of SSBs that may be transmitted in multiple downlink beams;
Figure 5 illustrates an example of a one-to-one mapping between SSBs and Physical Random Access Channel (PRACH) occasions; Figure 6 illustrates an example in which the number of SSBs per PRACH occasion is 2;
Figure 7 illustrates both the 4-step random access procedure and the 2-step random access procedure;
Figure 8 illustrates one example of a cellular communications system in which embodiments of the present disclosure may be implemented;
Figure 9 illustrates an example of a gNB having a split CU/DU architecture;
Figure 10 is a flow chart that illustrates a method executed by a first network node (e.g., a gNB-DU) in accordance with some embodiments of the present disclosure;
Figure 11 illustrates the operation of a gNB-DU and a gNB-CU in accordance with some embodiments of the present disclosure;
Figure 12 illustrates an example of how a first network node can detect a 2-step RACFI configuration conflict between neighboring cells in accordance with one embodiment of the present disclosure;
Figure 13 illustrates the operation of a gNB-DU and a gNB-CU in accordance with some other embodiments of the present disclosure;
Figure 14 illustrate the operation of a gNB-DU and a gNB-CU in accordance with some other embodiments of the present disclosure;
Figure 15 is a flow chart that illustrates a method executed by a second network node in accordance with some embodiments of the present disclosure;
Figure 16 is a flow chart that illustrates a method executed by a second network node in accordance with some other embodiments of the present disclosure; and
Figures 17, 18, and 19 are schematic diagrams of example embodiments of a network node (e.g., the first network node or the second network node).
Detailed Description
The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure. Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.
Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and/or is implied from the context in which it is used. All references to a/an/the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and/or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features, and advantages of the enclosed embodiments will be apparent from the following description.
Radio Node: As used herein, a "radio node" is either a radio access node or a wireless communication device.
Radio Access Node: As used herein, a "radio access node" or "radio network node" or "radio access network node" is any node in a Radio Access Network (RAN) of a cellular communications network that operates to wirelessly transmit and/or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), a relay node, a network node that implements part of the functionality of a base station (e.g., a network node that implements a gNB Central Unit (gNB-CU) or a network node that implements a gNB Distributed Unit (gNB-DU)) or a network node that implements part of the functionality of some other type of radio access node.
Core Network Node: As used herein, a "core network node" is any type of node in a core network or any node that implements a core network function. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Flome Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing an Access and Mobility Management Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.
Communication Device: As used herein, a "communication device" is any type of device that has access to an access network. Some examples of a communication device include, but are not limited to: mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or Personal Computer (PC). The communication device may be a portable, hand-held, computer-comprised, or vehicle- mounted mobile device, enabled to communicate voice and/or data via a wireless or wireline connection.
Wireless Communication Device: One type of communication device is a wireless communication device, which may be any type of wireless device that has access to (i.e., is served by) a wireless network (e.g., a cellular network). Some examples of a wireless communication device include, but are not limited to: a User Equipment device (UE) in a 3GPP network, a Machine Type Communication (MTC) device, and an Internet of Things (IoT) device. Such wireless communication devices may be, or may be integrated into, a mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or PC. The wireless communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless connection. Network Node: As used herein, a "network node" is any node that is either part of the RAN or the core network of a cellular communications network/system.
Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system.
Note that, in the description herein, reference may be made to the term "cell"; however, particularly with respect to 5G NR concepts, beams may be used instead of cells and, as such, it is important to note that the concepts described herein are equally applicable to both cells and beams.
There currently exist certain challenge(s). The NR Radio Access Technology (RAT), which is part of the Next Generation Radio Access Network (NG-RAN) system, has a new structure for the configuration of Random Access Channel (RACH) resources and processes as compared to LTE. In addition, NR supports two procedures for random access, a 4-step RACH procedure like in LTE and a 2-step RACH procedure which halves and radically changes the signaling required by the UE to access the radio access network. In NR, RACH resources and processes can be configured on a per beam basis. Cell beams are characterized by specific reference signals and communication channels. Typically, beams signals and channels are not always available in time for a given coverage area. The reason for this is that beams "sweep", namely their availability in terms of Reference Signal (RS) and communication channels changes in the time and spatial domain given that the beam orientation is swept across a pre-set coverage area. Furthermore, the split architecture followed in NR and in other RATs such as the Evolved Universal Terrestrial Radio Access Network (E-UTRAN) (i.e., LTE) implies that information needed to perform RACH optimization, such as RACH configurations of cells within a neighborhood, indications on whether a possible RACH configuration conflict exists, and indication of changes of RACH configuration to solve a RACH configuration conflict need to be exchanged between the gNB Central Unit (gNB- CU) and the gNB Distributed Unit (gNB-DU) (in the specific example of NR) or in general between the Central Unit (CU) and the Distributed Unit (DU) of the specific high layer split architecture for that RAT.
The above factors create a problem when a RACH optimization solution needs to be supported because the legacy mechanisms for LTE are not re-adaptable to NR. Hence, new solutions are needed. In particular, the conventional solution does not provide a solution to detect and resolve RACH configuration conflict for the 2-step RACH procedure defined for the 3GPP NG-RAN system.
Certain aspects of the present disclosure and their embodiments may provide solutions to the aforementioned or other challenges. Embodiments of a method executed by a first network node (e.g., a gNB-DU) for optimizing the configuration of resources for a 2-step RACH procedure for at least a controlled cell are disclosed. In one embodiment, the method comprises:
• receiving, at the first network node, a msgA associated to a 2-step RACH procedure from at least one wireless communication device in a cell (e.g., a cell controlled by the first network node, which is referred to herein as a "controlled cell");
• detecting/determining, at the first network node, a 2-step RACH configuration conflict for the cell based on the received msgA from the at least one wireless communication device in the cell;
• transmitting, by the first network node, a 2-step RACH optimization message to a second network node (e.g., a gNB-CU), based on the detection of the 2- step RACH configuration conflict for the controlled cell.
In one embodiment, the 2-step RACH optimization message comprises: (a) an indication of a RACH conflict (e.g., an actual RACH conflict or a potential RACH conflict), (b) an indication that the first network node is asking for RACH assistance information (i.e., a request for RACH assistance information), (c) information that informs the second network node of an updated RACH configuration for the cell, or (d) any combination of two or more of (a)-(c).
Corresponding embodiments of the first network node are also disclosed.
With respect to the first network node, embodiments disclosed herein include:
• Methods to detect 2-step RACH configuration conflict based on receiving msgA from one or more wireless communication devices in a controlled cell. o Detection can be done by:
■ decoding the msgA preamble but not being able to decode the payload; and/or ■ detecting that the msgA payload is scrambled with a different Physical Cell Identity (PCI) than the one used by the controlled cell.
• Inter-node 2-step RACH optimization and related signaling exchange: o Case 1: The first network node (gNB-DU) resolves a 2-step RACH conflict and signals an updated 2-step RACH configuration to a second network node (gNB-CU).
■ The first network node can solve the 2-step RACH configuration conflict independently.
■ The first network node can solve the 2-step RACH configuration conflict with assistance information from the second network node (gNB-CU). o Case 2: The first network node indicates a possible 2-step RACH configuration conflict to the second network node, which in return determines a new 2-step RACH configuration for the controlled cell and signals it to the first network node.
Embodiments of a method executed by a second network node (i.e., a gNB-CU) are also disclosed. In one embodiment, the method comprises:
• receiving, by the second network node, a 2-step RACH conflict assistance information request from a first network node (i.e., a gNB-DU);
• determining, by the second network node, assistance information associated to the 2-step RACH procedure for at least one cell controlled by the first network node based on the 2-step RACH conflict assistance information request; and
• transmitting, by the second network node, a 2-step RACH conflict assistance information response to the first network node comprising the 2-step RACH assistance information.
In one embodiment, the method executed by a second network node (i.e., a gNB-CU) may further comprise:
• receiving from a first network node (e.g., a gNB-DU) a 2-step RACH optimization message comprising a new/updated 2-step RACH resource configuration for a cell controlled by the first network node; and • transmitting a RACH configuration update message to another second network node (i.e., a neighboring gNB-CU) comprising the new/updated 2- step RACH resource configuration.
It should be noted that the names used for messages and signals exchanged between the first and second network nodes according to embodiments disclosed herein are only used as examples. Such message and signals could consist of an existing message and signals in a radio system, such as the 3GPP LTE system or the 3GPP NG- RAN (NR) system, that are enhanced to carry the information disclosed herein.
Certain embodiments may provide one or more of the following technical advantage(s). The embodiments disclosed herein allow a gNB-DU to efficiently detect a (potential) 2-step RACH configuration conflict for a controlled cell without any (or with limited amount of) assistance from the gNB-CU. Additionally, the method enables the gNB-DU to readily and efficiently optimize the 2-step RACH resource configuration for the controlled cell experiencing a configuration conflict with a neighboring cell, thereby improving the overall system performance when user devices attempt to access the controlled cell using a 2-step random access procedure.
The embodiments disclosed herein further enable a gNB-DU to efficiently detect and report a (potential) 2-step RACH configuration conflict for a controlled cell to the respective gNB-CU. In turn, this enables the gNB-CU to efficiently verify whether the reported 2-step RACH configuration conflict exists based on additional information about the allocation of 2-step RACH resources that is available only to the gNB-CU. Thus, the occurrence of a 2-step RACH configuration conflict between a cell controlled by the gNB-DU and a neighboring cell can be efficiently detected and resolved with minimal information exchange between the gNB-DU and the gNB-CU, thereby improving the system performance.
Figure 8 illustrates one example of a cellular communications system 800 in which embodiments of the present disclosure may be implemented. In the embodiments described herein, the cellular communications system 800 is a 5G System (5GS) including a NG-RAN or an Evolved Packet System (EPS) including an Evolved Universal Terrestrial Radio Access Network (E-UTRAN). In this example, the RAN includes base stations 802-1 and 802-2, which in the NG-RAN include gNBs and, optionally, ng-eNBs (i.e., LTE RAN nodes connected to the 5GC) and in the LTE RAN (i.e., E-UTRAN) are referred to as eNBs, controlling corresponding (macro) cells 804-1 and 804-2. The base stations 802-1 and 802-2 are generally referred to herein collectively as base stations 802 and individually as base station 802. Likewise, the (macro) cells 804-1 and 804-2 are generally referred to herein collectively as (macro) cells 804 and individually as (macro) cell 804. The RAN may also include a number of low power nodes 806-1 through 806-4 controlling corresponding small cells 808-1 through 808-4. The low power nodes 806-1 through 806-4 can be small base stations (such as pico or femto base stations) or Remote Radio Heads (RRHs), or the like. Notably, while not illustrated, one or more of the small cells 808-1 through 808-4 may alternatively be provided by the base stations 802. The low power nodes 806-1 through 806-4 are generally referred to herein collectively as low power nodes 806 and individually as low power node 806. Likewise, the small cells 808-1 through 808-4 are generally referred to herein collectively as small cells 808 and individually as small cell 808. The cellular communications system 800 also includes a core network 810, which in the 5GS is referred to as the 5G Core (5GC). The base stations 802 (and optionally the low power nodes 806) are connected to the core network 810.
The base stations 802 and the low power nodes 806 provide service to wireless communication devices 812-1 through 812-5 in the corresponding cells 804 and 808. The wireless communication devices 812-1 through 812-5 are generally referred to herein collectively as wireless communication devices 812 and individually as wireless communication device 812. In the following description, the wireless communication devices 812 are oftentimes UEs, but the present disclosure is not limited thereto.
In the embodiments described herein, the base stations 802 have a split architecture where each base station 802 includes a CU (which may further be split into a CU-CP and a CU-UP) and one or more DUs. As an example, see the split architecture of the gNB illustrated in Figures 1 and 2. In the embodiments described below, the base station 802 is a gNB having a split architecture as illustrated in Figure 9. Thus, the base station 802 is also referred to herein as a gNB 802. In particular, the gNB 802 includes a gNB-CU 900 and one or more gNB-DUs 902. In the example of Figure 9, the gNB 802 has two gNB-DUs 902, which are denoted as gNB-DUs 902-1 and 902-2.
Embodiments of a method for detecting and resolving RACH configuration conflicts between neighboring cells using 2-step RACH procedure in a split RAN architecture wherein a gNB-CU 900 is connected to multiple gNB-DUs 902 and each gNB-DU 902 serves/controls one or more radio access cells (referred to herein as "cells" or "controlled cells"). A 2-step RACH configuration conflict can occur either between two cells controlled by different gNB-DUs 902 connected to the same gNB-CU 900 or between two cells controlled by different gNB-DUs 902 connected to different gNB-CUs 900.
In this description, the example case of an NR RAT is considered. In such example, the architecture taken into consideration is a split architecture where the gNB- CU 900 hosts high layers such as the Radio Resource Control (RRC) layer and where the gNB-DU(s) 902 hosts lower layers such as the physical (PHY) layer, the Medium Access Control (MAC) layer, and the Radio Link Control (RLC). The methods described herein can be applied to any RAT that follows the same split architecture. For example, they can be applied to the E-UTRAN split architecture or to the E-UTRA split architecture.
I. Method and Embodiments for gNB-DU
Embodiments of a method executed by a first network node (e.g., the gNB-DU 902) for optimizing the configuration of resources for a 2-step RACH procedure for at least a controlled cell are disclosed herein. As illustrated in Figure 10 in which optional steps are represented by dashed lines/boxes, the method executed by the first network node comprises:
• Step 1000: The first network node receives a 2-step RACH msgA from at least one wireless communication device 812 for a controlled cell.
• Step 1002: The first network node detects (or determines) that there is a 2- step RACH configuration conflict (e.g., a potential conflict or an actual conflict) for the controlled cell (with a neighbor cell) based on the received msgA from the at least one wireless communication device 812 in the controlled cell.
• Step 1004 (Optional): The first network node determines a new or updated 2-step RACH resource configuration for the controlled cell based on the detection of the 2-step RACH configuration conflict, where the new or updated 2-step RACH resource configuration resolves the 2-step RACH configuration conflict.
• Step 1006 (Optional): The first network node configures the controlled cell with the new/updated 2-step RACH resource configuration. • Step 1008: The first network node transmits to a second network node (e.g., the gNB-CU 900) a 2-step RACH assistance message. The 2-step RACH assistance message is also referred to herein as a 2-step RACH optimization message. In one embodiment, the 2-step RACH assistance message comprises: (a) an indication of a RACH conflict (e.g., an actual RACH conflict or a potential RACH conflict), (b) an indication that the first network node is asking for RACH assistance information (i.e., a request for RACH assistance information), (c) information that informs the second network node of the new or updated RACH configuration for the cell, or (d) any combination of two or more of (a)-(c). In one embodiment, the 2-step RACH assistance message comprises the new/updated 2-step RACH resource configuration (including time/frequency and preamble resources as well as PUSCH resources used for payload part of msgA) for the controlled cell from step 1004 or an indication indicating the problematic RACH resources currently configured and associated cell identity.
Figure 11 shows an illustration of the method performed by the first network node in accordance with one embodiment of the present disclosure. In this example, the first network node is the gNB-DU 902. Note that steps 1100 through 1108 of Figure 11 correspond to steps 1000-1008 of Figure 10. As illustrated, the gNB-DU 902 receives a 2-step RACH msgA from at least one wireless communication device 812 for a controlled cell (step 1100) and detects a 2-step RACH configuration conflict (step 1102). Optionally, the gNB-DU 900 determines a new or updated 2-step RACH configuration for the cell that resolves the conflict (step 1104) and changes the 2-step RACH configuration in the cell accordingly (step 1106). The gNB-DU 900 sends a 2-step RACH optimization message (also referred to herein as a 2-step RACH assistance message) to the gNB-CU 900 (step 1108).
Embodiments related to the detection of a 2-step RACH configuration conflict are disclosed below in the Section entitled "Detection of 2-step RACH Configuration Conflict at gNB-DU". Embodiments are also disclosed in the Section entitled "gNB-DU Embodiment with RACH Conflict Resolution at gNB-DU" that are related to the determination of a new pool of 2-step RACH resources resolving the 2-step RACH configuration conflict, which can be done either independently by the first network node (see Section entitled "Resolution of RACH Conflict at gNB-DU without Assistance from gNB-CU") or with receiving assistance information from a second network node (e.g., a gNB-CU, see Section entitled "Resolution of RACH Conflict at gNB-DU with Assistance from gNB-CU").
I(A ) Detection of 2-step RA CH Configuration Conflict at gNB-DU
In one embodiment, in step 1002 of Figure 10 or step 1102 of Figure 11, the first network node detects a potential 2-step RACFI configuration conflict between the controlled cell and a neighboring cell based on statics associated to the reception of one or more 2-step RACFI msgAs from at least one wireless communication device 812. In particular, the first network node, upon receiving a 2-step RACFI msgA from at least one wireless communication device 812, may detect a 2-step RACFI configuration conflict by executing a method comprising the steps of:
• Correctly decoding the msgA preamble; and
• Not being able to decode the msgA payload.
This sequence of events may occur since, in case of a 2-step RACFI configuration conflict, the wireless communication device 812may have transmitted the 2-step RACFI msgA preamble using preamble resources shared by neighboring cells. Therefore, both cells sharing the conflicting RACFI resources would be able to decode the msgA preamble. Flowever, the msgA payload is scrambled with the physical cell identity (PCI) that the wireless communication device 812has decided to access. Thereby, if the wireless communication device 812has scrambled the msgA payload with a PCI different from the PCI of the cell controlled by the first network node, the first network node will not be able to decode the msgA payload.
Figure 12 illustrates an example of 2-step RACFI configuration conflict detection, wherein the first network node is represented by a gNB-DU 902. In particular, Figure 12 illustrates an example of how the first network node (i.e., gNB-DU 902 in this example) can detect a 2-step RACFI configuration conflict between neighboring cells. In this example, a wireless communication device 812 is trying to access a cell controlled by gNB-DU-2 (e.g., gNB-DU 902-2) and scrambles the msgA payload with the PCI of the associated cell (i.e., PCI-2). Since the msgA preamble is common to both cells, the msgA is received also by the gNB-DU-1 (e.g., gNB-DU 902-1) (step 1200) which can decode the preamble (step 1202) but not the msgA payload (step 1204). Therefore, gNB-DU-1 can infer a possible 2-step RACH configuration conflict for its controlled cell (identified by PCI-1).
The first network node may thereby collect statistical information associated to random access events using a 2-step RACH procedure wherein the first network node can receive a 2-step RACH msgA from a wireless communication device 812, can decode the msgA preamble, but cannot decode the msgA payload. For instance, the first network node may collect statistics of the occurrence of such events over a time (e.g., over one or more predefined time windows, which may be repeated periodically), such as maximum and/or minimum number of occurrences, the average and/or standard deviation and/or variance of the number of occurrences indicating a potential 2-step RACH configuration conflict. In one example, the first network node determines a 2-step RACH configuration conflict for a controlled cell if one or more statistical information associated to the 2-step RACH procedure for said cell exceed a threshold value. For instance, the first network node determines a 2-step RACH conflict if one or more of the following cases occurs:
• The maximum number of undecodable msgA payloads in the cell exceeds a threshold
• The minimum number of undecodable msgA payloads in the cell exceeds a threshold
• The average number of undecodable msgA payloads in the cell exceeds a threshold
• The standard deviation of the number of undecodable msgA payloads in the cell exceeds a threshold
• The variance of the number of undecodable msgA payloads in the cell exceeds a threshold
1(B) gNB-DU embodiment with RA CH conflict resolution at gNB- DU
I(B)(i) Resolution of RACH conflict at gNB-DU without assistance from gNB-CU
According to the method illustrated in Figures 10 and 11, upon detecting a potential 2-step RACH resource configuration conflict for a controlled cell, the first network node (e.g., a gNB-DU 902) is enabled to determine a new pool of resources for 2-step RACH procedure to resolve the detected conflict for the controlled cell. In one embodiment, the first network node determines a 2-step RACH resource configuration for the controlled cell to resolve the conflict comprising a set of RACH resources that is:
• orthogonal or non-overlapping with the set of 2-step RACH resources conflicting with a neighboring cell, or
• non-orthogonal or partly overlapping with the set of 2-step RACH resources conflicting with a neighboring cell.
In another embodiment, the first network node determines a new pool of resources for 2-step RACH procedure of the controlled cell to resolve the detected conflict based on the utilization of 2-step RACH resources and 4-step RACH resources within the controlled cell. For instance, the first network node may determine a new set of resources for 2-step RACH based on the number of users (i.e., wireless communication devices 812) using 2-step RACH and 4-step RACH.
In another embodiment, the first network node may swap the RACH resources assigned to different bandwidth parts (BWPs). In this approach, if the initial BWP uses a different RACH resources compared to the BWP that is used for enhanced Mobile Broadband (eMBB), and a RACH configuration conflict has been detected between RACH resources of initial BWP of one of the controlled cell and a neighboring cell, the first network node may swap the RACH resources of initial BWP and the RACH resources of the BWP used for eMBB purpose.
In yet another embodiment, the first network node may swap the conflicting RACH resources with RACH resources of another controlled cell operating in another frequency.
I(B)(ii) Resolution of RACH conflict at gNB-DU with assistance from gNB-CU
In one embodiment of the method illustrated in Figure 13, the first network node (e.g., the gNB-DU 902), upon detecting a 2-step RACH configuration conflict for a controlled cell, may request assistance information from the second network node (e.g., the gNB-CU 900) to resolve the conflict. Therefore, the method executed by the first network node may further comprise:
• Step 1300: The first network node transmits a 2-step RACH conflict assistance information request to the second network node; and • Step 1302: The first network node receives a 2-step RACH conflict assistance information response from the second network node;
• wherein determining the new/updated 2-step RACH resource configuration for the controlled cell in step 1104 is further based on based on the 2-step RACH conflict resolution assistance information response.
The 2-step RACH conflict assistance information request may comprise information associated to the detection of 2-step RACH configuration conflict for a controlled cell, such as, one or more information elements in the group of:
• a flag indication a 2-step RACH configuration conflict,
• an identifier for at least a controlled cell for which the first network node detected a 2-step RACH configuration conflict, such as a physical cell identity, or an RNTI, etc.
• information associated to the 2-step RACH conflict detection, such as o statistical information associated to successful detection of 2-step RACH msgA preambles transmitted by user devices within the coverage area of the controlled cell; o statistical information associated to the failed decoding of 2-step RACH msgA payload transmitted by user devices within the coverage area of the controlled cell; o statistical information on access delay probability for the given RACH resources; o an indication of the 2-step RACH resources where a conflict was detected, such as
■ the 2-step RACH preamble used in unsuccessful decoding of 2- step RACH msgA payload decoding;
■ the time-frequency resources used in unsuccessful decoding of 2-step RACH msgA payload decoding.
The 2-step RACH conflict assistance information response may comprise one or more information elements in the group of:
• an acknowledgement of the occurrence of a 2-step RACH configuration conflict; • an indication of the 2-step RACH resource configuration of a neighboring cell which caused the 2-step RACH configuration conflict with the cell controlled by the first network node;
• an indication of recommended resources that the first network node can configure for 2-step RACH procedure in the controlled cell to resolve the 2- step-RACh configuration conflict.
The recommended resources may include a list of time/frequency and preamble resources (e.g., root sequence index) as well as PUSCH resources that can be configured for payload part of msgA.
In yet another embodiment, the first network node (e.g., the gNB-DU 902) may receive a list of RACH resources from operation and management (OAM) system and may use the suggested list of 2-step RACH resources from OAM to resolve the RACH configuration conflict.
Upon resolving 2-step RACH configuration conflict (i.e., selecting and configuration of new RACH resources), the first network node sends new configured 2- step RACH resources to the second network node indicating the resolution of 2-step RACH configuration conflict.
1(C) gNB-DU Embodiment with RA CH Conflict Resolution at gNB-CU
In one embodiment of the method illustrated in Figure 14, the 2-step RACH conflict assistance information request may further comprise a request for the second network node (i.e., the gNB-CU 900) to resolve the 2-step RACH configuration conflict indicated by the first network node (i.e., the gNB-DU 902) (step 1400). The second network node then resolves the 2-step RACH configuration conflict for the cell (step 1402).
Additionally, the 2-step RACH conflict assistance information response message received by the first network node may comprise a new or an updated 2-step RACH configuration for the at least one cell controlled by the first network node for which the first network node has detected a 2-step RACH configuration conflict (step 1404). Therefore, in step 1106, the first network node may configure the controlled cell with the new or updated 2-step RACH configuration indicted by the second network node. Additionally, the first network node may indicate/acknowledge to the second network that the controlled cell has been reconfigured with the indicated 2-step RACH configuration, for instance using the 2-step RACH optimization message in step 1108.
II. Method and embodiments for gNB-CU
II(A ) gNB-CU 2-step RA CH assistance information
Embodiments of a method executed by a second network node (i.e., a gNB-CU 900) are also disclosed. As illustrated in Figure 15, in one embodiment, the method executed by the second node comprises:
• Step 1500: The second network node receives a 2-step RACH conflict assistance information request from a first network node (i.e., a gNB-DU 902).
• Step 1502: The second network node determines assistance information associated to the 2-step RACH procedure for at least one radio cell controlled by the first network node based on the 2-step RACH conflict assistance information request. As discussed above, in one embodiment, this assistance information includes information that is used by the first network node to resolve the 2-step RACH configuration conflict (see, e.g., the discussion related to Figure 13 above). In another embodiment, the second network node resolves the 2-step RACH configuration conflict, and the assistance information includes, e.g., an updated 2-step RACH configuration for the cell (see, e.g., the discussion related to Figure 14 above). The resolving of the conflict may include exchanging information with neighbor cells or just leveraging information already available at the second network node.
• Step 1504: The second network node transmits a 2-step RACH conflict assistance information response to the first network node comprising the 2- step RACH assistance information.
In one realization of the embodiment, upon receiving the 2-step RACH conflict assistance information request from the first network node indicating a potential 2-step RACH configuration conflict for a radio cell controlled by the first network node, the second network node can verify whether a 2-step RACH configuration conflict occurs/exists with neighboring cells controlled by another second network node (e.g., neighboring cells controlled by another gNB). This can be done by exchanging RACH configuration information between among one or more second nodes (i.e., among gNBs).
In one embodiment, the second network node may further determine or more types of 2-step RACH assistance information in the group of:
• a positive acknowledgment of indicating the occurrence/existence of a 2-step RACH configuration conflict for the radio cell indicated by the first network node or a negative acknowledgment (NACK) indicating a misdetection of a 2- step RACH configuration conflict for the radio cell indicated by the first network node;
• one or more RACH resource configurations associated to neighboring cells that could cause the 2-step RACH configuration conflict with the radio cell controlled by the first network node;
• a new/updated 2-step RACH resource configuration for the cell controlled by the first network node that resolves the conflict;
• a recommended/preferred set of RACH resources that the first network node can use to resolve the detected 2-step RACH conflict. For instance, a set of RACH preambles, a set of time frequency resources, etc.;
• an instruction to use 4-step RACH resources available at the first network node to resolve the 2-step RACH resource configuration conflict;
• an instruction to use 2-step RACH resources available at the first network node to resolve the 2-step RACH resource configuration conflict.
This can be done with information available exclusively at the second network node, such as the RACH configuration of neighboring radio cells controlled by other second network nodes and/or with information received from the first network node as part of the 2-step RACH conflict assistance information REQUEST signal.
In one embodiment, as illustrated in Figure 16, a method executed by a second network node (i.e., a gNB-CU 900) may comprise:
• Step 1600: The second network node receives from a first network node (e.g., a gNB-DU) a 2-step RACH optimization message comprising a new/updated 2-step RACH resource configuration for a radio cell controlled by the first network node (see, e.g., step 1108); and • Step 1602: The second network node transmits a RACH configuration update message to another second network node (i.e., a neighboring gNB-CU) comprising the new/updated 2-step RACH resource configuration.
Therefore, in a 3GPP NR system, upon receiving a 2-step RACH configuration update from a gNB-DU 902, the gNB-CU 900 could forward the updated configuration to a neighboring gNB-CU which may have had a controlled radio cells using RACH resources overlapping (hence conflicting) with the radio cell owned by the gNB-DU.
III. Additional Description
Figure 17 is a schematic block diagram of a radio access node 1700 according to some embodiments of the present disclosure. Optional features are represented by dashed boxes. The radio access node 1700 may be, for example, a base station 802 or 806 or a network node that implements all or part of the functionality of the base station 802 or gNB described herein (e.g., a network node that implements a DU such as, e.g., a gNB-DU 902 or a CU such as, e.g., a gNB-CU 900, as described herein). As illustrated, the radio access node 1700 includes a control system 1702 that includes one or more processors 1704 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory 1706, and a network interface 1708. The one or more processors 1704 are also referred to herein as processing circuitry. In addition, the radio access node 1700 may include one or more radio units 1710 that each includes one or more transmitters 1712 and one or more receivers 1714 coupled to one or more antennas 1716. This is particularly the case in embodiments in which the radio access node 1700 is a network node that implements a DU such as, e.g., a gNB-DU 902. The radio units 1710 may be referred to or be part of radio interface circuitry. In some embodiments, the radio unit(s) 1710 is external to the control system 1702 and connected to the control system 1702 via, e.g., a wired connection (e.g., an optical cable). However, in some other embodiments, the radio unit(s) 1710 and potentially the antenna(s) 1716 are integrated together with the control system 1702. The one or more processors 1704 operate to provide one or more functions of a radio access node 1700 as described herein (e.g., one or more functions of a DU such as, e.g., a gNB-DU 902 or one or more functions of a CU such as, e.g., a gNB-CU 900, as described herein). In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 1706 and executed by the one or more processors 1704.
Figure 18 is a schematic block diagram that illustrates a virtualized embodiment of the radio access node 1700 according to some embodiments of the present disclosure. This discussion is equally applicable to other types of network nodes. Further, other types of network nodes may have similar virtualized architectures. Again, optional features are represented by dashed boxes.
As used herein, a "virtualized" radio access node is an implementation of the radio access node 1700 in which at least a portion of the functionality of the radio access node 1700 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the radio access node 1700 may include the control system 1702 and/or the one or more radio units 1710, as described above. The control system 1702 may be connected to the radio unit(s) 1710 via, for example, an optical cable or the like. The radio access node 1700 includes one or more processing nodes 1800 coupled to or included as part of a network(s) 1802. If present, the control system 1702 or the radio unit(s) are connected to the processing node(s) 1800 via the network 1802. Each processing node 1800 includes one or more processors 1804 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 1806, and a network interface 1808.
In this example, functions 1810 of the radio access node 1700 described herein (e.g., one or more functions of a DU such as, e.g., a gNB-DU 902 or one or more functions of a CU such as, e.g., a gNB-CU 900, as described herein) are implemented at the one or more processing nodes 1800 or distributed across the one or more processing nodes 1800 and the control system 1702 and/or the radio unit(s) 1710 in any desired manner. In some particular embodiments, some or all of the functions 1810 of the radio access node 1700 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 1800. As will be appreciated by one of ordinary skill in the art, additional signaling or communication between the processing node(s) 1800 and the control system 1702 is used in order to carry out at least some of the desired functions 1810. Notably, in some embodiments, the control system 1702 may not be included, in which case the radio unit(s) 1710 communicate directly with the processing node(s) 1800 via an appropriate network interface(s). In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of radio access node 1700 or a node (e.g., a processing node 1800) implementing one or more of the functions 1810 of the radio access node 1700 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).
Figure 19 is a schematic block diagram of the radio access node 1700 according to some other embodiments of the present disclosure. The radio access node 1700 includes one or more modules 1900, each of which is implemented in software. The module(s) 1900 provide the functionality of the radio access node 1700 described herein (e.g., one or more functions of a DU such as, e.g., a gNB-DU 902 or one or more functions of a CU such as, e.g., a gNB-CU 900, as described herein). This discussion is equally applicable to the processing node 1800 of Figure 18 where the modules 1900 may be implemented at one of the processing nodes 1800 or distributed across multiple processing nodes 1800 and/or distributed across the processing node(s) 1800 and the control system 1702.
Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processor (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the present disclosure.
While processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).
Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein.

Claims

Claims
1. A method performed by a first network node, the method comprising: receiving (1000; 1100) a 2-step Random Access Channel, RACH, msgA from at least one wireless communication device (812) in a cell controlled by the first network node; determining (1002; 1102) that there is a potential or actual 2-step RACH configuration conflict for the cell; and performing one or more actions responsive to determining (1002; 1102) that there is a 2-step RACH configuration conflict for the cell.
2. The method of claim 1 wherein performing the one or more actions comprises transmitting (1008; 1108), to a second network node, a 2-step RACH assistance message.
3. The method of claim 2 wherein the 2-step RACH assistance message comprises: (a) an indication of the potential or actual 2-step RACH configuration conflict, (b) an indication that the first network node is asking for RACH assistance information, (c) information that informs the second network node of a new or updated RACH configuration for the cell, or (d) any combination of two or more of (a)-(c).
4. The method of claim 2 or 3 wherein the 2-step RACH assistance message comprises an indication of one or more RACH resources for which there is a conflict.
5. The method of any one of claims 2 to 4 wherein the 2-step RACH assistance message comprises a cell identity of the cell for which the first network node detected a potential or actual 2-step RACH configuration conflict.
6. The method of any one of claims 1 to 5 wherein performing the one or more actions comprises determining (1004; 1104) a new or updated RACH configuration for the cell that resolves the potential or actual 2-step RACH configuration conflict.
7. The method of claim 6 wherein performing the one or more actions further comprises configuring (1006; 1106) the cell with the new or updated RACH configuration.
8. The method of claim 6 or 7 wherein the new or updated RACH configuration is a 2-step RACH resource configuration for the cell that resolves the potential or actual 2- step RACH configuration conflict.
9. The method of claim 8 wherein the 2-step RACH resource configuration comprises a configuration of a set of RACH resources that is: orthogonal or non-overlapping with a set of 2-step RACH resources for which the potential or actual 2-step RACH configuration conflict was determined; or non-orthogonal or partly overlapping with the set of 2-step RACH resources for which the potential or actual 2-step RACH configuration conflict was determined.
10. The method of claim 6 or 7 wherein the new or updated RACH configuration comprises a new pool of resources for 2-step RACH in the cell that resolves the potential or actual 2-step RACH configuration conflict based on utilization of 2-step RACH resources and 4-step RACH resources within the cell.
11. The method of claim 6 or 7 wherein determining (1004; 1104) the new or updated RACH configuration for the cell that resolves the potential or actual 2-step RACH configuration conflict comprises swapping RACH resources assigned to different bandwidth parts.
12. The method of claim 6 or 7 wherein determining (1004; 1104) the new or updated RACH configuration for the cell that resolves the potential or actual 2-step RACH configuration conflict comprises swapping the conflicting RACH resources with RACH resources of another cell controlled by the first network node.
13. The method of claim 6 or 7 wherein performing the one or more actions further comprises: sending (1300), to the second network node, a request for 2-step RACH conflict assistance information; and receiving (1302), from the second network node, 2-step RACH conflict assistance information; wherein determining (1004; 1104) the new or updated RACH configuration for the cell that resolves the potential or actual 2-step RACH configuration conflict comprises determining (1004; 1104) the new or updated RACH configuration for the cell that resolves the conflict based on the 2-step RACH conflict assistance information.
14. The method of claim 13 wherein the request for 2-step RACH conflict assistance information comprises: a) an indication of the potential or actual 2-step RACH configuration 2-step conflict; b) an identifier for at least the cell for which the first network node determined the potential or actual 2-step RACH configuration conflict; c) information associated to the determining the potential or actual 2-step RACH configuration; d) an indication of 2-step RACH resources where the potential or actual 2-step RACH configuration conflict was determined; or e) any combination of two or more of (a) - (d).
15. The method of claim 13 or 14 wherein the 2-step RACH conflict assistance information comprises: i. an acknowledgement of the occurrence of an actual or potential 2-step RACH configuration conflict; ii. an indication of a 2-step RACH resource configuration of a neighboring cell which caused the potential or actual 2-step RACH configuration conflict with the cell; iii. an indication of recommended resources that the first network node can configure for 2-step RACH in the cell to resolve the potential or actual 2-step RACH configuration conflict; or iv. any two or more of (i) - (iii).
16. The method of claim 6 or 7 wherein performing the one or more actions further comprises: receiving a list of RACH resources from another node, the list of RACH resources being suggested RACH resources to resolve the potential or actual 2-step RACH configuration conflict; wherein determining (1004; 1104) the new or updated RACH configuration for the cell that resolves the potential or actual 2-step RACH configuration conflict comprises determining (1004; 1104) the new or updated RACH configuration for the cell that resolves the potential or actual 2-step RACH configuration conflict based on the received list of RACH resources.
17. The method of any of claims 6 to 16 wherein performing the one or more actions further comprises sending the 2-step RACH optimization message to the second network node, the 2-step RACH optimization message comprising the new or updated RACH configuration for the cell.
18. The method of any one of claims 1 to 5 wherein performing the one or more actions comprises: sending (1400), to the second network node, a request for 2-step RACH conflict assistance information; and receiving (1404), from the second network node, 2-step RACH conflict assistance information, the 2-step RACH conflict assistance information comprises a new or updated RACH configuration for at least the cell for which the potential or actual 2-step RACH configuration conflict was determined.
19. The method of claim 18 wherein performing the one or more actions further comprise configuring the cell with the new or updated RACH configuration.
20. The method of any one of claims 1 to 19 wherein determining (1002; 1102) that there is a potential or actual 2-step RACH configuration conflict for the cell comprises: determining (1202) that the first network node can correctly decode a RACH preamble of the 2-step RACH msgA; and determining (1204) that the first network node cannot correctly decode a payload of the 2-step RACH msgA.
21. The method of any one of claims 1 to 19 wherein determining (1002; 1102) that there is a potential or actual 2-step RACH configuration conflict for the cell comprises: obtaining statistical information associated with random access events that use a 2-step RACH procedure in which the first network node receives a 2-step RACH msgA from a wireless communication device, can decode a preamble of the msgA, but cannot decode a payload of the msgA; and determining that there is a potential or actual 2-step RACH configuration conflict for the cell based on the obtained statistical information and one or more predefined or preconfigured thresholds.
22. The method of any of claims 1 to 21 wherein the first network node is a Distributed Unit, DU, (902) of a base station (802) having a split Central Unit, CU, / DU architecture, and the second network node is a CU (900) of the base station (802).
23. A first network node adapted to: receive (1000; 1100) a 2-step Random Access Channel, RACH, msgA from at least one wireless communication device (812) in a cell controlled by the first network node; determine (1002; 1102) that there is a potential or actual 2-step RACH configuration conflict for the cell; and perform one or more actions responsive to determining (1002; 1102) that there is a 2-step RACH configuration conflict for the cell.
24. The first network node of claim 23 wherein the first network node is further adapted to perform the method of any one of claims 2 to 22.
25. A first network node (902; 1700) comprising processing circuitry (1704; 1804) configured to cause the first network node to: receive (1000; 1100) a 2-step Random Access Channel, RACH, msgA from at least one wireless communication device (812) in a cell controlled by the first network node; determine (1002; 1102) that there is a potential or actual 2-step RACH configuration conflict for the cell; and perform one or more actions responsive to determining (1002; 1102) that there is a 2-step RACH configuration conflict for the cell.
26. A method performed by a second network node, the method comprising: receiving (1500), from a first network node, a request for 2-step Random Access
Channel, RACH, conflict assistance information; determining (1502) the 2-step RACH conflict assistance information; and transmitting (1504) the 2-step RACH conflict assistance information to the first network node.
27. The method of claim 26 wherein the request comprises: a) an indication of a 2-step RACH configuration conflict detected by the first network node; b) an identifier for at least a cell for which the first network node detected the 2- step RACH configuration conflict; c) information associated to detection of the 2-step RACH conflict ; d) an indication of 2-step RACH resources where the 2-step RACH configuration conflict was detected; or e) any combination of two or more of (a) - (d).
28. The method of claim 27 wherein the 2-step RACH conflict assistance information comprises: i. an acknowledgement of the occurrence of a 2-step RACH configuration conflict; ii. an indication of a 2-step RACH resource configuration of a neighboring cell which caused the detected 2-step RACH configuration conflict with the cell; iii. an indication of recommended resources that the first network node can configure for 2-step RACH procedure in the cell to resolve the 2-step-RACH configuration conflict; or iv. any two or more of (i) - (iii).
29. The method of any of claims 26 to 28 wherein: determining (1502) the 2-step RACH conflict assistance information comprises determining (1402) a new or updated RACH configuration for at least a cell for which a conflict is detected, the new or updated RACH configuration being a RACH configuration that resolves the conflict; wherein the 2-step RACH conflict assistance information comprises the new or updated RACH configuration that resolves the conflict.
30. The method of any of claims 26 to 29 wherein the first network node is a Distributed Unit, DU, (902) of a base station (802) having a split Central Unit, CU, / DU architecture, and the second network node is a CU (900) of the base station (802).
31. A second network node adapted to: receive (1500), from a first network node, a request for 2-step Random Access Channel, RACH, conflict assistance information; determine (1502) the 2-step RACH conflict assistance information; and transmit (1504) the 2-step RACH conflict assistance information to the first network node.
32. The second network node of claim 31 wherein the second network node is further adapted to perform the method of any one of claims 27 to 30.
33. A second network node (900; 1700) comprising processing circuitry (1704; 1804) configured to cause the second network node to: receive (1500), from a first network node, a request for 2-step Random Access Channel, RACH, conflict assistance information; determine (1502) the 2-step RACH conflict assistance information; and transmit (1504) the 2-step RACH conflict assistance information to the first network node.
PCT/SE2021/050386 2020-04-30 2021-04-28 Detecting and resolving 2-step rach configuration conflicts WO2021221551A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202063017979P 2020-04-30 2020-04-30
US63/017,979 2020-04-30

Publications (1)

Publication Number Publication Date
WO2021221551A1 true WO2021221551A1 (en) 2021-11-04

Family

ID=75787197

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2021/050386 WO2021221551A1 (en) 2020-04-30 2021-04-28 Detecting and resolving 2-step rach configuration conflicts

Country Status (1)

Country Link
WO (1) WO2021221551A1 (en)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230044375A1 (en) * 2021-08-04 2023-02-09 Qualcomm Incorporated Base station resource selection for two step random access procedure
WO2024098573A1 (en) * 2023-02-16 2024-05-16 Zte Corporation Systems, methods, and non-transitory processor-readable media for transmission during random access procedure

Non-Patent Citations (8)

* Cited by examiner, † Cited by third party
Title
3GPP TS 36.331
3GPP TS 38.321
3GPP TS 38.331
CATT: "Summary of offline discussion on PRACH configuration conflict detection", vol. RAN WG1, no. RENO, NEVADA, USA; 20191118 - 20191122, 25 November 2019 (2019-11-25), XP051830627, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_ran/WG1_RL1/TSGR1_99/Docs/R1-1913345.zip R1-1913345 Summary of offline discussion on PRACH configuration conflict detection.docx> [retrieved on 20191125] *
ERICSSON: "Solution for RACH Conflict Detection and Resolution at gNB-DU", vol. RAN WG3, no. Online; 20200420 - 20200430, 9 April 2020 (2020-04-09), XP051870678, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_ran/WG3_Iu/TSGR3_107bis_e/Docs/R3-202266.zip R3-202266 TP on RACH Conflict resolution on F1 Interface.docx> [retrieved on 20200409] *
ERICSSON: "Solution for RACH Optimization in NG-RAN", vol. RAN WG3, no. Ljubljana, SI; 20190826 - 20190830, 17 August 2019 (2019-08-17), XP051770484, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg_ran/WG3_Iu/TSGR3_105/Docs/R3-194292.zip> [retrieved on 20190817] *
NOKIA ET AL: "Discussion on PRACH Configuration Conflict Resolution based on CB#30 at RAN3#107-e", vol. RAN WG3, no. Online Meeting ;20200420 - 20200430, 9 April 2020 (2020-04-09), XP051873799, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_ran/WG3_Iu/TSGR3_107bis_e/Docs/R3-201840.zip R3-201840 RACH Conflict Resolution discussion.docx> [retrieved on 20200409] *
QUALCOMM INCORPORATED: "RACH configuration conflict detection and resolution", vol. RAN WG3, no. Online Meeting ;20200420 - 20200430, 10 April 2020 (2020-04-10), XP051873766, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_ran/WG3_Iu/TSGR3_107bis_e/Docs/R3-201793.zip R3-201793 - RACH Configuration Conflict Detection and resolution function.doc> [retrieved on 20200410] *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230044375A1 (en) * 2021-08-04 2023-02-09 Qualcomm Incorporated Base station resource selection for two step random access procedure
US11889507B2 (en) * 2021-08-04 2024-01-30 Qualcomm Incorporated Base station resource selection for two step random access procedure
WO2024098573A1 (en) * 2023-02-16 2024-05-16 Zte Corporation Systems, methods, and non-transitory processor-readable media for transmission during random access procedure

Similar Documents

Publication Publication Date Title
US12010735B2 (en) Rach-report indicating rat or node in a dual-connectivity / multi-rat configuration
US20230379769A1 (en) Methods for mobility related handover in nr
US20220240326A1 (en) Recovery/fallback after unsuccessful 2-step random access attempt
JP6740130B2 (en) Communication device and method
US20190141592A1 (en) Beam-Based Connection Failure Report
KR20240038945A (en) METHOD AND APPARATUS FOR UE SIGNAL TRANSMISSION for 5G CELLULAR COMMUNICATIONS
KR102648865B1 (en) METHOD AND APPARATUS FOR UE SIGNAL TRANSMISSION for 5G CELLULAR COMMUNICATIONS
US20220132578A1 (en) RACH Report with Beam Selection Information
JP2020528711A (en) How to perform a random access procedure and its equipment
KR20210010842A (en) Method and apparatus for performing random access backoff in wireless communication system
CN111567133B (en) User equipment, network node and method for handling communication in a wireless communication network
US11818769B2 (en) First network node, second network node and methods performed thereby for handling a random access channel configuration conflict
KR20150109119A (en) Method and appratus of performing cell selection and random access of machine-type communication user equipment in mobile communication system
EP3020231B1 (en) Improved session setup in an energy-efficient cellular wireless telecommunications system
CN110800338A (en) Wireless communication device and method for network control beam based handover in NR
JP7221976B2 (en) User equipment and base station involved in improved prioritized random access
US20210352736A1 (en) Network access method and apparatus
US20230164582A1 (en) Beam Sweep Order Change due to RACH
US20220272770A1 (en) First Network Node, Second Network Node and Methods Performed Thereby for Handling a RACH Configuration
WO2021221551A1 (en) Detecting and resolving 2-step rach configuration conflicts
WO2021090261A1 (en) Two-step rach transmissions using guard band in unlicensed spectrum
JP2019525668A (en) Random access procedure supporting NB-IoT
WO2021183023A1 (en) Systems and methods for reporting of information related to requesting or reception of on-demand system information
EP2836009A1 (en) Synchronising radio configuration parameters
WO2022084943A1 (en) Inclusion of preamble group information in the ra-report

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: 21723449

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21723449

Country of ref document: EP

Kind code of ref document: A1