WO2025212005A1 - Network nodes, ue and methods for handling ue ids in a communications system - Google Patents

Network nodes, ue and methods for handling ue ids in a communications system

Info

Publication number
WO2025212005A1
WO2025212005A1 PCT/SE2025/050241 SE2025050241W WO2025212005A1 WO 2025212005 A1 WO2025212005 A1 WO 2025212005A1 SE 2025050241 W SE2025050241 W SE 2025050241W WO 2025212005 A1 WO2025212005 A1 WO 2025212005A1
Authority
WO
WIPO (PCT)
Prior art keywords
network node
request
network
response
node
Prior art date
Legal status (The legal status 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 status listed.)
Pending
Application number
PCT/SE2025/050241
Other languages
French (fr)
Inventor
Bikramjit Singh
Min Wang
Jie LING
Peter Hedman
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of WO2025212005A1 publication Critical patent/WO2025212005A1/en
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/18—Processing of user or subscriber data, e.g. subscribed services, user preferences or user profiles; Transfer of user or subscriber data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/38—Services specially adapted for particular environments, situations or purposes for collecting sensor information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/14—Direct-mode setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/20—Manipulation of established connections
    • H04W76/27—Transitions between radio resource control [RRC] states
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities

Definitions

  • the present disclosure relates generally to a first network node, a method performed by the first network node, a second network node, a method performed by the second network node, a User Equipment (UE) and a method performed by the UE.
  • UE User Equipment
  • the present disclosure relates to handling UE IDs in a communications system.
  • the present disclosure relates to selection of Ambient Internet of Things (Ambient-IoT, A-IoT) users in Inventory or Downlink (DL) command procedures.
  • the present disclosure relates to methods and apparatus for selection of A-IoT users in inventory or DL command.
  • ZE devices refer to wireless loT devices that do not require battery replacement and often harvest energy from the environment. In some use cases, such as monitoring the temperature of foodstuffs, the ZE devices may have small batteries that are disposable, e.g., organic, compostable batteries, rechargeable or have very limited capacity.
  • ZE-IoT devices may in addition be of very small form factor and could even be printable and they target ultra-low power consumption to enable operation based on either energy-harvesting from an ambient sources or back-scattering communication, cf. Radiofrequency identification (RFID). That is, instead of relying on energy for communication being provided by a battery it is instead harvested from an ambient source, such as vibrations, solar power, RF, etc. in the harvesting case, or a charge carrier wave is provided to the device which is modulated and reflected back to a reader in the back-scattering communication case. This enables energy autonomous operation during the lifetime of the devices without need for either manual replacement or charging of the batteries. Compared to existing radio access technologies this puts new requirements on the radio interface and the protocols.
  • RFID Radiofrequency identification
  • Device categorization based on corresponding characteristics may be discussed during the study, in relation to the relevant use cases.
  • the device ’s peak power consumption shall be limited by its practical form factor for the intended use cases and shall consider its energy source.
  • Base station characteristics e.g. macro/micro/pico cells-based deployments.
  • Connectivity topologies including which node(s), e.g. base station, UE, relay, repeater, etc. can communicate with target devices. . TDD/FDD, and frequency bands in licensed or unlicensed spectrum.
  • deployment scenario There can be more than one deployment scenario identified for a use case, and a deployment scenario may be common to more than one use case.
  • a set of RAN design targets based on the identified deployment scenarios and their characteristics for the relevant use cases, at least including
  • This study shall target for an loT segment well below the existing 3GPP loT technologies, e.g. NB-IoT, eMTC, RedCap, etc. The study shall not aim to replace existing 3GPP LPWA technologies. ”
  • a study item is expected to continue in Release- 19 (Rel-19).
  • a work item may be started during Rel-19 as well.
  • FIG. 1 is a schematic drawing illustrating topology 1 in TR 38.848 V 1.0.0.
  • the Ambient-IoT device 105 directly and bidirectionally communicates with a base station 101.
  • the communication between the base station 101 and the Ambient-IoT device 105 includes at least one of Ambient-IoT data and signaling.
  • This topology includes the possibility that the BS 101 transmitting to the Ambient-IoT device 105 is a different from the BS 101 receiving from the Ambient-IoT device 105.
  • the arrow in FIG. 1 represents Ambient-IoT data or Ambient-IoT data signaling.
  • Topology 2 BS - intermediate node - Ambient-IoT device
  • FIG. 2 is a schematic drawing illustrating topology 2 in TR 38.848 V 1.0.0.
  • the Ambient-IoT device 105 communicates bidirectionally with an intermediate node 103 between the Ambient-IoT device 105 and base station 101.
  • the intermediate node 103 may be a relay, Integrated Access and Backhaul (IAB) node, UE, repeater, etc. which is capable of Ambient-IoT.
  • the intermediate node 103 transfers at least one of Ambient-IoT data and signaling between BS 101 and the Ambient-IoT device 105.
  • the arrow in FIG. 2 represents Ambient-IoT data or Ambient-IoT signaling.
  • Topology 3 BS - assisting node - Ambient-IoT device - BS
  • FIG. 3 is a schematic drawing illustrating topology 3 with downlink assistance in TR 38.848 V 1.0.0.
  • FIG. 4 is a schematic drawing illustrating topology 3 with uplink assistance in TR 38.848 V 1.0.0.
  • the Ambient-IoT device 105 transmits data/signaling to a base station 101 and receives data/signaling from the assisting node 103; or the Ambient-IoT device 105 receives data or signaling from a base station 101 and transmits data or signaling to the assisting node 103.
  • the assisting node 103 may be a relay, IAB, UE, repeater, etc. which is capable of Ambient-IoT.
  • the arrow in FIG. 3 and FIG. 4 represents Ambient-IoT data or Ambient-IoT signaling.
  • Topology 4 UE «-> Ambient-IoT device
  • FIG. 5 is a schematic drawing illustrating topology 4 with uplink assistance in TR 38.848 V 1.0.0.
  • the Ambient-IoT device 105 communicates bidirectionally with a UE 105.
  • the communication between UE 105 and the Ambient-IoT device 105 includes at least one of Ambient-IoT data and signaling.
  • the arrow in FIG. 5 represents Ambient-IoT data or Ambient-IoT signaling.
  • Ambient-IoT devices 105 are characterized in the study according to their energy storage capacity, and capability of generating Radio Frequency (RF) signals for their transmissions.
  • RF Radio Frequency
  • - Device A No energy storage, no independent signal generation or amplification, i.e. backscattering transmission.
  • - Device B Has energy storage, no independent signal generation, i.e. backscattering transmission. Use of stored energy may include amplification for reflected signals.
  • a limited energy storage may be different among implementations within Device B or implementations within Device C, and different between Device B and Device C. Such storage is expected to be in an order(s) of magnitude smaller than an NB-IoT device would typically include.
  • Device A, B, and C are able to demodulate control, data, etc. from the relevant entity in RAN according to connectivity topology.
  • 3GPP will target an loT segment well below the existing Cellular Internet of Things (CIoT) technologies rather than replacement of existing 3GPP PLWA technologies. It is expected that together with simplifications in physical layer design, the higher layer design, e.g. L2 and L3, will also be much more lightweighted than the existing higher layer design in 3GPP, i.e., a minimal set of functionalities both at access stratum and non-access stratum levels, which is even more simplified compared to that adopted for the existing CIoT technologies, should be used to operate Ambient-IoT devices.
  • CIoT Cellular Internet of Things
  • One way of such simplifications is to design a communication protocol shifted from fully connection oriented with both Non-Access Stratum (NAS) and Radio Resource Control (RRC) connections between device and network to connectionless type of communication without RRC connections or even also no NAS connections between device and network so that the protocol and signaling overhead associated with the handshaking between device and network is minimized.
  • NAS Non-Access Stratum
  • RRC Radio Resource Control
  • Ambient-IoT devices do not setup and maintain an RRC connection with the network
  • ambient loT devices do not setup and maintain Application Server (AS) context including dedicated radio bearer, logical channel, etc.
  • AS Application Server
  • connectionless communication One way to implement connectionless communication is to employ message-based or self-contained transmission where context and control information associated with the signaling and data traffic is transmitted together with or right after the signaling and data traffic where in the latter case, i.e., the right after case, there is no other transmission between the context and control information and the associated signaling and data traffic carrying info that is needed for reception of the signaling/data traffic.
  • context and control information associated with the signaling and data traffic is transmitted together with or right after the signaling and data traffic where in the latter case, i.e., the right after case, there is no other transmission between the context and control information and the associated signaling and data traffic carrying info that is needed for reception of the signaling/data traffic.
  • the signaling/ data traffic is transmitted within or right after the paging message.
  • This study targets a further assessment at RAN WG-level of Ambient-IoT, a new 3GPP loT technology, suitable for deployment in a 3GPP system, which relies on ultra-low complexity devices with ultra-low power consumption for the very-low end loT applications.
  • the study shall provide clear differentiation, i.e. addressing use cases and scenarios that may not otherwise be fulfilled based on existing 3GPP LPWA loT technology e.g. NB-IoT including with reduced peak Tx power.
  • the overall objective shall be to study a harmonized air interface design with minimized differences where necessary for Ambient-IoT to enable the following devices: i. ⁇ 1 /zW peak power consumption, has energy storage, initial sampling frequency offset (SFO) up to ICA ppm, neither DL nor UL amplification in the device.
  • the device’s UL transmission is backscattered on a carrier wave provided externally. ii. ⁇ a few hundred /zW peak power consumption 1 , has energy storage, initial sampling frequency offset (SFO) up to ICA ppm, both DL and/or UL amplification in the device.
  • the device’s UL transmission may be generated internally by the device or be backscattered on a carrier wave provided externally.
  • Topologies 1 & 2 i.e. UE as intermediate node under Network (NW) control, per TR 38.848, with no RRC states, no mobility, i.e. at least no cell selection/re- selection -like function, no Hybrid Automatic Repeat reQuest (HARQ), no Automatic Repeat reQuest (ARQ).
  • NW Network
  • HARQ Hybrid Automatic Repeat reQuest
  • ARQ Automatic Repeat reQuest
  • FR1 Frequency Range 1 (FR1) licensed spectrum in FDD.
  • D Spectrum deployment in-band to New Radio (NR), in guard-band to LTE/NR, in standalone band(s).
  • NR New Radio
  • LTE is short for Long Term Evolution.
  • DO-DTT Device-Originated - Device-Terminated Triggered
  • the study will assess whether the harmonized air interface design, e.g. per bullet ‘A’ above, may address the Device-originated autonomous (DO- A) use case, only to identify which part(s) of the harmonized air interface design, e.g. per bullet ‘A’ above, is/are not sufficient for the DO-A use case.
  • DO- A Device-originated autonomous
  • Transmission from Ambient-IoT device, including backscattering when used, may occur at least in UL spectrum.
  • Evaluation assumptions a) Conclude at least the following aspects of design target left to WGs in Clause 5, i.e. RAN design targets, of TR 38.848, i.e. RANI. o Clause 5.3: Applicable maximum distance target values(s). o Clause 5.6: Refine the definition of latency suitable for use in RAN WGs. o Clause 5.8: 2D distribution of devices. b) Define necessary further evaluation assumptions of deployment scenarios for coverage and coexistence evaluations, i.e.RANl, RAN4.
  • c) Identify basic blocks/components of possible Ambient-IoT device architectures, taking into account state of the art implementations of low-power low-complexity devices which meet the RAN design target for power consumption and complexity, i.e. RANI. d) Define link budget calculation for coverage, including whether/how to model carrier wave from node(s) inside or outside the connectivity topology.
  • Ambient-IoT DL and UL o Frame structure, synchronization and timing, random access o Numerologies, bandwidths, and multiple access o Waveforms and modulations o Channel coding o Downlink channel/signal aspects o Uplink channel/signal aspects o Scheduling and timing relationships o Study necessary characteristics of carrier-wave waveform for a carrier wave provided externally to the Ambient-IoT device, including for interference handling at Ambient-IoT UL receiver, and at NR base station.
  • RAN2-led o Study and decide which functions are needed for an Ambient-IoT compact protocol stack and lightweight signaling procedure to enable DO-DTT and DT data transmission and study those functions.
  • RAN2 and RAN3 are expected to identify RAN-CN functional split in coordination with SA2.
  • the objective is achieved by a method performed by a UE for handling UE ID in a communications system, the method comprising one or more of: obtaining a first request from the first network node;
  • the objective is achieved by a method performed by a first network node for handling UE ID in a communications system, the method comprising one or more of: obtaining a first request from the second network node, wherein the first request may comprise a first UE ID or may not comprise the first UE ID; selecting which UE that should receive the first request by checking if a first UE ID is comprised in the first request;
  • the objective is achieved by a method performed by a second network node for handling UE ID in a communications system, the method comprising:
  • the first request may comprise a first UE ID or may not comprise the first UE ID.
  • - power supply circuitry configured to supply power to the processing circuitry, wherein the processing circuitry is configured to: obtain a first request from a first network node; provide a second UE ID to the first network node; obtain a third UE ID from the first network node; and to determine the second UE ID to be the third UE ID.
  • the objective is achieved by a first network node for handling UE ID in a communications system.
  • the first network node comprises:
  • - power supply circuitry configured to supply power to the processing circuitry, wherein the processing circuitry is configured to: obtain a first request from a second network node, wherein the first request comprises a first UE ID or does not comprise the first UE ID;
  • the objective is achieved by a second network node for handling UE ID in a communications system, the second network node comprising:
  • - power supply circuitry configured to supply power to the processing circuitry, wherein the processing circuitry is configured to: - provide a first request to a first network node, wherein the first request comprises a first UE ID or may does not comprise the first UE ID.
  • Certain embodiments may provide one or more of the following technical advantage(s).
  • FIG. 4 is a schematic drawing illustrating topology 3.
  • FIG. 5 is a schematic drawing illustrating topology 4.
  • FIG. 6a is a schematic drawing illustrating a communications system.
  • FIG. 6b is a signaling diagram illustrating a method.
  • FIG. 9 is a flow chart illustrating a method.
  • FIG. 10 is a flow chart illustrating a method.
  • FIG. 11 is a schematic block diagram illustrating a UE.
  • FIG. 12 is a schematic block diagram illustrating a first network node.
  • FIG. 13 is a schematic block diagram illustrating a second network node.
  • FIG. 14 is a schematic drawing illustrating an example of a communication system.
  • FIG. 17 is a block diagram illustrating a virtualization environment.
  • FIG. 6a is a schematic drawing illustrating a communications system 100.
  • FIG. 6a depicts a non-limiting example of a communications system 100, which may be a wireless communications system, sometimes also referred to as a wireless communications network, cellular radio system, or cellular network, in which the present disclosure may be implemented.
  • the communications system 100 may be a 5G system, 5G network, NR-U or Next Gen system or network.
  • the communications system 100 may alternatively be a younger system or older system than a 5G system, such as e.g. a 2G system, a 3G system, a 4G system, a 6G system, a 7G system etc.
  • the communications system 100 may support other technologies such as, for example, Long-Term Evolution (LTE), LTE-Advanced/LTE-Advanced Pro, e.g. LTE Frequency Division Duplex (FDD), LTE Time Division Duplex (TDD), LTE Half-Duplex Frequency Division Duplex (HD-FDD), LTE operating in an unlicensed band, NB-IoT.
  • LTE Long-Term Evolution
  • LTE-Advanced/LTE-Advanced Pro e.g. LTE Frequency Division Duplex (FDD), LTE Time Division Duplex (TDD), LTE Half-Duplex Frequency Division Duplex (HD-FDD), LTE operating in an unlicensed band
  • LTE Long-Term Evolution
  • LTE-Advanced/LTE-Advanced Pro e.g. LTE Frequency Division Duplex
  • TDD Time Division Duplex
  • HD-FDD LTE Half-Duplex Frequency Division Duplex
  • LTE operating in an unlicensed band NB-
  • the communications system 100 comprises one or a plurality of network nodes, whereof a first network node 101 and a second network node 103 are depicted in the nonlimiting example of FIG. 6a.
  • Any of the first network node 101, and the second network node 103 may be a radio network node, such as a radio base station, or any other network node with similar features capable of serving a user equipment, such as a wireless device or a machine type communication device, in the communications system 100.
  • the first network node 101 may be an eNB and the second network node 103 may be a gNB.
  • the first network node 101 may be a first eNB, and the second network node 103 may be a second eNB.
  • the first network node 101 may be a first gNB, and the second network node 103 may be a second gNB.
  • the first network node 101 may be a MeNB and the second network node 103 may be a gNB. Any of the first network node 101 and the second network node 103 may be co-localized, or they may be part of the same network node.
  • the first network node 101 may be referred to as a source node or source network node, whereas the second network node 103 may be referred to as a target node or target network node.
  • the first network node 101 may be a base station, a reader, a UE-based reader, a UE, an intermediate UE, an assisting node, just to mention some examples.
  • the second network node may be a base station, a Core Network node (CN node), an Ambient-IoT Function (Ambient-IoTF, AIoTF), an Access and Mobility Management Function (AMF), an Application Function (AF), just to mention some examples.
  • CN node Core Network node
  • Ambient-IoT Function Ambient-IoTF, AIoTF
  • AMF Access and Mobility Management Function
  • AF Application Function
  • One or both of the first network node 101 and the second network node 103 may be Ambient-IoT capable.
  • the communications system 100 covers a geographical area which may be divided into cell areas, wherein each cell area may be served by a network node, although, one network node may serve one or several cells.
  • the communications system 100 may comprise a first cell and a second cell (not illustrated in FIG. 6a).
  • a cell is a geographical area where radio coverage is provided by the network node at a network node site.
  • Each cell is identified by an identity within the local network node area, which is broadcast in the cell.
  • the first network node 101 may serve the first cell
  • the second network node 103 may serve the second cell.
  • any of the first network node 101 and the second network node 103 may be of different classes, such as, e.g., macro base station (BS), home BS or pico BS, based on transmission power and thereby also cell size. Any of the first network node 101 and the second network node 103 may be directly connected to one or more core networks, which are not depicted in FIG. 6a for the sake of simplicity. Any of the first network node 101 and the second network node 103 may be a distributed node, such as a virtual node in the cloud, and it may perform its functions entirely on the cloud, or partially, in collaboration with another network node.
  • the first cell may be referred to as a source cell, whereas the second cell may be referred to as a target cell.
  • One or aplurality of UEs 105 is comprised in the communication system 100. Only one UE 105 is exemplified in FIG. 6a for the sake of simplicity. A UE 105 may also be referred to simply as a device.
  • the UE 105 e.g. an LTE UE or a 5G/NR UE or an Ambient-IoT (AIoT, A-IoT), may be a wireless communication device which may also be known as e.g. at least one of a wireless device, a mobile terminal, wireless terminal and mobile station, a mobile telephone, cellular telephone, or laptop with wireless capability, just to mention some examples.
  • the UE 105 may be Ambient-IoT capable.
  • the UE 105 may be at least one of portable, pocket storable, hand held, computer comprised, or vehicle mounted devices, enabled to communicate voice and data, via the radio access network, with another entity, such as another UE, a server, a laptop, a Personal Digital Assistant (PDA), or a tablet, Machine-to-Machine (M2M) device, device equipped with a wireless interface, such as a printer or a file storage device, modem, or any other radio network unit capable of communicating over a radio link in the communications system 100.
  • PDA Personal Digital Assistant
  • M2M Machine-to-Machine
  • the UE 105 may be of one of the following types:
  • UE type A The UE does not comprise any energy storage, no independent signal generation/amplification, i.e. backs cattering transmission.
  • UE type A B The UE comprises energy storage, no independent signal generation, i.e. backscattering transmission. Use of stored energy may include amplification for reflected signals.
  • UE type C The UE comprises energy storage, it comprises independent signal generation, i.e., active RF components for transmission.
  • a limited energy storage may be different among implementations within UE B or implementations within UE C, and different between UE B and UE C. Such storage is expected to be in an order(s) of magnitude smaller than an NB-IoT device would typically include.
  • UE A, B, and C are able to demodulate control, data, etc. from the relevant entity in RAN according to connectivity topology.
  • the first network node 101 may be an intermediate UE and this means that it operates between the UE 105 and a second network node 103.
  • the intermediate may operate as a reader.
  • the intermediate UE may be a normal UE plus some potential enhancement. This is illustrated in FIG. 2.
  • the first network node 101 may be configured to communicate in the communications system 100 with the UE 105 over a first communication link, e.g., a radio link.
  • the second network node 103 may be configured to communicate in the communications system 100 with the UE 105 over a second communication link, e.g., a radio link.
  • the first network node 101 may be configured to communicate in the communications system 100 with the second network node 103 over a third communication link, e.g., a radio link or a wired link, although communication over more links may be possible.
  • the communication links in the communications system 100 may be of any suitable kind comprising either a wired or wireless link.
  • the link may use any suitable protocol depending on type and level of layer (e.g. as indicated by the Open Systems Interconnection (OSI) model) as understood by the person skilled in the art.
  • OSI Open Systems Interconnection
  • the communications system 100 may comprise one of the following deployment scenarios:
  • Deployment scenario 1 UE indoors, base station indoors
  • Deployment scenario 2 UE indoors, base station outdoors
  • Deployment scenario 3 UE indoors, UE-based reader
  • Deployment scenario 4 UE outdoors, base station outdoors
  • Ambient-IoT user may be based on
  • Active device also referred to as o B+, C-,C
  • B is referred to as passive device, but B+ may be classified as active device or low end active device.
  • A e.g. low end passive device
  • B e.g. high end passive device
  • C e.g. active device
  • the inventory command which initiates the inventory procedure may also be referred to as select command or Q command, typically used terminology in RFID.
  • the terms polling, poll and paging, page, inventory, query, interrogate is used to represent one or more than one signal transmitted by a network node broadcast wise or specially to a dedicated UE 105.
  • the purpose of the signal is to facilitate/serve/manage/command one or more than one UE 105 to synchronize to the network node, DL/UL synchronize to a reference time/frame/symbol or synchronize to one or more than one signal which the UE 15 receives from the network node, or synchronize based on a predefined rule, receive DL data, response and transmit UL data correctly in intended resources.
  • the content of such signal may be a particular reference signal or a signal carrying at least one of control information and data.
  • Such signal may be transmitted periodically or a periodically configured by the network node.
  • Ambient-IoT device A-IoT UE, A-IoT device, device, UE or user are used interchangeably without losing the meaning, and the reference number 105 may be used herein when referring to any of them.
  • Device 1 ⁇ 1 pW peak power consumption, has energy storage, initial sampling frequency offset (SFO) up to 10X ppm, neither DL nor UL amplification in the device.
  • SFO initial sampling frequency offset
  • the device s UL transmission is backscattered on a carrier wave provided externally.
  • Device 2a ⁇ a few hundred pW peak power consumption, has energy storage, initial sampling frequency offset (SFO) up to 10X ppm, both DL and/or UL amplification in the device.
  • SFO initial sampling frequency offset
  • the device s UL transmission is backscattered on a carrier wave provided externally.
  • Device 2b ⁇ a few hundred pW peak power consumption, has energy storage, initial sampling frequency offset (SFO) up to 10X ppm, both DL and/or UL amplification in the device.
  • SFO initial sampling frequency offset
  • the device s UL transmission is generated internally by the device.
  • the present disclosure proposes select command and signaling behavior or content which enables network or application to target specific devices.
  • the devices may be selected based on range of information which is available at application/ AF or CN or RAN side. Further, the proposed signaling method by which select command may be transmitted to selected or intended group of devices/users.
  • the Ambient-IoT function initiates an inventory request to selected users, corresponding to their CN/device IDs. The reader or gNB receives this request and sends the select command to indicated devices.
  • the select command may be sent to all devices, e.g., in a broadcast manner but the command may specify the indicated device IDs or credentials in the select command, e.g.(a) the IDs are same which originally mentioned by CN/AF or (b) the IDs that map to IDs mentioned by CN/AF, then only targeted devices, e.g. device IDs, will be prepared to move forward with inventory or command procedure. Other devices after reading a select command which don’t find their information or IDs in the command may ignore the command and continue to sleep or remain suspended. No access is initiated by such devices.
  • Means to divide the targeted devices for, e.g., a command is proposed based on the scope of the request and stored info in the devices such that at each moment in time only a subset of the devices replies to the request and the logic for how the reader may go through all subsets of the devices as to accomplish a complete command towards all targeted devices while limiting overload and interference.
  • FIG. 6b is a flow chart illustrating a method.
  • the method comprises at least one of the following steps, which steps may be performed in any suitable order than described below:
  • Step 601 The second network node 103 sends a first request to the first network node 101.
  • the first request may be an inventory request.
  • the first request may be a request to request UEs 105 to provide their UE ID and possibly more information.
  • the first request may be a request for status of the UE 105, e.g. if the UE is present in the communication system 100 or not.
  • the first request may be made in a broadcast manner, compared with paging, as the sender may not really be aware of what UEs 105 are available.
  • the first request may comprise information as to get a subset of the UEs 105 to respond to the first request.
  • the information to get a subset of UEs may be in the form of a first UE ID, e.g. CN device ID.
  • the first UE ID is allocated by the second network node 103.
  • the first request may comprise a first UE ID for each UE 105 that should response to the first request. If no first UE ID is comprised in the first request, then all UEs 105 in the communication system 100, e.g. all UEs in a particular region, may response to the first request.
  • Step 602 The first network node 101 receives the first request from the second network node 103. Based on the first request, the first network node 101 selects or determines which UEs 105 that should receive the first request. The selection is done based on whether or not the first request comprises a first UE ID. As mentioned above, the first request may comprise zero, one, two or more first UE IDs. When the first request does not comprise any first UE ID, the first network node 101 may determine to send the first request to all UEs 105, e.g. all UEs 105 in the communication system 100, in a certain region of the communication system 100 etc., i.e. a broadcast of the first request.
  • all UEs 105 e.g. all UEs 105 in the communication system 100, in a certain region of the communication system 100 etc., i.e. a broadcast of the first request.
  • the first network node 101 may select the UEs 105 with the first UE IDs to receive the first request.
  • the first UE ID(s) in the first request indicates which UE(s) 105 that should receive the first request.
  • Step 603 The first network node sends the first request to the UE 105.
  • the UE 105 receives the first request and allocates a second UE ID to itself.
  • the second UE ID may be a random ID.
  • the UE 105 sends information indicating the second UE ID to the first network node 101.
  • Step 604 The first network node 101 receives the second UE ID from the UE 105.
  • Step 605 The first network node 101 maps the second UE ID with a third UE ID.
  • the third UE ID has been allocated by the first network node 101.
  • the third UE ID may be an AS device ID.
  • Step 606 The first network node 101 may create a mapping table with mapping between the third UE ID allocated by the first network node 101 and the first UE ID allocated by the second network node 103.
  • Step 607 The first network node 101 sends information indicating the third UE ID to the UE 105.
  • the UE 105 may store the information indicating the third UE ID.
  • the UE 105 determines that the second UE ID is the third UE ID.
  • Step 608 The UE 105 sends a first response to the first network node 101.
  • the first response is a response to the first request in step 603.
  • the first response may comprise the third UE ID.
  • Step 609 The first network node 101 receives the first response comprising the third UE ID from the UE 105.
  • the first network node 101 sends the first response to the second network node 103.
  • the first response sent to the second network node 103 may or may or may not comprise the third UE ID.
  • Step 611 The first network node 101 searches the mapping table to find the third UE ID that maps to the first UE ID that was in the second request in step 610.
  • Step 612 The first network node 101 sends the second request to the UE 105, i.e. the UE 105 indicated by the first UE ID.
  • Step 613 The UE 105 sends a second response to the first network node 101.
  • the second response comprises the third UE ID.
  • the second response may be a command response.
  • the second response is a response to the second request in step 612.
  • Step 703 This step corresponds to step 603 in FIG. 6b.
  • the first network node 101 provides a query or scheduling and the inventory request to the UE 105, i.e. the inventory request from step 701.
  • a random ID of the UE 105 may be promoted to AS ID if the user is successfully resolved, e.g. contention resolution successful, provided this random ID will be barred from usage for other UE 105 in the same cell.
  • contention resolution successful e.g. contention resolution successful
  • Such methodology does not exist in NR. But it is also very unlikely to happen as it involves too many SI updates, e.g. it is hard to update the barred IDs.
  • Step 706 This step corresponds to step 607 in FIG. 6b.
  • the first network node 101 provides an acknowledgement (ACK) and the AS device ID to the UE 105.
  • the UE 105 obtains the ACK and the AS device ID from the first network node 101.
  • Step 707 This step corresponds to step 607 in FIG. 6b.
  • the UE 105 stores the random ID as the AS device ID provided by the first network node 101.
  • Step 708 This step corresponds to step 608 in FIG. 6b.
  • the UE 105 provides an inventory response and the AS device ID to the first network node 101.
  • the inventory response is in response to the inventory request in step 703.
  • the first network node 101 obtains the inventory response and AS device ID from the UE 105.
  • Step 709 This step corresponds to step 609 in FIG. 6b.
  • the first network node 101 provides an inventory response to the second network node 103.
  • the inventory response is in response to the inventory request in step 701.
  • the second network node 103 obtains the inventory response from the first network node 101.
  • Step 710 This step corresponds to step 610 in FIG. 6b.
  • the second network node 103 provides a command request to the first network node 101.
  • the command request may comprise a CN device ID.
  • the first network node 101 obtains the command request and the CN device ID from the second network node 103.
  • a command request may be e.g. a read or write command towards a known UE using dedicated signaling as to perform a command operation, e.g. read or write to/of memory in the designated UE 105 which is designated with the CN device ID.
  • the command may mean to read or write data from/to the UE 105.
  • the command request may implicitly include inventory in some cases. Inventory may still be performed for known or present UE 105, this is useful if the UE 105 is at risk of getting stolen, or if the device attached to product is very expensive, then the known UE 105 is continuously inventory.
  • the UE 105 may have gone through either of the procedures - inventory or registration or some sort of validation/authentication/applied security procedures.
  • Step 712 This step corresponds to step 612 in FIG. 6b.
  • the first network node 101 provides a query or scheduling to the UE 105.
  • the first network node 101 provides a command request and AS device ID to the UE 105.
  • the UE 105 obtains the query or scheduling, command request and AS device ID from the first network node.
  • mapping table mentioned in steps 705 and 711 may be, for example, as seen in one of Table 3 and Table 4:
  • the first network node may allocate a temporary CN device ID, e.g. GUTI or TMSI allocated by the second network node 103 which may be mapped to AS device ID allocated by the first network node 101.
  • a temporary CN device ID e.g. GUTI or TMSI allocated by the second network node 103 which may be mapped to AS device ID allocated by the first network node 101.
  • the real or default CN device ID e.g. SUPI or SUCI
  • the first network node may only know the temporary CN device ID, e.g. GUTI or TMSI which is mapped to the first network node 101 allocated as ID.
  • the inventory command may indicate at least one of the following parameters or information for which network intends to perform inventory for the associated UEs 105 where the indicated information may be at least one of:
  • This area information or area ID is meant to be in the CW signaling or DL or select command signaling for the UE 105 to know whether to respond to inventory.
  • Area ID may be basically a bit string, e.g., representing a building, say some x bits representing area but the device does not need to know what it represents. • User group ID.
  • the selection of IDs may also be based on masking or applied function.
  • the inventory command may indicate that the user ID beginning from 6, e.g. in hexadecimal format, should respond to inventory command; it means other UEs 105 whose IDs don’t start from 6 may respond to the inventory command.
  • the network e.g. at least one of the first network node 101 and the second network node 103, may define user ID format and flexibly specify and mask some values to target the UEs 105 accordingly.
  • network may define 5 letter/word long hexa decimal format, and in one example, network may indicate 0x1 lx in inventory command, e.g. 2 letters may be masked, which means maximum 16 A 2 users may respond with their IDs matching to the indicated value.
  • the user ID or device ID may be based on at least one of:
  • Device ID e.g., like o CN ID like SUPI/SUCI in 3 GPP o Transaction Identifier (TID) in RFID
  • Application ID o For example, CN ID or device ID may be mapped application ID, e.g. GPSI- like ID o EPC in RFID
  • Temporary ID o Temporary ID, which CN may allocate based on above IDs, e.g.,
  • ⁇ GUTI handle ID in case of RFID o Temporary ID allocated by reader or RAN node, e.g. gNB, intermediate node or UE.
  • RAN or CN initiated inventory command may be still controlled AF, e.g., AF may initiate periodic inventory, which means RAN or CN may decide or implement periodic inventory command without AF requires to initiate every time.
  • the inventory command may target user group which has not been registered yet.
  • the inventory command may be provisioned with a flag, if the UE 105 is registered or not. Based on flag status, non-registered UE 105 may respond to the inventory command, e.g., if such flag is set. Otherwise, all UEs 105 within the target group may respond irrespective of prior registration status.
  • the inventory command may target UE groups which have been inventoried within time window, e.g., last X units of time.
  • the inventory command may specify the time window, e.g., X units and set the flag, so that all the UEs 105 within the target may respond except the UEs 105 which are inventoried in this X unit time window.
  • the inventory command may specify duration of time window, or start and stop time of window, e.g. with an assumption that the UE 105 has maintained some sort of timer.
  • the inventory command may indicate inventory ID which may refer to inventory policy.
  • one policy may be the periodicity of inventory associated with given inventory ID.
  • Another example may be that an Ambient-IoT device 105 is required to transmit specific information as part of inventory reporting for inventory command associated with given inventory ID.
  • Table 5 presents a 2 -bit inventory ID, which lists inventory report type requirement for given Inventory ID.
  • the UE group signaling may indicate session ID where UEs 105 associated with session ID or application session ID will respond only during inventory or DL command procedure.
  • the session ID may be allocated during a UE’s 105 first inventory procedure or DL command procedure or registration procedure.
  • the benefit of the session may be where based on the application scenario, the UE 105 is required to report constantly or intermittently corresponding to that session.
  • a UE application may invoke a command to monitor a given or group of tag ID or product ID or device ID and allocate a session ID, and the associated UEs may respond according to the session policy. This application may be useful where reader, e.g.
  • gNB RAN node
  • UE handheld reader
  • CN or AF may set up a session to monitor the good constantly during the session period, e.g., to prevent a stealing, or find unlocated good(s) or device(s).
  • the UE 105 may respond, if no policy is enforced.
  • the UE 105 may not respond if it has already responded to the select command with similar content or ID earlier. o
  • the similar select commands or signaling may come from
  • NGRAN Next Generation Radio Access Network
  • the RAN signaling to indicate UE group selection may be done in one, two or more of the following ways.
  • Option 1 The UE group signaling may indicate one bitfield of fixed size where RAN or CN may specify in the bitfield either:
  • ⁇ different or specific device IDs map to one group ID, and/or
  • the ID in group ID is common bit value/mask in the targeted group of devices, similar to mask functionality, for instance, if there are maximum 16 devices possible to inventory, and bit field size set as 4 bit, and the RAN signaling specified MSB as 11, then only 4 devices will be targeted which are 1100, 1101, 1110, 1111.
  • Option 2 The signaling may comprise N bitfields, where in each bitfield the RAN may specify IDs or masks like Option 1. With this, the RAN may target N specific devices or N specific group of devices at the most.
  • size N may be dynamic and, e.g., o May be indicated in RRC signaling, e.g. System Information (SI), System Information Block (SIB) or Master Information Block (MIB), or configuration signaling specifically the size, e.g. value of N, for user selection signaling.
  • SI System Information
  • SIB System Information Block
  • MIB Master Information Block
  • o May be indicated in Physical (PHY) header or control information and the devices accordingly decode the payload.
  • Option 2B In one option, the value N may be fixed, e.g. hardcoded.
  • Option 3 In one option, to target N specific devices or group of devices, the RAN node may utilize signaling based on option 1 but may send the signaling N times indicating different ID each time. For example, if RAN node is intended to target user ID 1111 and 0000 for inventory or command procedure, then it may send user selection signaling indicating 1111 in the relevant bitfield, and then it may again send the send user selection signaling indicating 0000.
  • the above options 1 to 3 may be combined with one or more of the requested scopes of the request e.g. the group ID the devices belong to, the device categories or types the devices belong to, the owner id of the device etc.
  • the reader may limit/throttle the number of responses.
  • the select signaling content may be comprised in at least one of:
  • CW which may be sent in at least one of: o UL band, or o DL band,
  • a CN node or AF may send the signaling on user selection to the reader, e.g., the gNB or the intermediate UE.
  • the signaling may be one shot, i.e., valid/applicable for one scheduling/query round, or semi-static/periodic manner, i.e., valid/applicable for multiple scheduling/query rounds.
  • the signaling may be carried via RRC signaling, Medium Access Control (MAC) Control Element (CE) or LI signaling.
  • MAC Medium Access Control
  • CE Control Element
  • LI LI signaling
  • the RAN node e.g., the gNB, may send the signaling on user selection to the intermediate UE.
  • the RAN node may determine use selection according to a configuration received from the CN or AF.
  • the RAN node may determine user selection, which may be different from user selection made by the CN. This may occur due to that user selection made by the CN is not suitable to the RAN node, since the CN may not have up to date information or knowledge in the RAN on resource availability.
  • the RAN node may determine user selection, which is subset of user selection made by the CN. This may occur that CN determines a larger group of devices to be selected. However, the RAN node has decided to initiate scheduling/query multiple times/rounds to complete the overall scheduling/query procedure.
  • An inventory command may comprise indicators requesting one or multiple devices or device groups to provide capability information to the network/reader.
  • the indicators may comprise at least one of the below:
  • a device may immediately attempt to obtain an occasion in the current scheduling round or future scheduling rounds and transmit the requested capability information to the corresponding network node/reader.
  • the network node may decide to initiate a second scheduling or inventory round for these devices according to their capability information.
  • the second scheduling round may only target to devices which support security/encryption.
  • the second scheduling round may only target to devices which support registration procedure.
  • the second scheduling round may accommodate or provide sufficient occasions, e.g. at least one of in frequency and time domain, for a device to perform or enable encryption in subsequent transmissions/receptions after the initial access, e.g., after the network node has acknowledged reception of the initial ID of the device.
  • the second scheduling round may accommodate or provide sufficient occasions, e.g. at least one of in frequency and time domain, for a device to perform/ enable registration procedure in subsequent transmissions/receptions after the initial access, e.g., after the network node has acknowledged reception of the initial ID of the device.
  • the network node may instruct a carrier wave emitter or an energy provider/transmitter to start transmitting carrier wave or energy wave or start transmitting after a gap period towards one or multiple specific devices which have provided capability information to the network node to enable them to perform subsequent encryption/registration procedure.
  • the network node may be a gNB, DU, CU or CN entity, e.g., AMF, SMF or a specific entity for handling A-IoT services.
  • FIG. 8 is a flow chart describing the present method in the UE 105 for handling UE IDs in a communications system 100.
  • the UE 105 may be an Ambient-IoT device, or the UE 105 may comprise an Ambient-IoT device.
  • the method comprises at least one of the following steps to be performed by the UE 105, which steps may be performed in any suitable order than described below:
  • Step 801 This step may correspond to step 603 in FIG. 5 and step 703 in FIG. 7.
  • the UE 105 obtains a first request from the first network node 101.
  • Step 802 This step may correspond to step 604 in FIG. 6 and step 704 in FIG. 7.
  • the UE 105 provides a second UE ID to the first network node 101.
  • the second UE ID may be at least one of assigned and managed by the second network node 103.
  • the first request may be an inventory request
  • the second request may be a command request
  • the first response may be an inventory response
  • the second response may be a command response
  • FIG. 9 is a flowchart describing the present method in the first network node 101 for handling UE IDs in a communications system 100.
  • the first network node 101 may be at least one of: a base station, eNB, gNB and an intermediate UE.
  • the method comprises at least one of the following steps to be performed by the first network node 101, which steps may be performed in any suitable order than described below:
  • Step 901 This step may correspond to step 702 in FIG. 7.
  • the first network node 101 may provide information indicating at least one of: targeted user UE credentials, information and IDs etc., to the UE 105.
  • a purpose of providing this information to the UE 105 may be to indicate which UE 105 is the target UE, which needs to provide a response.
  • the information provided in step 901 may be information which may at least one of deduce and indicate the UE credentials, e.g., application ID, area ID, group ID, etc.
  • the provided ID may be at least one of: application ID, area ID, group ID, mask etc., which may be used to at least one of deduce and indicate UE credentials.
  • Step 902 This step may correspond to step 602 in FIG. 6.
  • the first network node 101 selects which UE 105 that should receive the first request by checking if the first UE ID is comprised in the first request.
  • All UEs 105 in the communications system 100 may be selected to receive the first request when the first request does not comprise the first UE ID.
  • Step 903 This step may correspond to step 603 in FIG. 6 and step 703 in FIG. 7.
  • the first network node 101 provides the first request to the UE 105 according to a result of the selecting.
  • Step 905 This step may correspond to step 605 in FIG. 6 and step 705 in FIG. 7.
  • the first network node 101 maps the second UE ID with a third UE ID.
  • the third UE ID may be an AS device ID.
  • Step 906 This step may correspond to step 606 in FIG. 6.
  • the first network node 101 may create a mapping table comprising information indicating a mapping between the first UE ID and the third UE ID.
  • Step 907 This step may correspond to step 607 in FIG. 6 and step 706 in FIG. 7.
  • the first network node 101 provides the third UE ID to the UE 105. This may be described as the first network node 101 providing information indicating the third UE ID to the UE 105.
  • Step 908 This step may correspond to step 609 in FIG. 6 and step 708 in FIG. 7.
  • the first network node 101 may obtain a first response from the UE 105.
  • the first response may comprise the third UE ID or it may not comprise the third UE ID.
  • Step 909 This step may correspond to step 609 in FIG. 6 and step 709 in FIG. 7.
  • the first network node 101 may provide the first response to the second network node 103.
  • Step 910 This step may correspond to step 610 in FIG. 6 and step 710 in FIG. 7.
  • the first network node 101 may obtain a second request from the second network node 103.
  • the second request may comprise the first UE ID or may not comprise the first UE ID.
  • Step 911 This step may correspond to step 611 in FIG. 6 and step 711 in FIG. 7,
  • the first network node 101 may determine which third UE ID that maps with the first UE ID in the second request.
  • Step 912 This step may correspond to step 612 in FIG. 6 and step 712 in FIG. 7.
  • the first network node 101 may provide a second request to the UE 105 having the third UE ID.
  • Step 913 This step may correspond to step 613 in FIG. 6 and step 713 in FIG. 7.
  • the first network node 101 may obtain a second response from the UE 105.
  • the second response may comprise the third UE ID or may not comprise the third UE ID.
  • Step 914 This step may correspond to step 614 in FIG. 6 and step 714 in FIG. 7.
  • the first network node 101 may provide a second response to the second network node 103.
  • the second response may comprise the third UE ID or does not comprise the third UE.
  • FIG. 10 is a flowchart describing the present method in the second network node 103 for handling UE IDs in a communications system 100.
  • the method comprises at least one of the following steps to be performed by the second network node 103, which steps may be performed in any suitable order than described below:
  • Step 1001 This step may correspond to step 601 in FIG. 6 and step 701 in FIG. 7.
  • the second network node 103 may provide a first request to a first network node 101.
  • the first request may comprise a first UE ID or may not comprise the first UE ID.
  • Step 1003 This step may correspond to step 610 in FIG. 6 and step 710 in FIG. 7.
  • the second network node 103 may provide a second request to the first network node 101.
  • the second request may comprise the first UE ID or may not comprise the first UE ID.
  • Step 1004 This step may correspond to step 614 in FIG. 6 and step 714 in FIG. 7.
  • the second network node 101 may obtain a second response from the first network node 101.
  • the second response may comprise the third UE ID or may not comprise the UE ID.
  • FIG. 11 is a schematic drawing illustrating the UE 105 for handling UE ID in a communications system 100.
  • the UE 105 may comprise processing circuitry 1101, e.g. one or more processors, configured to perform the methods herein.
  • the UE 105 may comprise a power supply circuitry configured to supply power to the processing circuitry 1101.
  • At least one of the UE 105 and the processing circuitry 1101 is configured to obtain a first request from a first network node 101. At least one of the UE 105 and the processing circuitry 1101 is configured to provide a second UE ID to the first network node 101. At least one of the UE 105 and the processing circuitry 1101 is configured to obtain a third UE ID from the first network node 101. At least one of the UE 105 and the processing circuitry 1101 is configured to determine the second UE ID to be the third UE ID.
  • the methods described herein for the UE 105 are respectively implemented using e.g., a computer program product 1107 or a computer program comprising instructions, i.e., software code portions, which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the UE 105.
  • the computer program product 1107 may be stored on a computer-readable storage medium 1108 e.g. a disc, a universal serial bus (USB) stick or similar.
  • the computer-readable storage medium 1108 having stored thereon the computer program product may comprise the instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the UE 105.
  • the computer-readable storage medium may be a transitory or anon-transitory computer-readable storage medium.
  • the present disclosure relates to a UE 105 for handling UE ID in a wireless communication network, wherein the UE 105 comprises processing circuitry 1101 and a memory 1105, the memory 1105 comprising instructions executable by the processing circuitry whereby the UE 105 is operative to perform any of the methods herein.
  • the UE 105 may comprise an antenna configured to send and receive wireless signals.
  • the UE 105 may comprise radio front-end circuitry connected to the antenna and to processing circuitry 1101 and configured to condition signals communicated between the antenna and the processing circuitry 1101.
  • the processing circuitry 1101 may be configured to perform the methods described herein.
  • the UE 105 may comprise an input interface connected to the processing circuitry 1101 and configured to allow input of information into the UE to be processed by the processing circuitry 1101.
  • the UE 105 may comprise an output interface connected to the processing circuitry 1101 and configured to output information from the UE that has been processed by the processing circuitry 1101.
  • the UE 105 may comprise a battery connected to the processing circuitry 1101 and configured to supply power to the UE 105.
  • the first network node 101 may comprise power supply circuitry configured to supply power to the processing circuitry 1201.
  • At least one of the first network node 101 and the processing circuitry 1201 is configured to obtain a first request from a second network node 103.
  • the first request comprises a first UE ID or does not comprise the first UE ID.
  • At least one of first network node 101 and the processing circuitry 1201 is configured to select which UE 105 that should receive the first request by checking if the first UE ID is comprised in the first request.
  • At least one of the first network node 101 and the processing circuitry 1201 is configured to obtain a second UE ID from the UE 105.
  • At least one of the first network node 101 and the processing circuitry 1201 is configured to map the second UE ID with a third UE ID.
  • At least one of the first network node 101 and the processing circuitry 1201 is configured to provide the third UE ID to the UE 105.
  • the methods described herein for the first network node 101 are respectively implemented using e.g., a computer program product 1207 or a computer program, comprising instructions, i.e., software code portions, which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the first network node 101.
  • the computer program product 1207 may be stored on a computer-readable storage medium 1208 e.g. a disc, a universal serial bus (USB) stick or similar.
  • the computer-readable storage medium 1208 having stored thereon the computer program product may comprise the instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the first network node 101.
  • the computer-readable storage medium may be a transitory or a non-transitory computer-readable storage medium.
  • the present disclosure relates to a first network node 101 for handling UE ID in a wireless communication network, wherein the first network node 101 comprises processing circuitry 1201 and a memory 1205, the memory 1205 comprising instructions executable by the processing circuitry 1201 whereby the first network node 101 is operative to perform any of the methods herein.
  • FIG. 13 is a schematic drawing illustrating the second network node 103 for handling UE ID in a communication system 100.
  • the second network node 103 may comprise processing circuitry 1301 e.g. one or more processors, configured to perform the methods herein.
  • the second network node 103 may comprise power supply circuitry configured to supply power to the processing circuitry 1301.
  • At least one of the second network node 103 and the processing circuitry 1301 is configured to provide a first request to a first network node 101.
  • the first request comprises a first UE ID or may does not comprise the first UE ID.
  • the second network node 103 further comprises a memory 1305.
  • 1306 such as comprising at least one of a transmitter, a receiver, a transceiver and one or more antennas.
  • the computer-readable storage medium may be a transitory or a non-transitory computer-readable storage medium.
  • the present disclosure relates to a second network node 103 for handling UE ID in a wireless communication network, wherein the second network node 103 comprises processing circuitry 1301 and amemory 1305, the memory 1305 comprising instructions executable by the processing circuitry 1301 whereby the second network node 103 is operative to perform any of the methods herein.
  • FIG. 14 shows an example of a communication system 1400 in accordance with some embodiments.
  • the telecommunication network 1402 includes one or more Open-RAN (ORAN) network nodes.
  • ORAN Open-RAN
  • An ORAN network node is a node in the telecommunication network 1402 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 1402, including one or more network nodes 1410 and/or core network nodes 1408.
  • ORAN Open-RAN
  • Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O- CU-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification).
  • a near-real time control application e.g., xApp
  • rApp non-real time control application

Landscapes

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

Abstract

The disclosure relates to a method performed by a user equipment, UE, (105) for handling UE identities, ID, in a communications system (100). The UE obtains (603, 703, 801) a first request from the first network node (101) and provides (604, 704, 802) a second UE ID to the first network node (101). The UE obtains a third UE ID from the first network node (101) and determine (607, 707, 804) the second UE ID to be the third UE ID.

Description

NETWORK NODES, UE AND METHODS FOR HANDLING UE IDs IN A COMMUNICATIONS SYSTEM
TECHNCIAL FIELD
[0001] The present disclosure relates generally to a first network node, a method performed by the first network node, a second network node, a method performed by the second network node, a User Equipment (UE) and a method performed by the UE.
[0002] More particularly, the present disclosure relates to handling UE IDs in a communications system. The present disclosure relates to selection of Ambient Internet of Things (Ambient-IoT, A-IoT) users in Inventory or Downlink (DL) command procedures. The present disclosure relates to methods and apparatus for selection of A-IoT users in inventory or DL command.
BACKGROUND
[0003] Zero-Energy loT & Ambient-IoT
[0004] Wireless Internet of Things (loT) devices are often battery powered and both the need to change battery and the battery lifetime may be a concern for many potential applications such as asset tracking, environmental sensors or industrial sensors. For this reason, the wireless communications industry has been interested in so-called zero-energy (ZE) devices. ZE devices refer to wireless loT devices that do not require battery replacement and often harvest energy from the environment. In some use cases, such as monitoring the temperature of foodstuffs, the ZE devices may have small batteries that are disposable, e.g., organic, compostable batteries, rechargeable or have very limited capacity.
[0005] These ZE-IoT devices may in addition be of very small form factor and could even be printable and they target ultra-low power consumption to enable operation based on either energy-harvesting from an ambient sources or back-scattering communication, cf. Radiofrequency identification (RFID). That is, instead of relying on energy for communication being provided by a battery it is instead harvested from an ambient source, such as vibrations, solar power, RF, etc. in the harvesting case, or a charge carrier wave is provided to the device which is modulated and reflected back to a reader in the back-scattering communication case. This enables energy autonomous operation during the lifetime of the devices without need for either manual replacement or charging of the batteries. Compared to existing radio access technologies this puts new requirements on the radio interface and the protocols.
[0006] Recently work on this has started in the Third Generation Partnership Project (3GPP), then referred to as ‘Ambient-IoT’. Technical Report (TR) 22.840 is being developed by Service and System Aspects 1 (SAI) to capture potential use cases, traffic scenarios, device constraints of Ambient-IoT and identify new potential service requirements as well as new Key Performance Indicators (KPI).
[0007] Meanwhile, a study on Ambient-IoT is being carried out at the 3GPP with a focus on the feasibility of meeting design targets for relevant use cases of Ambient-IoT. The outcome is being reported in TR 38.848 and the study item description is as below:
[0008] "This study targets at a new 3GPP loT technology, suitable for deployment in a 3GPP system, which relies on ultra-low complexity devices with ultra-low power consumption for the very-low end loT applications. The study shall provide clear differentiation, i.e. addressing use cases and scenarios that cannot otherwise be fulfilled based on existing 3GPP LPWA loT technology e.g. NB-IoT including with reduced peak Tx power.
[0009] In terms of energy storage, the study will consider the following device characteristics:
• Pure batteryless devices with no energy storage capability at all, and completely dependent on the availability of an external source of energy
• Devices with limited energy storage capability that do not need to be replaced or recharged manually.
Device categorization based on corresponding characteristics, (e.g. energy source, energy storage capability, passive/active transmission, etc.), may be discussed during the study, in relation to the relevant use cases. The device ’s peak power consumption shall be limited by its practical form factor for the intended use cases and shall consider its energy source.
- Identify the suitable deployment scenarios and their characteristics, at least for the use cases/services agreed in SAI ’s “Study on Ambient power -enabled internet of Things ”, comprising among at least the following aspects
• Indoor /outdoor environment.
• Base station characteristics, e.g. macro/micro/pico cells-based deployments.
• Connectivity topologies, including which node(s), e.g. base station, UE, relay, repeater, etc. can communicate with target devices. . TDD/FDD, and frequency bands in licensed or unlicensed spectrum.
• Coexistence with UEs and infrastructure in frequency bands for existing 3GPP technologies.
• Device originated and/or device terminated traffic assumption.
NOTE: There can be more than one deployment scenario identified for a use case, and a deployment scenario may be common to more than one use case.
NOTE: Where more than one deployment scenario is identified for a use case, the tradeoffs between them should also be studied.
NOTE: The study shall not prioritize deployment aspects that should be coordinated with SA, e.g. public or private network, with or without CN connection.
NOTE: A representative use case can be studied for a group of use cases that have similar requirements.
- Formulate a set of RAN design targets based on the identified deployment scenarios and their characteristics for the relevant use cases, at least including
Power consumption
Complexity
Coverage
Data rate
Positioning accuracy
NOTE: The requirements from SAI on the relevant use cases shall be taken into consideration.
NOTE: The study shall aim to provide better coverage compared to existing non-3GPP technologies for the relevant use cases.
NOTE: Other RAN design targets in relation to connection density, mobility, security, latency, reliability etc. may be discussed, if necessary for the relevant use cases. NOTE: Detailed definitions of the RAN design targets should be discussed during the study.
Compare and assess the feasibility of meeting the design targets for relevant use case on the basis of the deployment scenario(s) appropriate to it and identify assumptions on required functionality to be supported.
NOTE: This is not to require a detailed WG-level of analysis.
Note: This study shall target for an loT segment well below the existing 3GPP loT technologies, e.g. NB-IoT, eMTC, RedCap, etc. The study shall not aim to replace existing 3GPP LPWA technologies. ”
[0010] Some of the abbreviations used in the study item description above will now be spelled out:
- LPWA: Low-Power Wide-Area
- NB-IoT: Narrow Band-Internet of Things
- TDD: Time Division Duplex
- FDD: Frequency Division Duplex
- CN: Core Network
- RAN: Radio Access Network
- Tx: Transmission
- eMTC: enhanced Machine Type Communications
- WG: Working Group
[0011] Based on the outcome of the RAN study item, and further discussions, a study item is expected to continue in Release- 19 (Rel-19). In addition, depending on the progress and outcome of the Work Group (WG) level study, a work item may be started during Rel-19 as well.
- Need to have focused scope on issues such as device type(s), deployment scenario(s), topology option(s), etc. and,
- Need to address cross- Technical Specification Groups (TSG)-dependencies
- Is there a strong need and is it feasible to convert the study and hence specify Ambient- loT in Rel-19?
[0012] Deployment scenarios, use cases, services for Ambient-IoT
Deployment scenarios, use cases, services are described in clause 4 of TR 38.848 V 1.0.0. [0013] Use cases
Two sets or levels of grouping were defined. The first, Grouping A, is on the basis of the deployment environment(s) described for a use case in TR 22.840, and the second, Grouping B, is on the basis of functionality/application described in TR 22.840.
[0014] Grouping A:
- Indoor
Outdoor
- Indoor and outdoor
[0015] Grouping B:
Inventory
Sensors
- Positioning
Command
[0016] These two groupings are then used to form representative use cases (rUCs) as follows, which are used in Clause 4.2 - Deployment scenarios and connectivity topologies. rUCl: Indoor inventory rUC2: Indoor sensors rUC3: Indoor positioning rUC4: Indoor command rUC5: Outdoor inventory rUC6: Outdoor sensors rUC7: Outdoor positioning rUC8: Outdoor command
This resulted in the following mapping from SAI use cases and traffic scenarios onto RAN rUCs:
[0017]
Table 1 - Mapping between RAN representative use cases and SAI use cases in TR 38.848 V 1.0.0.
[0018] Connectivity topologies
[0019] The following connectivity topologies for Ambient-IoT networks and devices are defined for the purposes of the study. In all these topologies, the Ambient-IoT device may be provided with a carrier wave from other node(s) either inside or outside the topology. The links in each topology may be bidirectional or unidirectional. An Ambient-IoT network may be described as a network or system arranged to comprise at least one Ambient-IoT device.
[0020] A Base Station (BS), UE, assisting node, or intermediate node could be multiple BSs or UEs, respectively. The mixture of indoor and outdoor placement of such nodes is regarded as a network implementation choice. Account would need to be taken of potential impact on device or node complexity. In the connectivity topologies, this does not imply the existence of multi-hop assisting or intermediate nodes. Five different topologies are illustrated in FIGs. 1-5, respectively.
[0021] Topology 1: BS - Ambient-IoT device
[0022] FIG. 1 is a schematic drawing illustrating topology 1 in TR 38.848 V 1.0.0. In topology 1, the Ambient-IoT device 105 directly and bidirectionally communicates with a base station 101. The communication between the base station 101 and the Ambient-IoT device 105 includes at least one of Ambient-IoT data and signaling. This topology includes the possibility that the BS 101 transmitting to the Ambient-IoT device 105 is a different from the BS 101 receiving from the Ambient-IoT device 105. The arrow in FIG. 1 represents Ambient-IoT data or Ambient-IoT data signaling.
[0023] Topology 2: BS - intermediate node - Ambient-IoT device
[0024] FIG. 2 is a schematic drawing illustrating topology 2 in TR 38.848 V 1.0.0. In Topology 2, the Ambient-IoT device 105 communicates bidirectionally with an intermediate node 103 between the Ambient-IoT device 105 and base station 101. In this topology, the intermediate node 103 may be a relay, Integrated Access and Backhaul (IAB) node, UE, repeater, etc. which is capable of Ambient-IoT. The intermediate node 103 transfers at least one of Ambient-IoT data and signaling between BS 101 and the Ambient-IoT device 105. The arrow in FIG. 2 represents Ambient-IoT data or Ambient-IoT signaling.
[0025] Topology 3: BS - assisting node - Ambient-IoT device - BS
[0026] FIG. 3 is a schematic drawing illustrating topology 3 with downlink assistance in TR 38.848 V 1.0.0. FIG. 4 is a schematic drawing illustrating topology 3 with uplink assistance in TR 38.848 V 1.0.0. In Topology 3, the Ambient-IoT device 105 transmits data/signaling to a base station 101 and receives data/signaling from the assisting node 103; or the Ambient-IoT device 105 receives data or signaling from a base station 101 and transmits data or signaling to the assisting node 103. In this topology, the assisting node 103 may be a relay, IAB, UE, repeater, etc. which is capable of Ambient-IoT. The arrow in FIG. 3 and FIG. 4 represents Ambient-IoT data or Ambient-IoT signaling.
[0027] Topology 4: UE «-> Ambient-IoT device
[0028] FIG. 5 is a schematic drawing illustrating topology 4 with uplink assistance in TR 38.848 V 1.0.0. In Topology 4, the Ambient-IoT device 105 communicates bidirectionally with a UE 105. The communication between UE 105 and the Ambient-IoT device 105 includes at least one of Ambient-IoT data and signaling. The arrow in FIG. 5 represents Ambient-IoT data or Ambient-IoT signaling.
[0029] Deployment scenarios
- Deployment scenario 1: Device indoors, base station indoors
- Deployment scenario 2: Device indoors, base station outdoors
- Deployment scenario 3: Device indoors, UE-based reader
- Deployment scenario 4: Device outdoors, base station outdoors
- Deployment scenario 5: Device outdoors, UE-based reader
[0030] Device categories
[0031] Ambient-IoT devices 105 are characterized in the study according to their energy storage capacity, and capability of generating Radio Frequency (RF) signals for their transmissions.
[0032] The study considers that an Ambient-IoT device 105 has either:
- No energy storage at all; or
- Limited energy storage
[0033] Relying on these storage capacities, the study considers the following set of Ambient-IoT devices 105:
- Device A: No energy storage, no independent signal generation or amplification, i.e. backscattering transmission.
- Device B: Has energy storage, no independent signal generation, i.e. backscattering transmission. Use of stored energy may include amplification for reflected signals.
- Device C: Has energy storage, has independent signal generation, i.e., active RF components for transmission.
[0034] A limited energy storage may be different among implementations within Device B or implementations within Device C, and different between Device B and Device C. Such storage is expected to be in an order(s) of magnitude smaller than an NB-IoT device would typically include.
[0035] Device A, B, and C are able to demodulate control, data, etc. from the relevant entity in RAN according to connectivity topology.
[0036] Functional and protocol simplifications for Ambient/ZE loT
[0037] For Ambient-IoT , 3GPP will target an loT segment well below the existing Cellular Internet of Things (CIoT) technologies rather than replacement of existing 3GPP PLWA technologies. It is expected that together with simplifications in physical layer design, the higher layer design, e.g. L2 and L3, will also be much more lightweighted than the existing higher layer design in 3GPP, i.e., a minimal set of functionalities both at access stratum and non-access stratum levels, which is even more simplified compared to that adopted for the existing CIoT technologies, should be used to operate Ambient-IoT devices. One way of such simplifications is to design a communication protocol shifted from fully connection oriented with both Non-Access Stratum (NAS) and Radio Resource Control (RRC) connections between device and network to connectionless type of communication without RRC connections or even also no NAS connections between device and network so that the protocol and signaling overhead associated with the handshaking between device and network is minimized. This means Ambient-IoT devices do not setup and maintain an RRC connection with the network, also ambient loT devices do not setup and maintain Application Server (AS) context including dedicated radio bearer, logical channel, etc.
[0038] One way to implement connectionless communication is to employ message-based or self-contained transmission where context and control information associated with the signaling and data traffic is transmitted together with or right after the signaling and data traffic where in the latter case, i.e., the right after case, there is no other transmission between the context and control information and the associated signaling and data traffic carrying info that is needed for reception of the signaling/data traffic. One such example is that in DL the signaling/ data traffic is transmitted within or right after the paging message.
[0039] Objective of SI or Core part WI or Testing part WI [RP-234058, RAN SI, Release 19]
[0040] This study targets a further assessment at RAN WG-level of Ambient-IoT, a new 3GPP loT technology, suitable for deployment in a 3GPP system, which relies on ultra-low complexity devices with ultra-low power consumption for the very-low end loT applications. The study shall provide clear differentiation, i.e. addressing use cases and scenarios that may not otherwise be fulfilled based on existing 3GPP LPWA loT technology e.g. NB-IoT including with reduced peak Tx power.
[0041] General Scope
The definitions provided in TR 38.848 are taken into this SI, and the following are the exclusive general scope:
A. The overall objective shall be to study a harmonized air interface design with minimized differences where necessary for Ambient-IoT to enable the following devices: i. ~1 /zW peak power consumption, has energy storage, initial sampling frequency offset (SFO) up to ICA ppm, neither DL nor UL amplification in the device. The device’s UL transmission is backscattered on a carrier wave provided externally. ii. < a few hundred /zW peak power consumption1, has energy storage, initial sampling frequency offset (SFO) up to ICA ppm, both DL and/or UL amplification in the device. The device’s UL transmission may be generated internally by the device or be backscattered on a carrier wave provided externally.
• % is to be decided in WGs.
• Coverage design target: Maximum distance of 10-50 m with device indoors as per TR 38.848: “... a range that WGs can sub-select within”.
• For Topologies 1 & 2, i.e. UE as intermediate node under Network (NW) control, per TR 38.848, with no RRC states, no mobility, i.e. at least no cell selection/re- selection -like function, no Hybrid Automatic Repeat reQuest (HARQ), no Automatic Repeat reQuest (ARQ).
NOTE 1: It is to be understood that “< a few hundred /zW” means WGs are not tasked with setting a particular value, and that it will be for WG discussions to determine if a presented design with corresponding power consumption satisfies the “< a few hundred /zW” requirement.
B. Deployment Scenarios with the following characteristics, referenced to the tables in Clause 4.2.2 of TR 38.848:
• Deployment scenario 1 with Topology 1 o Base station and coexistence characteristics: Micro-cell, co-site
• Deployment scenario 2 with Topology 2 and UE as intermediate node, under network control o Base station and coexistence characteristics: Macro-cell, co-site o The location of intermediate node is indoor.
C. Frequency Range 1 (FR1) licensed spectrum in FDD. D. Spectrum deployment in-band to New Radio (NR), in guard-band to LTE/NR, in standalone band(s). LTE is short for Long Term Evolution.
E. Traffic types Device-Originated - Device-Terminated Triggered (DO-DTT), DT, with focus on rUCl, e.g. indoor inventory, and rUC4, e.g. indoor command.
• From RAN# 104, the study will assess whether the harmonized air interface design, e.g. per bullet ‘A’ above, may address the Device-originated autonomous (DO- A) use case, only to identify which part(s) of the harmonized air interface design, e.g. per bullet ‘A’ above, is/are not sufficient for the DO-A use case.
Transmission from Ambient-IoT device, including backscattering when used, may occur at least in UL spectrum.
[0042] The following objectives are set within the General Scope:
1. Evaluation assumptions a) Conclude at least the following aspects of design target left to WGs in Clause 5, i.e. RAN design targets, of TR 38.848, i.e. RANI. o Clause 5.3: Applicable maximum distance target values(s). o Clause 5.6: Refine the definition of latency suitable for use in RAN WGs. o Clause 5.8: 2D distribution of devices. b) Define necessary further evaluation assumptions of deployment scenarios for coverage and coexistence evaluations, i.e.RANl, RAN4. c) Identify basic blocks/components of possible Ambient-IoT device architectures, taking into account state of the art implementations of low-power low-complexity devices which meet the RAN design target for power consumption and complexity, i.e. RANI. d) Define link budget calculation for coverage, including whether/how to model carrier wave from node(s) inside or outside the connectivity topology.
NOTE: Assessment performance of the design targets is within the study of feasibility and necessity of proposals in the following objectives, e.g. by inspection of reference implementations in the field, simulations, analytically.
NOTE: strive to minimize evaluation cases in RANI. 2. Study necessary and feasible solutions for Ambient-IoT as prescribed in the General Scope, including decisions on which functions, procedures, etc. are needed and not needed, and ensuring at least the required functionalities in Section 6.2 of TR 38.848.
Study of positioning in Rel-19 is RAN3-led, limited to functionalities which would have no, or minimal, specification impact (note: this does not imply any decision relating to WI creation).
Study the feasibility and required functionalities for proximity determination, e.g. coordination with SA3 is required for privacy aspects.
• RANI -led:
For the Ambient-IoT DL and UL: o Frame structure, synchronization and timing, random access o Numerologies, bandwidths, and multiple access o Waveforms and modulations o Channel coding o Downlink channel/signal aspects o Uplink channel/signal aspects o Scheduling and timing relationships o Study necessary characteristics of carrier-wave waveform for a carrier wave provided externally to the Ambient-IoT device, including for interference handling at Ambient-IoT UL receiver, and at NR base station.
For Topology 2, there is no difference in physical layer design from Topology 1.
• RAN2-led: o Study and decide which functions are needed for an Ambient-IoT compact protocol stack and lightweight signaling procedure to enable DO-DTT and DT data transmission and study those functions.
For example:
■ Paging
■ Random access ■ Data transmission, including necessary radio resource control aspects, respecting the limitation in the General Scope
■ Interactions with upper layers
For functionalities not listed above, they are studied only if found essential.
• RAN3-led: o Identify necessary impacts on signaling and procedures for CN-RAN interface, to enable:
■ Paging
■ Device context management
■ Data transport o Identify RAN architecture aspects, including whether support for split architecture is necessary. o Identify potential solutions for locating an Ambient-IoT device with no specification impact, e.g. reusing existing user location report, or minimal specification impact to convey location information to core network.
• RAN4-led: o Coexistence study of Ambient-IoT and NR/LTE. o RF requirements study for Ambient-IoT:
■ Ambient-IoT BS transmission and reception
■ Ambient-IoT Device, as per the General Scope, transmission and reception
■ Intermediate node, e.g. UE, as per the General Scope, transmission and reception
RAN2 and RAN3 are expected to identify RAN-CN functional split in coordination with SA2.
Note: This study shall target for an loT segment well below the existing 3GPP loT technologies, e.g. NB-IoT, eMTC, RedCap, etc. The study should not aim to replace existing 3GPP LPWA technologies.
[0043] There currently exist certain challenge(s).
[0044] 3GPP is currently discussing supporting inventory or DL command use case for Ambient-IoT users. These use cases may target specific devices or device groups. Thus, if Application Function (AF) initiate inventory or command procedure, then the network must provide a method or framework, e.g., how to define select command or what information it may carry, so that specific devices may be targeted.
[0045] In addition, if a large set of devices are addressed by a select/inventory command, then the responses from these devices may lead to overload, congestion and interference that causes delays in completing the command. It is not always possible to physically steer the broadcast signal as to "scan" through the area.
[0046] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges.
SUMMARY
[0047] An objective is to obviate at least one of the above disadvantages and to provide improved handling of UE IDs in a communications system.
[0048] According to a first aspect, the objective is achieved by a method performed by a UE for handling UE ID in a communications system, the method comprising one or more of: obtaining a first request from the first network node;
- providing a second UE ID to the first network node; and obtaining information indicating a third UE ID from the first network node; and determining the second UE ID to be the third UE ID.
[0049] According to a second aspect, the objective is achieved by a method performed by a first network node for handling UE ID in a communications system, the method comprising one or more of: obtaining a first request from the second network node, wherein the first request may comprise a first UE ID or may not comprise the first UE ID; selecting which UE that should receive the first request by checking if a first UE ID is comprised in the first request;
- providing the first request to the UE according to a result of the selecting; obtaining a second UE ID from the UE; - mapping the second UE ID with a third UE ID; and providing information indicating the third UE ID to the UE.
[0050] According to a third aspect, the objective is achieved by a method performed by a second network node for handling UE ID in a communications system, the method comprising:
- providing a first request to a first network node, wherein the first request may comprise a first UE ID or may not comprise the first UE ID.
[0051] According to a fourth aspect, the objective is achieved by a UE for handling UE ID in a communications system comprising:
- processing circuitry; and
- power supply circuitry configured to supply power to the processing circuitry, wherein the processing circuitry is configured to: obtain a first request from a first network node; provide a second UE ID to the first network node; obtain a third UE ID from the first network node; and to determine the second UE ID to be the third UE ID.
[0052] According to a fifth aspect, the objective is achieved by a first network node for handling UE ID in a communications system. The first network node comprises:
- processing circuitry; and
- power supply circuitry configured to supply power to the processing circuitry, wherein the processing circuitry is configured to: obtain a first request from a second network node, wherein the first request comprises a first UE ID or does not comprise the first UE ID;
- select which UE that should receive the first request by checking if the first UE ID is comprised in the first request;
- provide the first request to the UE according to a result of the selecting; obtain a second UE ID from the UE;
- map the second UE ID with a third UE ID; and to
- provide the third UE ID to the UE.
[0053] According to a sixth aspect, the objective is achieved by a second network node for handling UE ID in a communications system, the second network node comprising:
- processing circuitry ; and
- power supply circuitry configured to supply power to the processing circuitry, wherein the processing circuitry is configured to: - provide a first request to a first network node, wherein the first request comprises a first UE ID or may does not comprise the first UE ID.
[0054] Thanks to the selection of which UE that should receive the first request, only the targeted UEs will receive the first request and no UEs will unnecessarily receive the first request.
[0055] Certain embodiments may provide one or more of the following technical advantage(s).
[0056] Enabling RAN node to select devices targeting for inventory or DL command procedure.
[0057] If such behavior is not considered, then all users may respond lead to one, two or more of:
• Congestion, and
• Resource wastage, and o Physical resources are wasted. o Processing resources are wasted as the RAN will receive unnecessary/untargeted transmissions and engage in decoding/reception procedures
• Energy wastage at the user side if it responds unnecessarily which are already energy starved.
[0058] The present disclosure may limit overload and interference in the communications system.
[0059] The present disclosure is not limited to the features and advantages mentioned above. A person skilled in the art will recognize additional features and advantages upon reading the following detailed description.
BRIEF DESCRIPTION OF THE DRAWINGS
[0060] The present disclosure will now be described in more detail by way of example only in the following detailed description by reference to the appended drawings in which: FIG. 1 is a schematic drawing illustrating topology 1.
FIG. 2 is a schematic drawing illustrating topology 2.
FIG. 3 is a schematic drawing illustrating topology 3.
FIG. 4 is a schematic drawing illustrating topology 3.
FIG. 5 is a schematic drawing illustrating topology 4. FIG. 6a is a schematic drawing illustrating a communications system.
FIG. 6b is a signaling diagram illustrating a method.
FIG. 7 is a signaling diagram illustrating a method.
FIG. 8 is a flow chart illustrating a method.
FIG. 9 is a flow chart illustrating a method.
FIG. 10 is a flow chart illustrating a method.
FIG. 11 is a schematic block diagram illustrating a UE.
FIG. 12 is a schematic block diagram illustrating a first network node.
FIG. 13 is a schematic block diagram illustrating a second network node.
FIG. 14 is a schematic drawing illustrating an example of a communication system.
FIG. 15 is a schematic drawing illustrating a UE.
FIG. 16 is a schematic drawing illustrating a network node.
FIG. 17 is a block diagram illustrating a virtualization environment.
[0061] The drawings are not necessarily to scale, and the dimensions of certain features may have been exaggerated for the sake of clarity. Emphasis is instead placed upon illustrating the principle.
DETAILED DESCRIPTION
[0062] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.
[0063] FIG. 6a is a schematic drawing illustrating a communications system 100. FIG. 6a depicts a non-limiting example of a communications system 100, which may be a wireless communications system, sometimes also referred to as a wireless communications network, cellular radio system, or cellular network, in which the present disclosure may be implemented. The communications system 100 may be a 5G system, 5G network, NR-U or Next Gen system or network. The communications system 100 may alternatively be a younger system or older system than a 5G system, such as e.g. a 2G system, a 3G system, a 4G system, a 6G system, a 7G system etc. The communications system 100 may support other technologies such as, for example, Long-Term Evolution (LTE), LTE-Advanced/LTE-Advanced Pro, e.g. LTE Frequency Division Duplex (FDD), LTE Time Division Duplex (TDD), LTE Half-Duplex Frequency Division Duplex (HD-FDD), LTE operating in an unlicensed band, NB-IoT. Thus, although terminology from 5G/NR and LTE may be used in this disclosure to exemplify, this should not be seen as limiting to only the aforementioned systems.
[0064] The communications system 100 comprises one or a plurality of network nodes, whereof a first network node 101 and a second network node 103 are depicted in the nonlimiting example of FIG. 6a. Any of the first network node 101, and the second network node 103 may be a radio network node, such as a radio base station, or any other network node with similar features capable of serving a user equipment, such as a wireless device or a machine type communication device, in the communications system 100. The first network node 101 may be an eNB and the second network node 103 may be a gNB. The first network node 101 may be a first eNB, and the second network node 103 may be a second eNB. The first network node 101 may be a first gNB, and the second network node 103 may be a second gNB. The first network node 101 may be a MeNB and the second network node 103 may be a gNB. Any of the first network node 101 and the second network node 103 may be co-localized, or they may be part of the same network node. The first network node 101 may be referred to as a source node or source network node, whereas the second network node 103 may be referred to as a target node or target network node.
[0065] The first network node 101 may be a base station, a reader, a UE-based reader, a UE, an intermediate UE, an assisting node, just to mention some examples. The second network node may be a base station, a Core Network node (CN node), an Ambient-IoT Function (Ambient-IoTF, AIoTF), an Access and Mobility Management Function (AMF), an Application Function (AF), just to mention some examples.
[0066] One or both of the first network node 101 and the second network node 103 may be Ambient-IoT capable.
[0067] The communications system 100 covers a geographical area which may be divided into cell areas, wherein each cell area may be served by a network node, although, one network node may serve one or several cells. For example, the communications system 100 may comprise a first cell and a second cell (not illustrated in FIG. 6a). Note that any n number of cells may be comprised in the communication system 100, where n is any positive integer. A cell is a geographical area where radio coverage is provided by the network node at a network node site. Each cell is identified by an identity within the local network node area, which is broadcast in the cell. The first network node 101 may serve the first cell, and the second network node 103 may serve the second cell. Any of the first network node 101 and the second network node 103 may be of different classes, such as, e.g., macro base station (BS), home BS or pico BS, based on transmission power and thereby also cell size. Any of the first network node 101 and the second network node 103 may be directly connected to one or more core networks, which are not depicted in FIG. 6a for the sake of simplicity. Any of the first network node 101 and the second network node 103 may be a distributed node, such as a virtual node in the cloud, and it may perform its functions entirely on the cloud, or partially, in collaboration with another network node. The first cell may be referred to as a source cell, whereas the second cell may be referred to as a target cell.
[0068] One or aplurality of UEs 105 is comprised in the communication system 100. Only one UE 105 is exemplified in FIG. 6a for the sake of simplicity. A UE 105 may also be referred to simply as a device. The UE 105, e.g. an LTE UE or a 5G/NR UE or an Ambient-IoT (AIoT, A-IoT), may be a wireless communication device which may also be known as e.g. at least one of a wireless device, a mobile terminal, wireless terminal and mobile station, a mobile telephone, cellular telephone, or laptop with wireless capability, just to mention some examples. The UE 105 may be Ambient-IoT capable. The UE 105 may be a device by which a subscriber may access services offered by an operator’s network and services outside the operator’s network to which the operator’s radio access network and core network provide access, e.g. access to the Internet. The UE 105 may be any device, mobile or stationary, enabled to communicate over a radio channel in the communications system 100, for instance but not limited to e.g. UE, mobile phone, smart phone, sensors, meters, vehicles, household appliances, medical appliances, media players, cameras, Machine to Machine (M2M) device, Internet of Things (IOT) device, A-IoT device, terminal device, communication device or any type of consumer electronic, for instance but not limited to television, radio, lighting arrangements, tablet computer, laptop or Personal Computer (PC). The UE 105 may be at least one of portable, pocket storable, hand held, computer comprised, or vehicle mounted devices, enabled to communicate voice and data, via the radio access network, with another entity, such as another UE, a server, a laptop, a Personal Digital Assistant (PDA), or a tablet, Machine-to-Machine (M2M) device, device equipped with a wireless interface, such as a printer or a file storage device, modem, or any other radio network unit capable of communicating over a radio link in the communications system 100.
[0069] The UE 105 is enabled to communicate wirelessly within the communications system 100. The communication may be performed e.g. between two UEs 105, between a UE 105 and a regular telephone, between the UE 105 and a network node, between at least one of network nodes, and between the UE 105 and a server via the radio access network and possibly one or more core networks and possibly the internet.
[0070] The UE 105 may comprise either no energy storage at all, or it may comprise limited storage.
[0071] The UE 105 may be of one of the following types:
[0072] UE type A: The UE does not comprise any energy storage, no independent signal generation/amplification, i.e. backs cattering transmission.
[0073] UE type A B: The UE comprises energy storage, no independent signal generation, i.e. backscattering transmission. Use of stored energy may include amplification for reflected signals.
[0074] UE type C: The UE comprises energy storage, it comprises independent signal generation, i.e., active RF components for transmission.
[0075] A limited energy storage may be different among implementations within UE B or implementations within UE C, and different between UE B and UE C. Such storage is expected to be in an order(s) of magnitude smaller than an NB-IoT device would typically include.
[0076] UE A, B, and C are able to demodulate control, data, etc. from the relevant entity in RAN according to connectivity topology.
[0077] As mentioned earlier, the first network node 101 may be an intermediate UE and this means that it operates between the UE 105 and a second network node 103. The intermediate may operate as a reader. The intermediate UE may be a normal UE plus some potential enhancement. This is illustrated in FIG. 2.
[0078] The first network node 101 may be configured to communicate in the communications system 100 with the UE 105 over a first communication link, e.g., a radio link. The second network node 103 may be configured to communicate in the communications system 100 with the UE 105 over a second communication link, e.g., a radio link. The first network node 101 may be configured to communicate in the communications system 100 with the second network node 103 over a third communication link, e.g., a radio link or a wired link, although communication over more links may be possible.
[0079] It should be noted that the communication links in the communications system 100 may be of any suitable kind comprising either a wired or wireless link. The link may use any suitable protocol depending on type and level of layer (e.g. as indicated by the Open Systems Interconnection (OSI) model) as understood by the person skilled in the art. [0080] The communications system 100 may comprise one of the following deployment scenarios:
Deployment scenario 1: UE indoors, base station indoors
Deployment scenario 2: UE indoors, base station outdoors
Deployment scenario 3: UE indoors, UE-based reader
Deployment scenario 4: UE outdoors, base station outdoors
Deployment scenario 5: UE outdoors, UE-based reader
[0081] Assumptions
[0082] For UL transmissions,
• The passive device requires CW, e.g. transmits UL using backscatter manner.
• The active does not need CW and may generate UL independently.
[0083] Ambient-IoT user may be based on
• Passive device, e.g. requires CW support for UL, also referred to as o device A, A+, B-, B o device (i), (ii), e.g. without independent UL, defined in RAN SID RP-234058 o the UL from passive device may be referred as backscattered UL
• Active device, also referred to as o B+, C-,C
■ In TR, B is referred to as passive device, but B+ may be classified as active device or low end active device. o device (ii) with independent UL defined in RAN SID RP-234058. o the UL from active device may be referred as active UL.
[0084] The term A, e.g. low end passive device, B, e.g. high end passive device, C, e.g. active device, referred to devices described in TR 38.848.
[0085] The inventory command which initiates the inventory procedure may also be referred to as select command or Q command, typically used terminology in RFID.
[0086] In response to inventory command, the user initiates random-access procedure and provide inventory reporting to the application hosted by network
[0087] In this disclosure, the terms polling, poll and paging, page, inventory, query, interrogate, is used to represent one or more than one signal transmitted by a network node broadcast wise or specially to a dedicated UE 105. The purpose of the signal is to facilitate/serve/manage/command one or more than one UE 105 to synchronize to the network node, DL/UL synchronize to a reference time/frame/symbol or synchronize to one or more than one signal which the UE 15 receives from the network node, or synchronize based on a predefined rule, receive DL data, response and transmit UL data correctly in intended resources. The content of such signal may be a particular reference signal or a signal carrying at least one of control information and data. Such signal may be transmitted periodically or a periodically configured by the network node.
[0088] In this disclosure, the terms Ambient-IoT device, A-IoT UE, A-IoT device, device, UE or user are used interchangeably without losing the meaning, and the reference number 105 may be used herein when referring to any of them.
[0089] The following terminologies are used herein to represent different device types, also referred to as UE types:
• Device 1: ~1 pW peak power consumption, has energy storage, initial sampling frequency offset (SFO) up to 10X ppm, neither DL nor UL amplification in the device. The device’s UL transmission is backscattered on a carrier wave provided externally.
• Device 2a: < a few hundred pW peak power consumption, has energy storage, initial sampling frequency offset (SFO) up to 10X ppm, both DL and/or UL amplification in the device. The device’s UL transmission is backscattered on a carrier wave provided externally.
• Device 2b: < a few hundred pW peak power consumption, has energy storage, initial sampling frequency offset (SFO) up to 10X ppm, both DL and/or UL amplification in the device. The device’s UL transmission is generated internally by the device.
[0090] The present disclosure proposes select command and signaling behavior or content which enables network or application to target specific devices. The devices may be selected based on range of information which is available at application/ AF or CN or RAN side. Further, the proposed signaling method by which select command may be transmitted to selected or intended group of devices/users. The Ambient-IoT function initiates an inventory request to selected users, corresponding to their CN/device IDs. The reader or gNB receives this request and sends the select command to indicated devices. In one method, the select command may be sent to all devices, e.g., in a broadcast manner but the command may specify the indicated device IDs or credentials in the select command, e.g.(a) the IDs are same which originally mentioned by CN/AF or (b) the IDs that map to IDs mentioned by CN/AF, then only targeted devices, e.g. device IDs, will be prepared to move forward with inventory or command procedure. Other devices after reading a select command which don’t find their information or IDs in the command may ignore the command and continue to sleep or remain suspended. No access is initiated by such devices.
[0091] Means to divide the targeted devices for, e.g., a command is proposed based on the scope of the request and stored info in the devices such that at each moment in time only a subset of the devices replies to the request and the logic for how the reader may go through all subsets of the devices as to accomplish a complete command towards all targeted devices while limiting overload and interference.
[0092] The present disclosure will now be described with reference to FIG. 6b. FIG. 6b is a flow chart illustrating a method. The method comprises at least one of the following steps, which steps may be performed in any suitable order than described below:
[0093] Step 601: The second network node 103 sends a first request to the first network node 101. The first request may be an inventory request. The first request may be a request to request UEs 105 to provide their UE ID and possibly more information. The first request may be a request for status of the UE 105, e.g. if the UE is present in the communication system 100 or not. The first request may be made in a broadcast manner, compared with paging, as the sender may not really be aware of what UEs 105 are available. The first request may comprise information as to get a subset of the UEs 105 to respond to the first request. The information to get a subset of UEs may be in the form of a first UE ID, e.g. CN device ID. The first UE ID is allocated by the second network node 103. In other words, the first request may comprise a first UE ID for each UE 105 that should response to the first request. If no first UE ID is comprised in the first request, then all UEs 105 in the communication system 100, e.g. all UEs in a particular region, may response to the first request.
[0094] Step 602: The first network node 101 receives the first request from the second network node 103. Based on the first request, the first network node 101 selects or determines which UEs 105 that should receive the first request. The selection is done based on whether or not the first request comprises a first UE ID. As mentioned above, the first request may comprise zero, one, two or more first UE IDs. When the first request does not comprise any first UE ID, the first network node 101 may determine to send the first request to all UEs 105, e.g. all UEs 105 in the communication system 100, in a certain region of the communication system 100 etc., i.e. a broadcast of the first request. When the first request comprises one, two or more first UE IDs, the first network node 101 may select the UEs 105 with the first UE IDs to receive the first request. Thus, the first UE ID(s) in the first request indicates which UE(s) 105 that should receive the first request. [0095] Step 603: The first network node sends the first request to the UE 105.
The UE 105 receives the first request and allocates a second UE ID to itself. The second UE ID may be a random ID. The UE 105 sends information indicating the second UE ID to the first network node 101.
[0096] Step 604: The first network node 101 receives the second UE ID from the UE 105.
[0097] Step 605: The first network node 101 maps the second UE ID with a third UE ID.
The third UE ID has been allocated by the first network node 101. The third UE ID may be an AS device ID.
[0098] Step 606: The first network node 101 may create a mapping table with mapping between the third UE ID allocated by the first network node 101 and the first UE ID allocated by the second network node 103.
[0099] Step 607: The first network node 101 sends information indicating the third UE ID to the UE 105. The UE 105 may store the information indicating the third UE ID. The UE 105 determines that the second UE ID is the third UE ID.
[0100] Step 608: The UE 105 sends a first response to the first network node 101. The first response is a response to the first request in step 603. The first response may comprise the third UE ID.
[0101] Step 609: The first network node 101 receives the first response comprising the third UE ID from the UE 105. The first network node 101 sends the first response to the second network node 103. The first response sent to the second network node 103 may or may or may not comprise the third UE ID.
[0102] Step 610: The second network node 103 sends a second request to the first network node 101. The first network node 101 obtains the second request from the second network node 103. The second request may be a command request. The second request may be e.g. a read or write command towards a known UE 105 using dedicated signaling as to perform a command operation, e.g. read or write to/of memory in the designated UE 105. The second request may comprise instructions to read or write data from/to the UE 105. The second request may implicitly comprise an inventory request. The second request comprises one, two or more first UE IDs which indicate which UEs 105 to send the second request to.
[0103] Step 611: The first network node 101 searches the mapping table to find the third UE ID that maps to the first UE ID that was in the second request in step 610.
[0104] Step 612: The first network node 101 sends the second request to the UE 105, i.e. the UE 105 indicated by the first UE ID. [0105] Step 613: The UE 105 sends a second response to the first network node 101. The second response comprises the third UE ID. The second response may be a command response. The second response is a response to the second request in step 612.
[0106] Step 614: The first network node 101 receives the second response from the UE 105. The first network node 101 sends the second response to the second network node 103. The second response is a response to the second request in step 610. The second response sent to the second network node 103 may or may not comprise the third UE ID.
[0107] FIG. 7 is a signaling diagram illustrating a method. The method in FIG. 7 comprises at least one of the following steps, which steps may be performed in any suitable order than described below. In FIG. 7, the first network node 101 may be represented by a gNB or reader, the second network node 103 may be represented by a CN or an AIoTF or an AMF or an AF and the UE 105 may be represented by a device.
[0108] Step 701: This step corresponds to step 601 in FIG. 6b. The second network node 103 provides an inventory request to the first network node 101. The inventory request may comprise an identity of the UE, e.g. CN ID, or device IDs. The CN ID or device ID is the ID of device, i.e. the UE 105, which is allocated by the second network node 103, e.g. the CN/network. The device ID is also referred to as CN ID. In order to do inventory request, the second network node 103 may initiate request for specific UEs 105 corresponding to their device ID or CN IDs. The ID is not mandatory to comprise in inventory request. If no ID is comprised in the inventory request, then all UEs 105 in the region may respond to the inventory request. The CN ID or device ID may be referred to as a first UE ID. The first network node 101 obtains the inventory request from the second network node 103.
[0109] The inventory request is a request to request UEs 105 to provide their UE ID and possibly more information. The inventory request may be done in a broadcast manner, compared with paging, as the sender is not really aware of what UEs 105 are available. The request may comprise information as to get a subset of the UEs 105 to answer which is done by including the CN device ID in the request. The inventory request may be a request for a status of the UE 105, if UE 105 is present or not.
[0110] Step 702: This step corresponds to step 601 in FIG. 6b. The first network node 101 provides a select command to the UE 105. The select command may comprise information indicating targeted user credentials, information, IDs etc. The UE 105 obtains the select command from the first network node 101. The select command is provided to the UE 105 indicated by the CN ID or device ID in the inventory request in step 701, if present. The selected command is provided to all UEs 105 in the region if no CN ID or device ID was comprised in the inventory request in step 701.
[0111] Step 703: This step corresponds to step 603 in FIG. 6b. The first network node 101 provides a query or scheduling and the inventory request to the UE 105, i.e. the inventory request from step 701.
[0112] Step 704: This step corresponds to step 604 in FIG. 6b. The UE 105 provides a random ID to the first network node 101. The first network node 101 obtains the random ID from the UE 105. Random ID is selected by UE 105 which is used by the first network node 101 for collision resolution among different UEs in the cell. The random ID may be referred to as a second UE ID.
[0113] Step 705: This step corresponds to step 605 and step 606 in FIG. 6b. The first network node 101 promotes the random ID as the Access Stratum (AS) device ID. The first network node 101 may create a mapping table between the AS device and the CN device ID. AS device ID is the context ID or local context ID used by the first network node 101, e.g. gNB, for a given UE 105 in the cell. It may be considered as credentials of the UE 105 which may help first network node 101, e.g. gNB, to recognize the UE 105. AS device ID may be mapped to at least one of CN ID and device ID of the UE 105. The AS device may be referred to as a third UE ID.
[0114] A random ID of the UE 105 may be promoted to AS ID if the user is successfully resolved, e.g. contention resolution successful, provided this random ID will be barred from usage for other UE 105 in the same cell. Such methodology does not exist in NR. But it is also very unlikely to happen as it involves too many SI updates, e.g. it is hard to update the barred IDs.
[0115] Step 706: This step corresponds to step 607 in FIG. 6b. The first network node 101 provides an acknowledgement (ACK) and the AS device ID to the UE 105. The UE 105 obtains the ACK and the AS device ID from the first network node 101.
[0116] Step 707: This step corresponds to step 607 in FIG. 6b. The UE 105 stores the random ID as the AS device ID provided by the first network node 101.
[0117] Step 708: This step corresponds to step 608 in FIG. 6b. The UE 105 provides an inventory response and the AS device ID to the first network node 101. The inventory response is in response to the inventory request in step 703. The first network node 101 obtains the inventory response and AS device ID from the UE 105. [0118] Step 709: This step corresponds to step 609 in FIG. 6b. The first network node 101 provides an inventory response to the second network node 103. The inventory response is in response to the inventory request in step 701. The second network node 103 obtains the inventory response from the first network node 101.
[0119] Step 710: This step corresponds to step 610 in FIG. 6b. The second network node 103 provides a command request to the first network node 101. The command request may comprise a CN device ID. The first network node 101 obtains the command request and the CN device ID from the second network node 103.
[0120] A command request may be e.g. a read or write command towards a known UE using dedicated signaling as to perform a command operation, e.g. read or write to/of memory in the designated UE 105 which is designated with the CN device ID. The command may mean to read or write data from/to the UE 105. The command request may implicitly include inventory in some cases. Inventory may still be performed for known or present UE 105, this is useful if the UE 105 is at risk of getting stolen, or if the device attached to product is very expensive, then the known UE 105 is continuously inventory. In order to execute the command, i.e. to act according to the command request, the UE 105 may have gone through either of the procedures - inventory or registration or some sort of validation/authentication/applied security procedures.
[0121] Step 711: This step corresponds to step 611 in FIG. 6b. The first network node 101 finds the mapping AS device ID by searching a mapping table between the AS device ID and CN device ID. For example, if the command request comprises CN device ID 11111, then a lookup in the mapping table will show that this corresponds to AS device ID aaaaa, see the examples provided in Table 3 and Table 4 below.
[0122] Step 712: This step corresponds to step 612 in FIG. 6b. The first network node 101 provides a query or scheduling to the UE 105. The first network node 101 provides a command request and AS device ID to the UE 105. The UE 105 obtains the query or scheduling, command request and AS device ID from the first network node.
[0123] Step 713: This step corresponds to step 613 in FIG. 6b. The UE 105 provides a command response and AS device ID to the first network node 101. The command response is in response to the command request in step 712. The first network node 101 obtains the command response and AS device ID from the UE 105.
[0124] Step 714: This step corresponds to step 614 in FIG. 6b. The first network node 101 provides a command response to the second network node 103. The command response is in response to the command request in step 710. The second network node 103 obtains the command response from the first network node 101.
[0125] An overview of the different UE IDs illustrated in FIG. 7 is shown in Table 2 below.
Table 2 - IDs [0126] The mapping table mentioned in steps 705 and 711 may be, for example, as seen in one of Table 3 and Table 4:
Table 3 - Mapping table
[0127]
Table 4 - Mapping table [0128] In addition to the ID’s exemplified above, there may be more IDs, application ID, temporary ID allocated by the second network node 103, e.g. Global Unique Temporary Identifier (GUTI ) or Temporary Mobile Subscriber Identities (TMSI) which is a part of GUTI. GUTI and TMSI are examples of temporary IDs. The application ID, e.g. Electronic Product Code (EPC) or other ID, which may be mapped with the CN device ID, e.g. Subscriber Permanent Identifier (SUPI) or Subscriber Concealed Identifier (SUCI). Upon verification/authentication of the UE 105, then for given with CN device ID, the first network node may allocate a temporary CN device ID, e.g. GUTI or TMSI allocated by the second network node 103 which may be mapped to AS device ID allocated by the first network node 101. In this manner, the real or default CN device ID, e.g. SUPI or SUCI, may be made hidden to the first network node 101. The first network node may only know the temporary CN device ID, e.g. GUTI or TMSI which is mapped to the first network node 101 allocated as ID.
[0129] User Selection for Inventory Procedure
[0130] The RAN based inventory or DL command in one or more signaling which indicates or specifies target group for which the belonging user(s), i.e., the users identified by the target group may respond to inventory command or DL command and may provide inventory or other reporting or proceed with inventory, access, read or write procedure. The read or write procedure at the device side may typically be represented by DL command use case/procedure.
[0131] The inventory command may indicate at least one of the following parameters or information for which network intends to perform inventory for the associated UEs 105 where the indicated information may be at least one of:
• Specific user ID or device IDs
• Specific service or service ID(s)
• Different services are modeled based on Quality of Service (QoS), reliability target, etc.
• Specific reader ID(s), .e.g. RAN node, such as gNB, UE or intermediate node.
• Area/region ID.
• This area information or area ID is meant to be in the CW signaling or DL or select command signaling for the UE 105 to know whether to respond to inventory.
• Area ID may be basically a bit string, e.g., representing a building, say some x bits representing area but the device does not need to know what it represents. • User group ID.
• Device categories or types.
• Inventory ID.
• Inventory ID may refer to a given procedure which may be defined with specific policies, e.g., how periodically this inventory needs to be done, e.g., the periodicity may be defined every day, or once in week, etc.
• Associated owner, i.e., UE 105 may be hardcoded with owner ID and only UEs 105 associated to indicated owner may respond. The owner may be identified with, e.g., Public Land Mobile Network (PLMN) ID, realm of Network Access Identifier (NAI), Private Enterprise Network (PEN), Stand-alone Non-Public Network (SNPN) ID. The owner ID may be a separate field hardcoded in the device, or part of, e.g., the device id.
[0132] In view of the above, the selection of IDs may also be based on masking or applied function. For e.g., the inventory command may indicate that the user ID beginning from 6, e.g. in hexadecimal format, should respond to inventory command; it means other UEs 105 whose IDs don’t start from 6 may respond to the inventory command. Hence, the network, e.g. at least one of the first network node 101 and the second network node 103, may define user ID format and flexibly specify and mask some values to target the UEs 105 accordingly. For example, network may define 5 letter/word long hexa decimal format, and in one example, network may indicate 0x1 lx in inventory command, e.g. 2 letters may be masked, which means maximum 16A2 users may respond with their IDs matching to the indicated value.
[0133] In above the user ID or device ID may be based on at least one of:
• Device ID, e.g., like o CN ID like SUPI/SUCI in 3 GPP o Transaction Identifier (TID) in RFID
• Application ID o For example, CN ID or device ID may be mapped application ID, e.g. GPSI- like ID o EPC in RFID
• Temporary ID o Temporary ID, which CN may allocate based on above IDs, e.g.,
■ GUTI, TMSI, handle ID in case of RFID o Temporary ID allocated by reader or RAN node, e.g. gNB, intermediate node or UE.
• RAN scope ID or gNB or reader allocated ID.
• Part or function or subset of IDs, e.g., last 16 bits of GUTI.
[0134] The inventory command may be triggered by at least one of:
. AF,
• RAN node, and
• CN node.
[0135] In above regarding RAN or CN initiated inventory command may be still controlled AF, e.g., AF may initiate periodic inventory, which means RAN or CN may decide or implement periodic inventory command without AF requires to initiate every time.
[0136] The inventory command may target user group which has not been registered yet. For example, the inventory command may be provisioned with a flag, if the UE 105 is registered or not. Based on flag status, non-registered UE 105 may respond to the inventory command, e.g., if such flag is set. Otherwise, all UEs 105 within the target group may respond irrespective of prior registration status.
[0137] The inventory command may target UE groups which have been inventoried within time window, e.g., last X units of time. The inventory command may specify the time window, e.g., X units and set the flag, so that all the UEs 105 within the target may respond except the UEs 105 which are inventoried in this X unit time window. In another example, the inventory command may specify duration of time window, or start and stop time of window, e.g. with an assumption that the UE 105 has maintained some sort of timer.
[0138] In the above, the inventory command may indicate inventory ID which may refer to inventory policy. As already indicated, one policy may be the periodicity of inventory associated with given inventory ID. Another example may be that an Ambient-IoT device 105 is required to transmit specific information as part of inventory reporting for inventory command associated with given inventory ID. Below Table 5 presents a 2 -bit inventory ID, which lists inventory report type requirement for given Inventory ID.
Table 5
[0139] The UE group signaling may indicate session ID where UEs 105 associated with session ID or application session ID will respond only during inventory or DL command procedure. The session ID may be allocated during a UE’s 105 first inventory procedure or DL command procedure or registration procedure. The benefit of the session may be where based on the application scenario, the UE 105 is required to report constantly or intermittently corresponding to that session. For instance, a UE application may invoke a command to monitor a given or group of tag ID or product ID or device ID and allocate a session ID, and the associated UEs may respond according to the session policy. This application may be useful where reader, e.g. gNB, RAN node, UE, handheld reader, with the help of CN or AF may set up a session to monitor the good constantly during the session period, e.g., to prevent a stealing, or find unlocated good(s) or device(s).
[0140] If the select signaling sent again with same ID or content, now depending on policy:
• The UE 105 may respond, if no policy is enforced.
• The UE 105 may not respond if it has already responded to the select command with similar content or ID earlier. o The similar select commands or signaling may come from
■ The same Next Generation Radio Access Network (NGRAN) node, or
■ Different NGRAN node
• For example, if CN sends inventory command to specific UE ID or group of UE IDs, then it may happen that all NGRANs connected to same CN, Ambient-IoTF or AMF may broadcast this select command and the given UE 105 may receive this command from multiple NGRANs. o This may prohibit or stop the device from sending redundant responses.
[0141] UE Selection Signaling Behavior
[0142] The RAN signaling to indicate UE group selection may be done in one, two or more of the following ways. [0143] Option 1 : The UE group signaling may indicate one bitfield of fixed size where RAN or CN may specify in the bitfield either:
• One specific device ID, or
• Group ID, or o The group ID may be defined where
■ different or specific device IDs map to one group ID, and/or
■ the ID in group ID is common bit value/mask in the targeted group of devices, similar to mask functionality, for instance, if there are maximum 16 devices possible to inventory, and bit field size set as 4 bit, and the RAN signaling specified MSB as 11, then only 4 devices will be targeted which are 1100, 1101, 1110, 1111.
• Area ID o All the devices within the area associated with Area ID may be targeted.
• IDs based on other information specified above .
• Null, e.g. no ID indicated, mean all devices may be targeted.
[0144] Option 2: The signaling may comprise N bitfields, where in each bitfield the RAN may specify IDs or masks like Option 1. With this, the RAN may target N specific devices or N specific group of devices at the most.
• Option 2A: In one option, size N may be dynamic and, e.g., o May be indicated in RRC signaling, e.g. System Information (SI), System Information Block (SIB) or Master Information Block (MIB), or configuration signaling specifically the size, e.g. value of N, for user selection signaling. o May be indicated in Physical (PHY) header or control information and the devices accordingly decode the payload.
• Option 2B: In one option, the value N may be fixed, e.g. hardcoded.
[0145] Option 3: In one option, to target N specific devices or group of devices, the RAN node may utilize signaling based on option 1 but may send the signaling N times indicating different ID each time. For example, if RAN node is intended to target user ID 1111 and 0000 for inventory or command procedure, then it may send user selection signaling indicating 1111 in the relevant bitfield, and then it may again send the send user selection signaling indicating 0000.
[0146] The above options 1 to 3 may be combined with one or more of the requested scopes of the request e.g. the group ID the devices belong to, the device categories or types the devices belong to, the owner id of the device etc. By combining the scope and n-bits of, e.g., the device ID the reader may limit/throttle the number of responses.
[0147] The select signaling content may be comprised in at least one of:
• DL command or signaling, e.g. sent in DL band,
• CW which may be sent in at least one of: o UL band, or o DL band,
• DL command multiplexed with CW.
[0148] A CN node or AF may send the signaling on user selection to the reader, e.g., the gNB or the intermediate UE. The signaling may be one shot, i.e., valid/applicable for one scheduling/query round, or semi-static/periodic manner, i.e., valid/applicable for multiple scheduling/query rounds.
[0149] The signaling may be carried via RRC signaling, Medium Access Control (MAC) Control Element (CE) or LI signaling.
[0150] The RAN node, e.g., the gNB, may send the signaling on user selection to the intermediate UE. The RAN node may determine use selection according to a configuration received from the CN or AF.
[0151] The RAN node may determine user selection, which may be different from user selection made by the CN. This may occur due to that user selection made by the CN is not suitable to the RAN node, since the CN may not have up to date information or knowledge in the RAN on resource availability.
[0152] The RAN node may determine user selection, which is subset of user selection made by the CN. This may occur that CN determines a larger group of devices to be selected. However, the RAN node has decided to initiate scheduling/query multiple times/rounds to complete the overall scheduling/query procedure.
[0153] Capability Information as a Criteria for User Selection
[0154] An inventory command may comprise indicators requesting one or multiple devices or device groups to provide capability information to the network/reader. The indicators may comprise at least one of the below:
• Indicating whether AS or RAN capability information is requested.
• Indicating whether NAS or CN capability information is requested.
• Indicating whether specific capability information is requested, o e.g., capability on whether device supports registration procedure, o e.g., capability on whether device supports security/encryption, o e.g., capability on whether device supports specific encryption/integrity algorithm
[0155] Upon reception of the command, a device may immediately attempt to obtain an occasion in the current scheduling round or future scheduling rounds and transmit the requested capability information to the corresponding network node/reader.
[0156] Upon reception of capability information from one or multiple devices, the network node may decide to initiate a second scheduling or inventory round for these devices according to their capability information.
• The second scheduling round may only target to devices which support security/encryption.
• The second scheduling round may only target to devices which support registration procedure.
• The second scheduling round may accommodate or provide sufficient occasions, e.g. at least one of in frequency and time domain, for a device to perform or enable encryption in subsequent transmissions/receptions after the initial access, e.g., after the network node has acknowledged reception of the initial ID of the device.
• The second scheduling round may accommodate or provide sufficient occasions, e.g. at least one of in frequency and time domain, for a device to perform/ enable registration procedure in subsequent transmissions/receptions after the initial access, e.g., after the network node has acknowledged reception of the initial ID of the device.
• The network node may instruct a carrier wave emitter or an energy provider/transmitter to start transmitting carrier wave or energy wave or start transmitting after a gap period towards one or multiple specific devices which have provided capability information to the network node to enable them to perform subsequent encryption/registration procedure.
• The network node may be a gNB, DU, CU or CN entity, e.g., AMF, SMF or a specific entity for handling A-IoT services.
[0157] Upon reception of capability information from one or multiple devices, the network node may decide to adjust/update the current scheduling/inventory round to provide more occasions, e.g. at least one of in frequency and time domain, for these devices to perform/enable encryption/registration in subsequent transmissions/receptions in the current scheduling round. [0158] The method described above will now be described seen from the perspective of the UE 105. FIG. 8 is a flow chart describing the present method in the UE 105 for handling UE IDs in a communications system 100. The UE 105 may be an Ambient-IoT device, or the UE 105 may comprise an Ambient-IoT device. The method comprises at least one of the following steps to be performed by the UE 105, which steps may be performed in any suitable order than described below:
[0159] Step 801: This step may correspond to step 603 in FIG. 5 and step 703 in FIG. 7. The UE 105 obtains a first request from the first network node 101.
[0160] Step 802: This step may correspond to step 604 in FIG. 6 and step 704 in FIG. 7. The UE 105 provides a second UE ID to the first network node 101. The second UE ID may be at least one of assigned and managed by the second network node 103.
[0161] Step 803: This step may correspond to step 607 in FIG. 6 and step 706 in FIG. 7. The UE 105 obtains a third UE ID from the first network node 101. This may be described as the UE 105 obtains information indicating a third UE ID from the first network node 101. The third UE ID may be an Access Stratum (AS) device ID or AS UE ID.
[0162] Step 804: This step may correspond to step 607 in FIG. 6 and step 707 in FIG. 7. The UE 105 determines the second UE ID to be the third UE ID.
[0163] The second UE ID may be an ID that may be at least one of assigned and managed by the second network node 103, e.g., CN node. The third UE ID may be an Access Stratum (AS) ID, assigned and/operated by the first network node 101, e.g., the gNB. Determining that the second UE ID is the third UE ID so that the UE 105 may use the AS ID for communication with the first network node 101, by avoiding using the second UE ID, which may have security concern for example if to be used directly by the UE 105 and the first network node 101. The third UE ID, e.g. the AS ID, is shorter in the size, which may reduce the control signaling overhead compared to the second UE ID.
[0164] Step 805: This may correspond to step 608 in FIG. 6 and step 708 in FIG. 7. The UE 105 may provide a first response to the first network node 101. The first response comprises the third UE ID or does not comprise the third UE ID.
[0165] Step 806: This step may correspond to step 612 in FIG. 6 and step 712 in FIG. 7. The UE 105 may obtain a second request from the first network node 101.
[0166] Step 807: The UE 105 may act according to the second request, e.g. e.g. read or write to/of memory in UE 105. [0167] Step 808: This step may correspond to step 613 in FIG. 6 and step 713 in FIG. 7. The UE 105 may provide a second response to the first network node 101. The second response comprises the third UE ID or does not comprise the third UE ID.
[0168] The first request may be an inventory request, and the second request may be a command request. The first response may be an inventory response, and the second response may be a command response.
[0169] The method described above will now be described seen from the perspective of the first network node 101. FIG. 9 is a flowchart describing the present method in the first network node 101 for handling UE IDs in a communications system 100. The first network node 101 may be at least one of: a base station, eNB, gNB and an intermediate UE. The method comprises at least one of the following steps to be performed by the first network node 101, which steps may be performed in any suitable order than described below:
[0170] Step 900: This step may correspond to step 601 in FIG. 6 and step 701 in FIG. 7. The first network node 101 obtains a first request from a second network node 103. The first request comprise a first UE ID or does not comprise the first UE ID. The first UE ID may be a random ID.
[0171] Step 901: This step may correspond to step 702 in FIG. 7. The first network node 101 may provide information indicating at least one of: targeted user UE credentials, information and IDs etc., to the UE 105. A purpose of providing this information to the UE 105 may be to indicate which UE 105 is the target UE, which needs to provide a response. The information provided in step 901 may be information which may at least one of deduce and indicate the UE credentials, e.g., application ID, area ID, group ID, etc. The provided ID may be at least one of: application ID, area ID, group ID, mask etc., which may be used to at least one of deduce and indicate UE credentials.
[0172] Step 902: This step may correspond to step 602 in FIG. 6. The first network node 101 selects which UE 105 that should receive the first request by checking if the first UE ID is comprised in the first request.
[0173] All UEs 105 in the communications system 100 may be selected to receive the first request when the first request does not comprise the first UE ID.
[0174] When the first request comprises the first UE ID, then the UEs 105 identified by the first UE ID may be selected to receive the first request. [0175] Step 903: This step may correspond to step 603 in FIG. 6 and step 703 in FIG. 7. The first network node 101 provides the first request to the UE 105 according to a result of the selecting.
[0176] Step 904: This step may correspond to step 604 in FIG. 6 and step 704 in FIG. 7. The first network node 101 obtains a second UE ID from the UE 105.
[0177] Step 905: This step may correspond to step 605 in FIG. 6 and step 705 in FIG. 7. The first network node 101 maps the second UE ID with a third UE ID. The third UE ID may be an AS device ID.
[0178] Step 906: This step may correspond to step 606 in FIG. 6. The first network node 101 may create a mapping table comprising information indicating a mapping between the first UE ID and the third UE ID.
[0179] Step 907: This step may correspond to step 607 in FIG. 6 and step 706 in FIG. 7. The first network node 101 provides the third UE ID to the UE 105. This may be described as the first network node 101 providing information indicating the third UE ID to the UE 105.
[0180] Step 908: This step may correspond to step 609 in FIG. 6 and step 708 in FIG. 7. The first network node 101 may obtain a first response from the UE 105. The first response may comprise the third UE ID or it may not comprise the third UE ID.
[0181] Step 909: This step may correspond to step 609 in FIG. 6 and step 709 in FIG. 7. The first network node 101 may provide the first response to the second network node 103.
[0182] Step 910: This step may correspond to step 610 in FIG. 6 and step 710 in FIG. 7. The first network node 101 may obtain a second request from the second network node 103. The second request may comprise the first UE ID or may not comprise the first UE ID.
[0183] Step 911: This step may correspond to step 611 in FIG. 6 and step 711 in FIG. 7, The first network node 101 may determine which third UE ID that maps with the first UE ID in the second request.
[0184] Step 912: This step may correspond to step 612 in FIG. 6 and step 712 in FIG. 7. The first network node 101 may provide a second request to the UE 105 having the third UE ID.
[0185] Step 913: This step may correspond to step 613 in FIG. 6 and step 713 in FIG. 7. The first network node 101 may obtain a second response from the UE 105. The second response may comprise the third UE ID or may not comprise the third UE ID. [0186] Step 914: This step may correspond to step 614 in FIG. 6 and step 714 in FIG. 7. The first network node 101 may provide a second response to the second network node 103. The second response may comprise the third UE ID or does not comprise the third UE.
[0187] The method described above will now be described seen from the perspective of the second network node 103. FIG. 10 is a flowchart describing the present method in the second network node 103 for handling UE IDs in a communications system 100. The method comprises at least one of the following steps to be performed by the second network node 103, which steps may be performed in any suitable order than described below:
[0188] Step 1001: This step may correspond to step 601 in FIG. 6 and step 701 in FIG. 7. The second network node 103 may provide a first request to a first network node 101. The first request may comprise a first UE ID or may not comprise the first UE ID.
[0189] Step 1002: This step may correspond to step 609 in FIG. 6 and step 709 in FIG. 7. The second network node 103 may obtain a first response from the first network node 101.
[0190] Step 1003: This step may correspond to step 610 in FIG. 6 and step 710 in FIG. 7. The second network node 103 may provide a second request to the first network node 101. The second request may comprise the first UE ID or may not comprise the first UE ID.
[0191] Step 1004: This step may correspond to step 614 in FIG. 6 and step 714 in FIG. 7. The second network node 101 may obtain a second response from the first network node 101. The second response may comprise the third UE ID or may not comprise the UE ID.
[0192] FIG. 11 is a schematic drawing illustrating the UE 105 for handling UE ID in a communications system 100. The UE 105 may comprise processing circuitry 1101, e.g. one or more processors, configured to perform the methods herein. The UE 105 may comprise a power supply circuitry configured to supply power to the processing circuitry 1101.
[0193] At least one of the UE 105 and the processing circuitry 1101 is configured to obtain a first request from a first network node 101. At least one of the UE 105 and the processing circuitry 1101 is configured to provide a second UE ID to the first network node 101. At least one of the UE 105 and the processing circuitry 1101 is configured to obtain a third UE ID from the first network node 101. At least one of the UE 105 and the processing circuitry 1101 is configured to determine the second UE ID to be the third UE ID.
[0194] The UE 105 further comprises a memory 1105. The memory 1105 comprises one or more units to be used to store data on, such as indications, requests, responses, first UE ID, second UE ID, third UE ID, measurements, thresholds, data related to nodes, and applications to perform the methods disclosed herein when being executed, and similar. Furthermore, the UE 105 may comprise a communication interface 1106 such as comprising at least one of a transmitter, a receiver, a transceiver and at least one antenna.
[0195] The methods described herein for the UE 105 are respectively implemented using e.g., a computer program product 1107 or a computer program comprising instructions, i.e., software code portions, which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the UE 105. The computer program product 1107 may be stored on a computer-readable storage medium 1108 e.g. a disc, a universal serial bus (USB) stick or similar. The computer-readable storage medium 1108 having stored thereon the computer program product, may comprise the instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the UE 105. The computer-readable storage medium may be a transitory or anon-transitory computer-readable storage medium. Thus, the present disclosure relates to a UE 105 for handling UE ID in a wireless communication network, wherein the UE 105 comprises processing circuitry 1101 and a memory 1105, the memory 1105 comprising instructions executable by the processing circuitry whereby the UE 105 is operative to perform any of the methods herein.
[0196] The UE 105 may comprise an antenna configured to send and receive wireless signals. The UE 105 may comprise radio front-end circuitry connected to the antenna and to processing circuitry 1101 and configured to condition signals communicated between the antenna and the processing circuitry 1101. The processing circuitry 1101 may be configured to perform the methods described herein. The UE 105 may comprise an input interface connected to the processing circuitry 1101 and configured to allow input of information into the UE to be processed by the processing circuitry 1101. The UE 105 may comprise an output interface connected to the processing circuitry 1101 and configured to output information from the UE that has been processed by the processing circuitry 1101. The UE 105 may comprise a battery connected to the processing circuitry 1101 and configured to supply power to the UE 105.
[0197] FIG. 12 is a schematic drawing illustrating the first network node 101 for handling UE ID in the communication system 100.
[0198] The first network node 101 may comprise processing circuitry 1201 e.g. one or more processors, configured to perform the methods herein.
[0199] The first network node 101 may comprise power supply circuitry configured to supply power to the processing circuitry 1201. [0200] At least one of the first network node 101 and the processing circuitry 1201 is configured to obtain a first request from a second network node 103. The first request comprises a first UE ID or does not comprise the first UE ID.
[0201] At least one of first network node 101 and the processing circuitry 1201 is configured to select which UE 105 that should receive the first request by checking if the first UE ID is comprised in the first request.
[0202] At least one of the first network node 101 and the processing circuitry 1201 is configured to provide the first request to the UE 105 according to a result of the selecting.
[0203] At least one of the first network node 101 and the processing circuitry 1201 is configured to obtain a second UE ID from the UE 105.
[0204] At least one of the first network node 101 and the processing circuitry 1201 is configured to map the second UE ID with a third UE ID.
[0205] At least one of the first network node 101 and the processing circuitry 1201 is configured to provide the third UE ID to the UE 105.
[0206] The first network node 101 further comprises a memory 1205. The memory 1205 comprises one or more units to be used to store data on, such as indications, requests, responses, first UE ID, second UE ID, third UE ID, measurements, thresholds, data related to nodes, and applications to perform the methods disclosed herein when being executed, and similar. Furthermore, the first network node 101 may comprise a communication interface 1206 such as comprising at least one of a transmitter, a receiver, a transceiver and at least one antenna.
[0207] The methods described herein for the first network node 101 are respectively implemented using e.g., a computer program product 1207 or a computer program, comprising instructions, i.e., software code portions, which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the first network node 101. The computer program product 1207 may be stored on a computer-readable storage medium 1208 e.g. a disc, a universal serial bus (USB) stick or similar. The computer-readable storage medium 1208 having stored thereon the computer program product, may comprise the instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the first network node 101. The computer-readable storage medium may be a transitory or a non-transitory computer-readable storage medium. Thus, the present disclosure relates to a first network node 101 for handling UE ID in a wireless communication network, wherein the first network node 101 comprises processing circuitry 1201 and a memory 1205, the memory 1205 comprising instructions executable by the processing circuitry 1201 whereby the first network node 101 is operative to perform any of the methods herein.
[0208] FIG. 13 is a schematic drawing illustrating the second network node 103 for handling UE ID in a communication system 100.
[0209] The second network node 103 may comprise processing circuitry 1301 e.g. one or more processors, configured to perform the methods herein.
[0210] The second network node 103 may comprise power supply circuitry configured to supply power to the processing circuitry 1301.
[0211] At least one of the second network node 103 and the processing circuitry 1301 is configured to provide a first request to a first network node 101. The first request comprises a first UE ID or may does not comprise the first UE ID.
[0212] The second network node 103 further comprises a memory 1305. The memory
1305 comprises one or more units to be used to store data on, such as indications, requests, responses, first UE ID, second UE ID, third UE ID, measurements, thresholds, data related to nodes, and applications to perform the methods disclosed herein when being executed, and similar. Furthermore, the second network node 103 may comprise a communication interface
1306 such as comprising at least one of a transmitter, a receiver, a transceiver and one or more antennas.
[0213] The methods described herein for the second network node 103 are respectively implemented using e.g., a computer program product 1307 or a computer program, comprising instructions, i.e., software code portions, which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the second network node 103. The computer program product 1307 may be stored on a computer-readable storage medium 1308 e.g. a disc, a universal serial bus (USB) stick or similar. The computer-readable storage medium 1308 having stored thereon the computer program product, may comprise the instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the second network node 103. The computer-readable storage medium may be a transitory or a non-transitory computer-readable storage medium. Thus, the present disclosure relates to a second network node 103 for handling UE ID in a wireless communication network, wherein the second network node 103 comprises processing circuitry 1301 and amemory 1305, the memory 1305 comprising instructions executable by the processing circuitry 1301 whereby the second network node 103 is operative to perform any of the methods herein. [0214] FIG. 14 shows an example of a communication system 1400 in accordance with some embodiments.
[0215] In the example, the communication system 1400 includes a telecommunication network 1402 that includes an access network 1404, such as a radio access network (RAN), and a core network 1406, which includes one or more core network nodes 1408. The access network 1404 includes one or more access network nodes, such as network nodes 1410a and 1410b (one or more of which may be generally referred to as network nodes 1410), or any other similar 3rd Generation Partnership Project (3GPP) access nodes or non-3GPP access points. Moreover, as will be appreciated by those of skill in the art, a network node is not necessarily limited to an implementation in which a radio portion and a baseband portion are supplied and integrated by a single vendor. Thus, it will be understood that network nodes include disaggregated implementations or portions thereof. For example, in some embodiments, the telecommunication network 1402 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a node in the telecommunication network 1402 that supports an ORAN specification (e.g., a specification published by the O-RAN Alliance, or any similar organization) and may operate alone or together with other nodes to implement one or more functionalities of any node in the telecommunication network 1402, including one or more network nodes 1410 and/or core network nodes 1408.
[0216] Examples of an ORAN network node include an open radio unit (O-RU), an open distributed unit (O-DU), an open central unit (O-CU), including an O-CU control plane (O- CU-CP) or an O-CU user plane (O-CU-UP), a RAN intelligent controller (near-real time or non-real time) hosting software or software plug-ins, such as a near-real time control application (e.g., xApp) or a non-real time control application (e.g., rApp), or any combination thereof (the adjective “open” designating support of an ORAN specification). The network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an Al, Fl, Wl, El, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN access node may be a logical node in a physical node. Furthermore, an ORAN network node may be implemented in a virtualization environment (described further below) in which one or more network functions are virtualized. For example, the virtualization environment may include an O-Cloud computing platform orchestrated by a Service Management and Orchestration Framework via an O-2 interface defined by the O-RAN Alliance or comparable technologies. The network nodes 1410 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 1412a, 1412b, 1412c, and 1412d (one or more of which may be generally referred to as UEs 1412) to the core network 1406 over one or more wireless connections.
[0217] Example wireless communications over a wireless connection include transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 1400 may include any number of wired or wireless networks, network nodes, UEs, and/or any other components or systems that may facilitate or participate in the communication of data and/or signals whether via wired or wireless connections. The communication system 1400 may include and/or interface with any type of communication, telecommunication, data, cellular, radio network, and/or other similar type of system.
[0218] The UEs 1412 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and/or operable to communicate wirelessly with the network nodes 1410 and other communication devices. Similarly, the network nodes 1410 are arranged, capable, configured, and/or operable to communicate directly or indirectly with the UEs 1412 and/or with other network nodes or equipment in the telecommunication network 1402 to enable and/or provide network access, such as wireless network access, and/or to perform other functions, such as administration in the telecommunication network 1402.
[0219] In the depicted example, the core network 1406 connects the network nodes 1410 to one or more host computing systems, such as host 1416. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 1406 includes one more core network nodes (e.g., core network node 1408) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and/or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 1408. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and/or a User Plane Function (UPF). [0220] The host 1416 may be under the ownership or control of a service provider other than an operator or provider of the access network 1404 and/or the telecommunication network 1402. The host 1416 may host a variety of applications to provide one or more services. Examples of such applications include live and pre-recorded audio/video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.
[0221] As a whole, the communication system 1400 of FIG. 14 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE), and/or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and/or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and/or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox.
[0222] In some examples, the telecommunication network 1402 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 1402 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 1402. For example, the telecommunications network 1402 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and/or Massive Machine Type Communication (mMTC)/Massive loT services to yet further UEs.
[0223] In some examples, the UEs 1412 are configured to transmit and/or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 1404 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 1404. Additionally, a UE may be configured for operating in single- or multi-RAT or multi -standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi -radio dual connectivity (MR-DC), such as E-UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN- DC).
[0224] In the example, the hub 1414 communicates with the access network 1404 to facilitate indirect communication between one or more UEs (e.g., UE 1412c and/or 1412d) and network nodes (e.g., network node 1410b). In some examples, the hub 1414 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 1414 may be a broadband router enabling access to the core network 1406 for the UEs. As another example, the hub 1414 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 1410, or by executable code, script, process, or other instructions in the hub 1414. As another example, the hub 1414 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 1414 may be a content source. For example, for a UE that is a VR device, display, loudspeaker, or other media delivery device, the hub 1414 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 1414 then provides to the UE either directly, after performing local processing, and/or after adding additional local content. In still another example, the hub 1414 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.
[0225] The hub 1414 may have a constant/persistent or intermittent connection to the network node 1410b. The hub 1414 may also allow for a different communication scheme and/or schedule between the hub 1414 and UEs (e.g., UE 1412c and/or 1412d), and between the hub 1414 and the core network 1406. In other examples, the hub 1414 is connected to the core network 1406 and/or one or more UEs via a wired connection. Moreover, the hub 1414 may be configured to connect to an M2M service provider over the access network 1404 and/or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 1410 while still connected via the hub 1414 via a wired or wireless connection. In some embodiments, the hub 1414 may be a dedicated hub - that is, a hub whose primary function is to route communications to/from the UEs from/to the network node 1410b. In other embodiments, the hub 1414 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 1410b, but which is additionally capable of operating as a communication start and/or end point for certain data channels. [0226] FIG. 15 shows a UE 1500 in accordance with some embodiments. The UE 1500 presents additional details of some embodiments of the UE 1412 of FIG. 14. As used herein, a UE refers to a device capable, configured, arranged and/or operable to communicate wirelessly with network nodes and/or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage/playback device, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), an Augmented Reality (AR) or Virtual Reality (VR) device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded/integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and/or an enhanced MTC (eMTC) UE.
[0227] A UE may support device-to-device (D2D) communication, for example by implementing a 3 GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle- to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and/or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter).
[0228] The UE 1500 includes processing circuitry 1502 that is operatively coupled via a bus 1504 to an input/output interface 1506, a power source 1508, a memory 1510, a communication interface 1512, and/or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in FIG. 15. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.
[0229] The processing circuitry 1502 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 1510. The processing circuitry 1502 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general -purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry 1502 may include multiple central processing units (CPUs). [0230] In the example, the input/output interface 1506 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and/or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 1500. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.
[0231] In some embodiments, the power source 1508 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source 1508 may further include power circuitry for delivering power from the power source 1508 itself, and/or an external power source, to the various parts of the UE 1500 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 1508. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 1508 to make the power suitable for the respective components of the UE 1500 to which power is supplied.
[0232] The memory 1510 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 1510 includes one or more application programs 1514, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 1516. The memory 1510 may store, for use by the UE 1500, any of a variety of various operating systems or combinations of operating systems.
[0233] The memory 1510 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD- DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and/or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory 1510 may allow the UE 1500 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 1510, which may be or comprise a device-readable storage medium.
[0234] The processing circuitry 1502 may be configured to communicate with an access network or other network using the communication interface 1512. The communication interface 1512 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 1522. The communication interface 1512 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter 1518 and/or a receiver 1520 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 1518 and receiver 1520 may be coupled to one or more antennas (e.g., antenna 1522) and may share circuit components, software or firmware, or alternatively be implemented separately.
[0235] In the illustrated embodiment, communication functions of the communication interface 1512 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and/or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol/intemet protocol (TCP/IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.
[0236] Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 1512, via a wireless connection to a network node. Data captured by sensors of a UE may be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient).
[0237] As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.
[0238] A UE, when in the form of an Internet of Things (loT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door/window sensor, a flood/moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an loT device comprises circuitry and/or software in dependence on the intended application of the loT device in addition to other components as described in relation to the UE 1500 shown in FIG. 15.
[0239] As yet another specific example, in an loT scenario, a UE may represent a machine or other device that performs monitoring and/or measurements and transmits the results of such monitoring and/or measurements to another UE and/or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation.
[0240] In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated into a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g. by controlling an actuator) to increase or decrease the drone’s speed. The first and/or the second UE may also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.
[0241] FIG. 16 shows a network node 1600 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and/or operable to communicate directly or indirectly with a UE and/or with other network nodes or equipment, in a telecommunication network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)), O-RAN nodes or components of an O-RAN node (e g., O-RU, O-DU, O-CU).
[0242] Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units, distributed units (e.g., in an O-RAN access node) and/or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).
[0243] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi -standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell/multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and/or Minimization of Drive Tests (MDTs). [0244] The network node 1600 includes a processing circuitry 1602, a memory 1604, a communication interface 1606, and a power source 1608. The network node 1600 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node 1600 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node 1600 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 1604 for different RATs) and some components may be reused (e.g., a same antenna 1610 may be shared by different RATs). The network node 1600 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 1600, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 1600. [0245] The processing circuitry 1602 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operable to provide, either alone or in conjunction with other network node 1600 components, such as the memory 1604, to provide network node 1600 functionality.
[0246] In some embodiments, the processing circuitry 1602 includes a system on a chip (SOC). In some embodiments, the processing circuitry 1602 includes one or more of radio frequency (RF) transceiver circuitry 1612 and baseband processing circuitry 1614. In some embodiments, the radio frequency (RF) transceiver circuitry 1612 and the baseband processing circuitry 1614 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 1612 and baseband processing circuitry 1614 may be on the same chip or set of chips, boards, or units. [0247] The memory 1604 may comprise any form of volatile or non-volatile computer- readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or any other volatile or non-volatile, non-transitory device-readable and/or computerexecutable memory devices that store information, data, and/or instructions that may be used by the processing circuitry 1602. The memory 1604 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and/or other instructions capable of being executed by the processing circuitry 1602 and utilized by the network node 1600. The memory 1604 may be used to store any calculations made by the processing circuitry 1602 and/or any data received via the communication interface 1606. In some embodiments, the processing circuitry 1602 and memory 1604 is integrated.
[0248] The communication interface 1606 is used in wired or wireless communication of signaling and/or data between a network node, access network, and/or UE. As illustrated, the communication interface 1606 comprises port(s)/terminal(s) 1616 to send and receive data, for example to and from a network over a wired connection. The communication interface 1606 also includes radio front-end circuitry 1618 that may be coupled to, or in certain embodiments a part of, the antenna 1610. Radio front-end circuitry 1618 comprises filters 1620 and amplifiers 1622. The radio front-end circuitry 1618 may be connected to an antenna 1610 and processing circuitry 1602. The radio front-end circuitry may be configured to condition signals communicated between antenna 1610 and processing circuitry 1602. The radio front-end circuitry 1618 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 1618 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 1620 and/or amplifiers 1622. The radio signal may then be transmitted via the antenna 1610. Similarly, when receiving data, the antenna 1610 may collect radio signals which are then converted into digital data by the radio front-end circuitry 1618. The digital data may be passed to the processing circuitry 1602. In other embodiments, the communication interface may comprise different components and/or different combinations of components.
[0249] In certain alternative embodiments, the network node 1600 does not include separate radio front-end circuitry 1618, instead, the processing circuitry 1602 includes radio front-end circuitry and is connected to the antenna 1610. Similarly, in some embodiments, all or some of the RF transceiver circuitry 1612 is part of the communication interface 1606. In still other embodiments, the communication interface 1606 includes one or more ports or terminals 1616, the radio front-end circuitry 1618, and the RF transceiver circuitry 1612, as part of a radio unit (not shown), and the communication interface 1606 communicates with the baseband processing circuitry 1614, which is part of a digital unit (not shown).
[0250] The antenna 1610 may include one or more antennas, or antenna arrays, configured to send and/or receive wireless signals. The antenna 1610 may be coupled to the radio frontend circuitry 1618 and may be any type of antenna capable of transmitting and receiving data and/or signals wirelessly. In certain embodiments, the antenna 1610 is separate from the network node 1600 and connectable to the network node 1600 through an interface or port.
[0251] The antenna 1610, communication interface 1606, and/or the processing circuitry 1602 may be configured to perform any receiving operations and/or certain obtaining operations described herein as being performed by the network node. Any information, data and/or signals may be received from a UE, another network node and/or any other network equipment. Similarly, the antenna 1610, the communication interface 1606, and/or the processing circuitry 1602 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and/or signals may be transmitted to a UE, another network node and/or any other network equipment. [0252] The power source 1608 provides power to the various components of network node 1600 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 1608 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 1600 with power for performing the functionality described herein. For example, the network node 1600 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 1608. As a further example, the power source 1608 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.
[0253] Embodiments of the network node 1600 may include additional components beyond those shown in FIG. 16 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and/or any functionality necessary to support the subject matter described herein. For example, the network node 1600 may include user interface equipment to allow input of information into the network node 1600 and to allow output of information from the network node 1600. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 1600. In some embodiments providing a core network node, such as core network node 108 of FIG. 8, some components, such as the radio front-end circuitry 1618 and the RF transceiver circuitry 1612 may be omitted.
[0254] FIG. 17 is a block diagram illustrating a virtualization environment 1700 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization may be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs) implemented in one or more virtual environments 1700 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized. In some embodiments, the virtualization environment 1700 includes components defined by the O-RAN Alliance, such as an O-Cloud environment orchestrated by a Service Management and Orchestration Framework via an 0-2 interface. Virtualization may facilitate distributed implementations of a network node, UE, core network node, or host.
[0255] Applications 1702 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein.
[0256] Hardware 1704 includes processing circuitry, memory that stores software and/or instructions executable by hardware processing circuitry, and/or other hardware devices as described herein, such as a network interface, input/output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1706 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1708a and 1708b (one or more of which may be generally referred to as VMs 1708), and/or perform any of the functions, features and/or benefits described in relation with some embodiments described herein. The virtualization layer 1706 may present a virtual operating platform that appears like networking hardware to the VMs 1708.
[0257] The VMs 1708 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1706. Different embodiments of the instance of a virtual appliance 1702 may be implemented on one or more of VMs 1708, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which may be located in data centers, and customer premise equipment.
[0258] In the context of NFV, a VM 1708 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 1708, and that part of hardware 1704 that executes that VM, be it hardware dedicated to that VM and/or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 1708 on top of the hardware 1704 and corresponds to the application 1702. [0259] Hardware 1704 may be implemented in a standalone network node with generic or specific components. Hardware 1704 may implement some functions via virtualization. Alternatively, hardware 1704 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 1710, which, among others, oversees lifecycle management of applications 1702. In some embodiments, hardware 1704 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling may be provided with the use of a control system 1712 which may alternatively be used for communication between hardware nodes and radio units. [0260] Although the computing devices described herein (e.g., UEs, network nodes) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and/or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and/or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and/or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.
[0261] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer- readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer- readable storage medium or not, the processing circuitry may be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device but are enjoyed by the computing device as a whole, and/or by end users and a wireless network generally.
[0262] 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.
[0263] In general, the usage of “first”, “second”, “third”, “fourth”, and/or “fifth” herein may be understood to be an arbitrary way to denote different elements or entities and may be understood to not confer a cumulative or chronological character to the nouns they modify, unless otherwise noted, based on context.
[0264] The present disclosure is not limited to the above. Various alternatives, modifications and equivalents may be used. Therefore, disclosure herein should not be taken as limiting the scope. A feature may be combined with one or more other features.
[0265] The term “at least one of A and B” should be understood to mean “only A, only B, or both A and B ”, where A and B are any parameter, number, indication used herein etc.
[0266] It should be emphasized that the term “comprises/comprising” when used in this specification is taken to specify the presence of stated features, integers, steps or components, but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof. It should also be noted that the words “a” or “an” preceding an element do not exclude the presence of a plurality of such elements.
[0267] The term “configured to” used herein may also be referred to as “arranged to”, “adapted to”, “capable of’ or “operative to”. [0268] The steps of the methods may be performed in another order than the order in which they appear herein.
REFERENCES
3GPP TR 22.840
3GPP TR 38.848 V EO.O
RP-234058, RAN SI, Release 19

Claims

1. A method performed by a user equipment, UE, (105) for handling UE identities, ID, in a communications system (100), the method comprising: obtaining (603, 703, 801) a first request from the first network node (101); providing (604, 704, 802) a second UE ID to the first network node (101); obtaining (607, 706, 803) a third UE ID from the first network node (101); and determining (607, 707, 804) the second UE ID to be the third UE ID.
2. The method of claim 1, comprising: providing (608, 708, 805) a first response to the first network node (101), wherein the first response comprises the third UE ID or does not comprise the third UE ID.
3. The method of any of the preceding claims, comprising: obtaining (612, 712, 806) a second request from the first network node (101); and acting (807) according to the second request.
4. The method of any of the preceding claims, comprising: providing (613, 713, 808) a second response to the first network node (101), wherein the second response comprises the third UE ID or does not comprise the third UE ID.
5. The method of any of the preceding claims, wherein the third UE ID is an Access Stratum, AS, device ID.
6. The method of any of the preceding claims, wherein the UE (105) is an Ambient Internet of Things, A-IoT device or wherein the UE (105) comprises an A-IoT device.
7. The method of any of the preceding claims, wherein the first request is an inventory request and the second request is a command request, and wherein the first response is an inventory response and the second response is a command response.
8. A method performed by a first network node (101) for handling User Equipment, UE, identity, ID, in a communications system (100), the method comprising: obtaining (601, 701, 900) a first request from a second network node (103), wherein the first request comprise a first UE ID or does not comprise the first UE ID; selecting (602, 902) which UE (105) that should receive the first request by checking if the first UE ID is comprised in the first request; providing (603, 703, 903) the first request to the UE (105) according to a result of the selecting; obtaining (604, 704, 904) a second UE ID from the UE (105); mapping (605, 705, 905) the second UE ID with a third UE ID; and providing (607, 706, 907) the third UE ID to the UE (105).
9. The method of claim 8, comprising: providing (702, 901) information indicating at least one of: targeted UE credentials, information and IDs to the UE (105).
10. The method of any of claims 8-9, comprising: creating (606, 906) a mapping table comprising information indicating a mapping between the first UE ID and the third UE ID.
11. The method of any of claims 8-10, comprising: obtaining (609, 708, 908) a first response from the UE (105), wherein the first response comprises the third UE ID or does not comprise the third UE ID.
12. The method of any of claims 8-11, comprising: providing (609, 709, 909) the first response to the second network node (103).
13. The method of any of claims 8-12, comprising: obtaining (610, 710, 910) a second request from the second network node (103), wherein the second request comprises the first UE ID or does not comprise the first UE ID; determining (611, 711, 911) which third UE ID that maps with the first UE ID in the second request; providing (612, 712, 912) a second request to the UE (105) having the third UE ID.
14. The method of any of claims 8-13, comprising: obtaining (613, 713, 913) a second response from the UE (105), wherein the second response comprises the third UE ID or does not comprise the third UE ID.
15. The method of any of claims 8-14, comprising: providing (614, 714, 914) a second response to the second network node (103), wherein the second response comprises the third UE ID or does not comprise the third UE.
16. The method of any of claims 8-15, wherein all UEs (105) in the communications system (100) are selected to receive the first request when the first request does not comprise the first UE ID.
17. The method of any of claims 8-16, wherein when the first request comprises the first UE ID, then the UEs (105) identified by the first UE ID is selected to receive the first request.
18. The method of any of claims 8-17, wherein the first UE ID is a random ID and the third UE ID is an Access Stratum, AS, device ID.
19. The method of any of claims 8-19, wherein the first network node (101) is at least one of: a base station, evolved Node B, eNB, next generation Node B, gNB and an intermediate UE.
20. A method performed by a second network node (103) for handling User Equipment, UE, identity, ID, in a communications system (100), the method comprising: providing (601, 701, 1001) a first request to a first network node (101), wherein the first request comprises a first UE ID or does not comprise the first UE ID.
21. The method of claim 20, comprising: obtaining (609, 709, 1002) a first response from the first network node (101).
22. The method of any of claims 20-21, comprising: providing (610, 710, 1003) a second request to the first network node (101), wherein the second request comprises the first UE ID or does not comprise the first UE ID.
23. The method of any of claims 20-22, comprising: obtaining (614, 714, 1004) a second response from the first network node (101), wherein the second response comprises the third UE ID or does not comprise the UE ID.
24. A user equipment (105) for handling User Equipment, UE, identity, ID, in a communications system (100) comprising: processing circuitry (1101) ; and power supply circuitry configured to supply power to the processing circuitry (1101), wherein the processing circuitry (1101) is configured to: obtain a first request from a first network node (101); provide a second UE ID to the first network node (101); obtain a third UE ID from the first network node (101); and to determine the second UE ID to be the third UE ID.
25. A first network node (101) for handling User Equipment, UE, identity, ID, in a communications system (100), the first network node (101) comprising: processing circuitry (1201); and power supply circuitry configured to supply power to the processing circuitry (1201), wherein the processing circuitry (1201) is configured to: obtain a first request from a second network node (103), wherein the first request comprises a first UE ID or does not comprise the first UE ID; select which UE (105) that should receive the first request by checking if the first UE ID is comprised in the first request; provide the first request to the UE (105) according to a result of the selecting; obtain a second UE ID from the UE (105); map the second UE ID with a third UE ID; and to provide the third UE ID to the UE (105).
26. A second network node (103) for handling User Equipment, UE, identity, ID, in a communications system (100), the second network node comprising: processing circuitry (1301); and power supply circuitry configured to supply power to the processing circuitry (1301), wherein the processing circuitry (1301) is configured to: provide a first request to a first network node (101), wherein the first request comprises a first UE ID or may does not comprise the first UE ID.
PCT/SE2025/050241 2024-04-05 2025-03-17 Network nodes, ue and methods for handling ue ids in a communications system Pending WO2025212005A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US202463574918P 2024-04-05 2024-04-05
US63/574,918 2024-04-05

Publications (1)

Publication Number Publication Date
WO2025212005A1 true WO2025212005A1 (en) 2025-10-09

Family

ID=95338278

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2025/050241 Pending WO2025212005A1 (en) 2024-04-05 2025-03-17 Network nodes, ue and methods for handling ue ids in a communications system

Country Status (1)

Country Link
WO (1) WO2025212005A1 (en)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230345243A1 (en) * 2020-12-31 2023-10-26 Huawei Technologies Co., Ltd. Authentication method and communication apparatus
CN117560640A (en) * 2022-08-04 2024-02-13 华为技术有限公司 An inventory method and device

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230345243A1 (en) * 2020-12-31 2023-10-26 Huawei Technologies Co., Ltd. Authentication method and communication apparatus
CN117560640A (en) * 2022-08-04 2024-02-13 华为技术有限公司 An inventory method and device

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Study on Architecture support of Ambient power-enabled Internet of Things (Release 19)", 7 March 2024 (2024-03-07), XP052615830, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_sa/WG2_Arch/Latest_SA2_Specs/Latest_draft_S2_Specs/23700-13-020.zip 23700-13-020_rm_v1.docx> [retrieved on 20240307] *
BRIAN CLASSON ET AL: "Discussion on frame structure and timing aspects for Ambient IoT devices", vol. RAN WG1, no. Athens, GR; 20240226 - 20240301, 16 February 2024 (2024-02-16), XP052567876, Retrieved from the Internet <URL:https://www.3gpp.org/ftp/TSG_RAN/WG1_RL1/TSGR1_116/Docs/R1-2400090.zip R1-2400090.docx> [retrieved on 20240216] *

Similar Documents

Publication Publication Date Title
US20250097811A1 (en) Systems and methods for reducing system information acquisition during cell reselection in a non-terrestrial network
CN118715820A (en) Terminal identification for communications using relay terminal equipment
WO2024096810A1 (en) Determination and transmission of wakeup signal
US20250159458A1 (en) Roaming for crowdsourced internet of things (iot)
WO2025170517A1 (en) Mechanism of selecting and configuring cwt in ambient iot
US20260059451A1 (en) Wur subcarriers-spacing adaptation &amp; configuration
US20260059423A1 (en) Power efficient transmission and scheduling of cooperative devices in the uplink
CN119908156A (en) Reduced uplink latency
WO2025212005A1 (en) Network nodes, ue and methods for handling ue ids in a communications system
WO2025209509A1 (en) Improved spectrum management
WO2025195013A1 (en) Methods, devices and medium for selection of intermediate device
WO2025209461A1 (en) Methods and apparatuses for registration
WO2025209394A1 (en) Method and apparatus for resource allocation
WO2025167817A1 (en) Methods, devices and medium for joint communications
WO2026032339A1 (en) Method and apparatus for supporting terminal device service
WO2026032079A1 (en) Method and apparatus for message transmission
WO2025209209A1 (en) Method and apparatus for user plane based communication
WO2025195014A1 (en) Methods, devices and medium for failure detection
WO2025209561A1 (en) Communication devices and methods for inventory procedure
WO2025195181A1 (en) Improved intermediate node management
WO2025234915A1 (en) On method of signaling dl trigger for a-iot devices
WO2025212033A1 (en) Control and system information for ambient iot
WO2025210481A1 (en) Methods and nodes for improved ran awareness, to improve reader-based scheduling procedure for a-iot
WO2025174318A1 (en) Methods for carrier wave transmitters in ambient-internet-of-things
WO2025234931A1 (en) Reader identifier for a-iot devices

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

Country of ref document: EP

Kind code of ref document: A1