Wireless device, network node and methods for handling transmission status in a communications system

Abstract

A method performed by a network node (901) is provided The method is for handling transmission status in a communications system (100, 900) The network node (901) determines (1002) status of a transmission from the wireless device (105, 903) to the network node (901). The network node (901) provides (1004), to a wireless device (903), status information indicating the status of the transmission from the wireless device (903) to the network node. The status information triggers an action to be performed by the wireless device (903).

Description

[0001] WIRELESS DEVICE, NETWORK NODE AND METHODS FOR HANDLING TRANSMISSION STATUS IN A COMMUNICATIONS SYSTEM

[0002] TECHNICAL FIELD

[0003] The present disclosure relates generally to a network node, a method performed by the network node, a wireless device and a method performed by the wireless device. More particularly, the present disclosure relates to handling transmission status in a communications system. The disclosure relates to an On Feedback method enabling Re-access and Retransmission for failed A-loT Transmission.

[0004] BACKGROUND

[0005] 3GPP Ambient-loT

[0006] In 3GPP, ZE-loT started to be studied in Release 18, there referred to as ‘Ambient loT’. In Release 19 the work continued with a study in RAN working groups. It was agreed to continue in the last part of Release 19 with normative work to specify a limited solution:

[0007] • Indoor inventory, indoor command only

[0008] • Backscattering Device Type 1 only

[0009] • D1T1-B, e.g. micro BS indoor; device indoor, only

[0010] o CW outside topology

[0011] • R2D in DL spectrum; D2R and CW in UL spectrum

[0012] That is, the only services supported in Release 19 ‘inventory’ (reporting of device identified to the network) and ‘command’ (transmitting a small payload to the device). Further the deployment scenario supported are indoor devices which receives carrier wave (CW) transmissions for network nodes and the reflected signals are received by indoor micro base stations (in FDD uplink spectrum). For downlink direct transmission from the indoor micro base station to the device is supported, e.g. in FDD downlink spectrum. This is illustrated in fig. 1. Fig. 1 illustrates a carrier wave transmitter, a reader, e.g. gNB, and a passive tag in an indoor location. Fig. 1 illustrates both uplink and downlink signaling.

[0013] Functional and protocol simplifications for Ambient loTFor Ambient loT (A-loT), 3GPP will target an IoT segment well below the existing cellular IoT technologies, e.g. NB-IoT, with significantly lower energy consumption and device complexity / cost. This requires simplifications in physical layer design, and the higher layer (L2 / L3) design will also be much more lightweight with a minimal set of functionalities. For Random Access and multiple access devices the Release 19 scope is limited to the following:

[0014] ■ A-IoT Random access, including re-access for failure handling. Contention-based and contention-free cases are supported. For the contention-based random access, only Solution 1 (3 -step only) is included (unless RAN2 decides to use Solution 3 (unified solution) by RAN2#129).

[0015]

[0016] An overview of contention-based Random Access Types is provided in the table below:

[0017] 2-Step CBRA 3-Step CBRA CFRA (Built similar / over CBRA)

[0018] • 2 messages / steps • 4 messages / steps • Methods sequence sequence

[0019] • Using 3- • Message 2 • Message 4 step CBRA can be can be for single optional (at optional (at device but least for least for without study) study) Msg1 / 2

[0020] • Device transmit • Device transmit • The paging collision resolution collision resolution message (CR ID, e.g., RN16) (CR ID, e.g., RN16) trigger along with data in 1stin 1stmessage and CBRA message data in subsequent targets message only if the single 1stmessage is device acknowledged

[0021] • Other methods

[0022]

[0023] can be based on ID to address reaource utilization locally, e.g.,

[0024] • AS ID (FFS)

[0025] • Other ID (FFS)

[0026]

[0027] Fig. 2 is a flow chart illustrating a method, i.e. a 2-step contention-based Random Access. The device provides message 1 to the reader in step 201. Message 1 comprises CR ID and data, e.g. device ID. The reader provides message 2 to the device in step 202. Message 2 comprises CR ID.

[0028] Fig. 3 is a flow chart illustrating a method, i.e. a 3-step and 4-step contention-based Random Access. The device provides message 1 to the reader in step 301. Message 1 comprises CR ID. The reader provides message 2 to the device in step 302. Message 2 comprises CR ID echo. The device 303 provides message 3 to the reader in step 303. Message 3 comprises data, e.g. device ID. The reader provides message 4 to the device in step 304. Message 4 comprises feedback.

[0029] There currently exist certain challenge(s).

[0030] Ambient loT (A-loT) has been agreed to be a work item for 3GPP Rel-19.

[0031] During SI, it was agreed to have optional feedback possibility for re-access. The concrete design was left to Wl. The SI TR 38.769 states the following for re-access:

[0032] It is supported for the A-IoT device to re-access in another opportunity controlled / provided by the

[0033]

[0034] reader (i.e., to retry the random access above), in case of D2R data transmission failure and contentionresolution failure of contention-based random access.

[0035] The A-IoT device is not expected to autonomously re-access. The re-access is always controlled by reader. It is supported for reader to use the optional explicit R2D failure / success feedback indication to determine the re-access of device:

[0036] - This indication can be used at least to determine the re-access for addressing the transmisison failure of the first D2R message, which contains the device ID and / or any other upper layer data (i.e. " Msg3");

[0037] - This indication can be also used for the following D2R data (as described in clause 6.3.5), to determine the re-access for addressing the transmisison failure.

[0038] The R2D message is used by the reader to provide access occasions), which can be used for re-access purpose. It needs to be further discussed if additional information is needed in this R2D message to differentiate the re-access purpose.

[0039] - A-IoT paging message is one of the options for this R2D message (e.g., see the "subsequent A- loT paging message" in Figure 6.3.4-1).

[0040] - Another option can be some R2D messages between A-IoT paging (e.g., see the other " R2D message" in Figure 6.3.4-1).

[0041]

[0042] And the Rel-19 Wl RP-243326 has the following objective regarding support of reaccess:

[0043] A-IoT Random access, including re-access for failure handling.

[0044]

[0045] The precise feedback design is not yet agreed on failure handling in SI. The aim is do in Wl and this may depend on multiple behaviors and possibilities agreed / assumed that a device can witness during random-access in regards to transmission success, retransmission and re-access, and whether the transmission is a non-segmented transmission or segmented transmission. Two issues are listed below.

[0046] Issue 1: How to accommodate data transmission success, retransmission, or re-access. That is, it is not yet agreed how the device can determine if transmission success, retransmission, or re-access is triggered, and the associated device behavior and signaling need to be specified. In the agreements, it is agreed that feedback is needed perhaps to trigger for re-access. Currently the behavior is set optional as exact feedback design yet to be concluded in Wl.In other words, currently retransmission and re-access were separately designed and discussed in RAN2. However, in practice there may be both retransmission and reaccess, and a harmonized solution handling both cases jointly is lacking, e.g., how a device determines if retransmission or re-access should be performed, once re-access is enabled could retransmission still be performed, etc.

[0047] Issue 2: According to the Rel-19 Wl RP-243326, segmentation of the data payload should be supported for uplink transmission from the device to the network:

[0048] ■ Segmentation is supported at least in D2R.

[0049]

[0050] If a device transmission is segmented in multiple segments, the feedback may have to be different depending on:

[0051] • If segment is not the last segment

[0052] • If segment is the last segment.

[0053] For example, for a segment that is not the last segment the device can expect either a grant / command for re-transmission or for transmission of the next segment (stop-and- wait, similar to legacy adaptive HARQ operation). However, if the same feedback mechanism is used also for the last segment, the device cannot distinguish between the cases that the segment was received successfully by the network (and the transmission of the full device ID in Msg3 was successful completing the inventory procedure) or if it was not successful. In the non-successful case, the device should trigger a re-access, whereas in the successful case it should not. Without any differentiation in the feedback this would not be possible for the device.

[0054] Therefore, there is a need to at least mitigate or solve this issue.

[0055] SUMMARY

[0056] An objective is to obviate at least one of the above disadvantages and to provide improved handling of transmission status in a communications system.According to a first aspect, the objective is achieved by a method performed by a network node for handling transmission status in a communications system. The network node determines status of a transmission from the wireless device to the network node. The network node provides, to a wireless device, status information indicating the status of the transmission from the wireless device to the network node. The status information triggers an action to be performed by the wireless device.

[0057] According to a second aspect, the objective is achieved by a method performed by a wireless device for handling transmission status in a communications system. The wireless device obtains, from a network node, status information indicating the status of the transmission from the wireless device to the network node. The status information triggers an action to be performed by the wireless device. The wireless device performs the action triggered by the status information.

[0058] According to a third aspect, the objective is achieved by a network node for handling transmission status in a communications system. The network node is arranged to determine status of a transmission from the wireless device to the network node. The network node is arranged to provide, to a wireless device, status information indicating the status of the transmission from the wireless device to the network node. The status information triggers an action to be performed by the wireless device.

[0059] According to a fourth aspect, the objective is achieved by wireless device for handling transmission status in a communications system. The wireless device is arranged to obtain, from a network node, status information indicating the status of the transmission from the wireless device to the network node. The status information triggers an action to be performed by the wireless device. The wireless device is arranged to perform the action triggered by the status information.

[0060] Thanks to the status information, which is an explicit indication of the status of the transmission from the wireless device to the network node, it is possible to distinguish between failure in regards to actions such as retransmission and re-access. The status information may be seen as a feedback for feedback for the transmission or last segment of the transmission. The transmission may be a message transmission, e.g.msg 1 or msg 3, or a data transmission. Thus, handling of transmission status in a communications system is improved.

[0061] Certain embodiments may provide one or more of the following technical advantage(s).

[0062] The feedback permits re-access, thereby increasing transmission success rate

[0063] If device constantly failing in current occasion, the re-access from feedback signaling allow device to terminate current occasion and help to save energy which device can store, gather use for next re-access which may occur later in time.

[0064] 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.

[0065] BRIEF DESCRIPTION OF THE DRAWINGS

[0066] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided byway of example to convey the scope of the subject matter to those skilled in the art.

[0067] Additional information may also be found in the document(s) provided in the Appendix.

[0068] Fig. 1 is a schematic drawing illustrating a communications system.

[0069] Fig. 2 is a flow chart illustrating a method.

[0070] Fig. 3 is a flow chart illustrating a method.

[0071] Fig. 4 is a schematic drawing illustrating an overview of the Paging Round, Access Round, and Access Occasion.

[0072] Fig. 5 is a schematic diagram illustrating a communication system.

[0073] Fig. 6 is a schematic diagram illustrating retransmission.

[0074] Fig. 7 is a schematic diagram illustrating re-access.

[0075] Fig. 8 is a schematic diagram illustrating re-access.

[0076] Fig. 9 is a schematic drawing illustrating a communications system.

[0077] Fig. 10 is a signaling diagram illustrating a method.

[0078] Fig. 11 A is a schematic flowchart illustrating a method.Fig. 11 B is a flowchart illustrating a method.

[0079] Fig. 12 is a schematic block diagram of a network node

[0080] Fig. 13A is a schematic flowchart illustrating a method.

[0081] Fig. 13B is a flowchart illustrating a method.

[0082] Fig. 14 is a schematic block diagram of a wireless device

[0083] Fig. 15 is an example of a communication system.

[0084] Fig. 16 is an example of a communication system.

[0085] Fig. 17 shows a wireless device

[0086] Fig. 18 shows a network node.

[0087] Fig. 19 is a block diagram illustrating a virtualization environment

[0088] 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.

[0089] DETAILED DESCRIPTION

[0090] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges.

[0091] The present disclosure relates to a feedback mechanism for the device which attempts to transmit data after passing contention in an access occasion which is randomly selected from the set of access occasions provided in a paging or access round. In this mechanism, the reader sends an explicit feedback message to device to indicate transmission failure and triggers re-access in the later access occasion or access round. Before triggering re-access, the reader can try with retransmission in the same access occasion, which is communicated by sending retransmission grant, say Msg2 retransmission triggering Msg3 / data retransmission for the device. After numerous Msg3 / data transmission failed attempts, the reader can send explicit feedback indicating NACK which triggers re-access.

[0092] There may be an explicit signaling from reader to device to indicate feedback for the transmission or last segment of the transmission to distinguish between failure case in regards to retransmission and re-access.The present disclosure relates to use cases with ultra-low power devices, zero-energy or A-loT devices.

[0093] The term RAN node is used which can be a network node or a user equipment (UE). Examples of network nodes are NodeB, base station (BS), multi-standard radio (MSR) radio node such as MSR BS, eNodeB, gNodeB, MeNB, SeNB, location measurement unit (LMU), integrated access backhaul (IAB) node, network controller, radio network controller (RNC), base station controller (BSC), relay, IAB, repeater, donor node controlling relay, base transceiver station (BTS), Central Unit (e.g. in a gNB), Distributed Unit (e.g. in a gNB), Baseband Unit, Centralized Baseband, C-RAN, access point (AP), transmission points, transmission nodes, transmission reception point (TRP), RRU, RRH, nodes in distributed antenna system (DAS), core network node (e.g. MCS, MME etc), O& M, OSS, SON, positioning node (e.g. E-SMLC), etc. In particular, in Ambient loT scenario the RAN nodes comprise intermediate node / UE (e.g., relay UE, IAB, repeater etc.) and assisting node / UE (e.g., relay UE, IAB, repeater etc.).

[0094] In particular, in A-loT scenario the RAN nodes comprise intermediate node / UE (e.g., relay UE, IAB, repeater etc.) and assisting node / UE (e.g., relay UE, IAB, repeater etc.). In this invention, ‘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. The purpose of the signal is to facilitate / serve / manage / command one or more than one UE 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 receives from the network node, or synchronize based on a pre-defined 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 control information and / or data. Such signal may be transmitted periodically or a periodically configured by the network node.

[0095] The terms A-loT UE, A-loT device, device, UE or wireless device are used interchangeably without losing the meaning.

[0096] The terms intermediate node, intermediate UE, UE and wireless device are applied interchangeably without losing the meaningIt was commonly understood in 3GPP that device performs re-access in case of contention resolution failure. Device performs re-access or retransmission in case of data transmission failure. Re-access means that the device accesses and transmits in a different access occasion from the access occasion where the device has experienced failures. Retransmission means that device uses the same or different resources to retransmit the data on the same access occasion in time domain. Fig. 4 is a schematic drawing illustrating an overview of the Paging Round, Access Round, and Access Occasion. As shown in fig. 4, the inventory procedure is triggered in devices by the paging message (MsgO) reception, which initiated the paging round. This in turn is followed by an adaptive number of ‘Access Rounds’ with a configurable number of ‘Access Occasions’ (depending on the load and number of devices addressed), and a device select a random Access Occasion per Access Round until it succeeds with the procedure (i.e. reporting its full device ID in Msg3 for inventory).

[0097] The reader can be gNB or intermediate-UE based.

[0098] Fig. 5 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 900, 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-loT. 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.

[0099] The communications system 100 comprises one or a plurality of network nodes, whereof a first network node 101a and a second network node 101b are depicted in the nonlimiting example of fig. 5. The first network node 101a, is also referred to as networknode 901 and gNB. Any of the first network node 101a, and the second network node 101b 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 101a may be an eNB and the second network node 101b may be a gNB. The first network node 101a may be a first eNB, and the second network node 101b may be a second eNB. The first network node 101a may be a first gNB, and the second network node 101b may be a second gNB. The first network node 101a may be a MeNB and the second network node 101b may be a gNB. Any of the first network node 101a and the second network node 101b may be co-localized, or they may be part of the same network node. The first network node 101a may be referred to as a source node or source network node, whereas the second network node 101b may be referred to as a target node or target network node. When the reference number 101 is used herein without the letters a or b, it refers to a network node in general, i.e. it refers to any of the first network node 101a or second network node 101b.

[0100] 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. In fig. 5, the communications system 100 comprises a first cell 103a and a second cell 103b. Note that two cells are exemplified in fig. 5 only as an example, and 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. In fig. 5, first network node 101a serves the first cell 103a, and the second network node 101b serves the second cell 103b. Any of the first network node 101a and the second network node 101b 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 101a and the second network node 101b may be directly connected to one or more core networks, which are not depicted in fig. 5 for the sake of simplicity. Any of the first network node 101a and the second network node 101n 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 103a may be referred to as a source cell, whereas the second cell 103bmay be referred to as a target cell. When the reference number 103 is used herein without the letters a or b, it refers to a cell in general, i.e. it refers to any of the first cell 103a or second cell 103b.

[0101] One or a plurality of UEs, such as the UE 105 is comprised in the communication system 100. Only one UE 105 is exemplified in fig. 5 for the sake of simplicity. A UE 105 is also be referred to as a wireless device 903 and simply as a device. The UE 105, e.g. a LTE UE or a 5G / NR UE, may be a wireless communication device which may also be known as e.g., a wireless device, a mobile terminal, wireless terminal and / or mobile station, a mobile telephone, cellular telephone, or laptop with wireless capability, just to mention some examples. The UE 105 may be a device by which a subscriber may access services offered by an operator’s network and services outside 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, 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 portable, pocket storable, hand held, computer comprised, or vehicle mounted devices, enabled to communicate voice and / or 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.

[0102] 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 network nodes, and / or between the UE 105 and a server via the radio access network and possibly one or more core networks and possibly the internet.The first network node 101a may be configured to communicate in the communications system 100 with the UE 105 over a first communication link 108a, e.g., a radio link. The second network node 101b may be configured to communicate in the communications system 100 with the UE 105 over a second communication link 108b, e.g., a radio link. The first network node 101a may be configured to communicate in the communications system 100 with the second network node 101b over a third communication link 108c, e.g., a radio link or a wired link, although communication over more links may be possible. When the reference number 108 is used herein without the letters a, b or c, it refers to a communication link in general, i.e. it refers to any of the first communication link 108a, the second communication link 108b and the third communication link 108c.

[0103] It should be noted that the communication links 108 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.

[0104] The difference between re-access and retransmission will now be described.

[0105] Retransmission

[0106] Retransmission is illustrated in Fig. 6.

[0107] Retransmission occurs within an Access occasion (or random access occasion)

[0108] Retransmission applies to data retransmission (e.g., of Msg3, or Msg5,...), which means the device successfully passed contention resolution in Msg2, (Retransmission is not possible before then so only re-attempt for Msg1)

[0109] The R2D message, such as Msg2 can trigger retransmission of e.g. Msg3, Msg5, etc.

[0110] Re-access

[0111] Scenario 1: This is illustrated in fig. 7. Msg1 / contention failure: If Msg1 transmission fails, the device should attempt to re-access for a new Msg1 transmission opportunity in a later / new Access Occasion which can be same Access round or in thesubsequent / later Access Round (not yet determined in 3GPP). For this no explicit NACK / feedback is needed. The re-access policy will determine how device can initiate or do re-access. The re-access policy must be either provided by reader a-priory, e.g., in some DL control signaling or paging message, or must be hardcoded in device.

[0112] Scenario 2: This is illustrated in fig. 8. Msg3 / data transmission failure: If several Msg3 / data transmission attempts fail, then device can do re-access as per re-access policy. The indication of data transmission failure requires a feedback based on explicit signaling which can be based on the options in Table 1 (later embodiments).

[0113] Embodiment on explicit signaling indicating feedback for transmission of last segment

[0114] In some embodiments, an explicit feedback signal is defined which is sent by the reader (gNB or intermediate UE based) to the device to indicate transmission (data / D2R) success (by indicating explicit ACK or by not indicating explicit NACK) or failure and triggering re-access (by indicating explicit NACK or not indicating explicit ACK) for a device’s data transmission occurred in device’s selected random-access (RA) occasion.

[0115] The present disclosure relates to failure handling when it comes to re-access and retransmission using explicit feedback (e.g., NACK or ACK whichever is standardized) and R2D (DL), e.g., Msg2 / 4... retransmission triggering retransmission for R2D (UL) data transmission, such as Msg3 / 5...

[0116] Note: the explicit feedback (NACK or ACK based) and retransmission grant message such as Msg2 / 4... grant can also be defined under Msg2 carrying different formats. For example, retransmission grant carried by Msg2 / 4 / 6... / R2D message is one format, and feedback (ACK or NACK based) can be an another format carried in Msg2 / 4 / 6... / R2D message.

[0117] Note: If the term “(explicit) NACK” is used or indicated in the below embodiments, the same embodiments also apply for the scenarios where “(explicit) NACK” can be replaced with “no (explicit) ACK”. Similarly, if the term “(explicit) ACK” is used or indicated in below embodiments, the embodiments also apply for the scenarios where “(explicit) ACK” can be replaced with “no (explicit) NACK”.In case NACK (no ACK) is indicated, then the re-access event is triggered or the device should / could perform re-access if triggered and retransmission is disallowed, which means the device

[0118] • Does not (re)transmit in the current access occasion anymore,

[0119] • Ignore Msg2 received in the current access occasion.

[0120] • May or may not ignore R2D message containing specific command(s) received in the current access occasion (e.g., may ignore read command but not write command which only requires a feedback in uplink), i.e., the device may only not perform retransmission or not perform both retransmission and new (data) transmission. Here feedback to write command is not regarded as data transmission.

[0121] • All the past successful transmission(s) or segment transmission(s) triggered by a specific R2D message would be deemed unsuccessful,

[0122] o The system is buffer-less and hence device does not keep the record of partly successful transmission(s) and segment(s)

[0123] • The device transmits from the scratch again when receiving paging or a R2D message containing a command in the new occasion where new occasion can be selected based on re-access policy, e.g., in the same or different access / paging round.

[0124] • Perform re-access if receiving paging or R2D message initiating re-access. o In case the device receives multiple R2D messages containing command before receiving paging or R2D message initiating re-access, the device may perform re-access in case it has received at least one NACK o corresponding to one of the R2D messages containing command.

[0125] After sending NACK corresponding to a R2D message containing specific command to a device, the reader shall not send R2D message containing that command or Msg2 associated to that command to the device again before re-access is performed by the device.

[0126] In addition, the NACK (for the purpose of re-access) can be 1 -bit indication, which is a separate signaling from retransmission grant (e.g., Msg retransmission).However, in other option, the NACK (re-access) and retransmission grant can be different codewords for same message, say NACK-re-access and NACK-retransmission, i.e., the R2D, or Msg2 can indicate with one logic or codeword a retransmission, and with other logic or codeword a re-access.

[0127] The feedback behavior in the embodiments herein applies uplink data transmission which is a D2R message, as an example, Msg3, or Msg5, so on, which can be

[0128] • a data transmission without segments, or

[0129] • if segmented, then the data transmission is last segment of the transmission. o If a transmission is segmented into N segments, then above specified feedback is applied to last, i.e., N-th segment transmission. o However, the above feedback behavior may or may not be applied to other segments from 1st to N-1-th (except the last segments)

[0130] ■ The case where above feedback behavior is not applied, see reasoning in Table 2 later, where no explicit feedback is needed to indicate re-access for segments (other than last segment)

[0131] ■ The case when above feedback behavior is applied. As indicated in above bullet point as there is no need to apply explicit feedback to other segments but there is no harm even if it is applied, e.g., • Explicit NACK can indicate failure of a segment and triggers re-access

[0132] • Explicit ACK is redundant as grant for next segment may work same as explicit ACK

[0133] Note: For retransmission of data again, the reader can send Msg2 again (i.e., Tmsg2 retransmission). Msg2 can contain same information as in original Msg2, i.e., echoed RN16 or it may contain additional information of retransmission resources information for data transmission etc.

[0134] Embodiment on explicit feedback triggering re-access in the next Access Round In an alternative of the above, a new type of NACK, or rather a stop-indication, is introduced to indicate to the device that it should stop any further access attempts or transmission in the current Access Occasion and instead try in the subsequent Access Round. In some embodiments, the status of failure is indicated by a stop-indication,wherein the stop-indication indicates that the wireless device 903 should stop any further access attempts or transmission in the current Access Occasion in the current access round and instead try in the subsequent access occasions of the current access round or Access Round.

[0135] • The new stop indication is separate from a signaling / message such as Msg2 indicating Msg3 / Msg5 / ... / data re-transmission.

[0136] • Msg2 indicating Msg3 re-transmission could be supported with a New Data Indicator (NDI) not being set (indicating retransmission of the same data / segment) in combination with an uplink grant, therefore in one implementation the stop indication could be realized as Msg2 only includes the NDI not being set but not contains any uplink grant or uplink resources for further transmission.

[0137] • The stop-indication may be transmitted when the network does not attempt to trigger further UL (data) retransmissions and new transmissions from the device in the current Access Occasion. E.g., the configuration parameters of the current Access Round do not work for the device and further Msg3 / / Msg5 / ... / data transmission show no chance of success, and the network would instead like the device to re-access in the subsequent Access Round or access occasion which can be configured in an updated and more suitable way. Without the stopindicator, the device could not distinguish between the case that the (last segment) of the Msg3 was successful or the network has just given up on scheduling further Msg3 (re)transmission. With the stop-indicator the device can now distinguish between the two cases and would trigger re-access in the subsequent Access Round or access occasion if the stop-indicator is received.

[0138] After receiving the stop-indicator, the device ignores all R2D message except the paging message or a R2D message triggering re-access or new access, and stops the ignoring when re-access or new-access is triggered.

[0139] Correspondingly, after sending the stop-indicator to a device, the reader should not send any R2D message triggering new transmission or retransmission of UL data or feedback (e.g., feedback to write command).In a variant embodiment, the reader may still send the write command to the device after sending stop-indicator and before triggering (re)-access while the device does not ignore the write command and may still send the feedback after receiving the stop-indicator and before performing (re)-access.

[0140] Embodiment on feedback options and types

[0141] In some embodiments, the feedback explicit signaling can be sent:

[0142] • After device’s one or more failed attempts to transmit data in order to trigger reaccess, or

[0143] • To indicate the success of data transmission, or

[0144] • When the gNB / reader intends to terminate the device’s occasion.

[0145] In the extended embodiment, the network can define single behavior / outcome with the explicit signaling, e.g., either transmission success or re-access, and the other behavior can be derived by device if the explicit signaling is not sent after device’s data transmission attempt. It means, the feedback explicit signally can only indicate, say ACK. The other outcome, e.g., NACK can be derived implicitly by the device if no ACK based signaling is sent. In other words, the device can distinguish between a) data or Msg3 / 5... reception success, and b) re-access triggering through either explicit ACK feedback or explicit NACK-re-access feedback. That is:

[0146] • If feedback explicit signaling is designed to carry / indicate only ACK message, and if the device does not receive ACK or data retransmission grant (e.g., Msg2 retransmission triggering Msg3 / data retransmission) after its data transmission attempt, then the device can assume NACK which triggers a re-access in later access occasion or access round. See column 2 in Table 1.

[0147] • If feedback explicit signaling is designed to indicate only explicit NACK message (to trigger re-access), and if the device does not receive an explicit NACK or data retransmission grant (e.g., Msg2 retransmission triggering Msg3 / data retransmission) after its data transmission attempt, then the device can assume ACK or transmission success. See column 1 in Table 1.

[0148] In some embodiments, the explicit feedback signaling can be designed to carry both messages (equivalent codeword) for ACK and NACK. However, during an instant, onlyone message / feedback can be delivered: ACK (success) or NACK (failure / re-access) or retransmission. See column 3 in Table 1 below.

[0149] Table 1: Feedback design

[0150] Column 0: Column 1: Column 2: Colum3: Msg3 or subsequent D2R Only explicit Only explicit Both explct tranmission NACK based ACK based NACK and explicit ACK based Transmission success No explicit NACK Explicit ACK Explicit ACK

[0151] Transmission Retransmission Msg2 or other Msg2 or other Msg2 or other failure R2D (e.g., Msg R2D (e.g., Msg R2D (e.g.,

[0152] 4...) indicate 4...) indicate Msg 4...) Msg3 Msg3 indicate Msg3 retransmisison retransmisison retransmisison

[0153] Re-access Explicit NACK No explicit ACK Explicit NACK

[0154]

[0155] Note that to be able to detect the absence of feedback (‘No explicit NACK’ in Column 1, or ‘No explicit ACK’ in Column 2), the last opportunity for providing feedback to the device must clearly be defined. This can either be a set of pre-determined R2D occasions, or a response time window, after which the device can accurately determine that there was no feedback for it.

[0156] In some embodiments, the feedback explicit signaling may carry only IDs (in terms of e.g., RN16) for which Msg3 / Msg5 has been correctly received. It includes no ID if no Msg3 / Msg5 has been correctly received in the access occasion since the last time feedback explicit signaling is sent in this access occasion (if the current feedback explicit signaling is not the first one). A device regards its Msg3 / Msg5 transmission as failed and re-access should / could be performed if its ID is not included in the feedback explicit signaling.

[0157] Similarly, the feedback explicit signaling may carry only IDs (in terms of e.g., RN16) for which Msg3 / Msg5 has not been correctly received. It includes no ID if all Msg3 / Msg5 has been correctly received in the access occasion since the last time feedback explicit signaling is sent in this access occasion (if the current feedback explicit signaling is notthe first one). A device regards its Msg3 / Msg5 transmission as successful, and reaccess should / could not be performed if its ID is not included in the feedback explicit signaling.

[0158] In one example, the IDs included in the feedback explicit signaling may be a bitmap whose length equals to the number of (AS) IDs included in the R2D message triggering initial Msg3 / Msg5 transmission. The Nth bit in the bitmap indicates whether Msg3 / Msg5 transmission from the Nth device indicated in the triggering R2D message is successful or not (potentially after retransmission).

[0159] In both of the above two options, if the device does not receive the expected feedback explicit signaling within a (pre)defined time window or before receiving a QueryRep like signaling which starts a new access occasion, the device may regard its Msg3 / Msg5 transmission as failed and re-access should / could be performed

[0160] Embodiment on explicit feedback signaling and Qrep type signaling interaction In some embodiments, the feedback explicit signaling can be combined or merged with QueryRep, which dynamically indicates the start of the Access Occasions of variable length (RDIF term, but likely something similar will be specified by 3GPP) or occasion / slot determination / indication (like)signaling. This is primarily for simple device, such as passive Device Type 1 where a device relies on QueryRep like signaling to know and understand an RA occasion (starting of an occasion / slot, or count of an occasion / slot). Therefore, the reader can combine the transmission of explicit feedback for the previous Access Occasion (ACK or NACK) with QueryRep-like signaling indicating beginning of next Access Occasion. When this Feedback+QueryRep signaling is broadcasted:

[0161] • a device which had transmitted in the Access Occasion prior to Query Rep like signaling will decode the QueryRep-like signaling to know the status of its data transmission whether it is successful (ACKed or no NACKed) or failed (NACKed or no ACKed).

[0162] o Note that the “ACK” or “NACK” here would typically indicate success or failure of the entire procedure in the previous Access Occasion (e.g. until successful Msg3 reception for the Inventory use case) or not a single data transmission.o The “ACK” or “NACK” could either be common for any device that participated in the previous Access Occasion, or device-specific, e.g., having “ACK” or “NACK” per device identifier, e.g. the random 16-bit device identifier used in Msg1.

[0163] Device ID: Feedback:

[0164] Device 7 ACK

[0165] Device 2 NACK

[0166] Device 12 ACK

[0167]

[0168] • Other devices (which had not transmitted or had not successfully transmitted) shall decode the QueryRep-like signaling to update the occasion / slot counter (i.e. basic RFID operation and not novel).

[0169] In this embodiment a device receiving a “NACK” could either be triggered to re-access in a later Access Occasion or the subsequent Access Round (not yet determined in 3GPP so including both options, even though the latter is more technically sound).

[0170] As above, using this embodiment, a device can now use the combined Feedback+QueryRep distinguish between the case that the (last segment) of the Msg3 was successful (“ACK” in QueryRep) or if the network has just given up on scheduling further Msg3 retransmissions (“NACK” in QueryRep). In the latter case the device would trigger re-access in the subsequent Access Round (or a later Access Occasion).

[0171] In one embodiment, Msg2 can be combined with QueryRep-like signaling to indicate whether re-access should / could be performed. More specifically, Msg2 may include an index indicating the number of (re)transmissions have been triggered for a specific Msg3 / Msg5, a device should / could perform re-access if the following conditions are met:

[0172] • The device receives a QueryRep-like signaling.

[0173] • The device has transmitted in the access occasion prior to Query Rep-like signaling.

[0174] • The last Msg2 received by the device prior to Query Rep-like signaling includes the AS ID (e.g., RN16) of the device and the index in Msg2 indicates it is the Nth retransmission where N larger than a preconfigured threshold (the thresholdshould be preferably not less than 1 meaning perform re-access after at least one retransmission).

[0175] Embodiment on feedback options and types if transmission is a segment other than the last one

[0176] In one embodiment, if a transmission is divided in multiple segments, then the feedback behavior for the segment (other than the last segment) is defined as follows:.

[0177] • For transmission success, the reader does not need to indicate any explicit ACK signaling as long as there is message defined for granting resources for next segment (e.g., NDI indicating new data and the uplink resources for the transmission). This means if a Msg2 is sent by reader to indicate grant related information of the next segment (or the NDI not indicating retransmission), it is assumed the current segment is transmitted successfully. We here assume segment transmission are in order. If a n-th segment is failing, then device cannot transmit n+1-th segment until the n-th segment is transmitted successfully.

[0178] • For triggering re-access when (re)transmission of a segment is failed and reader does not want to trigger retransmission anymore, the reader sends nothing. When device does not receive Msg2 retransmission grant (for current / last segment retransmission) or new Msg2 grant message indicating grant for next segment, it is assumed, the current segment transmission has failed (implicitly NACKed) and re-access should / could be performed, and device should / could do or look for re-access as per re-access policies and transmit from the 1st segment after re-access.

[0179] • See below Table 2 summarizing feedback behavior for segments (other than the last segment).

[0180] Table 2: Feedback behavior for a segment transmission (other than the last segment) Event type Segment Transmission Re-access retransmission success of the indication segment

[0181] Event trigger Send Msg2 Send Grant for next Send nothing retransmission grant segment (e.g., NDI

[0182] again (e.g., NDI indicating new data to

[0183]

[0184] indicating same data tobe transmitted) be transmitted)

[0185]

[0186] In case the segment transmission is a last segment, the feedback behavior can be based on various options defined in Table 1.

[0187] Further, related to segments, given a transmission is broken into N segments, and it is assumed a buffer-less system, hence if a device able to send n segments successfully where n < N, where due to failure of n+1 segment and accordingly reader indicates reaccess (implicitly e.g., based in Table 2), then device will look for new occasion to perform re-access and retransmit its segments.

[0188] Note that to have this work the reader needs to know whether the device has applied segmentation for the D2R transmission and whether the D2R transmission is for the last segment. To enable this the device may add a specific preamble / postamble to the D2R transmission when the transmission is not for the last segment. Based on the preamble / postamble the reader could know whether the corresponding D2R transmission is for the last segment and behaves as described above if this is the case. In some embodiments, if device is transmitting a transmission broken into N segments where it has successfully transmitted k segments but failed to transmit k+1-th segment, and if reader triggers a re-access, the device will not transmit the current failed and subsequent next segments and terminate the current occasion, and look for new occasion to transmit its transmission again, e.g.,

[0189] • In one option, right from 1st segment, and

[0190] • In another option, from the k+1-th segment (which had failed in previous occasion).

[0191] Embodiment on window for access and retransmission attempts

[0192] In one embodiment, the network (CN / reader / gNB) defines a common D2R window for one or more D2R (device-to-reader) / data “transmission and its retransmissions (if needed” in a random-access occasion which a device has grabbed after successful contention resolution, i.e., the device has successfully transmitted Msg1. In other words, in this common D2R window, the device is allowed to perform one or more D2Rtransmission (re-) attempts. For e.g., in this D2R window, say if Msg3 in its first attempt has failed, then it allowed to retransmit until the expiry of D2R window.

[0193] Note, here, a D2R transmission is data transmission (which may contain additional AS information). Hence a device transmission containing pure AS info, e.g., RN16 is excluded from our D2R definition. The device transmissions can be denoted as MsgX where X is odd number, i.e., X =1,3, 5, 7... and the reader transmissions are MsgY where Y is even whole number, i.e., Y = 0, 2,4,6...

[0194] Embodiment on cross-occasion access / re-access

[0195] In one embodiment, in this common D2R window, the device is allowed to perform transmission of all segments. For e.g., say device Msg5 is broken down to 4 segments, then in this window, then device has only this window to transmit one or more segments from set of 4 segments of this transmission. If the device performs transmission of less than 4 segments and window is expired, then transmission would be deemed failure and re-access policy may be triggered.

[0196] In one embodiment, the segments of a D2R transmission are not allowed to be transmitted in different random-access occasions, or in different D2R windows (each occasion is associated with a dedicated D2R window subject to Msg1 success. In case of re-access, the device transmits again all or attempt to transmit again all segments in the new occasion (whether it’s successful to transmit none, some or all is separate thing). In other words, segments from a single transmission must not be transmitted in different RA occasion.

[0197] Embodiment on retransmission

[0198] Assuming, after a device has won contention resolution during a contention based random access procedure, i.e., (after the device has transmitted an ID for contention resolution (e.g., a random ID with N bits), the reader has replied the same ID to the device indicating that the device’ ID has been successfully identified / received by the reader.), the device sends an initial transmission containing data to the reader (e.g., using the resources indicated by the reader in a DL message, e.g., Msg2). Hence, in the main embodiment, we define a behavior, where the device determines whether to trigger a retransmission based on one of the below conditions1) The device receives a DL message on the same access occasion indicating the same, e.g., frequency-domain resources as the previous transmission (note: time -domain resource cannot b same)

[0199] 2) The device receives a DL message on the same access occasion indicating different resources from the previous transmission

[0200] The DL message may also include the device’s ID (e.g., the device’s ID for contention resolution), to indicate that the allocated resources are for the device to perform retransmission.

[0201] As an additional embodiment, the device determines whether to trigger a retransmission when the device receives a DL message on the same access occasion indicating the same or different resources as the previous transmission within a time period. The time period may be configured to the device by the reader. Alternatively, the time period is preconfigured to the device. When the time period is expired, the device considers no (further) retransmissions needed.

[0202] As an additional embodiment, the device receives a DL (or R2D) signaling indicating a number of a maximum number of retransmissions on the same access occasion that the device can perform, and afterwards re-access policy kicks in. After the initial transmission, the device may perform retransmissions up to the maximum number. After that, the device considers no further retransmissions needed on the current access occasion.

[0203] In one of the embodiments, upon reception of an UL (or D2R) transmission from a device, the reader may trigger the device to perform retransmissions on the current access occasion if the reader determines that the reception of this UL transmission has failed. The reader applies one of the below options to trigger the device to perform retransmissions.

[0204] 1) Sends a DL message on the same access occasion indicating the same resources (e.g., frequency domain; not time domain resources) as the previous transmission

[0205] 2) Sends a DL message on the same access occasion indicating different resources from the previous transmissionAs an additional embodiment, the reader sends a DL signaling or (R2D) signaling to a device indicating a maximum number of retransmissions on the same access occasion that the device may perform.

[0206] Fig. 9 is a schematic drawing illustrating a communication system 900, also referred to as wireless communications system 100. The communication system 900 comprises a network node 901, such as the and a wireless device 903, such as the UE 105. The wireless communication system 900 may comprise other entities, for example at least one of the entities illustrated in fig. 5.

[0207] Fig. 10 is a signalling diagram illustrating a method. The method comprises at least one of the following steps:

[0208] Step 1001

[0209] The wireless device 903 provides a transmission to the network node 901.

[0210] Step 1002

[0211] The network node 901 checks the status of the transmission. The status may be that it has failed or succeeded. The first status may be failure, and the second status may be success, or vice versa.

[0212] Step 1003

[0213] The network node 901 may determine an action to be performed. The decision may be taken based on the status checked in step 1002.

[0214] Step 1004

[0215] The network node 901 may provide status information to the wireless information. The status information is according to the check in step 1002.

[0216] Step 1005

[0217] The wireless device 903 performs an action. The performing of the action is triggered by the obtained status information. Which action that is performed is dependent on thestatus. There may be a first action for a first status and a second action for a second status. The action may be related to retransmission or re-access.

[0218] The method described above will now be described seen from the perspective of the network node 901. Figs. 11A and 11B is a flowchart describing the present method in the network node 901 for handling transmissions in a communications system 100, 900. The method comprises at least one of the following steps to be performed by the network node 901, which steps may be performed in any suitable order than described below:

[0219] Step 1101

[0220] The network node 901, 101a determines status of a transmission from the wireless device 903, 105 to the network node 901, 101a.

[0221] Step 1102

[0222] The network node 901, 101a provides, to a wireless device 903, 105, status information indicating the status of the transmission from the wireless device 903, 105 to the network node 901, 101a, wherein the status information triggers an action to be performed by the wireless device 903, 105.

[0223] Step 1103

[0224] Based on the status of the transmission, the network node 901, 101a may determine the action to be performed.

[0225] Step 1104

[0226] The network node 901, 101a may obtain user data.

[0227] Step 1105

[0228] The network node 901, 101a may forward the user data to a host or a user equipment.

[0229] Fig. 12 is a schematic drawing illustrating the network node 901, 101a for handling transmissions in a communication system.The network node 901, 101a may comprise processing circuitry 1201 e.g. one or more processors, configured to perform the methods herein.

[0230] The network node 901, 101a further comprises a memory 1205. The memory 1205 comprises one or more units to be used to store data on, such as indications, transmissions, indications, status information, retransmission information, re-access information, measurements, thresholds, data related to nodes, and applications to perform the methods disclosed herein when being executed, and similar. Furthermore, the network node 901, 101a may comprise a communication interface 1206 such as comprising a transmitter, a receiver, a transceiver and / or one or more antennas.

[0231] The methods according to the embodiments described herein for the network node 901, 101a 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 network node 901, 101a. 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 network node 901, 101a. In some embodiments, the computer-readable storage medium may be a transitory or a non-transitory computer-readable storage medium. Thus, embodiments herein may disclose a network node 901, 101a for handling transmissions in a wireless communication network, wherein the network node 901, 101a comprises processing circuitry and a memory, the memory comprising instructions executable by the processing circuitry whereby the network node 901, 101a is operative to perform any of the methods herein.

[0232] The method described above will now be described seen from the perspective of the wireless device 903, 105. Figs. 13A and 13B is a flowchart describing the present method in the wireless device 903, 105 for handling transmissions in a communication system. The method comprises at least one of the following steps to be performed bythe wireless device 903, 105, which steps may be performed in any suitable order than described below:

[0233] Step 1301

[0234] The wireless device 903, 105 obtains, from a network node 901, 101a, status information indicating the status of the transmission from the wireless device 903, 105 to the network node 901, 101a, wherein the status information triggers an action to be performed by the wireless device 903, 105.

[0235] Step 1302

[0236] The wireless device 903, 105 performs the action triggered by the status information.

[0237] Step 1303

[0238] The wireless device 903, 105 may provide user data.

[0239] Step 1304

[0240] The wireless device 903, 105 may forward the user data to a host via the transmission to the network node 901, 101a.

[0241] Fig. 14 is a schematic drawing illustrating the wireless device 903, 105 for handling transmissions in a communications system 100, 900.

[0242] The wireless device 903, 105 may comprise processing circuitry 1401 e.g. one or more processors, configured to perform the methods herein.

[0243] The wireless device 903, 105 further comprises a memory 1405. The memory 1405 comprises one or more units to be used to store data on, such as indications, transmission, status information, retransmission information, re-access information, measurements, thresholds, data related to nodes, and applications to perform the methods disclosed herein when being executed, and similar. Furthermore, the wireless device 903, 105 may comprise a communication interface 1406 such as comprising a transmitter, a receiver, a transceiver and / or one or more antennas.The methods according to the embodiments described herein for the wireless device 903, 105 are respectively implemented using e.g., a computer program product 1407 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 wireless device 903, 105. The computer program product 1407 may be stored on a computer-readable storage medium 1408 e.g. a disc, a universal serial bus (USB) stick or similar. The computer-readable storage medium 1408 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 wireless device 903, 105. In some embodiments, the computer-readable storage medium may be a transitory or a non-transitory computer-readable storage medium. Thus, embodiments herein may disclose a wireless device 903, 105 for handling transmissions in a wireless communication network, wherein the wireless device 903, 105 comprises processing circuitry and a memory, the memory comprising instructions executable by the processing circuitry whereby the wireless device 903, 105 is operative to perform any of the methods herein.

[0244] Figure 15 shows an example of a communication system QQ100 in accordance with some embodiments.

[0245] In the example, the communication system QQ100 includes a telecommunications network QQ102 that includes an access network QQ104, such as a radio access network (RAN), and a core network QQ106, which includes one or more core network nodes QQ108. The access network QQ104 includes one or more access network nodes or base stations of various types, access network nodes QQ110A and QQ110B are depicted (which may be collectively referred to as network nodes QQ110), or any other similar 3rdGeneration Partnership Project (3GPP) access nodes or non-3GPP access points (APs). Some embodiments of the access network QQ104 may include more than one access network technology. The network nodes QQ110 of access network QQ104 facilitate direct or indirect connection of wireless devices, also referred to as user equipments (UEs), such as by connecting UEs QQ112A, QQ112B, QQ112C, and QQ112D (one or more of which may be generally referred to as UEs QQ112) to the core network QQ106 over one or more wireless connections.Moreover, 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 telecommunications network QQ102 includes one or more Open-RAN (ORAN) network nodes. An ORAN network node is a network node in the telecommunications network QQ102 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 network nodes to implement one or more functionalities of any network node in the telecommunications network QQ102, including one or more access network nodes QQ110 and / or core network nodes QQ108.

[0246] 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). An ORAN network node may support a specification by, for example, supporting an interface defined by the ORAN specification, such as an A1, F1, W1, E1, E2, X2, Xn interface, an open fronthaul user plane interface, or an open fronthaul management plane interface. Moreover, an ORAN network 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 0-2 interface defined by the O-RAN Alliance or comparable technologies.

[0247] The network nodes QQ110 facilitate direct or indirect connection of one or more UEs QQ112 to the core network QQ106 over one or more wireless connections. 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 QQ100 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 QQ100 may include and / or interface with any type of communication, telecommunication, data, cellular, radio network, and / or other similar type of system.

[0248] The UEs QQ112 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 QQ110 and other communication devices. Similarly, the network nodes QQ108, QQ110 are arranged, capable, configured, and / or operable to communicate directly or indirectly (e.g., via other devices of telecommunications network QQ102) with the UEs QQ112 and / or with other network nodes or equipment in the telecommunications network QQ102 to enable and / or provide network access, such as wireless network access, and / or to perform other functions, such as administration in the telecommunications network QQ102. More specifically, UEs QQ112 may send messages, data, and / or other signals to network nodes QQ108, QQ110 or other elements of the telecommunications network QQ102 by transmitting such signals to the relevant device directly without the signals passing through any intervening devices or by transmitting such signals to the relevant device indirectly through an intervening device (or multiple intervening devices) that then transmit the signal to the relevant device. Similarly, network nodes QQ108, QQ110 may send messages, data, and other signals to UEs QQ1122, other network nodes QQ108, QQ110, and other devices in telecommunications network QQ102 directly or indirectly. As one specific example, a core network node 108 may transmit a particular message to a UE QQ112 by transmitting the message to an access network node QQ110 that will then transmit the message to the intended UE QQ112. Similarly, a core network node 108 may receive a particular message from a UE QQ112 by receiving the message from an access network node QQ110 that itself received the message from the UE QQ112.

[0249] In the depicted example, the core network QQ106 connects elements of the access network QQ104 (e.g., one or more of the network nodes QQ110) to one or more hostcomputing systems, such as host QQ116. 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 QQ106 includes one or more core network nodes (e.g., core network node QQ108) of various types, one or more of which may be generally referred to as network nodes QQ108. Network nodes QQ108 are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, access network nodes, and / or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node QQ108. Example core network nodes provide 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).

[0250] The host QQ116 may be under the ownership or control of a service provider other than an operator or provider of the access network QQ104 and / or the telecommunications network QQ102. The host QQ116 may be operated by the service provider or on behalf of the service provider. The host QQ116 may host a variety of applications to provide one or more service. 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.

[0251] As a whole, the communication system QQ100 of Figure QQ1 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system QQ100 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(Wi-Fi); and / or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (Wi-Max), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, Li-Fi, and / or any low-power wide-area network (LPWAN) standards such as LoRa and Sigfox. Moreover, the communication system QQ100 may be configured to support multiple different standards, protocols, or other rule sets, with individual components supporting all of the relevant rule sets or with different components or sub-systems within the communication system QQ100 supporting different standards, protocols, or rule sets.

[0252] As one example, in certain embodiments, access network QQ104 may contain some access network nodes QQ110 that support 3GPP radio access technologies (RAT), such as LTE or NR, while other access network nodes QQ110 support (or the same access network nodes QQ110 additionally support) non-3GPP RATs, such as Wi-Fi or a proprietary RAT. As another example, telecommunications network QQ102 may support multiple generations of related communication standards (e.g., 4G and 5G 3GPP communication standards) and, as a result, may include an access network 104 and / or a core network 106 that supports multiple different standard generations or may include multiple access networks 104 and / or multiple core networks 106 with individual networks 104, 106 supporting different standard generations.

[0253] Telecommunications network QQ102 may support network slicing to provide different logical networks to different devices that are connected to the telecommunications network QQ102. For example, the telecommunications network QQ102 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.

[0254] In some examples, one or more of the UEs QQ112 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 QQ104 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network QQ104. 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).

[0255] In the example, the hub QQ114 communicates with the access network QQ104 to facilitate indirect communication between one or more UEs (e.g., UE QQ112C and / or QQ112D) and network nodes (e.g., network node QQ110B). In some examples, the hub QQ114 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub QQ114 may be a broadband router enabling access to the core network QQ106 for the UEs. As another example, the hub QQ114 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 QQ110, or by executable code, script, process, or other instructions in the hub QQ114.

[0256] As another example, the hub QQ114 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 QQ114 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub QQ114 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub QQ114 then provides to the UE either directly, after performing local processing, and / or after adding additional local content. In still another example, the hub QQ114 acts as a proxy server or orchestrator for the UEs, in particular if one or more of the UEs are low energy loT devices.

[0257] The hub QQ114 may have a constant / persistent or intermittent connection to the network node QQ110B. The hub QQ114 may also allow for a different communication scheme and / or schedule between the hub QQ114 and UEs (e.g., UE QQ112C and / or QQ112D), and between the hub QQ114 and the core network QQ106. In other examples, the hub QQ114 is connected to the core network QQ106 and / or one or more UEs via a wired connection. Moreover, the hub QQ114 may be configured to connect to an M2M service provider over the access network QQ104 and / or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes QQ110 while still connected via the hub QQ114 via a wired or wirelessconnection. In some embodiments, the hub QQ114 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 QQ110B. In other embodiments, the hub QQ114 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node QQ110B, but which is additionally capable of operating as a communication start and / or end point for certain data channels.

[0258] Figure 16 is another example of a communication system QQ200 according to some embodiments. As used herein, the communication system QQ200 includes multiple access points (APs) QQ210 (with four exemplary APs QQ210A, QQ210B, QQ210C, and QQ210D being depicted) and multiple wireless devices, referred to in the context of communication system QQ200 as stations (STAs) QQ212 (referred to individually as STA QQ212A, STA QQ212B, STA QQ212C, STA QQ212D, and STA QQ212E). STA QQ212A is served by AP QQ210A in a first basic service set (BSS) QQ220A. STA QQ210B and STA QQ210C are served by AP QQ210B in a second BSS, BSS QQ220B. STA QQ212D is served by AP QQ210C in a third BSS, BSS QQ220C. STA QQ212E is served by AP QQ210D in a fourth BSS, BSS QQ220D. Stations QQ212 may be non-AP STAs and correspond to various kinds of wireless devices, for example, user terminals, such as mobile or stationary computing devices like smartphones, laptop computers, desktop computers, tablet computers, gaming devices, head-mounted displays (HMDs) for Augmented Reality (AR) or Virtual Reality (VR), or the like. Further, stations QQ212 could, for example, correspond to other kinds of equipment like smart home devices, printers, multimedia devices, data storage devices, or the like.

[0259] Each of STAs QQ212 may connect through a radio link to one of APs QQ210. For example, depending on location or channel conditions experienced by a given STA QQ212, the STA may select an appropriate AP and BSS for establishing the radio link. The radio link may be based on one or more orthogonal frequency-division multiplexing (OFDM) carriers from a frequency spectrum that is shared on the basis of a contentionbased mechanism, e.g., an unlicensed or license exempt band like 2.4 GHz Industrial, Scientific, and Medical (ISM) band, the 5 GHz band, the 6 GHz band, or the 60 GHz band.Each AP QQ210 may provide data connectivity to STAs QQ212 connected to a particular AP QQ210. As illustrated, APs QQ210 may be connected to a data network QQ230. In this way, APs QQ210 may also provide data connectivity between STAs QQ212 and other entities, e.g., to one or more servers, service providers, data sources, data sinks, user terminals, or the like. Accordingly, the radio link established between a given STA QQ212 and its serving AP QQ210 may be used for providing various kinds of services to STA QQ212, e.g., a voice service, a multimedia service, or other data service. Such services may be based on applications that are executed on STA QQ212 and / or on a device linked to STA QQ212. By way of example, Figure 16 illustrates an application service platform QQ232 provided in data network QQ230. The application(s) executed on STA QQ212 and / or on one or more other devices linked to STA QQ212 may use the radio link for data communication with one or more other STA QQ212 and / or the application service platform QQ232, thereby enabling utilization of the corresponding service(s) at STA QQ212.

[0260] Figure 17 shows a wireless device QQ300, which may be configured to operate in communication system QQ100 of Figure QQ1 or in communication system QQ200 of Figure QQ20. The wireless device QQ300 may be alternatively referred to as a UE QQ300, like a UE QQ112 within the context of communication system QQ100, or as a station (STA) QQ300 or as a non-access-point station (non-AP STA) QQ300, like a STA QQ212 within the context of the communication system QQ200, in accordance with respective embodiments. As used herein, a wireless device refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other wireless devices. Examples of a wireless device 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 device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle, vehicle-mounted or vehicle embedded / integrated wireless device, and wireless terminal. Other examples include any type of UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-loT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.A wireless device QQ300 may support device-to-device (D2D) communication, for example by implementing a 3GPP 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, wireless device QQ300 may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, wireless device QQ300 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).

[0261] Alternatively, wireless device QQ300 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).

[0262] In particular embodiments, wireless device QQ300 includes processing circuitry QQ302 that is operatively coupled via a bus QQ304 to an input / output interface QQ306, a power source QQ308, a memory QQ310, a communication interface QQ312, and / or any other component, or any combination thereof. Certain embodiments of wireless device QQ300 may include all or a subset of the components shown in Figure QQ3. The level of integration between the components may vary from one embodiment of wireless device QQ300 to another. In general, in a particular embodiment of wireless device QQ300, processing circuitry QQ302, input / output interface QQ306, power source QQ308, memory QQ310, and communication interface QQ312 may, in whole or in part, represent or include physical components common to or shared by one or more of the other elements of wireless device QQ300. Further, certain embodiments of wireless devices QQ300 may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0263] The processing circuitry QQ302 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 QQ310. The processing circuitry QQ302 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-purposeprocessors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry QQ302 may include multiple central processing units (CPUs).

[0264] In the example, the input / output interface QQ306 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 wireless device QQ300. 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.

[0265] In some embodiments, the power source QQ308 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 to supply power to circuitry or to charge an associated battery. The power source QQ308 may further include power circuitry for delivering power from the power source QQ308 itself, and / or an external power source, to the various parts of wireless device QQ300 via input circuitry or an interface such as an electrical power cable. Power source QQ308 may perform any formatting, converting, or other modification to make accessible power suitable for the respective components of the wireless device QQ300 to which power is supplied.

[0266] The memory QQ310 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 erasableprogrammable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory QQ310 includes one or more programs QQ314, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data QQ316. The memory QQ310 may store, for use by wireless device QQ300, any of a variety of various operating systems or combinations of operating systems.

[0267] The memory QQ310 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 (eUlCC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory QQ310 may allow wireless device QQ300 to access instructions, 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 QQ310, which may be or comprise a device-readable storage medium.

[0268] The processing circuitry QQ302 may be configured to communicate with an access network or other network via or using the communication interface QQ312. The communication interface QQ312 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna QQ322. The communication interface QQ312 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 wireless device or a network node in an access network). Each transceiver may include a transmitter QQ318 and / or a receiver QQ320 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter QQ318 and receiver QQ320 may be coupled to one or more antennas (e.g., antenna QQ322) andmay share circuit components, software or firmware, or alternatively be implemented separately.

[0269] In the illustrated embodiment, communication functions of the communication interface QQ312 may include cellular communication, Wi-Fi communication (e.g., according to an IEEE 802.11 family standard), 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 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 / internet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.

[0270] In particular embodiments, wireless device QQ300 may provide an output of data captured via a sensor, through its communication interface QQ312, via a wireless connection to a network node, and / or in any appropriate manner. Data captured by sensors of a wireless device QQ300 can be communicated through a wireless connection to a network node via another wireless device QQ300. In particular embodiments, such 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).

[0271] As another example, wireless device QQ300 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, wireless device QQ300 may comprise a motor that adjusts the control surfaces or rotors of adrone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input.

[0272] Wireless device QQ300, 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, wearable technology, extended industrial application and healthcare. Nonlimiting 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 smartwatch, 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. In particular embodiments, wireless device QQ300 represents an loT device that comprises circuitry and / or software in dependence of the intended application of the loT device in addition to other components as described in relation to the example embodiment of wireless device QQ300 shown in Figure QQ3.

[0273] As yet another specific example, in an loT scenario, wireless device QQ300 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 wireless device and / or a network node. Wireless device QQ300 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, wireless device QQ300 may implement the 3GPP NB-loT standard. In other scenarios, wireless device QQ300 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.

[0274] In practice, any number of wireless devices QQ300 may be used together with respect to a single use case. For example, a first wireless device QQ300 might be or be integratedin a drone and provide the drone’s speed information (obtained through a speed sensor) to a second wireless device QQ300 that is a remote controller operating the drone. When a user makes changes from the remote controller, the first wireless device QQ300 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 wireless device QQ300 can also include more than one of the functionalities described above. For example, wireless device QQ300 might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

[0275] Figure 18 shows a network node QQ400 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 telecommunications network. In accordance with respective embodiments, network node QQ400 may be configured to operate in communication system QQ100 of Figure QQ1, like network nodes QQ108 or QQ110, or in communication system QQ200 of Figure QQ2, like an AP QQ210 or a station QQ212. 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).

[0276] Network nodes QQ400 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. Network node QQ400 may be a relay node or a relay donor node controlling a relay. Network nodes QQ400 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).Other examples of network nodes QQ400 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).

[0277] In particular embodiments, network node QQ400 includes a processing circuitry QQ402, a memory QQ404, a communication interface QQ406, and a power source QQ408. In general, in a particular embodiment of network node QQ400, processing circuitry QQ402, memory QQ404, communication interface QQ406, and power source QQ408 may, in whole or in part, represent or include physical components common to or shared by one or more of the other elements of network node QQ400.

[0278] The network node QQ400 may be composed of multiple distinct network entities (e.g., a NodeB entity and a RNC entity, or a BTS entity and a BSC entity, etc.), which may each have or utilize their own respective physical components. In certain scenarios in which the network node QQ400 comprises multiple such entities (e.g., BTS and BSC), one or more of the separate entities 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 QQ400 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memories QQ404 or portions of memory QQ404 for different RATs) and some components may be reused (e.g., a same antenna QQ410 may be shared by different RATs). The network node QQ400 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node QQ400, for example GSM, WCDMA, LTE, NR, Wi-Fi (e.g., according to an IEEE 802.11 family standard), 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 QQ400.The processing circuitry QQ402 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 components, such as the memory QQ404, to provide network node QQ400 functionality.

[0279] In some embodiments, the processing circuitry QQ402 includes a system on a chip (SOC). In some embodiments, the processing circuitry QQ402 includes one or more of radio frequency (RF) transceiver circuitry QQ412 and baseband processing circuitry QQ414. In some embodiments, the RF transceiver circuitry QQ412 and the baseband processing circuitry QQ414 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 QQ412 and baseband processing circuitry QQ414 may be on the same chip or set of chips, boards, or units.

[0280] The memory QQ404 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 computer-executable memory devices that store information, data, and / or instructions that may be used by the processing circuitry QQ402. The memory QQ404 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 QQ402 and utilized by the network node QQ400. The memory QQ404 may be used to store any calculations made by the processing circuitry QQ402 and / or any data received via the communication interface QQ406. In some embodiments, the processing circuitry QQ402 and memory QQ404 is integrated.The communication interface QQ406 is used in wired or wireless communication of signaling and / or data with UEs, other network nodes, and / or any other network equipment. In the illustrated embodiment, communication interface QQ406 comprises port(s) / terminal(s) QQ416 to send and receive data, for example to and from a network over a wired connection. In particular embodiments, network node QQ300 may be capable of wireless communication and communication interface QQ406 may also include radio front-end circuitry QQ418 that may be coupled to, or in certain embodiments a part of, an antenna QQ410. Particular embodiments of radio front-end circuitry QQ418 include filter(s) QQ420 and amplifier(s) QQ422. The radio front-end circuitry QQ418 may be connected to an antenna QQ410 and processing circuitry QQ402. The radio front-end circuitry may be configured to condition signals communicated between antenna QQ410 and processing circuitry QQ402. The radio front-end circuitry QQ418 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 QQ418 may convert the digital data into a radio signal(s) having the appropriate channel and bandwidth parameters using a combination of filters QQ420 and / or amplifiers QQ422. The radio signal(s) may then be transmitted via the antenna QQ410. Similarly, when receiving data, the antenna QQ410 may collect radio signals which are then converted into digital data by the radio front-end circuitry QQ418. The digital data may be passed to the processing circuitry QQ402. In other embodiments, the communication interface may comprise different components and / or different combinations of components.

[0281] In certain alternative embodiments, network node QQ400 may be capable of wireless communication but does not include separate radio front-end circuitry QQ418, instead, the processing circuitry QQ402 includes radio front-end circuitry and is connected to the antenna QQ410. Similarly, in some embodiments, all or some of the RF transceiver circuitry QQ412 is part of the communication interface QQ406. In still other embodiments, the communication interface QQ406 includes one or more ports or terminals QQ416, the radio front-end circuitry QQ418, and the RF transceiver circuitry QQ412, as part of a radio unit (not shown), and the communication interface QQ406 communicates with the baseband processing circuitry QQ414, which is part of a digital unit (not shown).The antenna QQ410 may include one or more antennas, or antenna arrays, configured to send and / or receive wireless signals. The antenna QQ410 may be coupled to the radio front-end circuitry QQ418 and may be any type of antenna capable of transmitting and receiving data and / or signals wirelessly. In certain embodiments, the antenna QQ410 is separate from the network node QQ400 and connectable to the network node QQ400 through one or more interfaces or ports.

[0282] The antenna QQ410, communication interface QQ406, and / or the processing circuitry QQ402 may be configured to perform some or all of the receiving operations and / or obtaining operations described herein as being performed by the network node QQ400. Any information, data and / or signals may be received from a UE, another network node and / or any other network equipment. Similarly, the antenna QQ410, the communication interface QQ406, and / or the processing circuitry QQ402 may be configured to perform some or all of the transmitting or sending operations described herein as being performed by the network node QQ400. Any information, data and / or signals may be transmitted to a UE, another network node and / or any other network equipment.

[0283] The power source QQ408 provides power to the various components of network node QQ400 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source QQ408 may further comprise, or be coupled to, power management circuitry to supply the components of the network node QQ400 with power for performing the functionality described herein. For example, the network node QQ400 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 QQ408. As a further example, the power source QQ408 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.

[0284] Embodiments of the network node QQ400 may include additional components beyond those shown in Figure QQ4 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 networknode QQ400 may include user interface equipment to allow input of information into the network node QQ400 and to allow output of information from the network node QQ400. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node QQ400.

[0285] Figure 19 is a block diagram illustrating a virtualization environment QQ500 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 can 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 QQ500 hosted by one or more of hardware nodes, such as a hardware computing device that operates as an access network node, UE, core network node, or host. Further, in embodiments in which a 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 QQ500 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.

[0286] Applications QQ502 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment QQ400 to implement some of the features, functions, and / or benefits of some of the embodiments disclosed herein.

[0287] Hardware QQ504 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 QQ506 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VM QQ508A and VM QQ508B (which may be collectively referred to as VMs QQ508), and / or perform any of the functions, features and / or benefits describedin relation with some embodiments described herein. The virtualization layer QQ506 may present a virtual operating platform that appears like networking hardware to one or more of the VMs QQ508.

[0288] The VMs QQ508 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by virtualization layer QQ506. Different embodiments of the instance of a virtual appliance QQ502 may be implemented on one or more of VMs QQ508, and the implementations may be made in different ways.

[0289] 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 can be located in data centers, and customer premise equipment.

[0290] In the context of NFV, each of the VMs QQ508 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, nonvirtualized machine. Each of the VMs QQ508, and that part of hardware QQ504 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 of the VMs QQ508 on top of the hardware QQ504 and corresponds to an application QQ502.

[0291] Hardware QQ504 may be implemented in a standalone network node with generic or specific components. Hardware QQ504 may implement some functions via virtualization. Alternatively, hardware QQ504 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 QQ510, which, among others, oversees lifecycle management of applications QQ502. In some embodiments, hardware QQ504 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 can be provided with the use of a control systemQQ512 which may alternatively be used for communication between hardware nodes and radio units.

[0292] Although the computing devices described herein (e.g., UEs, network nodes, hosts) 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.

[0293] 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.

[0294] 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 hardwired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits providedby 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.

[0295] 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.

[0296] 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.

[0297] 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.

[0298] 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.

[0299] 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.The term “configured to” used herein may also be referred to as “arranged to”, “adapted to”, “capable of” or “operative to”.

[0300] The steps of the methods may be performed in another order than the order in which they appear herein.APPENDIX

[0301] 3GPP TSG-RAN WG2 #129 R2-2500974 Athens, Greece, Feb. 17th- 21st, 2025

[0302] Agenda Item: 8.2.4

[0303] Source: Ericsson

[0304] Title: A-loT Data Transmission and Other General Aspects

[0305] Document for: Discussion / Decision

[0306] 1 Introduction

[0307] In RAN#106, a new Wl has been approved for Ambient loT devices. The following RAN2 related objectives are capture in the WID:

[0308] o Specify the necessary functions and procedures for an Ambient loT compact protocol stack and lightweight signalling procedure to enable DO-DTT and DT data transmission:

[0309] ■ A-loT Paging, including subsequent paging for the same service.

[0310] Support the options that a paging message contains one identifier, and that a paging message contains no identifier.

[0311] Temporary identifier is not supported, unless required by SA WGs.

[0312] Note: RAN2 aims to design a paging message format such that multiple identifiers can be contained in one paging message, for forward compatibility purposes.

[0313] ■ A-loT Random access, including re-access for failure handling.

[0314] Contention-based and contention-free cases are supported. For the contention-based random access, only Solution 1 (3-step only) is included (unless RAN2 decides to use Solution 3 (unified solution) by RAN2#129).

[0315] ■ A-loT data transmission, including data (re-)transmission for failure handling. Segmentation is supported at least in D2R.

[0316] ■ Only MAC layer is included

[0317] This paper discusses aspects of data transmission functionality and other remaining general aspects required for A-loT D1T1 devices, such as MAC PDU format and control signaling, data (re)transmission for failure handling, segmentation / reassembly, AS ID handling and the use of IDs in general, as well as information related to message size of expected D2R transmission and command type information.2 Discussion

[0318] 2.1 MAC PDU format and Control signaling

[0319] 2.1.1 Octet vs. Bit aligned MAC PDU

[0320] In the previous meetings, some companies proposed the concept of not having octet aligned MAC PDU (or upper layer SDUs). It may be that the amount of control information to be sent is very low, just a few bits. In such case it might be beneficial to avoid octet alignment to avoid padding bits.

[0321] This discussion of course depends on how flexible and generic the TBS allocation is expected to be, also in future extensions.

[0322] Nevertheless, typically the length of a SDU is given in octet in NR. Avoiding octetalignment means that now the length should be given in bits, which would increase the amount of signaling bits for indicating the TBS size. As a result, it is not obvious, without other assumptions, to determine if bit-alignment would lead to a more efficient MAC PDU encoding than octet-alignment.

[0323] Moreover, considering device limitations, memory works by addressing words of various length, typically a byte. Therefore, it might create excessive complexity on device side to have bit-aligned buffers and stored data. Also, current network design assumes octet alignment. Changing this may create excessive implementation effort on network side.

[0324] Bit-alignment may cause excessive complexity and implementation effort on both device and network size due to the normal functioning of memory and existing implementations.

[0325] Octet aligned MAC PDUs and Sup PDUs are used at AloT MAC layer.

[0326] 2.1.2 MAC PDU format

[0327] For MAC PDU design, it is worth listing possible A-loT messages in both D2R and R2D transmission directions including field information and their use. Table 1 and table 2 below show possible messages to consider.

[0328] 2.1.2.1 D2R

[0329] Table 1: Possible D2R messages for MAC PDU designMsgl Any attar D2 R messages are farger fa s$se. thus no oOlllll TSedipSsss 1)111111 fe)Ote^ Ssctint^?j)eftdiHgjSS3;

[0330] iSijiaSp&iits; 1)111111): M$gS<:^ NA$ POU carryfag. upper Sayer OhOhssss: data

[0331] : C3ta&£:fiW&

[0332]

[0333] In D2R direction, Msg1 contains RN16 and be distinguished from other D2R message; given that all other D2R messages are larger in size. It is therefore proposed that MAC PDU for Msg1 does not need any control information. If this construct is possible, the message size would be small. Then Msg3 and onwards contains upper layer data (NAS PDU) with possible variable size, and to that also UL control information such as a segmentation indication. In addition, Msg3 may need to carry security information in support of the challenge-response authentication mechanism if defined (as in SA3 TR). Figure 1 shows an example of MAC PDU content for Msg1 and other D2R messages, respectively. Note that this example does not comprehensively list options, e.g. for where a smaller optimized size could be made, due to e.g. a fixed size payload part or where a random ID is not needed.

[0334] sgl J2. bytes)

[0335]

[0336] Msg3, 5,... with variable size (2 bytes overhead)

[0337]

[0338] Fixed pan of D h MAC POU from Msg3 (32 bits)

[0339] Figure 1: Example of MAC PDU format for D2R messages.

[0340] MAC PDU for Msg1 contains only RN16 without control information.

[0341] For the D2R message from Msg3, given that we may have command responses, the reader can know from which device (or RN16 sender) the D2R message comes from, either by explicit addressing with a device ID (e.g., AS ID / RN16) inside D2R message itself, or by means of associating where the message is received with scheduling information. The latter would require less overhead given device ID is at least 16 bits. RAN2 should discuss and clarify that addressing information (AS ID) is not included in D2R message itself. A length field tis needed o indicate how many bytes the upper layer data part is unless a fixed size Device ID is used. In addition, as detailed in section 2.2, a 1 -bit segmentation indication may be required to be included in the D2R message from Msg3, as detailed in Figure 1. This naturally depends on the TB sizes to assume additionally.

[0342] RAN2 to clarify the need of addressing information inside a D2R message from Msg3 and on.MAC PDU for D2R message other than Msg1 includes:

[0343] • A length field indicating the length of the upper layer data part. Discuss the size of this field (e.g., 7 bits)

[0344] • A 1 -bit segmentation indication

[0345] • Upper layer data (e.g., device ID, command reply, or other NAS data).

[0346] 2.1.2.2 R2D

[0347] In the R2D transmission direction, there are many more messages over the air interface, as exemplified in Table 2. A R2D message type field is useful to allow device(s) to identify and parse the received message. With such a message type field, we support a leaner protocol structure if we have a low number of fixed formats, i.e., fewer flags and length fields resulting in lower header overhead as well as less processing at device side. Currently, there are approx. 7 types of R2D messages, and as a starting point 3 bits seems sufficient for a message type field.

[0348] A R2D message type field is used to identify R2D messages and their corresponding format. It is still unclear what the content of the A-loT paging message is, including if this is impacted from subsequent paging. For example, the configuration and scheduling information regarding access occasion, frequency offset (to support FDMA + TDMA in D2R transmission), may be either carried by MAC, by PHY control information or both. RAN2 should wait for RAN1 progress on this aspect. The same applies to the R2D message used to update / adjust configurations for all devices in an access / paging / inventory round. In addition, RAN2 can assume that that least the R2D message used for synchronization purposes (Qrep-like) is part of PHY layer control signaling.

[0349] Table 2: Possible R2D messages for MAC PDU design

[0350] |||||||||$||^^ liiiiiiiiiiiiiiifiti 3 R2D message for re access

[0351] :giggg>g;g>g:ij!gigigitg::gigig)ggggS?jg§gi: S::sigg;igjtgggg!ggggggg:::::::::::::::::;:^|||j|ggggg; jffortiggSSsOssss MAC POL1design depends on i? (which part c?) 6 A-fc; T paging iSgif^giigiligSgg^ggggigSijgigggghggggiSggiggjgigiiigigAigfTgggggh OilOsOislsi igggr-gi3jiggJggiggigjg;ggggiggSg;^;: Sggggjgigigg|j:gggg;ggigg:j!:;:;:;:;:;:;:;:;:;: ggg^^^g:fg^gggg:)g:g OOltggggg;: S^§rOsSSSSSS? SsH8fogS§S3sj;fofofifoaifofi?rssss

[0352] :ggig:iagg§ggg§g:gg:geggggg§ggg8g:ggggg:g:

[0353]

[0354] For A-loT paging of an access round, RAN2 wait for further input from other WGs (RAN1, SA3, SA2) regarding control information to be included in the MAC PDU.

[0355] RAN2 assume the R2D message for sync (Qrep-like) is L1 control signaling. Send an LS to RAN1 to inform this.

[0356] OOP > s- A-ioT Paging, FPS MAC PDU format, pending RANI, SA3 progress

[0357] 001 > 2D for round reconfig, FrS MAC PDU format, pending RANI, SA3 progress

[0358] Fixed part of R2D MAC POU (3 bits)

[0359]

[0360] > Original Msg2 (variable size)

[0361]

[0362]

[0363] Oil. S' hiiS^^fT^^eservecngyi I RNis indication field codepoint:

[0364] _ I _ _ H _ Llliiiia 00 - R20 message for retx of D2R / Msg3 (3 bytes)

[0365] 01 - R2D message for re -access request (3 bytes) 10 ■ R2D message for next segment tx (3 bytes

[0366] 100 Msg4 / S (variable size) S

[0367]

[0368] (i‘ ^its.) I 13 G bits.) I ts h-iss) I contrfrur-ici I

[0369] >

[0370] Figure 3: Example of MAC PDU for R2D messages.’

[0371] Msg2 used to echo the RN16 in response to Msg1 can have its own format. As Msg2 may contain more than one RN16 value, there needs a field to indicate number of RN16s. Size of this field can be discussed, e.g., 5 bits. In addition, RAN2 needs to wait for progress from RAN1 to see if any L2 control signaling is needed, e.g., to facilitate a device to process only some parts meant for it rather than processing the whole PDU. For example, if a relation to FDMA index to selected RN16 would be defined. For instance, the valid RN16s are indicated in association with FDMA index, which means a device needs to parse RN16s related FDMA occasion index where it had transmitted. In addition, it remains open if any or what information for scheduling Msg3 is needed in the Msg2 MAC PDU.

[0372] MAC PDU for Msg2 used to echo Msg1 includes:

[0373] • R2D message type

[0374] • A field indicating the number of RN16s. Discuss the size of this field.

[0375] • FDMA index. Check with RAN1 if the information is available to MAC layer.

[0376] One or multiple RN16s

[0377] FFS if any L2 control information to facilitate processing of Msg2 at device and scheduling information for Msg3.

[0378] Before Msg3 is successfully delivered, there can be a need for some other R2D messages or indications to support a feedback mechanism, i.e., to indicate explicitly or implicitly to a device to perform retransmission of the previous D2R message, or to perform re-access, or to transmit the next D2R segment (as in Table 2). These cases can be combined in one MAC PDU format. In these cases there needs to be a device ID in such an R2D message indicating the targeted device. Given that the reader has not successfully received the complete upper layer device ID (in Msg3), this device ID can only be the RAN16 / handle. RAN2 can discuss if 2 bits are sufficient for such an indication. One example of this R2D message is illustrated in Figure 2.

[0379] MAC PDU for R2D messages for feedback mechanism may include:• R2D message type

[0380] • 16-bit ID for addressing information (e.g., AS ID / RN16)

[0381] • A field to indicate the usage, i.e., whether device needs to retransmission, re-access, or continue with next segment transmission.

[0382] MAC PDU for the DL message from Msg4 is to carry DL NAS data, i.e., command request received from CN and possibly other NAS information. The size of DL NAS data in this R2D message is likely variable. As a result, a length field is needed in the MAC sub-header to indicate the size of the MAC SDU. We assume 7 bits are sufficient for the length. For addressing purpose, a 16-bit AS ID / RN16 is also needed. Other potential DL control information can be decoded by using any of unused bits for future extension.

[0383] MAC PDU of R2D message from Msg4 includes:

[0384] • R2D message type

[0385] • 16-bit ID for addressing information (e.g., AS ID / RN16)

[0386] • A length field indicating the size of the upper layer data part. Discuss if 8 bits are sufficient.

[0387] Note that we assume that some of the formats e.g. subPDll, header fields for messages may in some cases be the same where the type field(s) may indicate the content, existence and use.

[0388] RAN2 waits forSA3 progress regarding if / what security information needs to be included in R2D and D2R message(s).

[0389] 2.2 Segmentation and Data retransmission for Failure Handling

[0390] In here retransmission is to allow the A-loT device to deliver the D2R message again in the same access occasion, possibly including a D2R segment without the need of performing the random access procedure again (re-access). To support this, one solution from the study is that the reader repeats the R2D transmission of Msg2 to specific devices whose D2R transmissions were not successfully received by the reader. This can apply also to the case of transmission pairs after Msg2 and Msg3, e.g., in case of a command procedure with multiple steps.

[0391] For the D2R segmentation mechanism, an indication is included to let the reader know if segmentation is used and if the PDU is the last segment. Details to the usage of the indication and its resulting size as well as how to realize this at MAC needs further discussion. For the segmentation, the current TR38.769 mentions as below:

[0392] - The sequence number, the segment number and the number of segments are not supported;

[0393] - An indication is used to indicate to the reader on whether the data is segmented and whether the MAC PDU is the last segment. It needs to be further discussed on the size of this indication (one or two bits) and the corresponding further details;

[0394] - It is beneficial for the reader to be able to trigger a re-transmission of a segment;

[0395] - It is assumed that the A-IoT device will not support AS layer buffering for A-IoT segmentation functionalities, i.e., all segment(s) are stored in upper layer(s).The overall mechanism is “Stop & Wait”, meaning that the transmitter waits for the receiver before continuing with a transmission of a next segment, or if possibly retransmit the (previous) segment.

[0396] For the indication, if the data is not segmented, this is equivalent to the first segment being also the last segment. On the other hand, if the device indicates that this is not the last segment, it is clear for the reader that this data is a segment. Therefore, only 1 bit is necessary to support segmentation, as also detailed in the Msg3 MAC PDU format in previous section.

[0397] The device sends a 1-bit indication indicating whether the current transmission is the last segment or not.

[0398] Figure 1 a) and b) show the normal functioning of the segmentation procedure under these assumptions, and how the device keeps track of the offset in the buffer (c.f. pointer or “ptr”). It is assumed that the trigger from the reader contains a New Data Indicator (NDI) that is set to 1 to request the next segment or 0 to request the retransmission of the previous one.

[0399] It is important to notice that if we assume that each segment is sent upon a trigger from the reader (e.g.: UL Grant + ACK / NACK) two failures can happen: either the device receives the UL Grant but the reader does not receive the segment, or the device does not receive the UL Grant. In both cases, the reader will not detect any transmission in the UL resources reserved for the segment transmission, and thus in both cases the reader should behave in the same manner, for instance by sending a NACK. The device updates the buffer pointer “ptr” when the previous transmission has been acknowledged (NDI=1 )

[0400] The reader does not have a way to distinguish if a failure was caused by missing reception of the UL Grant or missing reception of the data segment.

[0401] The problem with this is represented in Figure 1 where in c) the device correctly receives the trigger message (and updates its buffer pointer) but the transmission of the segment fails. After NDI=0 has been sent the device just retransmits the previous segment and everything works as intended. On the other hand, if the trigger transmission fails (case d)) the device does not update the buffer pointer, so when the next NDI=0 is transmitted, the device would retransmit segment i, but the reader received segment i and is now expecting a retransmission of segment i+1. Therefore, in the reader buffer segment I will be appended twice.Device Pseudo-code:

[0402] On Upper LayerTrigger received:

[0403] Build Reply

[0404] ptr:= O

[0405] TBS_prev:= 0

[0406] Process UL Grant (below)

[0407] On ULGrant(TBS=x) received:

[0408] - if NDI==1:

[0409] o ptr:= ptr + TBS_prev

[0410] - if ptr== end_of_buffer:

[0411] o Completed

[0412] o TBS_prev:= x

[0413] o Transmit bit from

[0414]

[0415] ptr to ptr + x-1

[0416] a)

[0417] Device Reader

[0418] Data is OK

[0419] Figure 1: Simple segmentation procedcure and error cases: a) pseudo code at device side, b) normal functioning, c) failed data transmission error case d) failed trigger transmission error case

[0420] Here we consider that the ULI design is so that an UL Grant is sent with a robust MCS so that case d) is not actually possible, or at least the case is otherwise so that the SINR is anyway not sufficient to receive the UL Grant correctly, and the device is considered out of coverage.Additionally, there may be a CRC assumed to be included in the overall transmission, used as a mechanism to check the validity of the received data once the last segment has been received.

[0421] Given this, it can be considered rare over the population of devices that this is a significant issue.

[0422] It is also worth noticing that passive devices that will likely have enough energy for the whole duration of the session, will not have issues in losing the stored data due to lack of energy.

[0423] On the other hand, active devices may in fact lose energy during the transaction. In this case, assuming NVM is used for this feature, all information regarding the ongoing segmentation procedure will be lost. The reader will likely detect a failure and may decide to try again later. If the device is never able to transmit all the segments it may be considered simply out of coverage because unable to operate. Note that this will not be different from the case of a single segment (of the same size).

[0424] The above failures should therefore come with a simple out of coverage handling, as defining signaling and UE behavior for these cases would come with unnecessary signaling and complexity.

[0425] A device not able to complete the transmission of all the segments should be considered “out of coverage” or “unable to operate”.

[0426] For a failed data transmission, retransmission can be triggered with a repeated Msg2 transmission. This was agreed during SI phase and particularly discussed as a solution for non-segmented transmissions. However, the same solution can be applied for failed segment transmissions, i.e., reader indicates retransmission via Msg2 for failed segment transmission with new grant parameters.

[0427] If the segment is other than the last segment, we believe following behavior is reasonable.

[0428] • For transmission success, the reader does not need to indicate any explicit ACK signalling as long as there is message defined for granting resources for next segment.

[0429] • For indicating retransmission of a segment, the reader can send Msg2 again to trigger retransmission of the given segment with a simple NDl-type indication.

[0430] o One codeword for NDI can indicate retransmission trigger,

[0431] o Other codeword for NDI can indicate grant for next segment transmission.

[0432] • The NDI can be always present and would cater for both segmented and unsegmented cases. • If a device performs re-access the transmission starts from a 1st segment if segmentation is perfomed.

[0433] For the case with segmented transmission, the device should transmit segments in order. A bit in Msg2 response is introduced to indicate

[0434] • retransmission grant for previous segment transmission or

[0435] • new transmission grant for next segment.

[0436] For the case with segmented transmission, if the re-access is triggered, the device begins transmission from a 1stsegment in a new occasion if contention-resolution is successful.2.4 Device Addressing and AS identifier handling Regarding AS ID, it is currently mentioned in TR38.769:

[0437] From higher layer perspective, it is assumed that " AS ID" (if defined according to the design in clause 6.1) is used at least for purpose of D2R scheduling and R2D reception. From higher layer perspective, it is assumed that this " AS ID" should be a short AS layer ID, rather than the full upper layer device ID. It needs to be further discussed if this " AS ID" can be based on partial upper layer device ID. It needs to be further discussed on the length of this " AS ID". From higher layer perspective, following options are possible for this " AS ID" (it is aimed to define one common design for all access procedures in clause 6.3.4, if technically possible):

[0438] - Option 1: a random ID (if used in first D2R message) can be reused;

[0439] - Option 2: the reader assigns this " AS ID" to the device. It needs to be further discussed via which R2D message.

[0440] - Option 3: It is up to the reader whether to reuse the random ID (if used in first D2R message) as the " AS ID" or to assign a new " AS ID". It needs to be further discussed via which R2D message.

[0441] NOTE 1: The further down-selection for " AS ID" needs to consider the involved message and whether the reader needs to handle the collision.

[0442] The UE should be able to determine if a message received on the shared DL channel is directed to itself or not.

[0443] In this section, we call “address” the information needed to distinguish transmission from / to different devices from MAC perspective, (i.e.: it is out of scope higher-layer perspective such as NAS, Application, or inventory as a whole).

[0444] There are two main problems to solve regarding the device addressing:

[0445] • Which information is used as address (including considerations on scope of the address and collision probabilities)

[0446] • How the address is used

[0447] 2.4.1 Which information is used as address

[0448] In general, the address should be a piece of information that is agreed between the reader and device (provisioning) and for which its validity is clear for both nodes. In the last meeting it was also agreed that this address should be “short” although it is still to be studied if it should be based on part of the device ID or not.

[0449] In assessing each possible option, we have to consider the following aspects:

[0450] • Security and Privacy: can the information used as address be shared with the involved nodes? Should it be used in its encrypted form or can be used in clear text?

[0451] • Uniqueness: is the address unique within a certain area or time scope? Could there be unacceptable collisions with other devices?

[0452] • Provisioning: how is the address provisioned (i.e.: agreed between device and network)• Usage of memory: should the address be kept in volatile registers or written in NVM? How often? This affects energy consumption and complexity.

[0453] RAN2 to determine which information should be used as address based on security, privacy, uniqueness, provisioning, and usage of NVM. FFS other aspects.

[0454] We can start by assessing the uniqueness of the address, meaning that within a certain scope in time and space there should not be excessive collisions between users.

[0455] The TR mentions 3 options on how the address may be generated:

[0456] • Option 1, i.e., randomly generated by the device: in this case there is a collision probability which depends on how many devices are sharing the same address scope and how many bits compose the address.

[0457] • Option 2, i.e., allocated by the network AS: in this case it is ensured that the address is unique, but it requires additional signalling overhead for the address provisioning. In this case the maximum number of devices that can share the address scope is exactly 2b.

[0458] • Option 3, i.e., reader decides if the random ID is reused or to assign a new AS ID. This is flexible but can also ensure the uniqueness given that reader knows if the random ID has been used by any other device in the system. Given that the Msg2 anyway needs to carry an RN16 to acknowledge the device sending corresponding Msg1, if the reader allocates a new AS ID, there needs another R2D message for such allocation.

[0459] It is worth noticing that if the address is randomly generated, there is a probability of collision. Regardless of how negligible it may be, the system should still be able to recover from this.

[0460] A classical example is the contention resolution ID in legacy. There is a non-zero probability that two devices select the same RACH resource and random ID in Msg3 and they would both win the contention without reader / network knowing this. This case is typically considered negligible, but if this happens the network would shortly after verify the 5G-TMSI sent in Msg3 and Msg5 understanding that something went wrong and terminating the procedure. A similar recovery should be considered for A-loT.

[0461] A network-assigned address guarantees uniqueness but requires signalling overhead for its provisioning.

[0462] A randomly generated address, or address calculated as function of the Device ID or an already assigned CN ID, does not require provisioning overhead but has a collision probability. Regardless of how negligible this probability is, the system should be able to recover from this.

[0463] If within a certain scope (time or space) there are N devices with a randomly generated address composed by b bit, the probability that a collision between at least 2 devices happens can be estimated following the “birthday problem” approach: the probability of a collision is one minus the probability that in all possible pairs of devices they have a different address.

[0464] This probability is:N(N-1)

[0465] / 1 \~

[0466] Pc = 1“ (1 _2^ 10° „

[0467] > >

[0468] 1O‘!L.....

[0469] 10-4

[0470] >

[0471] 10‘4t >

[0472] 10-5

[0473] >

[0474] >

[0475] 10-7100101102103104

[0476]

[0477] Number of competing users

[0478] Figure 2: Collision probability for 16 bit randomly generated address as function of the number of competing users.

[0479] Considering that the AS ID, according to the discussion, will have a scope limited to the few devices that perform the random access concurrently, the number of competing devices will be relatively low: the number of frequency shifts for Msg1 and possibly a few TDM occasions. We can imagine this number will be around 16. This means that in each access occasion there is a probability not greater than 0.3% that at least two devices collide. In an inventory procedure for 10k devices there would be roughly 600 access occasions, so the probability that a collision happens at least in one access occasion is

[0480] pcIV= 1 — (1 — pc')Nround ≃ 84%

[0481] In conclusion, despite the collision probability being relatively low, in a long inventory these chances accumulate so that it’s very likely that an address collision happens and should be handled.

[0482] Given the only two use cases in Rel-19 (inventory, and inventory + command), it is observed that even if collision happens, it may be possible to recover from upper layer processing thanks to security protection at A-loT NAS. For example, if two devices happen to both win contention resolution with the same RN16 and are allocated as AS ID, the command request is intended for only one device, but is received by the two devices. However, only one of the devices succeeds in processing at A-loT NAS layer. Thus, in worst case, there is a potential waste of energy for unintended devices. Therefore, it is proposed to adopt the most simple option, i.e., AS ID is promoted from the RN16 randomly generated by the device (option 1).

[0483] AS ID is promoted from the RN16 randomly generated by the device (option 1).2.4.2 Ways to support addressing

[0484] Assuming that an address has been agreed in this section we discuss how it may be used to univocally determine which device is supposed to decode a certain R2D transmission or which device transmitted in a certain D2R resource.

[0485] There are two general ways. With explicit addressing a data transmission will contain the address as part of control information. The receiver of this message will decode the entire message, including the address control information. Otherwise with implicit addressing some separate signalling, containing the address, will indicate which device is supposed to receive / use some upcoming resources. In this case the data transmission itself will not contain the address.

[0486] Which option is more efficient depends on the expected message exchange. For instance, explicit addressing requires larger data transmission but no additional signalling, while the opposite is true for implicit addressing, therefore explicit addressing may be more suited for short sessions, while implicit for longer sessions. Within the explicit addressing, the address may be included at different layers. For instance, if PHY layer will include a control part, this could contain the address.

[0487] Otherwise, the address may be included as a MAC CE or part of the MAC subheader or even added at upper layers.

[0488] Within the implicit addressing, we distinguish one-shot and persistent implicit addressing.

[0489] One-shot implicit addressing consists in providing an UL / DL Grant containing the address and a description of a specific resource which will be used by the indicated device for a single transmission. This is analogous of legacy PDCCH followed by a PDSCH or PLISCH transmission.

[0490] Another Device Reader

[0491]

[0492] Device

[0493] _ Grant _

[0494] Address

[0495] Single resource definition

[0496]

[0497] Resource begins-- Data.

[0498] ■4 (.no address)

[0499] -Resource ends - t

[0500] t

[0501] _ Grant _

[0502] Address

[0503] Single resource definition

[0504] t

[0505] ■ Resource begins

[0506] Data

[0507]

[0508] trto address}’"

[0509] -Resource ends -

[0510]

[0511] i

[0512]

[0513] Figure 3: Basic functioning of one-shot implicit addressing.Persistent implicit addressing consists in a DL control signal blocking until further notice all the resources (or all resources in a specific frequency range in case of FDMA) for a specific device. In this case all data transmissions in this reserved band will belong to the same device. This option is more similar to how RFID works where once a slot begins with QueryRep all transmissions will belong to the same user until the following QueryRep starts a new slot.

[0514] Another Device Reader

[0515] Device T~~

[0516] , Resejvafion Start

[0517] Address

[0518] Persistent resource definition

[0519] L Data

[0520] (no address

[0521]

[0522] I Data j

[0523] (no address)

[0524]

[0525] L Data

[0526] [ (no address)

[0527] Reservation End

[0528] Figure 4: Basic functioning of persistent implicit addressing.

[0529] Considering current progress on other agenda items, such as RACH, it is likely that either one-shot or persistent implicit addressing can fit nicely in the agreed mechanism. So, we propose to focus more on these.

[0530] Resources can either reserved via an UL / DL grant containing the device address, or by reserving indefinitely a frequency resource using an address until a further reservation is made.

[0531] 2.5 Other MAC aspects

[0532] 2.5.1 Expected D2R message size and command type information

[0533] In last RAN2 meeting, there was an agreement on visibility:

[0534] 1. The reader needs to know whether a response is expected and expected D2R message size. FFS how the reader gets this information. Wait for SA2 LS response on expected D2R message size to resolve the FFS. FFS if command type is explicit, if it can be

[0535]

[0536] inferred from expected D2R message size if available.

[0537] SA2 has concluded that AIOTF may provide the approximate D2R message size based on AF request (as in TR23.700-13):

[0538] e. The AIOTF may provide the following assistance information to AIoT RAN / UE Reader:

[0539] - AIoT service type (e.g. Inventory, Command);

[0540] - approximate number of AIoT devices based on AF request;

[0541] - approximate D2R message size based on AF request.NOTE 6: The approximate D2R message size considering the overhead of AIoT Device NAS layer will be determined later in cooperation with CT WG1 and SA WG3. NOTE 7: Further assistance information can be added during the normative phase and in cooperation with other WGs if necessary.

[0542] In addition, SA2_166AH meeting also agreed that the inventory request is not an NAS message (S2-2501244) and command-only is not supported in Rel-19 (S2-2501249). Thus, to address the FFS on how the reader gets this information, we assume that assistant information is provided by AIOTF to RAN reader as NG-AP information rather than part of NAS message.

[0543] From SA2 progress, assistant information including approximate D2R message size is provided by AIOTF to RAN reader not as part of A-loT NAS message.

[0544] Given that command-only is not supported in Rel-19 and only three command cases (read, write, and permanent disable) are considered, for inventory + command procedure, the expected D2R message size already tells the reader whether a command request is for read operation (with expected command reply on the data from device memory) or the reply is just an acknowledgment of a request for write operation or disable operation. In case of write and disable command, there is no need to distinguish the command type given that the D2R message in response to the command is in relatively small.

[0545] Command type can be inferred from expected D2R message size. No need of explicit assistant information regarding command type from AIOTF.

[0546] Conclusion

[0547] In the previous sections we made the following observations:

[0548] Observation 1 Bit-alignment may cause excessive complexity and implementation effort on both device and network size due to the normal functioning of memory and existing implementations.

[0549] Observation 2 The reader does not have a way to distinguish if a failure was caused by missing reception of the UL Grant or missing reception of the data segment. Observation 3 A network-assigned address guarantees unigueness but reguires signalling overhead for its provisioning.

[0550] Observation 4 A randomly generated address, or address calculated as function of the Device ID or an already assigned C ID, does not reguire provisioning overhead but has a collision probability. Regardless of how negligible this probability is, the system should be able to recover from this. Observation 5 From SA2 progress, assistant information including approximate D2R message size is provided by AIOTF to RAN reader not as part of A-IoT NAS message.

[0551] Based on the discussion in the previous sections we propose the following:

[0552] Proposal 1 Octet aligned MAC PDUs and Sub PDUs are used at AIoT MAC layer.

[0553] Proposal 2 MAC PDU for Msg1 contains only RN16 without control information.

[0554] Proposal 3 RAN2 to clarify the need of addressing information inside a D2R message from Msg3 and on.Proposal 4 MAC PDU for D2R message other than Msg1 includes:

[0555] • A length field indicating the length of the upper layer data part. Discuss the size of this field (e.g., 7 bits)

[0556] » A 1-bit segmentation indication

[0557] • Upper layer data (e.g., device ID, command reply, or other NAS data).

[0558] Proposal 5 A R2D message type field is used to identify R2D messages and their corresponding format.

[0559] Proposal 6 For A-loT paging of an access round, RAN2 wait for further input from other WGs (RAN1, SA3, SA2) regarding control information to be included in the MAC PDU.

[0560] Proposal 7 RAN2 assume the R2D message for sync (Qrep-like) is L1 control signaling.

[0561] Send an LS to RAN1 to inform this.

[0562] Proposal 8 MAC PDU for Msg2 used to echo Msg1 includes:

[0563] • R2D message type

[0564] » A field indicating the number of RN16s. Discuss the size of this field.

[0565] FDMA index. Check with RAN1 if the information is available to MAC layer.® One or multiple RN16s

[0566]

[0567] » FFS if any L2 control information to facilitate processing of Msg2 at device and scheduling information for Msg3.

[0568] Proposal 9 MAC PDU for R2D messages for feedback mechanism may include:

[0569] • R2D message type

[0570] » 16-bit ID for addressing information (e.g., AS ID / RN16)

[0571] • A field to indicate the usage, i.e., whether device needs to retransmission, re¬ access, or continue with next segment transmission.

[0572] Proposal 10 MAC PDU of R2D message from Msg4 includes:

[0573] ® R2D message type

[0574] ® 16-bit ID for addressing information (e.g., AS ID / RN16)

[0575] ® A length field indicating the size of the upper layer data part. Discuss if 8 bits are sufficient.

[0576] Note that we assume that some of the formats e.g. subPDU, header fields for messages may in some cases be the same where the type field(s) may indicate the content, exsitence and use.

[0577] Proposal 11 RAN2 waits for SA3 progress regarding if / what security information needs to be included in R2D and D2R message(s).

[0578] Proposal 12 The device sends a 1-bit indication indicating whether the current transmission is the last segment or not.

[0579] Proposal 13 A device not able to complete the transmission of ah the segments should be considered “out of coverage” or “unable to operate”.

[0580] For a failed data transmission, retransmission can be triggered with a repeated Msg2

[0581] transmission. This was agreed during SI phase and particularly discussed as a solution for non-segmented transmissions. However, the same solution can be applied for failed segment transmissions, i.e., reader indicates retransmission via Msg2 for failed segment transmission with new grant parameters.

[0582] Proposal 14 For the case with segmented transmission, the device should transmit segments in order.A bit in Msg2 response is introduced to indicate

[0583] • retransmission grant for previous segment transmission or

[0584] • new transmission grant for next segment.

[0585] Proposal 16 For the case with segmented transmission, if the re-access is triggered, the device begins transmission from a 1stsegment in a new occasion if contention-resoiution is successful.

[0586] Proposal 17 RAN2 to determine which information should be used as address based on security, privacy, uniqueness, provisioning, and usage of NVM. FFS other aspects.

[0587]

[0588] Proposal 18 AS ID is promoted from the RN16 randomly generated by the device (option Proposal 19 Resources can either reserved via an UL / DL grant containing the device address, or by reserving indefinitely a frequency resource using an address until a further reservation is made.

[0589] Proposal 20 Command type can be inferred from expected D2R message size. No need of explicit assistant information regarding command type from AIOTF.3GPP TSG-RAN WG2 #129 R2-2500863 Athens, Greece, Feb 17th– 21st, 2025

[0590] Agenda Item: 8.2.3

[0591] Source: Ericsson

[0592] Title: UL multiple access for Ambient loT

[0593] Document for: Discussion / Decision

[0594] 1 Introduction

[0595] A new work item for A-loT has been recently agreed in RP#106 [1], The following objectives are defined for RAN2 scope:

[0596] o Specify the necessary functions and procedures for an Ambient loT compact protocol stack and lightweight signalling procedure to enable DO-DTT and DT data transmission:

[0597] ■ A-loT Paging, including subsequent paging for the same service.

[0598] Support the options that a paging message contains one identifier, and that a paging message contains no identifier.

[0599] Temporary identifier is not supported, unless required by SA WGs.

[0600] Note: RAN2 aims to design a paging message format such that multiple identifiers can be contained in one paging message, for forward compatibility purposes.

[0601] ■ A-loT Random access, including re-access for failure handling.

[0602] Contention-based and contention-free cases are supported. For the contention-based random access, only Solution 1 (3-step only) is included (unless RAN2 decides to use Solution 3 (unified solution) by RAN2#129).

[0603] ■ A-loT data transmission, including data (re-)transmission for failure handling. Segmentation is supported at least in D2R. ■ Only MAC layer is included

[0604] We focus on the objective related to random access in this paper.

[0605] 2 Discussion

[0606] 2.1 Contention Based Random Access

[0607] Both 2-step and 3-step CBRA have pros and cons which are summarised in the below table.

[0608] Table 1

[0609] Pros and cons of 2- and 3-step CBRA2-step CBRA 3-step CBRA

[0610] Pros • Faster access or low latency as • Works well in high load scenarios as Msg1 data can be transmitted in 1st UL is much smaller than 2-step CBRA’s Msg1, message, i.e., Msg1. and collision rate is reduced.

[0611] • Works as well in low load scenario. The performance can be either same or slightly better than 2-step given both 2 and 3-step CBRA will have nearly same collision success probaility due to sparse load.

[0612] Cons • Works well in low load scenario • Slightly longer latency as data is transmited as Msg1 can be extremely big in Msg3 or later.

[0613] which may increase contention

[0614] failures.

[0615]

[0616] The clear benefit of 2-step is slightly short latency and applicability in low load scenario. However, for A-loT, the latency is not critical requirement. Further, on the contrary, the load can be extremely high with thousands of devices contending for access and thus 2-step CBRA.

[0617] Hence, we believe, only 3-step CBRA should be considered as primary method for access. In other words, RAN2 doesn’t pursue any unified option to also support 2-step CBRA.

[0618] 2-step CBRA benefits with low latency and low load scenarios.

[0619] 3-step CBRA benefits with high load scenario. The performance in low load scenario is nearly same as low load scenario as collisions rate might be negligible.

[0620] Adopt only 3-step CBRA for A-loT random access, i.e., not pursue any unified option to also support 2-step CBRA.

[0621] 2.2 Paging and Access Round

[0622] The random-access procedure for inventory or command use case is initiated by a paging message. During this random access, there is probability that some devices may fail to access, and thus re-access is needed. Currently, there are couple of options where re-access can be triggered by a paging message or an access trigger message. But before getting into details regarding these two options, let us define following terminologies.

[0623] Access occasion: It is defined as resource opportunity for transmitting Msg1 and possibly successive messages if reader successfully echoes back the Msg1 to the device in the same occasion.

[0624] Access round: A round consists of N random-access occasions allocated by the reader to group of devices where a device selects one of the occasions randomly for its access.

[0625] Paging round: Depending on the option, a paging round can be defined as an equivalent to single access round or consisting of multiple access rounds.

[0626] The transmissions in contention based random-access procedure may be prone to collisions when there is high number of devices contending the channel. In addition, in general, the channel error probability for A-loT transmissions would be higher than of typical NR transmission due to device’s limited capabilities and most likely itsinability to do channel measurements. As a consequence, A-loT transmissions can be unreliable and thus, a suitable feedback mechanism can be useful to indicate device’s UL message success or failure. However, the feedback has a cost on device energy and processing resources which are already scarce and limited.

[0627] Subject to feedback design, reliability requirements, there can be multiple ways reaccess for the failed devices can be done. For instance, re-access can be done in same or next inventory / access round, therefore, first, it is important if we agree on terminologies related to paging, access, inventory round and the interactions which RAN2 has not defined properly. See below figure which depicts an interaction between paging message, access round, occasions, etc.

[0628] Occasion #0 Occasion#! Occasion#N-l

[0629]

[0630]

[0631] < - Access round with N occasions - > Figure 1: A paging message triggers an access round composed of N occasions serving group of devices. Each occasion can be used for CBRA based access. If the paging targets a single device and only single occasion is allocated in the access round, then the allocation behaviour reduces to CFRA.

[0632] RAN2 has captured two options: 1- and 2-tier in TR where the re-access allowed with access trigger or paging. The options are described as below.

[0633] Option A (1 -tier): Paging round is equivalent to access round.

[0634] In this option, the access round is same as paging round. The paging message triggers the paging / access round consisting of N random-access occasions. In order to do re-access of failed devices, the reader can send new message to perform reaccess with new resource allocation, e.g., more or less random-access occasions, updated MCS, etc. Below figure portrays a paging / access round consisting of N random-access occasions.

[0635] < - Access round - >

[0636] <

[0637]

[0638] - Paging round (paging session / transaction ID#X - >

[0639] Figure 2: A paging round is equivalent to an access round.

[0640] Option B (2-tier): In this option, a paging round consists of multiple access rounds.

[0641] Apart from 1stround, the remaining access rounds are primarily of re-access for the devices which unable to access in first round within a paging round. Given, multiple rounds are assumed within a paging round, essentially there can be two trigger message types:

[0642] • Paging trigger: Initiates first round or initial access round.

[0643] • Access trigger: Initiates successive rounds within a paging round. It differs from paging trigger as it may have reduced information. For instance, access trigger may not have information pertinent to transaction ID or devices IDs, etc. depending on what scenarios we foresee and define this trigger message accordingly with reduced overhead. If access trigger is defined like paging trigger, then this option reduces to Option A.

[0644]

[0645] Figure 3: A paging round consists of multiple access rounds.

[0646] In the below table, we capture pros and cons of both options.

[0647] Table 2

[0648] Pros and cons of both options with paging round consisting of single or _ _ multiple access rounds. _

[0649] Option A: Paging round equal to Option B: Paging round consists of access round multiple access rounds Benefits • Reader and device complexity is lower • Signaling overhead may be lower slightly as there is single message type is when it comes to re-acess given the needed (i.e., paging trigger). device will be sent access trigger

[0650] message which may contain only relevant

[0651] • The device which has missed initial or reduced infiormation, say updated

[0652] paging message (unable to decode resource allocation, such as new number due to channel error or lack of energy) of occasions in the round.

[0653] may not particpate in correponding

[0654] access round, however, it can • Given, the acces trigger may have particpate in next round if network relatively smaller size, the energy cost for delivers paging message again for reprocessing such message will be lower. access or new access for devices for But there can be downside (see

[0655] the same request (e.g., same drawbacks)

[0656] transaction ID).

[0657] Drawbacks • Signaling overhead may increase • Reader and device complexity will be when it comes to re-acess given the slightly higher as there will be multiple device will be sent paging message messages or triggers, for instance, paging containing full or redundant information trigger, access trigger, etc.

[0658] (as the failed user may already know

[0659] some of the information when it had • The access trigger messge may have attempted failed initial access in reduced information which means both previous round. reader and device (with failed attempt)

[0660] needs to remember paging

[0661] • In contrast to acces trigger in Option B, message / triggerwhich adds cost to

[0662] the failed device may need to decode memory or buffering reuirement of

[0663] whole paging message everytime for old / paging information which is extremely re-access, and thus may have slightly critical for devices of Type 1 or passive increased energy cost. nature.

[0664] • The device which has missed initial paging message (unable to decode due to channel error or lack of energy) may not particpate in correponding access round, however, it may happen it still may not able particpate in next round initiated by access trigger if the message is defined in such as manner that some of the

[0665] information in paging messag is excluded from access trigger message. In this round, only device can particpate which have successfully decoded paging message initially but failed with uplink access, e.g., failure in Msg1 transmission or Msg3 transmission.

[0666]

[0667] • Due to large number of formats, the monitoring or blind decoding cost of number of formats may result in increased energy cost.

[0668]

[0669] Based on above texts, we believe tier-1 is most suited option as it results simple device behaviour.

[0670] Adopt only 1 -tier option where one paging round is equivalent to one access round.

[0671] 2.3 Re-access

[0672] In RAN#127bis, it was agreed to support optional explicit R2D failure / success feedback indication for at least Msg3 for re-access purpose, and FFS for following D2R data. However, in order to feedback design and various options, it is important to understand and agree on termninologies surrounding retransmission and reaccess. Note, we TDMA as baseline for feedback. We will update he discussion once concerete behavior from RAN1 and RAN2 on FDMA basline is specified.

[0673] Retransmission: In an occasion, if a device has done contention resolution successfully, i.e., Msg1 is transmitted successfully and network has echoed back the selected RN16 in Msg2, then the device has a right to transmit its data / Msg3. If the device encounters Msg3 transmission failure, then the reader can send Msg2 again to trigger Msg3 retransmission. Summarising, the transmission is possible in the occasion where device has gotten the access. See Fig. 4.

[0674]

[0675] Figure 4: Retransmission of failed Msg3 triggered by Msg2 retransmission.

[0676] Device performs re-access or retransmission in case of data transmission failure.

[0677] Device performs re-access in case of contention resolution failure.

[0678] Re-access: In an occasion, if a device has failed to get an access where it does not receive a Msg2 echoing back its selected RN 16 from the reader, then device does not have the right to transmit its Msg3 in the current occasion and has to look for new occasion either in the same or next round or not, subject to re-access policies defined by the reader. Here, the re-access can be triggered based on defined policies and possibly no explicit indication is needed to trigger re-access. See Fig. 5.

[0679]

[0680] Figure 5: Re-access after failed access due Msg1 transmission failure.

[0681] In another scenario, the re-access can also be permitted or defined, in case device has gotten the access in the given occasion but constantly failing with its Msg3 / data transmission, then reader may allow re-access in a newer occasion where the device competes again for the access by transmitting Msg1 again. In this scenario, and explicit AS signalling possibly needed to trigger re-access as its intention from reader to stop the access in the current occasion and trigger a re-access. See Fig. 6. Most likely, this could happen due to poor coverage issues. The re-access in later time allows the device to get out of poor-coverage region or the obstacle to move away if the coverage issues are temporary.

[0682]

[0683] Figure 6: Re-access is triggered after repeated failed Msg3 retransmission attempts. Summarising above, as we see for retransmission, there is no ned for additional AS signalling other than Msg2 retransmission triggering Msg3 retransmission, however, for re-access, we may need additional explicit feedback signalling which indicates NACK and thus stopping the device in current occasion and triggering re-access. As indicated above, RAN2 already agreed to have such feedback message, but it was left optional without any details. Consider extremely simple device, to the least we may need AS signalling

[0684] In our option, the option based on explicit AS signaling (e.g., 1 NACK bit) is most suitable. Given majority devices are expected to have transmission success, and thus requiring fewer devices re-access, then sending NACK would be beneficial as it amounts to fewer transmissions.

[0685] Based on above discussion, we propose following observation and proposals.

[0686] For data transmission failure, the device may be triggered to perform re-access by the reader after a number of times of (re-)transmissions failed attempts.

[0687] Reader to send an explicit AS signalling (e.g., 1 bit) to devices for triggering re-accesses due to data transmission failures (regardless of if data transmission is segmented or not).

[0688] Further, this AS signalling is equally applicable for the case where if a transmission is divided in multiple segments. The reader doesn’t need to distinguish between segment and non-segment case regarding re-access trigger.2.4 FDMA and Msg2

[0689] In the WID, FDMA with small frequency shift is included and we elaborate solutions for the above two issues focusing small frequency shift and wait for RAN1 progress on issue with large frequency shifts. Given the device can perform small frequency shift we believe, thus it can desire FDMA occasion from the pool of occasion within a TDMA occasion randomly. This is bit similar the same device selects a TDMA occasion in a random manner.

[0690] Device randomly selects among FDMA occasions as the baseline. FFS if other conditions / rules are needed for the selection of FDMA occasions.

[0691] On issue 2, one solution can be based on RAR functionality where Msg2 can be addressed to multiple devices with their RN16s as their sub-headers and corresponding resource allocation information for their Msg3 and Msg4 transmissions as MAC sub-payloads. The major issue is the message size would increase as it would include all the successfully transmitted RN16s which a device may not be interested in the message.

[0692] Other solution can be based on L1 mapping where a preceding DL control information is sent before individual Msg2 transmissions. Each Msg2 is addressed to single device and the preceding DL control information provides mapping information of Msg2 resource allocation, see below figure. The individual message size is decreased compare RAR inspired option, however, there is a need of additional DL control information prior to Msg2 transmissions which provides the resource mapping.

[0693] In our opinion, RAR functionality based Msg2 is more suitable as this behaviour already implemented in legacy solutions, and thus, for A-loT, a simplified version for RAR message for Msg2 is very appropriate, and accordingly we capture following proposal.

[0694] The Msg2 echoes the list RN16s for the devices which have successfully accessed the FDMA occasions within a TDMA occasion limited by grant size.

[0695] For each echoed RN16, there should have some mapping between the echoed RN16 and FDMA resource. The mapping can be either

[0696] • Static, or

[0697] • Dynamic.

[0698] In case of static mapping, the Msg2 contains the same amount of placeholders as umber of available FDMA access occasions. The FDMA access occasion which is access successfully, then the mapped placeholder in Msg2 will indicate RN16. Other placeholders may indicate dummy RN 16 where no device is identified. The drawback is the Msg2 length is long even the number of accessed devices is small.

[0699] On the other hand, the Msg2 can include FDMA occasion index as a header and the corresponding payload contains the accessed device’s RN16 in that particular FDMA occasion. Compared to static scenario, the message length is small as its size is limited by number of access devices, not by total number of FDMA occasions configured. Further, the order of indication of FDMA occasion indices need to be defined. For instance, FDMA access occasion at lower frequency channel can be assigned smaller index and the occasion at relatively higher frequency channel ca be assigned higher index. Further, a rule is needed on indicating index (MAC sub-header) and the corresponding RN16 (MAC sub-payload). In Msg2, the echoed RN16s for the corresponding FDMA occasion indices can be arranged in, e.g., increased sort order. We believe dynamic mapping is more suitable as static mapping may incur lot of wastage of resource as it necessitates dummy indications, resulting bigger Msg2 size.In case there are multiple FDMA occasions available, reader signals devices a mapping between FDMA occasions and received random IDs in Msg2. FFS if the mapping is conveyed via L1 control info or MAC header.

[0700] In case there are multiple FDMA occasions available, Msg2 format allows inclusion of multiple random IDs limited by the size of the R2D resources for Msg2 transmission.

[0701] 2.5 Contention-Free Access

[0702] To provide CFRA, the reader needs to allocate dedicated (collision-free) resources to the devices. We have named two methods, where in one method, the device IDs are know to reader and in another, they are kept hidden.

[0703] One of the method is to allocate resources by mapping them to their device IDs. It means the paging message includes non-transparent device ID (IDs are not part of NAS container) and the corresponding resources. It is not yet agreed what are these device IDs based on, e.g., AS ID, original device ID (CN allocated), or temporary ID (CN allocated) and whether it will be transparent or non-transparent to reader. This discussion we leave it to SA2 first except the part with AS ID which is a focus of agenda item dealing with protocol stack. In essence, in this method, the reader needs to know the IDs and provide mapping of resources.

[0704] In another method, the device IDs are part of NAS container or kept hidden from reader in paging message. In order to allocate CFRA resource, the

[0705] 1. the reader needs to know the group size or number of devices from CN and his information can be retrieved by reader from CN via NGAP signaling, and based on this information, the reader provides group of resources to group of devices without any explicit mapping;

[0706] 2. A implicit mapping rule is defined by the reader, for instance, the devices can arrange themselves to group of resources in increasing sort manner. For instance, device with lower ID have a right o transmit on resource with lower resource index;

[0707] 3. In order of implicit mapping to work, a device must able to other device IDs in paging message so the device knows where it should position itself on resource w.r.t. other devices

[0708] Below is summary of two methods.

[0709] CFRA Allocation

[0710] Method 1: Device IDs are non-transparent to Method 2: Device IDs are transparent to reader reader

[0711] There is direct / explcit mapping between IDs and There is implicit mapping between IDs and resource resource as IDs are not known to reader The resources are ptovided by reader based on group size information which reader can retrive from CN via NGAP message

[0712] The devices must be able to know other devices indicatd paging message in order to implcit map to pool of rsources

[0713]

[0714] Observation: For CFRA based allocation, two allocation methods are observed where in one method device IDs are known to reader, and in another method, it is transparent to reader.For CFRA, it is assumed that the reader knows at least the number of devices (e.g., provided by CN) to allocate contention free resources corresponding to the number of devices.

[0715] For CFRA, reader indicates a mapping rule between the set of allocated resources and the corresponding devices explicitly or implicitly to devices.

[0716] 3 Conclusion

[0717] In the previous sections we made the following observations:

[0718] Observation 1 2-step CBRA benefits with low latency and low load scenarios.

[0719] Observation 2 3-step CBRA benefits with high load scenario. The performance in low load scenario is nearly same as low load scenario as collisions rate might be negligible.

[0720] Observation 3 Device performs re-access or retransmission in case of data transmission failure.

[0721] Observation 4 Device performs re-access in case of contention resolution failure.

[0722] Observation 5 For data transmission failure, the device may be triggered to perform re- access by the reader after a number of times of (re-)transmissions failed attempts.

[0723] Observation 6 The Msg2 echoes the list R 16s for the devices which have successfully accessed the FDMA occasions within a TDMA occasion limited by grant size. Observation 7 For CFRA, it is assumed that the reader knows at least the number of devices (e.g., provided by CN) to allocate contention free resources corresponding to the number of devices.

[0724] Based on the discussion in the previous sections we propose the following:

[0725] Proposal 1 Adopt only 3-step CBRA for A-loT random access, i.e., not pursue any unified option to also support 2-step CBRA.

[0726] Proposal 2 Adopt only 1 -tier option where one paging round is equivalent to one access round.

[0727] Proposal 3 Reader to send an explicit AS signalling (e.g., 1 bit) to devices for triggering re-accesses due to data transmission failures (regardless of if data transmission is segmented or not).

[0728] Proposal 4 Device randomly selects among FDMA occasions as the baseline. FFS if other conditions / rules are needed tor the selection of FDMA occasions. Proposal 5 In case there are multiple FDMA occasions available, reader signals devices a mapping between FDMA occasions and received random IDs in Msq2. FFS if the mapping is conveyed via L.1 control info or MAC header.

[0729] Proposal 6 In case there are multiple FDMA occasions available, Msg2 format allows inclusion of multiple random IDs limited by the size of the R2D resources for Msg2 transmission.

[0730] Proposal 7 For CFRA, reader indicates a mapping rule between the set of allocated resources and the corresponding devices explicitly or implicitly to devices.4 References

[0731] [1] RP-243326, “New Work Item: Solutions for Ambient loT (Internet of Things) in NR”, Huawei, 3GPP TSG RAN Meeting #106, Madrid, Spain, December 9-12, 2024.

Claims

53CLAIMS1. A method performed by a network node (101a, 901) for handling transmission status in a communications system (100, 900), the method comprising:determining (1002) status of a transmission from the wireless device (105, 903) to the network node;providing (1004), to a wireless device (105, 903), status information indicating the status of the transmission from the wireless device (105, 903) to the network node (101a, 901), wherein the status information triggers an action to be performed by the wireless device (105,903).

2. The method of any of the preceding claims, comprising:based on the status of the transmission, determining (1003) the action to be performed.

3. The method of any of the preceding claims, wherein the action to be performed comprises any one or more out of:- a re-access event when the status of the data transmission is failure.- that retransmission is disallowed,- retransmission of resource information for the transmission.- re-access performed after a number of times of transmission or retransmission failed attempts.

4. The method of any of the preceding claims, wherein the transmission is an uplink data transmission, e.g. a Reader to Device, R2D, message.

5. The method of any of the preceding claims, wherein the action to be performed comprises retransmission of resource information for the transmission.

6. The method of any of the preceding claims, wherein the action to be performed is re-access performed after a number of times of transmission or retransmission failed attempts.

7. The method of any of the preceding claims, wherein the status is success or failure.

548. The method of any of the preceding claims, wherein the status of success is indicated by at least one of the following:• an explicit ACK; and• by not indicating explicit NACK,or wherein the status of failure is indicated by at least one of the following:• an explicit NACK; and• not indicating explicit ACK.

9. The method of any of the preceding claims, wherein the status of failure is indicated by a stop-indication, wherein the stop-indication indicates that the wireless device (105, 903) should stop any further access attempts or transmission in the current Access Occasion and instead try in the subsequent Access Round.

10. The method of any of the preceding claims, wherein the status information is or comprises an explicit AS signalling, e.g., 1 bit.

11. The method of the preceding claims, wherein the status information is sent to the wireless device (105, 903) for triggering re-accesses due to transmission failures, e.g. regardless of if message transmission is segmented or not.

12. The method of any of the preceding claims, wherein the transmission comprises n segments, where n is a positive integer.

13. The method of any of the preceding claims, wherein the transmission is a msg 1 or msg 3.

14. The method of any of the preceding claims, wherein the status is at least one of:• msg 1 failure• contention failure• msg3 failure• data transmission failure15. The method of any of the preceding claims, comprising:55providing, msg2, to the wireless device (105, 903), wherein msg 2 comprises a FDMA index.

16. The method of any of the preceding claims, comprising:providing, msg2, to the wireless device (105, 903), wherein msg 2 comprises at least one of the following:an indication of retransmission grant for previous segment transmission, or an indication of a new transmission grant for next segment.

17. The method of any of the preceding claims, further comprising:obtaining user data; andforwarding the user data to a host or a user equipment.

18. The method of any of the preceding claims, wherein the network node (101 a, 901) is a radio network node, a gNB or an intermediate User Equipment, UE, based network node.

19. A method performed by a wireless device (105, 903) for message transmission status in a communications system (100, 900), the method comprising:obtaining (1004), from a network node, status information indicating the status of the transmission from the wireless device (105, 903) to the network node (101a, 901), wherein the status information triggers an action to be performed by the wireless device (105, 903); andperforming (1005) the action triggered by the status information.

20. The method of claim 19, wherein the action to be performed comprises a reaccess event when the status of the transmission is failure.

21. The method of any of the preceding claims 19-20, wherein the action to be performed comprises that retransmission is disallowed.

22. The method of any of the preceding claims 1-9-21, wherein the transmission is an uplink data transmission, e.g. a Reader to Device, R2D, message.5623. The method of any of the preceding claims 19-22, wherein the action to be performed comprises retransmission of resource information for the transmission.

24. The method of any of the preceding claims 19-23, wherein the action to be performed is re-access performed after a number of times of transmission or retransmission failed attempts.

25. The method of any of the preceding claims 19-24, wherein the status is success or failure.

26. The method of any of the preceding claims 19-25, wherein the status of success is indicated by at least one of the following:• an explicit ACK; and• by not indicating explicit NACK,or wherein the status of failure is indicated by at least one of the following:• an explicit NACK; and• not indicating explicit ACK.

27. The method of any of the preceding claims 19-26, wherein the status of failure is indicated by a stop-indication, wherein the stop-indication indicates that the wireless device (105, 903) should stop any further access attempts or transmission in the current Access Occasion and instead try in the subsequent Access Round.

28. The method of any of the preceding claims 19-27, wherein the message is a msg 1 or msg 3.

29. The method of any of the preceding claims 19-28, wherein the status is at least one of:• msg 1 failure• contention failure• msg3 failure• data transmission failure30. The method of any of the preceding claims 19-29, further comprising:providing user data; andforwarding the user data to a host via the transmission to the network node31. A wireless device (105, 903) for handling transmission status in a communications system (100, 900), comprising:processing circuitry configured to perform the method of any of claims 19-30; and a power source configured to supply power to the processing circuitry.

32. A network node (101a, 901) for handling transmission status in a communications system (100, 900), the network node (101a, 901) comprising: processing circuitry configured to perform the method of any of claims 1-18; and a power source circuitry configured to supply power to the processing circuitry.

33. A computer program product comprising program code for performing, when executed by the processing circuitry, the method of any of claims 1-18 and / or 19-30.

34. A non-transitory computer-readable storage medium comprising instructions, which when executed by the processing circuitry, cause the processing circuitry to perform the method of any of claims 1-18 and / or 19-30.

Images