WO2025165490A1

WO2025165490A1 - Scheduling mechanisms and carrier wave design for ambient – internet of things (a-iot)

Info

Publication number: WO2025165490A1
Application number: PCT/US2024/060820
Authority: WO
Inventors: Gang Xiong; Debdeep CHATTERJEE; Daewon Lee
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2024-02-01
Filing date: 2024-12-18
Publication date: 2025-08-07
Anticipated expiration: 2026-08-01

Abstract

Various embodiments herein relate to a reader of a cellular network configured to identify a parameter related to an ambient internet of things (A-IoT) transmission that is to be transmitted by an A-IoT device. The reader may then provide an indication of the parameter to the A-IoT device, and identify an A-IoT transmission from the A-IoT device based on the parameter. Other embodiments may be described and/or claimed.

Description

SCHEDULING MECHANISMS AND CARRIER WAVE DESIGN FOR AMBIENT - INTERNET OF THINGS (A-IOT)

CROSS REFERENCE TO RELATED APPLICATION

The present application claims priority to U.S. Provisional Patent Application No. 63/548,719, which was filed February 1st, 2024; and to U.S. Provisional Patent Application No. 63/574,016, which was filed April 3rd, 2024.

BACKGROUND

Various embodiments generally may relate to the field of wireless communications.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals designate like structural elements. Embodiments are illustrated by way of example and not by way of limitation in the figures of the accompanying drawings.

Figure 1 illustrates examples of ambient internet of things (A-IoT) topologies, in accordance with various embodiments.

Figure 2 depicts an example of a channel structure, in accordance with various embodiments.

Figure 3 depicts an alternative example of a channel structure, in accordance with various embodiments.

Figure 4 depicts an example of scheduling delay for A-IoT uplink (UL) or reverse link transmission, in accordance with various embodiments.

Figure 5 depicts an example of acknowledgement delay for A-IoT downlink (DL) or forward link transmission, in accordance with various embodiments.

Figure 6 depicts an example of frequency offset indication for device to reader (D2R) transmission for an A-IoT device with frequency shift, in accordance with various embodiments.

Figure 7 schematically illustrates a wireless network in accordance with various embodiments.

Figure 8 schematically illustrates components of a wireless network in accordance with various embodiments.

Figure 9 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein.

Figure 10 illustrates a network in accordance with various embodiments. Figure 11 depicts an example procedure for practicing the various embodiments discussed herein.

Figure 12 depicts another example procedure for practicing the various embodiments discussed herein.

Figure 13 depicts another example procedure for practicing the various embodiments discussed herein.

Figure 14 depicts another example procedure for practicing the various embodiments discussed herein.

DETAILED DESCRIPTION

The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the various aspects of various embodiments. However, it will be apparent to those skilled in the art having the benefit of the present disclosure that the various aspects of the various embodiments may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of the various embodiments with unnecessary detail. For the purposes of the present document, the phrase “A or B” means (A), (B), or (A and B). Unless used differently herein, terms, definitions, and abbreviations may be consistent with terms, definitions, and abbreviations defined in the third generation partnership project (3GPP) technical report (TR) 21.905 V16.0.0 (2019-06).

Internet of Things (loT) has evolved to encompass a diverse range of applications, including smart home, smart city, healthcare monitoring, etc. In 3GPP, various connectivity technologies tailored to loT requirements were introduced. In particular, Low Power, Wide-Area (LPWA) Technologies such as Narrowband loT (NB-IoT) and long term evolution (LTE)- machine type communication (MTC), which may also be referred to herein as “LTE-M,” were specified to address the specific needs of low-power devices, extending the battery life of loT devices and enabling their use in remote or hard-to-reach locations.

Given that legacy technologies may not be able to meet all the requirements of target use cases such as asset identification, inventory, sensing, etc., Ambient Internet of Things (A-IoT) technology may be implemented in 3GPP release-19 (ReL19) specifications and/or systems to enable numbers of connections and/or device densities that are orders of magnitude higher than legacy 3GPP loT technologies. The new loT technology may provide complexity and power consumption at levels that are orders of magnitude lower than legacy 3GPP LPWA technologies, and shall address use cases and scenarios that cannot otherwise be fulfilled based on legacy 3GPP LPWA loT technologies.

In particular, the A-IoT devices may have limited size with limited energy storage that may not need to be replaced or recharged manually. In this case, the output power of energy harvester may be between approximately 1 microWatt ( W) to a few hundreds of W. Legacy cellular devices may not work well with energy harvesting due to their peak power consumption of higher than 10 milli Watts (mW).

Two topologies may beconsidered for A-IoT applications. Figure 1 illustrates two example Topologies for A-IoT applications, which may be referred to as “Topology 1” and “Topology 2.” In these examples, Topology 1 may refer to a topology wherein an A-IoT device directly and bidirectionally communicates with a reader such as a base station. The communication between the reader and the ambient loT device may include Ambient loT data and/or signalling. Topology 2 may refer to a topology wherein an A-IoT device communicates bidirectionally with an intermediate node between the A-IoT device and a reader such as a base station. In embodiments, the intermediate node may be a relay, an integrated access/backhaul (IAB) node, a user equipment (UE), a repeater, etc. which is capable of A-IoT communication. The intermediate node may transfer A-IoT data and/or signalling between the reader and the A-IoT device.

As used herein, a device capable of NR communication such as a UE or a base station may be referred to as a “reader.” Transmission of one or more wireless signals between an A-IoT device and a reader may be referred to as A-IoT transmission. A-IoT transmission from an A-IoT device to a reader may be referred to as device-to-reader, or “D2R” transmission. In some cases, D2R transmission may also be referred to as A-IoT uplink (UL) transmissions or A-IoT reverse link transmissions. A-IoT transmission from a reader to an A-IoT device may be referred to as reader- to-device, or “R2D” transmission. In some cases, R2D transmission may be referred to as A-IoT downlink (DL) transmissions or A-IoT forward link transmissions. By contrast, transmissions of NR or cellular signals between a UE and a base station may be referred to herein as “cellular transmissions.” It will be understood that such terms are used for the sake of discussion, and are not intended to provide other limitations to such symbols or transmissions. For A-IoT applications, given that the A-IoT device may have extremely low power consumption, it may be challenging to align the transmission timing with some reference timing due to the use of low cost radio frequency (RF) components in the A-IoT device. In this case, certain design aspects on scheduling and timing may need to be considered for A-IoT applications.

Further, an A-IoT device may need to receive carrier wave signal in order to perform backscattering for uplink transmission. In order to allow proper operation and facilitate simple interference cancellation, certain design aspects on carrier wave signal may need to be considered for A-IoT applications.

Various embodiments herein may relate to or include scheduling mechanisms and carrier wave design for A-IoT. For example, aspects of various embodiments may include one or both of scheduling mechanisms for A-IoT and carrier wave design for A-IoT.

Note that, unless mentioned explicitly, the disclosed embodiments and examples may apply to both deployment topology 1 and deployment topology 2 described herein, and/or another deployment topology.

Scheduling mechanisms for A-IoT

As mentioned above, for A-IoT applications, given that the A-IoT device may have extremely low power consumption, it is challenging to align the transmission timing with some reference timing due to low-cost RF components. In this case, certain appropriate design aspects on scheduling and timing may need to be considered for A-IoT applications.

Embodiments of scheduling mechanisms for A-IoT are provided as follows:

In one embodiment, for scheduling of DL or UL data packet, modulation and coding scheme (MCS), use to determine the effective data rate of the transmission, or transport block size (TBS) or length of data packet can be included in the control command prior to the transmission of data packet. In an example, the control command may be carried via a specified physical control channel while data packet mapped to a specified physical data channel. Further, in an example, the associated physical data channel may follow the physical control channel without any timegap. Alternatively, pre-defined or indicated (via the control command) time gaps may be present between the control and associated data channel.

In one option, information for MCS and/or TBS or length of data packet may be carried by preambles. In this case, a set of preambles may be predefined in the specification, and one preamble from the set of preambles may be used to point to a codepoint for the MCS and/or TBS or length of data packet.

In one option, when the length of data packet is 0, this may indicate that the data packet portion of transmission is not present. In another option, one bit indication may be used to indicate whether the data packet is present or not during the transmission. In particular, bit “1“ may be used to indicate that the data packet is present while bit “0” may be used to indicate that the data packet is not present.

In Figure 2, 101 refers to the control command and 100 refers to the preamble of the transmission that could be used to identify start of the control command. The control command in the figure indicates that data length is 0. In Figure 3, 101 refers to the control command and 100 refers to the preamble of the transmission that could be used to identify start of the control command. 102 refers to the data message portion of the transmission. The control command in the figure indicates that length of the data is not 0 and provides information of the length of the data message. In another option, the control command may be embedded in the data message. In this case, the control command may be included as part of Medium Access Control - Control Element (MAC-CE).

In addition, identifier(s) that are associated with gNB, or UE, or A-IoT device, or combination of the nodes may be explicitly included in the control command for scheduling of DL and/or UL data packet or implicitly included in the control command. In one example, part of or the whole identification of one or more of: gNB or UE and/or A-IoT devices may be used to mask the CRC of the control command message.

Alternatively, identifier that are associated with gNB, or UE, or A-IoT device, or combination of the nodes can be sent as part of the preamble sequence, prior to the control command.

In one option, for topology 1, gNB ID may be indicated within the select and/or query command before the random access procedure. In another option, for topology 1, gNB ID could correspond to a physical cell ID that may be conveyed entirely or in part via a preamble which may be a physical signal involving a specified structure of one or more sequence(s) mapped to physical resources.

In another option, for topology 2, UE ID may be indicated within the select and/or query command before the random access procedure. In another option, for topology 2, UE may indicate the gNB ID within the select and/or query command before the random access procedure. Alternatively, UE ID may be defined as C-RNTI or a function of C-RNTI (e.g., truncated version of C-RNTI bits or C-RNTI bits scrambled with physical cell ID of the cell serving the UE, etc.).

In one option, the A-IoT device ID may be defined as the contention resolution ID that A- loT device randomly generated during random access procedure. In another option, the A-IoT device ID may be defined as an ID that is provided by serving gNB or serving UE during the random access procedure.

When control message also includes the CRC, part of or whole A-IoT device ID may be masked with the CRC for control message. In one example, if the length of CRC for control message is less than the length of A-IoT device ID, a part of A-IoT device ID may be used to mask the CRC for control message.

In another embodiment, for scheduling of UL packet, a scheduling delay may be included in the control command or pre-defined in the specifications. The scheduling delay may be defined as the timing duration between the end of control message and start of UL packet. In other option, the scheduling delay may be defined as the timing duration between the end of DL data packet and start of UL packet. This may also depend on whether the data packet is present in the DL transmission.

Further, the time duration of the scheduling delay may be determined in accordance with the orthogonal frequency division multiplexed (OFDM) symbol, slot or subframe duration. The symbol or slot duration may be determined in accordance with the subcarrier spacing that is predefined in the specification or configured by higher layers or indicated by the gNB or UE.

In some aspects, when transmitting the UL packet, certain range of transmission timing may be allowed for A-IoT devices. This may also depend on the A-IoT device type. In one example, for A-IoT devices that perform backscattering for the UL transmission, the range of transmission timing may be larger than the case for A-IoT devices that generate internally for the UL transmission.

Figure 4 illustrates one example of scheduling delay for A-IoT UL or reverse link transmission. In the figure, gNB or UE may transmit the control message for scheduling of A-IoT UL transmission. The scheduling delay may be included in the control message. Based on the indicated scheduling delay, A-IoT device may perform backscattering for UL transmission with some timing range, which may be defined relative to the symbol, slot or subframe boundary.

In another embodiment, for A-IoT applications, a control message may include acknowledgement (ACK) information when the receiver correctly decodes the DL or UL packet, e.g., when cyclic redundancy check (CRC) of the data packet is passed correctly.

When the receiver does not correctly receive the DL or UL data packet, e.g., when CRC of the data packet is not passed correctly, the receiver does not transmit the negative acknowledgment (NACK) message. In this case, when the transmitter does not receive the acknowledge message, the transmitter may re-transmit the data packet after certain time duration, where the time duration may be predefined in the specification or configured by the higher layers. The time duration may be defined with respect to the end of the last symbol (e.g., end) of the initial transmission and start of the retransmission, or with respect to the end of the last symbol (e.g., end) of the control message with the NACK indication and the start of the retransmission. Further, the time duration may be defined relative to the subcarrier spacing or OFDM symbol, slot or subframe duration. In another example, such a time duration relating initial and retransmission(s) may not be defined since it is not expected that hybrid automatic repeat request (HARQ)-based retransmissions and combining would be supported for A-IoT devices.

Alternatively, a control message may include NACK information when the receiver fails to decode a DL or UL packet successfully. Further, there may not be an explicit ACK indication in case of successful decoding of a DL or UL packet. Accordingly, a transmitter may assume a packet to be successfully received at the receiver.

In another option, the ACK and/or NACK information may be conveyed explicitly or implicitly using the data channel itself.

The ACK and/or NACK information could be indirectly inferred from message sequence index that may be sent in the control message or data message. For example, if the message sequence index is incremented by the transmitter from the message sequence index associated with the last correctly received data message, then the receiver is able to infer that last data message is correctly received. If the transmitter sends a message with message sequence index that is not a incremented value from last message sent by the receiver, then the receiver is able to infer that the last message sent was not correctly received.

In another option, dedicated sequences may be defined for representing ACK and/or NACK messages, respectively. The dedicated sequences may be predefined in the specification or configured by the network for an A-IoT device.

In another embodiment, for scheduling of DL packet, acknowledgment delay may be included in the control command.

The acknowledgment delay may be defined as the time duration between the end of control message and start of acknowledgment message. In other option, the scheduling delay may be defined as the time duration between the end of DL data packet and start of acknowledgement message.

Further, the time duration of the scheduling delay may be determined in accordance with the OFDM symbol, slot or subframe duration. The symbol or slot duration may be determined in accordance with the subcarrier spacing that is predefined in the specification or configured by higher layers or indicated by the gNB or UE.

Figure 5 illustrates one example of acknowledgement delay for A-IoT DL or forward link transmission. In the figure, gNB or UE may transmit the DL data packet to A-IoT device. The acknowledgement delay may be included in the control message that is associated with DL data packet. Based on the indicated acknowledgement delay, A-IoT device may perform backscattering for UL control command including acknowledgement message with some timing range, which may be defined relative to the symbol, slot or subframe boundary.

In another embodiment, for A-IoT devices that generate internally for the UL transmission, the frequency domain resource allocation may be included in the control message that schedules the UL transmission. In an example, the frequency domain resource allocation indication may include only the index of the lowest subcarrier and/or physical resource block (PRB) with a specified value or configured value via higher layers of the bandwidth used for the UL transmission. In another example, both the starting subcarrier and/or PRB index as well as the transmission bandwidth may be indicated as part of the frequency domain resource allocation. In both cases, the bandwidth for the UL transmission may be defined in a number of subcarriers or PRBs. In case of UL transmission bandwidth occupying multiple subcarriers or PRBs, the indicated subcarrier(s) and/or PRB(s) for UL transmission may be contiguous in frequency or may be indicated to follow a frequency hopping pattern defined in time. Alternatively, the subcarriers for UL transmission may be determined based on a subcarrier-selection (or “tone selection”)- based approach that selects one or multiple subcarriers from a larger number of subcarriers following a specified pattern in time, e.g., defined as a function of choice of subcarrier index within a PRB being even or odd.

In another embodiment, if a frequency shifter is implemented in an A-IoT device, one field may be included in the control command to indicate whether the A-IoT device transmits the D2R signal/channel in the upper side or lower side relative to the frequency location of carrier wave signal.

In one example, one bit indicator may be included in the control command to indicate whether the A-IoT device transmits the D2R signal/channel in the upper or lower side relative to the frequency location of carrier wave signal. In particular, bit “0” may indicate that D2R is transmitted in the lower side of the frequency location of carrier wave signal while bit “1” may indicate that D2R is transmitted in the upper side of the frequency location of carrier wave signal or vice versa. The exact separation in frequency may be predefined in the specification or configured by higher layers. This frequency separation may be defined in accordance with the number of subcarriers or the number of RPBs.

Figure 6 illustrates the frequency offset indication for D2R transmission for A-IoT device with frequency shifter. In the figure, when bit “1” is included in the control command for scheduling D2R transmission, D2R transmission at 602 is scheduled, where the frequency resource is at the upper side of frequency resource allocated for carrier wave signal at 604, with K subcarriers separation. Further, when bit “0” is included in the control command for scheduling D2R transmission, D2R transmission at 606 is scheduled, where the frequency resource is at the lower side of frequency resource allocated for carrier wave signal at 604, with K subcarriers separation.

Further, whether frequency shifter is implemented in an A-IoT device can be indicated in the D2R message during random access procedure. In one example, bit “1” may indicate that the A-IoT device is equipped with the frequency shifter, while bit “1” may indicate that the A-IoT device is not equipped with the frequency shifter. In another example, whether frequency shifter is included in the A-IoT device can be part of A-IoT device type. In addition, the D2R message may be the first D2R message during the random access procedure. In another option, the D2R message may be the D2R message after the reader responds with random access response (RAR) message.

In another option, when multi-tone based carrier wave signal is generated by the carrier wave source, and when frequency shifter is implemented in an A-IoT device, one field may be included in the control command to indicate whether the A-IoT device transmits the device-to- reader (D2R) signal/channel in the upper side or lower side relative to each frequency location of multi-tone carrier wave signal.

In another embodiment, for A-IoT initiated D2R transmission, a scheduling request message may be included in the control command. In this case, a dedicated sequences may be defined to represent scheduling request message. The dedicated sequence may be predefined in the specification or configured by the network for an A-IoT device.

In one embodiment, after encoding, data packet may be scrambled with a scrambling sequence. The scrambling sequence may be initialized with an initialization seed, which is defined as a function of one or more of: gNB, UE and/or A-IoT device ID.

In another option, the initialization seed of the scrambling sequence may be initialized as an ID that is indicated in a message that is broadcast to the A-IoT devices by the gNB or UE. For topology 2, the ID may be configured by higher layers from the gNB, or equal to the physical cell ID if it is not configured by higher layers.

In another embodiment, for topology 2, when UE transmits the DL packet or control message to A-IoT, which may also include preamble, the DL transmission timing for A-IoT applications follows the DL transmission timing in NR. In particular, timing advance (TA) = 0 is applied for DL transmission to A-IoT devices. In this case, a UE can serve as an intermediate node for an A-IoT device when in RRC_CONNECTED or RRC_INACTIVE states, e.g., irrespective of whether the UE has a valid TA to the serving cell.

In another option, for topology 2, when UE transmits the DL packet or control message to A-IoT, which may also include preamble, the DL transmission timing for A-IoT applications follows the UL transmission timing in NR. In particular, UL TA is applied for DL transmission to A-IoT devices from a UE serving as an intermediate node for an A-IoT device. In this case, a UE can serve as an intermediate node for an A-IoT device only when in RRC_CONNECTED state. In another example, under a UE can serve as an intermediate node for an A-IoT device when in RRC_INACTIVE state only when it may have a valid TA to the serving/camping cell.

In another embodiment, for topology 2, for A-IoT devices that are capable of generating the UL transmission internally, the UL transmission timing follows the DL transmission timing from the intermediate UE. The DL transmission timing may be obtained from the preamble and/or synchronization message for A-IoT applications.

Carrier wave design for A-IoT

As mentioned above, A-IoT device may need to receive carrier wave signal in order to perform backscattering for uplink transmission. In order to allow proper operation and facilitate simple interference cancellation, certain design aspects on carrier wave signal may need to be considered for A-IoT applications.

Embodiments of carrier wave design for A-IoT are provided as follows:

In one embodiment, a fixed sequence may be generated for carrier wave signal, where the fixed sequence may be predefined in the specification. In one example, all “1” or “0” sequence may be defined for carrier wave signal generation.

In another option, a pseudo-random sequence may be generated for carrier wave signal, where the pseudo-random sequence may be generated in accordance with the gNB and/or UE ID and/or an ID that is configured by higher layers via RRC signalling. The latter case may apply to topology 2 where UE is served as an intermediate node for A-IoT applications.

NR based transmission signals and channels generate OFDM symbol(s) and transmit the OFDM symbol using carrier up-conversion and receive the OFDM symbols using carrier downconversion. The existing NR signals reset the phase of the carrier used for up-conversion for each transmitted OFDM symbol. where a_{fe (} is the frequency domain modulated complex symbol for subcarrier k and OFDM symbol /, N_RB is the number resource block (RB) that is occupied by the frequency domain signals, N _C ^B is the number of subcarriers for a RB, k₀ is the frequency offset in which the signal is embedded in the frequency domain with respect to the carrier frequency, N ^p is the number of samples for cyclic prefix (CP) of the OFDM symbol I, T_c is the sampling rate of the OFDM symbol transmission, t ^LarL is the time value of the start of the OFDM symbol /, A is the subcarrier spacing. s₍ (t) represents the baseband OFDM symbol in time domain, z₍ (t) is the radio frequency OFDM symbol signal in time domain, which has been up-converted to carrier frequency fo. From the equations, it can be seen that carrier phase of the each OFDM symbol is 0 at the start of the OFDM symbol (after CP) for every OFDM symbol being transmitted.

When signals are up-converted with a carrier frequency, the phase of the carrier will be continuously increasing. In order to create up-converted radio signal that resets the carrier phase each symbol, specific complex phase should be multiplied to each OFDM symbol.

For A-IoT carrier wave, the generated carrier wave should result in continuous carrier phase. As such the up-converted carrier wave should use the following up-conversion equation.

The carrier wave generated based on OFDM symbol framework, s_t (t) , is up-converted with a carrier phase that does not reset as a function of OFDM symbol index or location. The different OFDM symbols that make up the carrier wave are mapped in time domain and up- converted with a continuous up-conversion carrier.

In another embodiment, carrier wave signal may occupy one or more subcarriers in the frequency domain. Further, in case of multiple subcarriers, they may map to contiguous subcarriers in frequency or be mapped using subcarrier-selection or subcarrier-hopping wherein a subset (e.g., one) of the available subcarriers are utilized at a time with or without application of a time hopping pattern that may be predefined.

For topology 2, when UE or an external node is configured or indicated to transmit a carrier wave signal in UL spectrum in FDD, frequency domain resource allocation of carrier wave signal may be configured by higher layers via RRC signalling from the gNB.

For topology 1, when an external node is used to transmit a carrier wave signal in UL spectrum in FDD, frequency domain resource allocation of carrier wave signal may be configured by higher layers via RRC signalling from the gNB.

In another embodiment, for UL transmission from A-IoT devices that perform backscattering for the UL transmission, the A-IoT devices may expect that the carrier wave signal is present after the A-IoT devices receive the DL packet or control message.

During random access, the A-IoT devices that perform backscattering for the UL transmission may expect that the carrier wave signal is always present.

SYSTEMS AND IMPLEMENTATIONS

Figures 7-10 illustrate various systems, devices, and components that may implement aspects of disclosed embodiments.

Figure 7 illustrates a network 700 in accordance with various embodiments. The network 700 may operate in a manner consistent with 3GPP technical specifications for LTE or 5G/NR systems. However, the example embodiments are not limited in this regard and the described embodiments may apply to other networks that benefit from the principles described herein, such as future 3 GPP systems, or the like.

The network 700 may include a UE 702, which may include any mobile or non-mobile computing device designed to communicate with a RAN 704 via an over-the-air connection. The UE 702 may be communicatively coupled with the RAN 704 by a Uu interface. The UE 702 may be, but is not limited to, a smartphone, tablet computer, wearable computer device, desktop computer, laptop computer, in-vehicle infotainment, in-car entertainment device, instrument cluster, head-up display device, onboard diagnostic device, dashtop mobile equipment, mobile data terminal, electronic engine management system, electronic/engine control unit, electronic/engine control module, embedded system, sensor, microcontroller, control module, engine management system, networked appliance, machine-type communication device, M2M or D2D device, loT device, etc.

In some embodiments, the network 700 may include a plurality of UEs coupled directly with one another via a sidelink interface. The UEs may be M2M/D2D devices that communicate using physical sidelink channels such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc.

In some embodiments, the UE 702 may additionally communicate with an AP 706 via an over-the-air connection. The AP 706 may manage a WLAN connection, which may serve to offload some/all network traffic from the RAN 704. The connection between the UE 702 and the AP 706 may be consistent with any IEEE 802.11 protocol, wherein the AP 706 could be a wireless fidelity (Wi-Fi®) router. In some embodiments, the UE 702, RAN 704, and AP 706 may utilize cellular- WLAN aggregation (for example, LWA/LWIP). Cellular- WLAN aggregation may involve the UE 702 being configured by the RAN 704 to utilize both cellular radio resources and WLAN resources.

The RAN 704 may include one or more access nodes, for example, AN 708. AN 708 may terminate air-interface protocols for the UE 702 by providing access stratum protocols including RRC, PDCP, RLC, MAC, and LI protocols. In this manner, the AN 708 may enable data/voice connectivity between CN 720 and the UE 702. In some embodiments, the AN 708 may be implemented in a discrete device or as one or more software entities running on server computers as part of, for example, a virtual network, which may be referred to as a CRAN or virtual baseband unit pool. The AN 708 be referred to as a BS, gNB, RAN node, eNB, ng-eNB, NodeB, RSU, TRxP, TRP, etc. The AN 708 may be a macrocell base station or a low power base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.

In embodiments in which the RAN 704 includes a plurality of ANs, they may be coupled with one another via an X2 interface (if the RAN 704 is an LTE RAN) or an Xn interface (if the RAN 704 is a 5G RAN). The X2/Xn interfaces, which may be separated into control/user plane interfaces in some embodiments, may allow the ANs to communicate information related to handovers, data/context transfers, mobility, load management, interference coordination, etc.

The ANs of the RAN 704 may each manage one or more cells, cell groups, component carriers, etc. to provide the UE 702 with an air interface for network access. The UE 702 may be simultaneously connected with a plurality of cells provided by the same or different ANs of the RAN 704. For example, the UE 702 and RAN 704 may use carrier aggregation to allow the UE 702 to connect with a plurality of component carriers, each corresponding to a Pcell or Scell. In dual connectivity scenarios, a first AN may be a master node that provides an MCG and a second AN may be secondary node that provides an SCG. The first/second ANs may be any combination of eNB, gNB, ng-eNB, etc.

The RAN 704 may provide the air interface over a licensed spectrum or an unlicensed spectrum. To operate in the unlicensed spectrum, the nodes may use LAA, eLAA, and/or feLAA mechanisms based on CA technology with PCells/Scells. Prior to accessing the unlicensed spectrum, the nodes may perform medium/carrier-sensing operations based on, for example, a listen-before-talk (LBT) protocol.

In V2X scenarios the UE 702 or AN 708 may be or act as a RSU, which may refer to any transportation infrastructure entity used for V2X communications. An RSU may be implemented in or by a suitable AN or a stationary (or relatively stationary) UE. An RSU implemented in or by: a UE may be referred to as a “UE-type RSU”; an eNB may be referred to as an “eNB-type RSU”; a gNB may be referred to as a “gNB-type RSU”; and the like. In one example, an RSU is a computing device coupled with radio frequency circuitry located on a roadside that provides connectivity support to passing vehicle UEs. The RSU may also include internal data storage circuitry to store intersection map geometry, traffic statistics, media, as well as applications/software to sense and control ongoing vehicular and pedestrian traffic. The RSU may provide very low latency communications required for high speed events, such as crash avoidance, traffic warnings, and the like. Additionally or alternatively, the RSU may provide other cellular/WLAN communications services. The components of the RSU may be packaged in a weatherproof enclosure suitable for outdoor installation, and may include a network interface controller to provide a wired connection (e.g., Ethernet) to a traffic signal controller or a backhaul network.

In some embodiments, the RAN 704 may be an LTE RAN 710 with eNBs, for example, eNB 712. The LTE RAN 710 may provide an LTE air interface with the following characteristics: SCS of 15 kHz; CP-OFDM waveform for DL and SC-FDMA waveform for UL; turbo codes for data and TBCC for control; etc. The LTE air interface may rely on CSLRS for CSI acquisition and beam management; PDSCH/PDCCH DMRS for PDSCH/PDCCH demodulation; and CRS for cell search and initial acquisition, channel quality measurements, and channel estimation for coherent demodulation/detection at the UE. The LTE air interface may operating on sub-6 GHz bands.

In some embodiments, the RAN 704 may be an NG-RAN 714 with gNBs, for example, gNB 716, or ng-eNBs, for example, ng-eNB 718. The gNB 716 may connect with 5G-enabled UEs using a 5G NR interface. The gNB 716 may connect with a 5G core through an NG interface, which may include an N2 interface or an N3 interface. The ng-eNB 718 may also connect with the 5G core through an NG interface, but may connect with a UE via an LTE air interface. The gNB 716 and the ng-eNB 718 may connect with each other over an Xn interface.

In some embodiments, the NG interface may be split into two parts, an NG user plane (NG-U) interface, which carries traffic data between the nodes of the NG-RAN 714 and a UPF 748 (e.g., N3 interface), and an NG control plane (NG-C) interface, which is a signaling interface between the nodes of the NG-RAN714 and an AMF 744 (e.g., N2 interface).

The NG-RAN 714 may provide a 5G-NR air interface with the following characteristics: variable SCS; CP-OFDM for DL, CP-OFDM and DFT-s-OFDM for UL; polar, repetition, simplex, and Reed-Muller codes for control and LDPC for data. The 5G-NR air interface may rely on CSLRS, PDSCH/PDCCH DMRS similar to the LTE air interface. The 5G-NR air interface may not use a CRS, but may use PBCH DMRS for PBCH demodulation; PTRS for phase tracking for PDSCH; and tracking reference signal for time tracking. The 5G-NR air interface may operating on FR1 bands that include sub-6 GHz bands or FR2 bands that include bands from 24.25 GHz to 52.6 GHz. The 5G-NR air interface may include an SSB that is an area of a downlink resource grid that includes PSS/SSS/PBCH.

In some embodiments, the 5G-NR air interface may utilize BWPs for various purposes. For example, BWP can be used for dynamic adaptation of the SCS. For example, the UE 702 can be configured with multiple BWPs where each BWP configuration has a different SCS. When a BWP change is indicated to the UE 702, the SCS of the transmission is changed as well. Another use case example of BWP is related to power saving. In particular, multiple BWPs can be configured for the UE 702 with different amount of frequency resources (for example, PRBs) to support data transmission under different traffic loading scenarios. A BWP containing a smaller number of PRBs can be used for data transmission with small traffic load while allowing power saving at the UE 702 and in some cases at the gNB 716. A BWP containing a larger number of PRBs can be used for scenarios with higher traffic load.

The RAN 704 is communicatively coupled to CN 720 that includes network elements to provide various functions to support data and telecommunications services to customers/subscribers (for example, users of UE 702). The components of the CN 720 may be implemented in one physical node or separate physical nodes. In some embodiments, NFV may be utilized to virtualize any or all of the functions provided by the network elements of the CN 720 onto physical compute/storage resources in servers, switches, etc. A logical instantiation of the CN 720 may be referred to as a network slice, and a logical instantiation of a portion of the CN 720 may be referred to as a network sub-slice.

In some embodiments, the CN 720 may be an LTE CN 722, which may also be referred to as an EPC. The LTE CN 722 may include MME 724, SGW 726, SGSN 728, HSS 730, PGW 732, and PCRF 734 coupled with one another over interfaces (or “reference points”) as shown. Functions of the elements of the LTE CN 722 may be briefly introduced as follows.

The MME 724 may implement mobility management functions to track a current location of the UE 702 to facilitate paging, bearer activation/deactivation, handovers, gateway selection, authentication, etc.

The SGW 726 may terminate an S I interface toward the RAN and route data packets between the RAN and the LTE CN 722. The SGW 726 may be a local mobility anchor point for inter-RAN node handovers and also may provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful intercept, charging, and some policy enforcement.

The SGSN 728 may track a location of the UE 702 and perform security functions and access control. In addition, the SGSN 728 may perform inter-EPC node signaling for mobility between different RAT networks; PDN and S-GW selection as specified by MME 724; MME selection for handovers; etc. The S3 reference point between the MME 724 and the SGSN 728 may enable user and bearer information exchange for inter-3GPP access network mobility in idle/active states.

The HSS 730 may include a database for network users, including subscription-related information to support the network entities’ handling of communication sessions. The HSS 730 can provide support for routing/roaming, authentication, authorization, naming/addressing resolution, location dependencies, etc. An S6a reference point between the HSS 730 and the MME 724 may enable transfer of subscription and authentication data for authenticating/authorizing user access to the LTE CN 720.

The PGW 732 may terminate an SGi interface toward a data network (DN) 736 that may include an application/content server 738. The PGW 732 may route data packets between the LTE CN 722 and the data network 736. The PGW 732 may be coupled with the SGW 726 by an S5 reference point to facilitate user plane tunneling and tunnel management. The PGW 732 may further include a node for policy enforcement and charging data collection (for example, PCEF). Additionally, the SGi reference point between the PGW 732 and the data network 7 36 may be an operator external public, a private PDN, or an intra-operator packet data network, for example, for provision of IMS services. The PGW 732 may be coupled with a PCRF 734 via a Gx reference point.

The PCRF 734 is the policy and charging control element of the LTE CN 722. The PCRF 734 may be communicatively coupled to the app/content server 738 to determine appropriate QoS and charging parameters for service flows. The PCRF 732 may provision associated rules into a PCEF (via Gx reference point) with appropriate TFT and QCI.

In some embodiments, the CN 720 may be a 5GC 740. The 5GC 740 may include an AUSF 742, AMF 744, SMF 746, UPF 748, NSSF 750, NEF 752, NRF 754, PCF 756, UDM 758, and AF 760 coupled with one another over interfaces (or “reference points”) as shown. Functions of the elements of the 5GC 740 may be briefly introduced as follows.

The AUSF 742 may store data for authentication of UE 702 and handle authentication- related functionality. The AUSF 742 may facilitate a common authentication framework for various access types. In addition to communicating with other elements of the 5GC 740 over reference points as shown, the AUSF 742 may exhibit an Nausf service-based interface.

The AMF 744 may allow other functions of the 5GC 740 to communicate with the UE 702 and the RAN 704 and to subscribe to notifications about mobility events with respect to the UE 702. The AMF 744 may be responsible for registration management (for example, for registering UE 702), connection management, reachability management, mobility management, lawful interception of AMF-related events, and access authentication and authorization. The AMF 744 may provide transport for SM messages between the UE 702 and the SMF 746, and act as a transparent proxy for routing SM messages. AMF 744 may also provide transport for SMS messages between UE 702 and an SMSF. AMF 744 may interact with the AUSF 742 and the UE 702 to perform various security anchor and context management functions. Furthermore, AMF 744 may be a termination point of a RAN CP interface, which may include or be an N2 reference point between the RAN 704 and the AMF 744; and the AMF 744 may be a termination point of NAS (Nl) signaling, and perform NAS ciphering and integrity protection. AMF 744 may also support NAS signaling with the UE 702 over an N3 IWF interface.

The SMF 746 may be responsible for SM (for example, session establishment, tunnel management between UPF 748 and AN 708); UE IP address allocation and management (including optional authorization); selection and control of UP function; configuring traffic steering at UPF 748 to route traffic to proper destination; termination of interfaces toward policy control functions; controlling part of policy enforcement, charging, and QoS; lawful intercept (for SM events and interface to LI system); termination of SM parts of NAS messages; downlink data notification; initiating AN specific SM information, sent via AMF 744 over N2 to AN 708; and determining SSC mode of a session. SM may refer to management of a PDU session, and a PDU session or “session” may refer to a PDU connectivity service that provides or enables the exchange of PDUs between the UE 702 and the data network 736.

The UPF 748 may act as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point of interconnect to data network 736, and a branching point to support multi-homed PDU session. The UPF 748 may also perform packet routing and forwarding, perform packet inspection, enforce the user plane part of policy rules, lawfully intercept packets (UP collection), perform traffic usage reporting, perform QoS handling for a user plane (e.g., packet filtering, gating, UL/DL rate enforcement), perform uplink traffic verification (e.g., SDF- to-QoS flow mapping), transport level packet marking in the uplink and downlink, and perform downlink packet buffering and downlink data notification triggering. UPF 748 may include an uplink classifier to support routing traffic flows to a data network.

The NSSF 750 may select a set of network slice instances serving the UE 702. The NSSF 750 may also determine allowed NSSAI and the mapping to the subscribed S-NSSAIs, if needed. The NSSF 750 may also determine the AMF set to be used to serve the UE 702, or a list of candidate AMFs based on a suitable configuration and possibly by querying the NRF 754. The selection of a set of network slice instances for the UE 702 may be triggered by the AMF 744 with which the UE 702 is registered by interacting with the NSSF 750, which may lead to a change of AMF. The NSSF 750 may interact with the AMF 744 via an N22 reference point; and may communicate with another NSSF in a visited network via an N31 reference point (not shown). Additionally, the NSSF 750 may exhibit an Nnssf service-based interface.

The NEF 752 may securely expose services and capabilities provided by 3GPP network functions for third party, internal exposure/re-exposure, AFs (e.g., AF 760), edge computing or fog computing systems, etc. In such embodiments, the NEF 752 may authenticate, authorize, or throttle the AFs. NEF 752 may also translate information exchanged with the AF 760 and information exchanged with internal network functions. For example, the NEF 752 may translate between an AF-Service-Identifier and an internal 5GC information. NEF 752 may also receive information from other NFs based on exposed capabilities of other NFs. This information may be stored at the NEF 752 as structured data, or at a data storage NF using standardized interfaces. The stored information can then be re-exposed by the NEF 752 to other NFs and AFs, or used for other purposes such as analytics. Additionally, the NEF 752 may exhibit an Nnef service-based interface.

The NRF 754 may support service discovery functions, receive NF discovery requests from NF instances, and provide the information of the discovered NF instances to the NF instances. NRF 754 also maintains information of available NF instances and their supported services. As used herein, the terms “instantiate,” “instantiation,” and the like may refer to the creation of an instance, and an “instance” may refer to a concrete occurrence of an object, which may occur, for example, during execution of program code. Additionally, the NRF 754 may exhibit the Nnrf service-based interface.

The PCF 756 may provide policy rules to control plane functions to enforce them, and may also support unified policy framework to govern network behavior. The PCF 756 may also implement a front end to access subscription information relevant for policy decisions in a UDR of the UDM 758. In addition to communicating with functions over reference points as shown, the PCF 756 exhibit an Npcf service-based interface.

The UDM 758 may handle subscription-related information to support the network entities’ handling of communication sessions, and may store subscription data of UE 702. For example, subscription data may be communicated via an N8 reference point between the UDM 758 and the AMF 744. The UDM 758 may include two parts, an application front end and a UDR. The UDR may store subscription data and policy data for the UDM 758 and the PCF 756, and/or structured data for exposure and application data (including PFDs for application detection, application request information for multiple UEs 702) for the NEF 752. The Nudr service-based interface may be exhibited by the UDR 221 to allow the UDM 758, PCF 756, and NEF 752 to access a particular set of the stored data, as well as to read, update (e.g., add, modify), delete, and subscribe to notification of relevant data changes in the UDR. The UDM may include a UDM- FE, which is in charge of processing credentials, location management, subscription management and so on. Several different front ends may serve the same user in different transactions. The UDM-FE accesses subscription information stored in the UDR and performs authentication credential processing, user identification handling, access authorization, registration/mobility management, and subscription management. In addition to communicating with other NFs over reference points as shown, the UDM 758 may exhibit the Nudm service-based interface.

The AF 760 may provide application influence on traffic routing, provide access to NEF, and interact with the policy framework for policy control.

In some embodiments, the 5GC 740 may enable edge computing by selecting operator/3^rd party services to be geographically close to a point that the UE 702 is attached to the network. This may reduce latency and load on the network. To provide edge-computing implementations, the 5GC 740 may select a UPF 748 close to the UE 702 and execute traffic steering from the UPF 748 to data network 736 via the N6 interface. This may be based on the UE subscription data, UE location, and information provided by the AF 760. In this way, the AF 760 may influence UPF (re)selection and traffic routing. Based on operator deployment, when AF 760 is considered to be a trusted entity, the network operator may permit AF 760 to interact directly with relevant NFs. Additionally, the AF 760 may exhibit an Naf service-based interface.

The data network 736 may represent various network operator services, Internet access, or third party services that may be provided by one or more servers including, for example, application/content server 738.

Figure 8 schematically illustrates a wireless network 800 in accordance with various embodiments. The wireless network 800 may include a UE 802 in wireless communication with an AN 804. The UE 802 and AN 804 may be similar to, and substantially interchangeable with, like-named components described elsewhere herein.

The UE 802 may be communicatively coupled with the AN 804 via connection 806. The connection 806 is illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols such as an LTE protocol or a 5G NR protocol operating at mmWave or sub-6GHz frequencies.

The UE 802 may include a host platform 808 coupled with a modem platform 810. The host platform 808 may include application processing circuitry 812, which may be coupled with protocol processing circuitry 814 of the modem platform 810. The application processing circuitry 812 may run various applications for the UE 802 that source/sink application data. The application processing circuitry 812 may further implement one or more layer operations to transmit/receive application data to/from a data network. These layer operations may include transport (for example UDP) and Internet (for example, IP) operations

The protocol processing circuitry 814 may implement one or more of layer operations to facilitate transmission or reception of data over the connection 806. The layer operations implemented by the protocol processing circuitry 814 may include, for example, MAC, RLC, PDCP, RRC and NAS operations.

The modem platform 810 may further include digital baseband circuitry 816 that may implement one or more layer operations that are “below” layer operations performed by the protocol processing circuitry 814 in a network protocol stack. These operations may include, for example, PHY operations including one or more of HARQ-ACK functions, scrambling/descrambling, encoding/decoding, layer mapping/de-mapping, modulation symbol mapping, received symbol/bit metric determination, multi-antenna port precoding/decoding, which may include one or more of space-time, space-frequency or spatial coding, reference signal generation/detection, preamble sequence generation and/or decoding, synchronization sequence generation/detection, control channel signal blind decoding, and other related functions.

The modem platform 810 may further include transmit circuitry 818, receive circuitry 820, RF circuitry 822, and RF front end (RFFE) 824, which may include or connect to one or more antenna panels 826. Briefly, the transmit circuitry 818 may include a digital-to-analog converter, mixer, intermediate frequency (IF) components, etc.; the receive circuitry 820 may include an analog-to-digital converter, mixer, IF components, etc.; the RF circuitry 822 may include a low-noise amplifier, a power amplifier, power tracking components, etc.; RFFE 824 may include filters (for example, surface/bulk acoustic wave filters), switches, antenna tuners, beamforming components (for example, phase-array antenna components), etc. The selection and arrangement of the components of the transmit circuitry 818, receive circuitry 820, RF circuitry 822, RFFE 824, and antenna panels 826 (referred generically as “transmit/receive components”) may be specific to details of a specific implementation such as, for example, whether communication is TDM or FDM, in mmWave or sub-6 gHz frequencies, etc. In some embodiments, the transmit/receive components may be arranged in multiple parallel transmit/receive chains, may be disposed in the same or different chips/modules, etc.

In some embodiments, the protocol processing circuitry 814 may include one or more instances of control circuitry (not shown) to provide control functions for the transmit/receive components.

A UE reception may be established by and via the antenna panels 826, RFFE 824, RF circuitry 822, receive circuitry 820, digital baseband circuitry 816, and protocol processing circuitry 814. In some embodiments, the antenna panels 826 may receive a transmission from the AN 804 by receive-beamforming signals received by a plurality of antennas/antenna elements of the one or more antenna panels 826.

A UE transmission may be established by and via the protocol processing circuitry 814, digital baseband circuitry 816, transmit circuitry 818, RF circuitry 822, RFFE 824, and antenna panels 826. In some embodiments, the transmit components of the UE 804 may apply a spatial filter to the data to be transmitted to form a transmit beam emitted by the antenna elements of the antenna panels 826.

Similar to the UE 802, the AN 804 may include a host platform 828 coupled with a modem platform 830. The host platform 828 may include application processing circuitry 832 coupled with protocol processing circuitry 834 of the modem platform 830. The modem platform may further include digital baseband circuitry 836, transmit circuitry 838, receive circuitry 840, RF circuitry 842, RFFE circuitry 844, and antenna panels 846. The components of the AN 804 may be similar to and substantially interchangeable with like-named components of the UE 802. In addition to performing data transmission/reception as described above, the components of the AN 808 may perform various logical functions that include, for example, RNC functions such as radio bearer management, uplink and downlink dynamic radio resource management, and data packet scheduling. Figure 9 is a block diagram illustrating components, according to some example embodiments, able to read instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and perform any one or more of the methodologies discussed herein. Specifically, Figure 9 shows a diagrammatic representation of hardware resources 900 including one or more processors (or processor cores) 910, one or more memory/storage devices 920, and one or more communication resources 930, each of which may be communicatively coupled via a bus 940 or other interface circuitry. For embodiments where node virtualization (e.g., NFV) is utilized, a hypervisor 902 may be executed to provide an execution environment for one or more network slices/sub-slices to utilize the hardware resources 900.

The processors 910 may include, for example, a processor 912 and a processor 914. The processors 910 may be, for example, a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a DSP such as a baseband processor, an ASIC, an FPGA, a radio-frequency integrated circuit (RFIC), another processor (including those discussed herein), or any suitable combination thereof.

The memory/storage devices 920 may include main memory, disk storage, or any suitable combination thereof. The memory/storage devices 920 may include, but are not limited to, any type of volatile, non-volatile, or semi-volatile memory such as dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), Flash memory, solid-state storage, etc.

The communication resources 930 may include interconnection or network interface controllers, components, or other suitable devices to communicate with one or more peripheral devices 904 or one or more databases 906 or other network elements via a network 908. For example, the communication resources 930 may include wired communication components (e.g., for coupling via USB, Ethernet, etc.), cellular communication components, NFC components, Bluetooth® (or Bluetooth® Low Energy) components, Wi-Fi® components, and other communication components.

Instructions 950 may comprise software, a program, an application, an applet, an app, or other executable code for causing at least any of the processors 910 to perform any one or more of the methodologies discussed herein. The instructions 950 may reside, completely or partially, within at least one of the processors 910 (e.g., within the processor’s cache memory), the memory/storage devices 920, or any suitable combination thereof. Furthermore, any portion of the instructions 950 may be transferred to the hardware resources 900 from any combination of the peripheral devices 904 or the databases 906. Accordingly, the memory of processors 910, the memory/storage devices 920, the peripheral devices 904, and the databases 906 are examples of computer-readable and machine-readable media.

Figure 10 illustrates a network 1000 in accordance with various embodiments. The network 1000 may operate in a matter consistent with 3 GPP technical specifications or technical reports for 6G systems. In some embodiments, the network 1000 may operate concurrently with network 700. For example, in some embodiments, the network 1000 may share one or more frequency or bandwidth resources with network 700. As one specific example, a UE (e.g., UE 1002) may be configured to operate in both network 1000 and network 700. Such configuration may be based on a UE including circuitry configured for communication with frequency and bandwidth resources of both networks 700 and 1000. In general, several elements of network 1000 may share one or more characteristics with elements of network 700. For the sake of brevity and clarity, such elements may not be repeated in the description of network 1000.

The network 1000 may include a UE 1002, which may include any mobile or non-mobile computing device designed to communicate with a RAN 1008 via an over-the-air connection. The UE 1002 may be similar to, for example, UE 702. The UE 1002 may be, but is not limited to, a smartphone, tablet computer, wearable computer device, desktop computer, laptop computer, in- vehicle infotainment, in-car entertainment device, instrument cluster, head-up display device, onboard diagnostic device, dashtop mobile equipment, mobile data terminal, electronic engine management system, electronic/engine control unit, electronic/engine control module, embedded system, sensor, microcontroller, control module, engine management system, networked appliance, machine-type communication device, M2M or D2D device, loT device, etc.

Although not specifically shown in Figure 10, in some embodiments the network 1000 may include a plurality of UEs coupled directly with one another via a sidelink interface. The UEs may be M2M/D2D devices that communicate using physical sidelink channels such as, but not limited to, PSBCH, PSDCH, PSSCH, PSCCH, PSFCH, etc. Similarly, although not specifically shown in Figure 10, the UE 1002 may be communicatively coupled with an AP such as AP 706 as described with respect to Figure 7. Additionally, although not specifically shown in Figure 10, in some embodiments the RAN 1008 may include one or more ANss such as AN 708 as described with respect to Figure 7. The RAN 1008 and/or the AN of the RAN 1008 may be referred to as a base station (BS), a RAN node, or using some other term or name.

The UE 1002 and the RAN 1008 may be configured to communicate via an air interface that may be referred to as a sixth generation (6G) air interface. The 6G air interface may include one or more features such as communication in a terahertz (THz) or sub-THz bandwidth, or joint communication and sensing. As used herein, the term “joint communication and sensing” may refer to a system that allows for wireless communication as well as radar-based sensing via various types of multiplexing. As used herein, THz or sub-THz bandwidths may refer to communication in the 80 GHz and above frequency ranges. Such frequency ranges may additionally or alternatively be referred to as “millimeter wave” or “mmWave” frequency ranges.

The RAN 1008 may allow for communication between the UE 1002 and a 6G core network (CN) 1010. Specifically, the RAN 1008 may facilitate the transmission and reception of data between the UE 1002 and the 6G CN 1010. The 6G CN 1010 may include various functions such as NSSF 750, NEF 752, NRF 754, PCF 756, UDM 758, AF 760, SMF 746, and AUSF 742. The 6G CN 1010 may additional include UPF 748 and DN 736 as shown in Figure 10.

Additionally, the RAN 1008 may include various additional functions that are in addition to, or alternative to, functions of a legacy cellular network such as a 4G or 5G network. Two such functions may include a Compute Control Function (Comp CF) 1024 and a Compute Service Function (Comp SF) 1036. The Comp CF 1024 and the Comp SF 1036 may be parts or functions of the Computing Service Plane. Comp CF 1024 may be a control plane function that provides functionalities such as management of the Comp SF 1036, computing task context generation and management (e.g., create, read, modify, delete), interaction with the underlying computing infrastructure for computing resource management, etc.. Comp SF 1036 may be a user plane function that serves as the gateway to interface computing service users (such as UE 1002) and computing nodes behind a Comp SF instance. Some functionalities of the Comp SF 1036 may include: parse computing service data received from users to compute tasks executable by computing nodes; hold service mesh ingress gateway or service API gateway; service and charging policies enforcement; performance monitoring and telemetry collection, etc. In some embodiments, a Comp SF 1036 instance may serve as the user plane gateway for a cluster of computing nodes. A Comp CF 1024 instance may control one or more Comp SF 1036 instances.

Two other such functions may include a Communication Control Function (Comm CF) 1028 and a Communication Service Function (Comm SF) 1038, which may be parts of the Communication Service Plane. The Comm CF 1028 may be the control plane function for managing the Comm SF 1038, communication sessions creation/configuration/releasing, and managing communication session context. The Comm SF 1038 may be a user plane function for data transport. Comm CF 1028 and Comm SF 1038 may be considered as upgrades of SMF 746 and UPF 748, which were described with respect to a 5G system in Figure 7. The upgrades provided by the Comm CF 1028 and the Comm SF 1038 may enable service-aware transport. For legacy (e.g., 4G or 5G) data transport, SMF 746 and UPF 748 may still be used.

Two other such functions may include a Data Control Function (Data CF) 1022 and Data Service Function (Data SF) 1032 may be parts of the Data Service Plane. Data CF 1022 may be a control plane function and provides functionalities such as Data SF 1032 management, Data service creation/configuration/releasing, Data service context management, etc. Data SF 1032 may be a user plane function and serve as the gateway between data service users (such as UE 1002 and the various functions of the 6G CN 1010) and data service endpoints behind the gateway. Specific functionalities may include include: parse data service user data and forward to corresponding data service endpoints, generate charging data, report data service status.

Another such function may be the Service Orchestration and Chaining Function (SOCF) 1020, which may discover, orchestrate and chain up communication/computing/data services provided by functions in the network. Upon receiving service requests from users, SOCF 1020 may interact with one or more of Comp CF 1024, Comm CF 1028, and Data CF 1022 to identify Comp SF 1036, Comm SF 1038, and Data SF 1032 instances, configure service resources, and generate the service chain, which could contain multiple Comp SF 1036, Comm SF 1038, and Data SF 1032 instances and their associated computing endpoints. Workload processing and data movement may then be conducted within the generated service chain. The SOCF 1020 may also responsible for maintaining, updating, and releasing a created service chain.

Another such function may be the service registration function (SRF) 1014, which may act as a registry for system services provided in the user plane such as services provided by service endpoints behind Comp SF 1036 and Data SF 1032 gateways and services provided by the UE 1002. The SRF 1014 may be considered a counterpart of NRF 754, which may act as the registry for network functions.

Other such functions may include an evolved service communication proxy (eSCP) and service infrastructure control function (SICF) 1026, which may provide service communication infrastructure for control plane services and user plane services. The eSCP may be related to the service communication proxy (SCP) of 5G with user plane service communication proxy capabilities being added. The eSCP is therefore expressed in two parts: eCSP-C 1012 and eSCP- U 1034, for control plane service communication proxy and user plane service communication proxy, respectively. The SICF 1026 may control and configure eCSP instances in terms of service traffic routing policies, access rules, load balancing configurations, performance monitoring, etc.

Another such function is the AMF 1044. The AMF 1044 may be similar to 744, but with additional functionality. Specifically, the AMF 1044 may include potential functional repartition, such as move the message forwarding functionality from the AMF 1044 to the RAN 1008.

Another such function is the service orchestration exposure function (SOEF) 1018. The SOEF may be configured to expose service orchestration and chaining services to external users such as applications.

The UE 1002 may include an additional function that is referred to as a computing client service function (comp CSF) 1004. The comp CSF 1004 may have both the control plane functionalities and user plane functionalities, and may interact with corresponding network side functions such as SOCF 1020, Comp CF 1024, Comp SF 1036, Data CF 1022, and/or Data SF 1032 for service discovery, request/response, compute task workload exchange, etc. The Comp CSF 1004 may also work with network side functions to decide on whether a computing task should be run on the UE 1002, the RAN 1008, and/or an element of the 6G CN 1010.

The UE 1002 and/or the Comp CSF 1004 may include a service mesh proxy 1006. The service mesh proxy 1006 may act as a proxy for service-to-service communication in the user plane. Capabilities of the service mesh proxy 1006 may include one or more of addressing, security, load balancing, etc.

EXAMPLE PROCEDURES

In some embodiments, the electronic device(s), network(s), system(s), chip(s) or component(s), or portions or implementations thereof, of Figures 7-10, or some other figure herein, may be configured to perform one or more processes, techniques, or methods as described herein, or portions thereof. One such process is depicted in Figure 11. For example, the process may include, at 1101 , transmitting, to an ambient - Internet of Things (A-IoT) device, a control message that indicates configuration information for a data packet. The configuration information may include an MCS, a TBS, and/or a length of the data packet. In some embodiments, the configuration information may additionally or alternatively include time and/or frequency information for the data packet. At 1102, the process may further include transmitting the data packet to the A-IoT device, or receiving the data packet from the A-IoT device, in accordance with the configuration information. The data packet may immediately follow the control message or may follow after a time/scheduling gap from the control message (which may be indicated in the control message).

In some embodiments, the method of Figure 11 may be performed by a gNB, a UE, and/or another intermediate node (e.g., a relay, an IAB node, a repeater, etc.).

Figure 12 illustrates another example process in accordance with various embodiments. At 1201, the process may include generating carrier wave signal based on a sequence. At 1202, the process may further include transmitting the carrier wave signal to an ambient Internet of Things (A-IoT) device.

The carrier wave signal may be used by the A-IoT device to perform backscattering for an uplink transmission. In some embodiments, the method of Figure 11 may be performed by a gNB, a UE, and/or another intermediate node (e.g., a relay, an IAB node, a repeater, etc.).

Figure 13 depicts an alternative example process that may be performed by a reader in a cellular network, one or more elements of a reader, and/or one or more electronic devices that include and/or implement a reader. In some embodiments, the reader may be, or may be a part of, a UE. In some embodiments, the reader may be, or may be a part of, a base station. The process may include identifying, at 1301 by the reader, a parameter related to an ambient internet of things (A-IoT) transmission that is to be transmitted by an A-IoT device; transmitting, at 1302 to the A-IoT device, an indication of the parameter; and identifying, at 1303 from the A-IoT device, an A-IoT transmission based on the parameter.

Figure 14 depicts an alternative example process that may be performed by an ambient internet of things (A-IoT) device, one or more elements of an A-IoT device, and/or one or more electronic devices that include and/or implement an A-IoT device. The process may include identifying, at 1401 from a reader of a cellular network, a parameter related to an ambient internet of things (A-IoT) transmission that is to be transmitted by the A-IoT device; and encoding, at 1402 by the A-IoT device, the A-IoT transmission based on the parameter.

For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, and/or methods as set forth in the example section below. For example, the baseband circuitry as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below. For another example, circuitry associated with a UE, base station, network element, etc. as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below in the example section.

EXAMPLES

Example 1 may include a method comprising: indicating, by a gNB or a UE, a modulation and coding scheme (MCS) and/or length of data packet in a control message; and transmitting, by the gNB or the UE, a data packet in accordance with the indicated MCS and/or length of data packet.

Example 2 may include the method of example 1 and/or some other example herein, wherein information for MCS and/or TBS or length of data packet may be carried by preambles.

Example 3 may include the method of example 1 and/or some other example herein, wherein when the length of data packet is 0, this may indicate that the data packet portion of transmission is not present.

Example 4 may include the method of example 1 and/or some other example herein, wherein identifier(s) that are associated with gNB, or UE, or A-IoT device, or combination of the nodes may be explicitly included in the control command for scheduling of DL and/or UL data packet or implicitly included in the control command. Example 5 may include the method of example 1 and/or some other example herein, wherein for scheduling of UL packet, a scheduling delay may be included in the control command or pre-defined in the specifications.

Example 6 may include the method of example 1 and/or some other example herein, wherein for A-IoT applications, a control message may include acknowledgement (ACK) information when the receiver correctly decodes the DL or UL packet.

Example 7 may include the method of example 1 and/or some other example herein, wherein a control message may include NACK information when the receiver fails to decode a DL or UL packet successfully.

Example 8 may include the method of example 1 and/or some other example herein, wherein ACK and/or NACK information may be conveyed explicitly or implicitly using the data channel itself.

Example 9 may include the method of example 1 and/or some other example herein, wherein ACK and/or NACK information could be indirectly inferred from message sequence index that may be sent in the control message or data message.

Example 10 may include the method of example 1 and/or some other example herein, wherein for scheduling of DL packet, acknowledgment delay may be included in the control command.

Example 11 may include the method of example 1 and/or some other example herein, wherein A-IoT devices that generate internally for the UL transmission, the frequency domain resource allocation may be included in the control message that schedules the UL transmission.

Example 12 may include the method of example 1 and/or some other example herein, wherein after encoding, data packet may be scrambled with a scrambling sequence, wherein the scrambling sequence may be initialized with an initialization seed, which is defined as a function of one or more of: gNB, UE and/or A-IoT device ID.

Example 13 may include the method of example 1 and/or some other example herein, wherein for topology 2, when UE transmits the DL packet or control message to A-IoT, which may also include preamble, the DL transmission timing for A-IoT applications follows the DL transmission timing in NR.

Example 14 may include the method of example 1 and/or some other example herein, wherein for topology 2, when UE transmits the DL packet or control message to A-IoT, which may also include preamble, the DL transmission timing for A-IoT applications follows the UL transmission timing in NR. Example 15 may include the method of example 1 and/or some other example herein, wherein for topology 2, for A-IoT devices that are capable of generating the UL transmission internally, the UL transmission timing follows the DL transmission timing from the intermediate UE.

Example 16 may include the method of example 1 and/or some other example herein, wherein a fixed sequence may be generated for carrier wave signal, where the fixed sequence may be predefined in the specification.

Example 17 may include the method of example 1 and/or some other example herein, wherein pseudo-random sequence may be generated for carrier wave signal, where the pseudorandom sequence may be generated in accordance with the gNB and/or UE ID and/or an ID that is configured by higher layers via RRC signalling.

Example 18 may include the method of example 1 and/or some other example herein, wherein the carrier wave generated based on OFDM symbol framework is up-converted with a carrier phase that does not reset as a function of OFDM symbol index or location.

Example 19 may include the method of example 1 and/or some other example herein, wherein carrier wave signal may occupy one or more subcarriers in the frequency domain, wherein in case of multiple subcarriers, they may map to contiguous subcarriers in frequency or be mapped using subcarrier-selection or subcarrier-hopping wherein a subset (e.g., one) of the available subcarriers are utilized at a time with or without application of a time hopping pattern that may be predefined.

Example 20 may include the method of example 1 and/or some other example herein, wherein for UL transmission from A-IoT devices that perform backscattering for the UL transmission, the A-IoT devices may expect that the carrier wave signal is present after the A- loT devices receive the DL packet or control message.

Example 21 may include the method of example 1 and/or some other example herein, wherein dedicated sequences may be defined for representing ACK and/or NACK messages, respectively.

Example 22 may include the method of example 1 and/or some other example herein, wherein one field may be included in the control command to indicate whether the A-IoT device transmits the device-to-reader (D2R) signal/channel in the upper side or lower side relative to the frequency location of carrier wave signal.

Example 23 may include the method of example 1 and/or some other example herein, wherein whether frequency shifter is implemented in an A-IoT device can be indicated in the D2R message during random access procedure. Example 24 may include the method of example 1 and/or some other example herein, wherein for A-IoT initiated D2R transmission, a scheduling request message may be included in the control command.

Example 25 may include a method comprising: transmitting, to an ambient - Internet of Things (A-IoT) device, a control message that indicates configuration information for a data packet; and transmitting the data packet to the A-IoT device, or receiving the data packet from the A- loT device, in accordance with the configuration information.

Example 26 may include the method of example 25 and/or some other example herein, wherein the configuration information includes a modulation and coding scheme (MCS), a transport block size (TBS), and/or a length of the data packet.

Example 27 may include the method of example 25-26 and/or some other example herein, wherein at least some of the configuration information is included in a preamble of the control message.

Example 28 may include the method of example 25-27 and/or some other example herein, wherein the data packet immediately follows the control message in a time domain.

Example 29 may include the method of example 25-27 and/or some other example herein, wherein the data packet is transmitted after a time gap from the control message.

Example 30 may include the method of example 29 and/or some other example herein, wherein the time gap is predefined or indicated in the control message.

Example 31 may include the method of example 25-30 and/or some other example herein, wherein the configuration information includes a gNB ID or a UE ID associated with the data packet.

Example 32 may include the method of example 25-31 and/or some other example herein, wherein the configuration information further indicates a time at which the A-IoT device is to send an acknowledgement message if it successfully receives the data packet.

Example 33 may include the method of example 32 and/or some other example herein, wherein the time is indicated as a scheduling delay from the control message or the data packet.

Example 34 may include the method of example 25-33 and/or some other example herein, wherein the configuration information includes a frequency domain resource allocation for the data packet.

Example 35 may include the method of example 25-34 and/or some other example herein, further comprising scrambling the data packet with a scrambling sequence after encoding, wherein the scrambling sequence is initialized with an initialization seed, and wherein the initialization seed is a function of one or more of a gNB ID, a UE ID, and/or A-IoT device ID.

Example 36 may include the method of example 25-35 and/or some other example herein, wherein the data packet is a downlink (DL) data packet with a transmission timing that corresponds to a DL transmission timing or an uplink (UL) transmission timing used for New Radio (NR) communication.

Example 37 may include the method of example 25-37 and/or some other example herein, wherein the method is performed by a gNB, a UE, and/or another intermediate node.

Example 38 may include a method comprising: generating carrier wave signal based on a sequence; and transmitting the carrier wave signal to an ambient Internet of Things (A-IoT) device.

Example 39 may include the method of example 38 and/or some other example herein, wherein the sequence is a fixed sequence that is predefined.

Example 40 may include the method of example 38 and/or some other example herein, wherein the sequence is a pseudo-random sequence.

Example 41 may include the method of example 40 and/or some other example herein, wherein the pseudo-random sequence is generated based on a gNB ID, a UE ID, and/or another ID that is configured (e.g., via RRC signaling).

Example 42 may include the method of example 38-41 and/or some other example herein, wherein generating the carrier wave signal includes upconverting a carrier wave generated based on an OFDM symbol framework with a carrier phase that does not reset as a function of an OFDM symbol index or location.

Example 43 may include the method of example 38-42 and/or some other example herein, wherein the carrier wave signal occupies one or more subcarriers in the frequency domain.

Example 44 may include the method of example 43 and/or some other example herein, wherein the carrier wave signal is mapped to multiple, contiguous carriers in the frequency domain.

Example 45 may include the method of example 43 and/or some other example herein, wherein the carrier wave signal is mapped to multiple subcarriers using subcarrier-selection or subcarrier-hopping wherein a subset (e.g., one) of available subcarriers are utilized at a time with or without application of a time hopping pattern.

Example 46 may include the method of example 38-45 and/or some other example herein, wherein the carrier wave signal is transmitted after transmission of a control message and/or a downlink packet to the A-IoT device. Example 47 may include the method of example 38-46 and/or some other example herein, wherein the carrier wave signal is to be used by the A-IoT device to perform backscattering for an uplink transmission.

Example 48 may include the method of example 38-47 and/or some other example herein, wherein the sequence is an ACK sequence dedicated to represent an ACK or a NACK sequence dedicated to represent a NACK.

Example 49 may include the method of example 38-48 and/or some other example herein, wherein the method is performed by a gNB, a UE, and/or another intermediate node.

Example 50 may include a method of an A-IoT device, the method comprising: receiving a control command that indicates whether the A-IoT device is to transmit a device-to-reader (D2R) signal/channel in an upper side or a lower side relative to a frequency of a carrier wave signal; and transmitting the D2R signal/channel in accordance with the indication.

Example 51 may include the method of example 50 and/or some other example herein, further comprising sending a message to indicate whether the A-IoT implements a frequency shifter.

Example 52 may include the method of example 51 and/or some other example herein, wherein the message is part of a random access procedure.

Example 53 may include a method of an A-IoT device, the method comprising: sending a control command that includes a scheduling request for a D2R transmission; transmitting the D2R transmission in accordance with the scheduling request.

Example 54 may include the method of example 53 and/or some other example herein, further comprising receiving, based on the scheduling request, a scheduling message to schedule the D2R transmission.

Example 55 may include the method of example 53-54 and/or some other example herein, wherein the scheduling request corresponds to a dedicated sequence for scheduling requests.

Example 56 may include the method of example 55 and/or some other example herein, wherein the dedicated sequence is predefined or configured.

Example 57 includes a method to be performed by a reader in a cellular network, one or more elements of a reader, and/or one or more electronic devices that include and/or implement a reader, wherein the method comprises: identifying, by the reader, a parameter related to an ambient internet of things (A-IoT) transmission that is to be transmitted by an A-IoT device; transmitting, to the A-IoT device, an indication of the parameter; and identifying, from the A- loT device, an A-IoT transmission based on the parameter. Example 58 includes the method of example 57, and/or one or more other examples herein, wherein the reader is a base station or a user equipment (UE).

Example 59 includes the method of any one or more of examples 57-58, and/or one or more other examples herein, wherein the indication of the parameter is an indication of a time domain resource that is to be used for the A-IoT transmission.

Example 60 includes the method of any one or more of examples 57-59, and/or one or more other examples herein, wherein the indication of the parameter is an indication of a frequency domain resource that is to be used for the A-IoT transmission.

Example 61 includes the method of example 60, and/or one or more other examples herein, wherein the indication of the frequency domain resource is an indication of a frequency shift compared to a carrier wave.

Example 62 includes the method of any one or more of examples 57-61, and/or one or more other examples herein, wherein the parameter relates to a modulation coding scheme (MCS) to be used for the A-IoT transmission.

Example 63 includes the method of any one or more of examples 57-62, and/or one or more other examples herein, wherein the parameter is an identifier (ID) related to the reader.

Example 64 includes the method of any one or more of examples 57-63, and/or one or more other examples herein, wherein the parameter is an identifier (ID) related to the A-IoT device.

Example 65 includes the method of any one or more of examples 57-64, and/or one or more other examples herein, wherein the indication of the parameter is carried in a control command related to the A-IoT device.

Example 66 includes the method of any one or more of examples 57-65, and/or one or more other examples herein, wherein the indication of the parameter is carried in a preamble associated with a control command that is related to the A-IoT device.

Example 67 includes a method to be performed by an ambient internet of things (A-IoT) device, one or more elements of an A-IoT device, and/or one or more electronic devices that include and/or implement an A-IoT device, wherein the method comprises: identifying, from a reader of a cellular network, an indication of a parameter related to an ambient internet of things (A-IoT) transmission that is to be transmitted by the A-IoT device; and encoding, by the A-IoT device, the A-IoT transmission based on the parameter.

Example 68 includes the method of example 67, and/or one or more other examples herein, wherein the reader is a base station or a user equipment (UE). Example 69 includes the method of any one or more of examples 67-68, and/or one or more other examples herein, wherein the indication of the parameter is an indication of a time domain resource that is to be used for the A-IoT transmission.

Example 70 includes the method of any one or more of examples 67-69, and/or one or more other examples herein, wherein the indication of the parameter is an indication of a frequency domain resource that is to be used for the A-IoT transmission.

Example 71 includes the method of example 70, and/or one or more other examples herein, wherein the indication of the frequency domain resource is an indication of a frequency shift compared to a carrier wave.

Example 72 includes the method of any one or more of examples 67-71, and/or one or more other examples herein, wherein the parameter relates to a modulation coding scheme (MCS) to be used for the A-IoT transmission.

Example 73 includes the method of any one or more of examples 67-72, and/or one or more other examples herein, wherein the parameter is an identifier (ID) related to the reader.

Example 74 includes the method of any one or more of examples 67-73, and/or one or more other examples herein, wherein the parameter is an identifier (ID) related to the A-IoT device.

Example 75 includes the method of any one or more of examples 67-74, and/or one or more other examples herein, wherein the indication of the parameter is carried in a control command related to the A-IoT device.

Example 76 includes the method of any one or more of examples 67-75, and/or one or more other examples herein, wherein the indication of the parameter is carried in a preamble associated with a control command that is related to the A-IoT device.

Example Z01 may include an apparatus comprising means to perform one or more elements of a method described in or related to any of examples 1-76, and/or any other method or process described herein.

Example Z02 may include one or more non-transitory computer-readable media comprising instructions to cause an electronic device, upon execution of the instructions by one or more processors of the electronic device, to perform one or more elements of a method described in or related to any of examples 1-76, and/or any other method or process described herein.

Example Z03 may include an apparatus comprising logic, modules, or circuitry to perform one or more elements of a method described in or related to any of examples 1-76, and/or any other method or process described herein. Example Z04 may include a method, technique, or process as described in or related to any of examples 1-76, and/or portions or parts thereof.

Example Z05 may include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1-76, and/or portions thereof.

Example Z06 may include a signal as described in or related to any of examples 1-76, or portions or parts thereof.

Example Z07 may include a datagram, packet, frame, segment, protocol data unit (PDU), or message as described in or related to any of examples 1-76, and/or portions or parts thereof, or otherwise described in the present disclosure.

Example Z08 may include a signal encoded with data as described in or related to any of examples 1-76, and/or portions or parts thereof, or otherwise described in the present disclosure.

Example Z09 may include a signal encoded with a datagram, packet, frame, segment, protocol data unit (PDU), or message as described in or related to any of examples 1-76, and/or portions or parts thereof, or otherwise described in the present disclosure.

Example Z10 may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors is to cause the one or more processors to perform the method, techniques, or process as described in or related to any of examples 1-76, and/or portions thereof.

Example Zll may include a computer program comprising instructions, wherein execution of the program by a processing element is to cause the processing element to carry out the method, techniques, or process as described in or related to any of examples 1-76, and/or portions thereof.

Example Z12 may include a signal in a wireless network as shown and described herein.

Example Z13 may include a method of communicating in a wireless network as shown and described herein.

Example Z14 may include a system for providing wireless communication as shown and described herein.

Example Z15 may include a device for providing wireless communication as shown and described herein.

Any of the above-described examples may be combined with any other example (or combination of examples), unless explicitly stated otherwise. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

5

Claims

1. An electronic device for use in a user equipment (UE) of a cellular network, wherein the electronic device comprises: memory to store a parameter related to an ambient internet of things (A-IoT) transmission that is to be transmitted by an A-IoT device; and one or more processors configured to: encode, for transmission to the A-IoT device, an indication of the parameter; and identify, from the A-IoT device, a received A-IoT transmission based on the parameter.

2. The electronic device of claim 1 , wherein the indication of the parameter is an indication of a time domain resource that is to be used for the A-IoT transmission.

3. The electronic device of claim 1, wherein the indication of the parameter is an indication of a frequency domain resource that is to be used for the A-IoT transmission.

4. The electronic device of claim 3, wherein the indication of the frequency domain resource is an indication of a frequency shift compared to a carrier wave.

5. The electronic device of any of claims 1-4, wherein the parameter relates to a modulation coding scheme (MCS) to be used for the A-IoT transmission.

6. The electronic device of any of claims 1-4, wherein the parameter is an identifier (ID) related to the UE.

7. The electronic device of any of claims 1-4, wherein the parameter is an identifier (ID) related to the A-IoT device.

8. The electronic device of any of claims 1-4, wherein the indication of the parameter is carried in a control command related to the A-IoT device.

9. The electronic device of any of claims 1-4, wherein the indication of the parameter is carried in a preamble associated with a control command that is related to the A-IoT device.

10. One or more computer-readable media comprising instructions that, upon execution of the instructions by one or more processors of an electronic device, are to cause an ambient internet of things (A-IoT) device to: identify, from a reader of a cellular network, a parameter related to an ambient internet of things (A-loT) transmission that is to be transmitted by the A-loT device; and encode, by the A-loT device, the A-loT transmission based on the parameter.

11. The one or more computer-readable media of claim 10, wherein the parameter includes an indication of a time domain resource or a frequency domain resource that is to be used for the A-loT transmission.

12. The one or more computer-readable media of claim 10, wherein the parameter relates to a modulation coding scheme (MCS) to be used for the A-loT transmission.

13. The one or more computer-readable media of claim 10, wherein the parameter is an identifier (ID) related to the reader or an ID related to the A-loT device.

14. The one or more computer-readable media of any of claims 10-13, wherein the parameter is carried in a control command related to the A-loT device.

15. The one or more computer-readable media of any of claims 10-13, wherein the parameter is carried in a preamble associated with a control command that is related to the A- loT device.

16. One or more computer-readable media comprising instructions that, upon execution of the instructions by one or more processors of an electronic device, are to cause a reader of a cellular network to: identify a parameter related to an ambient internet of things (A-loT) transmission that is to be transmitted by an A-loT device; encode, for transmission to the A-loT device, an indication of the parameter; and identify, from the A-loT device, a received A-loT transmission based on the parameter.

17. The one or more computer-readable media of claim 16, wherein the indication of the parameter is an indication of a time domain resource or a frequency domain resource that is to be used for the A-loT transmission.

18. The one or more computer-readable media of any of claims 16-17, wherein the indication of the parameter is carried in a control command related to the A-IoT device.

19. The one or more computer-readable media of any of claims 16-17, wherein the indication of the parameter is carried in a preamble associated with a control command that is related to the A-IoT device.

20. The one or more computer-readable media of any of claims 16-17, wherein the reader is a base station or a user equipment (UE) of a cellular network.