Patent Description:
Wireless communication systems, as are for example described in <CIT>, <NPL>, and <NPL>, are widely deployed to provide various telecommunication services such as telephony, video, data, messaging, and broadcasts.

In some examples, a wireless multiple-access communication system may include a number of base stations, each simultaneously supporting communication for multiple communication devices, otherwise known as user equipment (UEs). In LTE or LTE-A network, a set of one or more base stations may define an eNodeB (eNB). In other examples (e.g., in a next generation or <NUM> network), a wireless multiple access communication system may include a number of distributed units (DUs) (e.g., edge units (EUs), edge nodes (ENs), radio heads (RHs), smart radio heads (SRHs), transmission reception points (TRPs), etc.) in communication with a number of central units (CUs) (e.g., central nodes (CNs), access node controllers (ANCs), etc.), where a set of one or more distributed units, in communication with a central unit, may define an access node (e.g., a new radio base station (NR BS), a new radio node-B (NR NB), a network node, <NUM> NB, eNB, etc.). A base station or DU may communicate with a set of UEs on downlink channels (e.g., for transmissions from a base station or to a UE) and uplink channels (e.g., for transmissions from a UE to a base station or distributed unit).

Wording such as "may" and "for example" used in the description in conjunction with features of the independent claims should not be interpreted to mean that those features are merely optional.

Aspects of the present disclosure provide apparatus, methods, systems, and computer readable mediums for new radio (NR) (new radio access technology or <NUM> technology).

NR may support various wireless communication services, such as Enhanced mobile broadband (eMBB) targeting wide bandwidth (e.g. <NUM> beyond), millimeter wave (mmW) targeting high carrier frequency (e.g. <NUM>), massive MTC (mMTC) targeting non-backward compatible MTC techniques, and/or mission critical targeting ultra-reliable low latency communications (URLLC).

In conventional systems (e.g., LTE), nodes typically have fixed length identifiers typically use identifiers that have a fixed length. As a reference example, the eNB identifier length in LTE is generally fixed to <NUM> bits (e.g., the first <NUM> bits of the cell identity). In some cases, fixing the eNB identifier length to <NUM> bits may allow for up to a million eNBs to be deployed in a network and each eNB may be able to support up to <NUM> cells. However, as the demand for networks to support both larger nodes (hosting more cells) as well as larger numbers of nodes continues to increase, certain deployments (e.g., with large number of nodes) may not be possible with fixed length node identifiers.

Accordingly, aspects of the present disclosure provide methods and apparatus for supporting variable and reconfigurable radio access network (RAN) node identifier lengths (e.g., for flexible deployment of cells) in a network.

In one aspect, a (first) base station (e.g., eNB, gNB, etc.) may determine a cell identity of a cell associated with another (second) base station in a network. The base station may determine, from the cell identity, an identifier of the second base station based on a partitioning of an identifier space used for identifying cells in the network. The base station may transmit a message that includes at least one of the identifier of the other base station or the cell identity associated with the other base station.

<FIG> illustrates an example wireless network <NUM>, such as a new radio (NR) or <NUM> network, in which aspects of the present disclosure may be performed, for example, for enabling flexible deployment of cells in a network, as described in greater detail below.

As illustrated in <FIG>, the wireless network <NUM> may include a number of BSs <NUM> and other network entities. A BS may be a station that communicates with UEs. Each BS <NUM> may provide communication coverage for a particular geographic area. In 3GPP, the term "cell" can refer to a coverage area of a Node B and/or a Node B subsystem serving this coverage area, depending on the context in which the term is used. In NR systems, the term "cell" and evolved NB (eNB), Node B (NB), <NUM> NB, Next Generation NB (gNB), access point (AP), BS, NR BS, <NUM> BS, or transmission reception point (TRP) may be interchangeable. In some examples, a cell may not necessarily be stationary, and the geographic area of the cell may move according to the location of a mobile base station. In some examples, the base stations may be interconnected to one another and/or to one or more other base stations or network nodes (not shown) in the wireless network <NUM> through various types of backhaul interfaces such as a direct physical connection, a virtual network, or the like using any suitable transport network.

A network controller <NUM> may communicate with a set of BSs and provide coordination and control for these BSs. The BSs <NUM> may also communicate with one another, e.g., directly or indirectly via wireless or wireline backhaul.

A UE may also be referred to as a mobile station, a terminal, an access terminal, a subscriber unit, a station, a Customer Premises Equipment (CPE), a cellular phone, a smart phone, a personal digital assistant (PDA), a wireless modem, a wireless communication device, a handheld device, a laptop computer, a cordless phone, a wireless local loop (WLL) station, a tablet, a camera, a gaming device, a netbook, a smartbook, an ultra book, a medical device or medical equipment, a biometric sensor/device, a wearable device such as a smart watch, smart clothing, smart glasses, a smart wrist band, smart jewelry (e.g., a smart ring, a smart bracelet, etc.), an entertainment device (e.g., a music device, a video device, a satellite radio, etc.), a vehicular component or sensor, a smart meter/sensor, industrial manufacturing equipment, a global positioning system device, or any other suitable device that is configured to communicate via a wireless or wired medium. Some UEs may be considered evolved or machine-type communication (MTC) devices or evolved MTC (eMTC) devices. MTC and EMTC UEs include, for example, robots, drones, remote devices, sensors, meters, monitors, location tags, etc., that may communicate with a BS, another device (e.g., remote device), or some other entity. Some UEs may be considered Internet-of-Things (IoT) devices or narrowband IoT (NB-IoT) devices.

For example, the spacing of the subcarriers may be <NUM> and the minimum resource allocation (called a 'resource block' (RB)) may be <NUM> subcarriers (or <NUM>). Consequently, the nominal FFT size may be equal to <NUM>, <NUM>, <NUM>, <NUM> or <NUM> for system bandwidth of <NUM>, <NUM>, <NUM>, <NUM> or <NUM> megahertz (MHz), respectively. For example, a subband may cover <NUM> (i.e., <NUM> resource blocks), and there may be <NUM>, <NUM>, <NUM>, <NUM> or <NUM> subbands for system bandwidth of <NUM>, <NUM>, <NUM>, <NUM> or <NUM>, respectively.

NR may utilize OFDM with a CP on the uplink and downlink and include support for half-duplex operation using time division duplex (TDD).

In some examples, access to the air interface may be scheduled, where a scheduling entity (e.g., a BS) allocates resources for communication among some or all devices and equipment within its service area or cell. BSs are not the only entities that may function as a scheduling entity.

As noted above, a RAN may include a CU and DUs. A NR BS (e.g., eNB, <NUM> Node B, Node B, gNB, TRP, AP) may correspond to one or multiple BSs. NR cells can be configured as access cell (ACells) or data only cells (DCells). For example, the RAN (e.g., a CU or DU) can configure the cells. DCells may be cells used for carrier aggregation or dual connectivity, but not used for initial access, cell selection/reselection, or handover. In some cases DCells may not transmit synchronization signals-in some case cases DCells may transmit SS. NR BSs may transmit downlink signals to UEs indicating the cell type. Based on the cell type indication, the UE may communicate with the NR BS. For example, the UE may determine NR BSs to consider for cell selection, access, handover, and/or measurement based on the indicated cell type.

<FIG> illustrates an example logical architecture of a distributed RAN <NUM>, which may be implemented in the wireless communication system illustrated in <FIG>. The ANC may be a CU of the distributed RAN <NUM>. The backhaul interface to the next generation core network (NG-CN) <NUM> may terminate at the ANC <NUM>. The backhaul interface to neighboring next generation access nodes (NG-ANs) may terminate at the ANC <NUM>. The ANC <NUM> may include one or more TRPs <NUM> (which may also be referred to as cells, BSs, NR BSs, gNB, Node Bs, <NUM> NBs, APs, or some other term).

The TRPs <NUM> may be connected to a single ANC (e.g., ANC <NUM>) or more than one ANC (not illustrated). For example, for RAN sharing, radio as a service (RaaS), and service specific AND deployments, the TRPs <NUM> may be connected to more than one ANC. A TRP <NUM> may include one or more antenna ports. The TRPs <NUM> may be configured to individually (e.g., dynamic selection) or jointly (e.g., joint transmission) serve traffic to a UE.

The logical architecture of the distributed RAN <NUM> may support fronthauling solutions across different deployment types. The local architecture of the distributed RAN <NUM> may share features and/or components with LTE. NG-AN <NUM> may support dual connectivity with NR and may share a common fronthaul for LTE and NR. The logical architecture of the distributed RAN <NUM> may enable cooperation between and among TRPs <NUM>, for example, within a TRP and/or across TRPs via the ANC <NUM>.

Logical functions may be dynamically distributed in the logical architecture of the distributed RAN <NUM>. As will be described in more detail with reference to <FIG>, the Radio Resource Control (RRC) layer, Packet Data Convergence Protocol (PDCP) layer, Radio Link Control (RLC) layer, Medium Access Control (MAC) layer, and a Physical (PHY) layers may be adaptably placed at the DU (e.g., the TRP <NUM>) or CU (e.g., the ANC <NUM>).

C-RU <NUM> may host core network functions locally. C-RU <NUM> may have distributed deployment. C-RU <NUM> may be closer to the network edge.

The DU <NUM> may be located at edges of the network with radio frequency (RF) functionality.

<FIG> illustrates example components of the BS <NUM> and UE <NUM> illustrated in <FIG>, which may be used to implement aspects of the present disclosure. For example, antennas <NUM>, Tx/Rx <NUM>, processors <NUM>, <NUM>, <NUM>, and/or controller/processor <NUM> of the UE <NUM> and/or antennas <NUM>, processors <NUM>, <NUM>, <NUM>, and/or controller/processor <NUM> of the BS <NUM> may be used to perform the operations described herein and illustrated with reference to <FIG> and <FIG>.

At BS <NUM>, a transmit processor <NUM> may receive data from a data source <NUM> and control information from a controller/processor <NUM>. The control information may be for the physical broadcast channel (PBCH), physical control format indicator channel (PCFICH), physical hybrid ARQ indicator channel (PHICH), physical downlink control channel (PDCCH), group common PDCCH (GC PDCCH), etc. The data may be for the physical downlink shared Channel (PDSCH), etc. For example, according to certain aspects of the present disclosure the BS <NUM> can send a slot format indicator (SFI), slot aggregation level information, and/or downlink control information (DCI) in a downlink control region. The processor <NUM> may process (e.g., encode and symbol map) the data and control information to obtain data symbols and control symbols, respectively. The processor <NUM> may also generate reference symbols, such as primary synchronization signal (PSS), secondary synchronization signal (SSS), and cell-specific reference signal (CRS).

At UE <NUM>, the antennas 452a through 452r may receive the downlink signals from BS <NUM> and may provide received signals to the demodulators (DEMODs) 454a through 454r, respectively. For example, according to certain aspects of the present disclosure the UE <NUM> can receive a slot format indicator (SFI), slot aggregation level information, and/or downlink control information (DCI) from the BS <NUM> in a downlink control region.

On the uplink, at UE <NUM>, a transmit processor <NUM> may receive and process data (e.g., for the physical uplink shared channel (PUSCH)) from a data source <NUM> and control information (e.g., for the physical uplink control channel (PUCCII)) from the controller/processor <NUM>. The symbols from the transmit processor <NUM> may be preceded by a TX MIMO processor <NUM> if applicable, further processed by the demodulators 454a through 454r (e.g., for SC-FDM, etc.), and transmitted to BS <NUM>.

The controllers/processors <NUM> and <NUM> may direct the operation at BS <NUM> and UE <NUM>, respectively. The processor <NUM> and/or other processors and modules at the base station <NUM> may perform or direct, e.g., the execution of the functional blocks illustrated in <FIG>, operations illustrated in <FIG>, and/or other processes for the techniques described herein. The processor <NUM> and/or other processors and modules at the UE <NUM> may perform or direct, e.g., the execution of the functional blocks illustrated in <FIG>, operations illustrated in <FIG>, and/or other processes for the techniques described herein.

Diagram <NUM> illustrates a communications protocol stack including a RRC layer <NUM>, a PDCP layer <NUM>, a RLC layer <NUM>, a MAC layer <NUM>, and a PHY layer <NUM>. Layers of the protocol stack may be implemented as separate modules of software, portions of a processor or ASIC, portions of non-collocated devices connected by a communications link, or various combinations thereof.

A subframe contains a variable number of slots (e.g., <NUM>, <NUM>, <NUM>, <NUM>, 7_6,.

A mini-slot is a subslot structure (e.g., <NUM>, <NUM>, or <NUM> symbols).

Real-world applications of such sidelink communications may include public safety, proximity services, UE-to-network relaying, vehicle-to-vehicle (V2V) communications, Internet-of-Everything (IoE) communications, loT communications, mission-critical mesh, and/or various other suitable applications.

As noted, in certain networks (e.g., LTE), RAN node (e.g., eNB) identifiers are generally defined with a single fixed length. For example, as shown in <FIG>, in LTE, the length of the eNB identifier (ID) <NUM> is typically fixed to the first <NUM> bits (e.g., the <NUM> most significant bits) of the cell identity (ID). Fixing the eNB ID <NUM> length to <NUM> bits may allow for up to a million eNBs to be deployed in a network (e.g., public land mobility network (PLMN)) and each eNB may be able to support up to <NUM> cells. In another example, for Home eNBs (HeNBs), the HeNB ID length in LTE is equal to the full <NUM> bits of the cell ID <NUM> (e.g., as shown in <FIG>). A <NUM> bit eNB ID length may allow for a larger deployment of eNBs (e.g., compared to a <NUM> bit eNB ID length), but each eNB may support one cell only. In other examples, an <NUM> bit eNB ID length and <NUM> bit eNB ID length may also be supported.

RAN node IDs may enable support for one or more different functions in a network. In one example, RAN node IDs may allow for mutual identification of nodes in an instance of an interface (e.g., eNB IDs across X2), and support the relationship between a RAN node ID and configuration data (e.g., cells hosted by the node, cell characteristics, etc.). In one example, RAN node IDs may allow for simple message routing within the RAN (e.g., which node, and therefore interface, to address for a particular interaction which may be at cell level). In this example, this function may not require the definition of a target RAN node ID (e.g., the target may be implicit in the choice of interface that carries the message). In one example, RAN node IDs may allow for message routing involving the core network (CN) and/or other entities (e.g., S1 handover). In this example, the target may be defined such that it can be interpreted by intermediate nodes.

Additionally, the ability to identify a RAN node (e.g., based on UE reports), and subsequently set up either direct interfacing towards that node (e.g., X2/Xn), or alternatively to route messages to that node via the CN (e.g., S1 HO), may be based on having a relationship between the cell ID and RAN Node ID (e.g., "most significant N bits"). Automatic neighbor relations (ANR) functionality, for example, may be based on this property.

In general, there has been increased demand for networks to support both larger RAN nodes (hosting more cells) as well as a larger number of RAN nodes. However, setting the RAN node ID to a fixed length (or limited set of fixed lengths) (e.g., as in current LTE networks) may limit the deployment options for a network. Accordingly, to allow for flexible deployment of RAN nodes and/or cells per RAN node, it may be desirable to support variable and reconfigurable RAN node ID lengths in a network.

To maximize deployment flexibility, certain networks (e.g., NR or <NUM> networks) may enable a range of lengths of the RAN node identifier. Referring to one reference example in <FIG>, assuming a <NUM> bit cell ID is employed in the network, the network may allow nodes to have variable RAN node ID lengths/sizes of the <NUM> bit cell ID. Note, however, that a <NUM> bit cell ID is used as merely a reference example, and that other (smaller or larger) sizes may be used for the cell ID,.

In some aspects, each RAN node (e.g., eNB, gNB) may signal their node ID during setup of the interface towards the core (e.g., S1 or next generation (NG) in <NUM>). Each ID may have a length (e.g., subset of "N" bits of the cell ID) which is specific for that RAN node. The signaling may be defined using a variable length bit string. For example, the variable length bit string could be defined as "BIT STRING(SIZE (<NUM>. <NUM>))," meaning the RAN node ID could include any length between <NUM> and <NUM> bits, assuming a <NUM> bit size cell ID. In this example, a RAN node ID of <NUM> bits may enable up to approximately <NUM> nodes with up to approximately <NUM> million cells each, and a RAN node ID of <NUM> bits may enable up to approximately <NUM> billion nodes of <NUM> cell each. Different combinations of maximum nodes and maximum cells per node may be enabled for ID sizes between <NUM> and <NUM> bits.

However, in networks that support variable RAN node ID lengths, RAN nodes (e.g., eNBs/gNBs), network entities (e.g., mobility management entity (MME), access and mobility function (AMF), etc.) and/or UEs may not be able to determine (e.g., derive) the RAN node ID from the detected cell ID. For example, referring back to <FIG>, from the <NUM> bit cell ID (eNB ID <NUM> + local cell <NUM>), the eNB ID size can usually be inferred from the ID space (e.g., nodes may a priori know that the first <NUM> bits of the cell ID are equal to the eNB ID, or that <NUM> bits of the cell ID or equal to the eNB ID, etc.). Once the eNB ID is derived, it can be used in S1 messages as part of "Target ID," enabling routing between nodes (e.g., for handover via the CN, indirect communication via CN between the eNBs, etc.). However, if the RAN node ID for a given node can have any length, nodes may not be able to derive the RAN node ID from the detected cell ID, and thus, it may not be possible to route messages via the CN (as the target ID cannot be defined).

Aspects of the present disclosure provide techniques and apparatus for enabling support of variable RAN node ID sizes in a network (e.g., to support flexible deployment of cells and/or nodes in a network). More specifically, aspects presented herein provide techniques and apparatus for determining a RAN node ID from a cell ID of a cell associated with the RAN node. Note that, for the sake of clarity, the term eNB ID may be used to refer to eNB ID, gNB ID, or any other RAN node ID.

<FIG> illustrates example operations <NUM> for wireless communications, in accordance with certain aspects of the present disclosure. The operations <NUM> may be performed by a first BS (e.g., BS <NUM>, such as an eNB, gNB, etc.).

The operations <NUM> may begin at <NUM>, where the first BS determines a cell ID of a cell associated with a second BS in a network. The second BS, for example, may be a target BS of a handover of a UE from the first BS. A UE served by the first BS may have detected the cell ID and reported the cell ID to the first BS (e.g., as in ANR). At <NUM>, the first BS determines, from the cell ID, an ID of the second BS based on a partitioning of an identifier space used for identifying cells in the network. At <NUM>, the first BS transmits a message that includes at least one of the ID of the second BS or the cell ID associated with the second BS.

<FIG> illustrates example operations <NUM> for wireless communications, in accordance with certain aspects of the present disclosure. The operations <NUM> may be performed by a network entity (e.g., a core network entity, such as a MME or AMF).

The operations <NUM> may begin at <NUM>, where the network entity receives a message that includes a cell ID of a cell associated with a BS (e.g., second/target BS). In one aspect, the message may be received from the first (e.g., source) BS to trigger a CN based handover of a UE from the first BS to a second (e.g., target) BS. In one aspect, the message may be received as part of a configuration information transfer from the first BS to a second BS. At <NUM>, the network entity determines, from the cell ID, an ID of the (second/target) BS based on a partitioning of an identifier space used for identifying cells in the network.

In some aspects, there may be an explicit signaling of the RAN node ID length. For example, the length of the RAN node ID could be broadcast in SIB (or the ID itself could be broadcast). The detected RAN node ID length (of the second BS) may be reported by the UE to the first BS, and the first BS can use the RAN node ID length to derive the RAN node ID from the cell ID.

Alternatively, in some aspects, (e.g., at operations <NUM>/<NUM>/<NUM> in <FIG>, <FIG> and <FIG>, respectively) the RAN node ID length may be determined based on a partitioning of the cell ID space. For example, the cell ID space may be divided up in a deployment, such that the RAN node ID length can be inferred from a subset of the cell ID. In one aspect, the partitioning may be determined based on one or more first bits of the cell ID. For example, assuming a <NUM> bit cell ID, the first <NUM> most significant bits (or another amount of bits) may be used for partitioning the cell ID space. A node (e.g., first BS, UE, network entity) may determine a second one or more bits of the cell ID used for at least a portion of the RAN node ID (e.g., the length of the RAN node ID), based on the first one or more bits. For example, the first <NUM> most significant bits can be used to signal the length of the RAN node ID. In one reference example, if the value of the first <NUM> bits is between <NUM> and <NUM>, the RAN node ID length may be <NUM> bits, if the value of the first <NUM> bits is between <NUM> and <NUM>, the RAN node ID length may be <NUM> bits, and so on.

Once the node (e.g., gNB, UE, network entity) determines the length of the RAN node ID, the node may compare the second one or more bits of the cell ID to corresponding bits of each of a plurality of RAN node IDs, and select one of the RAN node IDs as the RAN node ID based on the comparison. In some cases, the node may determine, based on the comparison, that the second one or more bits of the cell ID match corresponding bits of a single RAN node ID from the plurality of RAN node IDs, and set the ID of the RAN node equal to the single RAN node ID.

For example, the RAN node IDs may be defined so as not to be fully contained in another RAN node ID. Assuming a <NUM> bit RAN node ID is defined, then all RAN node IDs of length <NUM> bits may be different (e.g., for legacy networks), all RAN node IDs of length greater than <NUM> bits may not have the same settings in the first <NUM> bits, and all RAN node IDs of length L (where L < <NUM>) may be such that the first L bits of the <NUM> bit RAN node ID may not have the same values as any of these. With the above restriction, given a cell ID and the complete list of RAN node IDs, the RAN node controlling the cell is the one where all its bits match the corresponding bits in the cell ID.

In some cases, the node may determine, from the comparison, that the second one or more bits of the cell ID match corresponding bits of multiple RAN node IDs from the plurality of RAN node IDs. In such a case, the node may determine a RAN node ID from the RAN node IDs that has a greatest number of matching bits to bits of the cell ID, and set the ID of the RAN node (e.g., second BS) equal to the determined RAN node ID.

For example, the RAN node IDs may be defined such that one or more of the RAN node IDs have common prefixes. In this case, the RAN node ID (signaled by the node) may correspond to a common prefix of the RAN node IDs hosted by the node, subject to the condition that the configured cell IDs are unique and that, for any two nodes, the RAN node ID lengths and values are different. With the above restriction, the RAN node controlling the cell is the one with the longest prefix match (e.g., between bits of the RAN node ID and cell ID).

Once the node (e.g., first BS) determines the RAN node ID of the RAN node (e.g., second BS), the node can use the RAN node ID to route messages, e.g., as part of a configuration information transfers, CN-based handovers, etc. As shown in <FIG>, the node may generate a message with a "Target ID Information Element" <NUM>. The Target ID Information Element <NUM> may include at least one of a Target RAN node ID field <NUM> or a cell ID field <NUM>. The Target RAN node ID field <NUM> may include the RAN Node ID <NUM> and selected tracking area identity (TAI) <NUM>. The cell ID field <NUM> may include the cell ID <NUM> and the selected TAI <NUM>. The selected TAI <NUM> may be same or different as selected TAI <NUM>. The Target ID information element <NUM> may be included in Sl-type messages, such as "Handover Required," "eNB Configuration Transfer," and "MME Configuration Transfer.

For messages that include the RAN node ID (e.g., RAN Node ID <NUM>), a legacy routing procedure may be used to route the message via the RAN and/or CN. For messages that include the cell ID (e.g., Cell ID <NUM>), the CN may move the message to the CN node that controls the tracking area (e.g., TAI). The CN node may find the full match between N-bit RAN node ID <NUM> and first N bits of cell ID <NUM>, and (<NUM>) if there is a single match, select that RAN node ID, or (<NUM>) if there is more than one match, select the RAN node ID for which N is the largest (e.g., based on a longest prefix match algorithm).

<FIG> illustrates an example call flow for a CN based handover to a non-configured neighbor cell that uses a variable RAN node identifier, according to certain aspects of the present disclosure. Note that while <FIG> depicts a CN based handover for a LTE network, the techniques may also be applied to a <NUM> network. For example, the eNB, MME, and SGW entities (for a LTE network) in <FIG> may be interchangeable with gNB, AMF, and UPF (for a <NUM> network).

As shown, in step <NUM>, the source eNB may determine to trigger a relocation via S1. In step <NUM>, the source eNB sends "Handover Required" with target ID based on cell ID to the source MME. In some cases, if the source eNB is not able to determine the target ID, the source eNB can send the cell ID to the source MME. The source MME can use the TAI to identify the target MME in step <NUM> (if needed), and send a "Forward Relocation Request" including new type of Target ID (e.g., with cell ID). In step <NUM>, the target MME can use prefix match with the received cell ID to select the target eNB, and if there is more than one possible target, the target MME can select the longest prefix as the target eNB ID. In step <NUM>, the source MME can provide the target ID to the source eNB.

In some aspects, the variable RAN node IDs may also be used as part of a configuration information exchange. For example, a first BS may send a message to the CN with cell ID and configuration information. The CN may use the cell ID to identify a second BS, and send the message to the second BS. The second BS may receive the information, and send a message to the CN with its own configuration information including its ID (and the ID of the first BS). The CN may forward the message to the first BS, which receives the ID of the second BS and configuration information.

<FIG> illustrates an example call flow for a configuration information exchange (e.g., for new cell/eNB IP address discovery for X2 setup) using variable RAN node identifiers, according to certain aspects of the present disclosure. Note that while <FIG> depicts a configuration exchange for LTE, the techniques may also be applied to a <NUM> network. For example, the eNB, MME, and SGW entities (for a LTE network) in <FIG> may be interchangeable with gNB, AMF, and UPF (for a <NUM> network).

As shown, in step <NUM>, a new cell is detected by the UE and reported to the source eNB. In step <NUM>, the source eNB sends eNB Configuration Transfer with target ID based on cell ID. In step <NUM>, the source MME forwards the configuration transfer based on TAI, and includes the cell ID information. In step <NUM>, the target MME uses prefix match, and if there is more than one match, selects longest matching prefix as the target eNB ID. In step <NUM>, the target eNB sends a message to the target MME with its own configuration information (including its ID and the source ID). In step <NUM>, the target MME forwards the information to the source MME, and in step <NUM>, the source MME forwards the information to the source eNB.

In some aspects, the variable RAN node IDs may also be used by UEs operating in an inactive mode.

There are various IoT applications that involve an exchange of relatively small amounts of data. For example, metering and alarm applications typically involve a small amount of mobile originated (MO) data, while various queries, notifications of updates, enabling actuators, and the like involve a small amount of mobile terminated (MT) data. Unfortunately, establishing a connection between a mobile device and network involves a large overhead (relative to the small amount of data). In some cases, a UE may be placed in an inactive "RAN controlled" state that represents a middle ground between a connected state and an idle state. For example, a UE in an inactive "RAN controlled" connected state (e.g., RRC_INACTIVE state) may have various characteristics, such as:.

Allowing data transmission to/from a mobile device (e.g., a UE) that is in RRC_INACTIVE state makes sense if UE has small amount of data to transmit and RAN has no or small amount of data to transmit in the state. If either the UE or RAN has subsequent data to transmit, the overhead to move to an active connected state (e.g., RRC_CONNECTED mode) may be justified, so that the data can be sent with dedicated resources.

In one scenario, UL data transmissions may be supported without RRC signaling without initiating transition to active (this may be referred to as option A). An alternative scenario is to support UL data transmission with RRC signaling, but without initiating transition to active (this may be referred to as option B).

While operating in inactive mode, there may be several functions where the UE may benefit from identifying cells belonging to the same RAN node. In one example, staying on such cells during UE controlled mobility in idle/inactive mode may allow for faster resumption of connected mode when transitioning from inactive state as no context fetch is need. In some cases, staying on the cell may also allow for faster paging of MT traffic in idle/inactive mode. In one example, using a short ID that is unique in the cells controlled by the RAN node may be beneficial when making a request to transition from the inactive to connected state.

In some aspects, the UE may use a similar algorithm as described above to determine the RAN node ID from the cell ID. For example, the UE may perform a maximum prefix match between its current cell (or last cell in connected mode) and detected cells in idle mode. The cells with a higher prefix match may be given higher priority during the idle/inactive reselection process.

<FIG> illustrates example operations <NUM> for wireless communications, in accordance with certain aspects of the present disclosure. The operations <NUM> may be performed by a UE (e.g., UE <NUM>).

The operations <NUM> may begin at <NUM>, wherein the UE determines a cell ID of a cell associated with a first BS in a network. At <NUM>, the UE determines, from the cell ID, an ID of the first BS based on a partitioning of an identifier space used for identifying cells in the network. At <NUM>, the UE determines whether to take one or more actions while transitioning from operating in an inactive mode to operating in a connected mode, based in part on the ID of the first BS.

In some aspects, the one or more actions may include at least one of a context switch or security key change procedure. The UE may determine to perform at least one of a context switch or security key change procedure if the ID of the first BS is different than a second BS the UE was previously connected to prior to transitioning from operating in the inactive mode.

<FIG> illustrates a communications device <NUM> that may include various components (e.g., corresponding to means-plus-function components) configured to perform operations for the techniques disclosed herein, such as the operations illustrated in <FIG> and <FIG>. The transceiver <NUM> is configured to transmit and receive signals for the communications device <NUM> via an antenna <NUM>, such as the various signals described herein.

The processing system <NUM> includes a processor <NUM> coupled to a computer-readable medium/memory <NUM> via a bus <NUM>. In certain aspects, the computer-readable medium/memory <NUM> is configured to store instructions that when executed by processor <NUM>, cause the processor <NUM> to perform the operations illustrated in <FIG> and <FIG>, and/or other operations for performing the various techniques discussed herein.

In certain aspects, the processing system <NUM> further includes a communicating component <NUM> for performing the operations illustrated at <NUM> in <FIG>, operations illustrated at <NUM> in <FIG>, and/or operations illustrated in <FIG>. Additionally, the processing system <NUM> includes a RAN node ID component <NUM> for performing the operations illustrated at <NUM> and <NUM> in <FIG>, operations illustrated at <NUM> in <FIG>, and/or operations illustrated at <NUM>, <NUM> and <NUM> in <FIG>. The communicating component <NUM> and RAN node ID component <NUM> may be coupled to the processor <NUM> via bus <NUM>. In certain aspects, the communicating component <NUM> and RAN node ID component <NUM> may be hardware circuits. In certain aspects, the communicating component <NUM> and RAN node ID component <NUM> may be software components that are executed and run on processor <NUM>.

In some cases, rather than actually communicating a frame, a device may have an interface to communicate a frame for transmission or reception. For example, a processor may output a frame, via a bus interface, to an RF front end for transmission. Similarly, rather than actually receiving a frame, a device may have an interface to obtain a frame received from another device. For example, a processor may obtain (or receive) a frame, via a bus interface, from an RF front end for transmission.

Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean "one and only one" unless specifically so stated, but rather "one or more. §<NUM>, sixth paragraph, unless the element is expressly recited using the phrase "means for" or, in the case of a method claim, the element is recited using the phrase "step for.

For example, means for transmitting, means for signaling, means for indicating, means for routing, means for forwarding, means for communicating, and/or means for receiving may comprise one or more of a transmit processor <NUM>, a TX MIMO processor <NUM>, a receive processor <NUM>, or antenna(s) <NUM> of the base station <NUM> and/or the transmit processor <NUM>, a TX MIMO processor <NUM>, a receive processor <NUM>, or antenna(s) <NUM> of the user equipment <NUM>. Additionally, means for identifying, means for determining, means for generating, means for partitioning, means for adding, means for comparing, means for selecting, means for setting, means for initiating, means for handing over, means for triggering, means for routing, means for forwarding, means for performing and/or means for applying may comprise one or more processors, such as the controller/processor <NUM> of the base station <NUM> and/or the controller/processor <NUM> of the user equipment <NUM>.

For example, the instructions may include instructions for performing the operations described herein and illustrated in <FIG> and <FIG>.

Claim 1:
A method for wireless communications by a first base station, comprising:
determining (<NUM>) a cell identity of a cell associated with a second base station in a network;
determining (<NUM>), from the cell identity, an identifier of the second base station based on a partitioning of an identifier space used for identifying cells in the network, wherein the partitioning of the identifier space is based on a first one or more bits of the cell identity, and wherein determining the identifier of the second base station comprises:
determining a second one or more bits of the cell identity used for at least a portion of the identifier of the second base station, based on the partitioning;
comparing the second one or more bits of the cell identity to corresponding bits of each of a plurality of base station identifiers; and
selecting one of the plurality of base station identifiers as the identifier of the second base station based on the comparison,
wherein selecting one of the plurality of base station identifiers as the identifier of the second base station comprises:
determining, from the comparison, that the second one or more bits of the cell identity match corresponding bits of multiple base station identifiers from the plurality of base station identifiers,
determining a base station identifier from the multiple base station identifiers that has a greatest number of matching bits to bits of the cell identity, and
setting the identifier of the second base station equal to the determined base station identifier; and
transmitting (<NUM>) a message comprising at least one of the identifier of the second base station or the cell identity associated with the second base station.