AMBIENT INTERNET-OF-THINGS (IoT) MEDIUM ACCESS CONTROL (MAC) DESIGN

Abstract

Disclosed are methods, systems, and computer-readable medium to perform operations including: receiving, from a reader and by an Ambient Internet-of-Things (A-IoT) device, a paging medium access control (MAC) protocol data unit (PDU); determining that the paging MAC PDU is addressed to the A-IoT device; responsively initiating a random access procedure with the reader to establish a communication channel; and transmitting an uplink (UL) MAC PDU to the reader via the communication channel.

Description

Ambient Internet-of-Things (IoT) Medium access control (MAC) DesignBACKGROUND

[0001] Wireless communication networks provide integrated communication platforms and telecommunication services to wireless user devices. Example telecommunication services include telephony, data (e.g., voice, audio, and / or video data) , messaging, and / or other services. The wireless communication networks have wireless access nodes that exchange wireless signals with the wireless user devices using one or more wireless network protocols, such as protocols described in various telecommunication standards promulgated by the ETSI Third Generation Partnership Project (3GPP) . The wireless communication networks facilitate mobile broadband service using technologies such as orthogonal frequency-division multiple access (OFDMA) , multiple input multiple output (MIMO) , advanced channel coding, massive MIMO, beamforming, and / or other features.

[0002] Internet-of-Things (IoT) technology allows a variety of devices to be wirelessly connected to an IoT reader via a communication network. For example, a radio frequency identification (RFID) tag may be wirelessly connected to an RFID reader such that the reader can obtain information from the tag and pass the information to a server for processing. The IoT reader can be a base station, e.g., a g-Node B (gNB) , that provides cellular services to communicate with the IoT device, or can be a user equipment (UE) that communicates with the IoT device in a wireless network provided by a base station.SUMMARY

[0003] In accordance with one aspect of the present disclosure, a method involves receiving, from a reader and by an Ambient Internet-of-Things (A-IoT) device, a paging medium access control (MAC) protocol data unit (PDU) ; determining that the paging MAC PDU is addressed to the A-IoT device; responsively initiating a random access procedure with the reader to establish a communication channel; and transmitting an uplink (UL) MAC PDU to the reader via the communication channel.

[0004] Other versions include corresponding systems, a device that includes one or more processors, and computer programs to perform the actions of methods defined by instructions encoded on computer readable storage devices (memory) . These and other versions may optionally include one or more of the following features.

[0005] In some implementations, the paging MAC PDU includes at least one of a control header, an address field, a UL grant, or a data field.

[0006] In some implementations, a format of the paging MAC PDU matches a format of a downlink (DL) data MAC PDU.

[0007] In some implementations, the control header includes at least one of a protocol version, a message type, or an acknowledgement bit.

[0008] In some implementations, the message type is: (i) data, (ii) paging, (iii) paging and data, or (iv) a random access procedure message.

[0009] In some implementations, the UL grant includes at least one of time resources or frequency resources for an upcoming UL transmission.

[0010] In some implementations, the UL grant is a shared UL grant or a dedicated UL grant.

[0011] In some implementations, the UL MAC PDU includes a control header and a data field.

[0012] In some implementations, the control header includes a protocol version, a message type, an acknowledgement bit, an energy status alert indication, and a last segment / additional data indication.

[0013] In some implementations, the A-IoT device does not support UL data segmentation, and where transmitting the uplink MAC PDU to the reader device involves: transmitting UL data up to a predetermined transport block (TB) size; and setting an additional data bit in the UL MAC PDU to 0.

[0014] In some implementations, the A-IoT device supports UL data segmentation, and where transmitting the uplink MAC PDU to the reader device involves determining whether UL data for transmission fits into a predetermined transport block size; if the UL data fits into the predetermined TB size: transmitting the UL data in a TB; and setting an additional data bit in the UL MAC PDU to 0.

[0015] In some implementations, the method further involves if the UL data does not fit into the predetermined TB size: transmitting a first portion of the UL data in the TB; storing the first portion of the UL data in memory; and setting the additional data bit in the UL MAC PDU to 1.

[0016] In some implementations, the method further involves receiving, from the reader device, a NACK in response to the uplink MAC PDU; and retransmitting the first portion of the UL data to the reader device.

[0017] In some implementations, the paging MAC PDU includes a single paging address field indicating the address of the UE and where determining that the paging MAC PDU is addressed to the A-IoT device involves determining that the single paging address field indicates the address of the A-IoT device.

[0018] In some implementations, the paging PDU includes a plurality of device field groups, each device field group including: a paging address field indicating an address of a respective A-IoT device corresponding to the device field group; and a paging UL grant field indicating a quantity of uplink resources allocated for the respective A-IoT device, and where determining that the paging MAC PDU is addressed to the A-IoT device involves identifying a device field group including a paging address field indicating the address of the A-IoT device.

[0019] In some implementations, the paging MAC PDU includes a single paging address field, and where determining that the paging MAC PDU is addressed to the A-IoT device involves determining that an address within the single paging address field is indicative of a broadcast message.

[0020] In some implementations, at least one of the paging MAC PDU and the UL MAC PDU have a fixed control header format, where the fixed control header format specifies a corresponding location within a control header for each field in the control header.

[0021] The details of one or more embodiments of these systems and methods are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of these systems and methods will be apparent from the description and drawings, and from the claims. BRIEF DESCRIPTION OF THE FIGURES

[0022] FIG. 1 illustrates an example call flow between an A-IoT device and a reader device, according to some implementations.

[0023] FIG. 2A and FIG. 2B illustrate UL and DL MAC PDU formats, according to some implementations.

[0024] FIG. 3A illustrates an example UL control header, according to some implementations.

[0025] FIG. 3B illustrates an example DL control header, according to some implementations.

[0026] FIG. 4 illustrates a data field in a MAC PDU, according to some implementations.

[0027] FIG. 5 illustrates an example paging DL MAC PDU, according to some implementations.

[0028] FIG. 6 illustrates different topologies of A-IoT communications, according to some implementations.

[0029] FIG. 7 illustrates a flowchart of an example method, according to some implementations.

[0030] FIG. 8 illustrates an example user equipment (UE) , according to some implementations.

[0031] FIG. 9 illustrates an example access node, according to some implementations.

[0032] FIG. 10 illustrates an example A-IoT device, according to some implementations.DETAILED DESCRIPTION

[0033] An Ambient IoT (A-IoT) device is an IoT device that supports harvesting energy from the environment, e.g., by backscattering carrier waves external to the A-IoT device, to support its communications with an A-IoT reader (also referred to herein as “reader” or “reader device” ) . Depending on the capacity to power wireless transmissions, there are multiple types of A-IoT devices. Depending on the A-IoT reader, an A-IoT device can be implemented according to multiple topologies. And depending on the application of the A-IoT device, there are multiple types of A-IoT traffic. Accordingly, it is desirable to have a harmonized air interface capable of supporting a variety of A-IoT implementations.

[0034] Medium access control (MAC) layer is an important component of the A-IoT protocol stack. When designing the MAC layer for A-IoT, a number of factors and constraints are considered. For example, different from many user devices in cellular communications, an A-IoT device typically runs only one application or communicates for only one purpose at a time. This means that the A-IoT device usually does not generate a large amount of traffic with high complexity. Also, due to an A-IoT device’s reliance on external energy harvesting, the power to support A-IoT transmissions is usually limited and may be drained after only a small number of receptions and transmissions. This means that the A-IoT device usually cannot support a large number of continuous receptions and transmissions. Additionally, an A-IoT device often has registers of volatile memory to store certain information, such as a temporary identifier (ID) . Because the volatile memory requires power to retain its stored information, power efficiency may affect the A-IoT device’s ability to continuously operate.

[0035] Some the high-level principles guiding the design of the MAC layer for the A-IoT protocol stack include: (1) the MAC layer is used as the single protocol for control and data messaging, (2) MAC protocol data units (PDUs) carry a MAC header and optionally an A-IoT payload / service data unit (SDU) , (3) no notion of a Logical Channel Identifier (LCID) or a MAC Control Element (MAC CE) , (4) no assumption of capability signaling, (5) a fixed MAC header length (where possible) , (5) a fixed control bit assignment in the MAC header, and (6) common (to different messages) formats (where possible) . Note that departure from these principles is possible in certain scenarios.

[0036] In line with these principles, this disclosure provides MAC design solutions for uplink (UL) and downlink (DL) communications in a wireless network that includes an A-IoT device and a reader device. Among other things, the MAC design solutions for UL communications include a MAC PDU format for UL messages from the A-IoT device to the reader device. The UL messages can include data messages, acknowledgement messages, and / or random access messages (e.g., “msg1” or “msg3” ) . And among other things, the MAC design solutions for DL communications include a MAC PDU format for DL messages from the reader device to the A-IoT device. The DL messages can include paging messages, random access messages (e.g., “msg2” or “msg4” ) , and / or data messages.

[0037] Before discussing the MAC design solutions, it is helpful to understand how an A-IoT device and a reader device establish communication and exchange messages. To that end, FIG. 1 illustrates an example call flow between an A-IoT device and a reader device.

[0038] FIG. 1 illustrates an example call flow 100 between an A-IoT device 102 and a reader device 104, according to some implementations. In this example, the A-IoT device 102 can be similar to A-IoT device 1000 of FIG. 10. The A-IoT device 102 is an ultra-low-power or battery-less device that communicates by harvesting energy from ambient sources (e.g., radio waves) and using backscatter communication to reflect signals rather than generating its own signals. The A-IoT device 102 is designed for applications such as inventory tracking, environmental sensing, and smart monitoring. In some examples, the A-IoT device 102 may either passively reflect signals (Type 1) , amplify backscattered signals (Type 2a) , or actively generate its own transmissions (Type 2b) . The A-IoT device can communicate with the reader device 104 over a Physical Device-to-Reader Channel.

[0039] The reader device 104 can be similar to UE 800 of FIG. 8 or can be similar to base station 900 of FIG. 9. The reader device 104 is responsible for initiating communication, providing a carrier wave for backscatter-based devices, and / or receiving and decoding the signals transmitted by the Ambient IoT devices over the PDRCH. The reader device 104 also manages synchronization, error correction, and network coordination, ensuring reliable data exchange in an asynchronous, low-power IoT environment. Further, the reader device 104 can communicate with the A-IoT device 102 over a Physical Reader-to-Device Channel (PRDCH) .

[0040] Within examples, the PRDCH and PDRCH are air interface channels that enable communicative coupling. These physical channels enable a Layer 2 (L2) communication protocol designed for Ambient IoT.

[0041] As shown in FIG. 1, the A-IoT device 102 receives a carrier wave (CW) 106 that instructs the A-IoT device 102 to power on. In some examples, the CW 106 can additionally serve as the energy source for the A-IoT device 102. In response to receiving the CW 106, the A-IoT device 102 powers on at step 108. Note that not all A-IoT devices require CWs to operate. After powering on, the A-IoT device 102 awaits a paging message from a reader. In this example, the A-IoT device 102 receives a paging message 110 from the reader device 104. As will be discussed below, the paging message 110 can optionally include data sent to the A-IoT device 102. In response to receiving the paging message 110, the A-IoT device 102 and the reader device 104 initiate a random access procedure 112 that establishes a connection between the devices.

[0042] Once the connection is established, the A-IoT device 102 and the reader device 104 can communicate. For example, as shown in FIG. 1, the A-IoT device 102 can send UL data 114a to the reader device 104, perhaps using an UL grant that was received in the random access procedure 112. As will be discussed below, the UL data from the A-IoT device 102 can be segmented or unsegmented data. In response to receiving the UL data, the reader device 104 can send the A-IoT device 102 an acknowledgment message 114b that informs the A-IoT device 102 whether the UL data was received. The communication between the A-IoT device 102 and the reader device 104 can continue until the A-IoT device 102 completes its UL data transmissions, the reader device 104 completes its DL data transmission, or the A-IoT device 102 powers off. Note that this call flow is merely an example call flow between the A-IoT device 102 and the reader device 104. Other examples are possible and are contemplated herein.

[0043] In line with the discussion above, this disclosure provides MAC design solutions for UL and DL communications in a wireless network that includes an A-IoT device, e.g., the A-IoT device 102, and a reader device, e.g., the reader device 104. As discussed in more detail below, the UL messages can include data messages (e.g., UL data 114a) , acknowledgement messages (e.g., in response to data received from the reader device 104) , and / or random access messages (e.g., “msg1” or “msg3” ) used in random access procedure 112. And the DL messages can include paging messages (e.g., paging message 110) , random access messages (e.g., “msg2” or “msg4” ) used in random access procedure 112, and / or data messages.

[0044] FIG. 2A and FIG. 2B illustrate UL and DL MAC PDU formats, according to some implementations. Although these formats are for data, they can be aligned (to the extent possible) with formats for other types of messages. In some examples, at least the control header (and its bit assignment) is fixed and the format is common to all message types. A fixed header format is one in which a control bit (e.g., ACK / NACK) is always in the same location in the header. Additionally, the data field can have a variable length (including 0) .

[0045] FIG. 2A illustrates an UL MAC PDU format 200. As shown in FIG. 2A, the UL MAC PDU format 200 includes a control header 202 and a data field 204. As stated, the control header 202 (and its bit assignment) can be fixed and can share its format with all message types in the disclosed MAC design solutions. As also stated, the data field 204 can have a variable length (including 0) . The A-IoT device 102 is configured to use the UL MAC PDU format 200 for communicating with the reader device 104. For example, the A-IoT device 102 can use the UL MAC PDU format 200 for UL data messages (e.g., UL data 114a) sent to the reader device 104.

[0046] FIG. 2B illustrates a DL MAC PDU format 210. As shown in FIG. 2B, the DL MAC PDU format 210 includes a header field 212, an address field 214, a UL grant 216, and a data field 218. As stated, the control header 212 (and its bit assignment) can be fixed and can share its format with all message types in the disclosed MAC design solutions. As also stated, the data field 214 can have a variable length (including 0) . The fields of the MAC PDU formats are described in more detail below. The reader device 104 is configured to use the DL MAC PDU format 210 to communicate with the A-IoT device 102. For example, reader device 104 can use the DL MAC PDU format 210 for paging messages (e.g., paging message 110) and / or data messages to the A-IoT device 102.

[0047] In some implementations, the A-IoT device 102 is configured to handle UL transmissions, like the UL data 114a. If the A-IoT device 102 has UL data to transmit and the device has received a UL grant, the device behavior depends on whether the device supports UL segmentation or not. In scenarios where the A-IoT device 102 supports UL segmentation, if the (entire) UL data fits into a transport block (TB) , the device transmits the UL data and sets a “more data” bit to “0. ” And if the UL data does not fit into a TB, the A-IoT device 102 transmits UL data up to the TB size and sets the “more data” bit to “1. ” The transmitted UL data is referred to as the “last segment, ” which the A-IoT device 102 stores in device memory. The A-IoT device 102 repeats this procedure until the UL data transmission is complete. In scenarios where the A-IoT device 102 does not support UL segmentation, then the device transmits UL data up to the TB size and sets the “more data” bit to “0. ”

[0048] In some implementations, the A-IoT device 102 is configured to handle DL transmissions, like paging message 110. When the A-IoT device 102 is powered on, the device listens to the PRDCH to detect DL messages from readers, like the reader device 104. The DL messages can be messages that include the A-IoT device 102’s address or can be broadcast messages. In scenarios where the A-IoT device 102 supports DL Automatic Repeat Request (ARQ) , for each successfully received DL message from the reader device 104, the device sends the reader a UL with ACK bit set (e.g., in the control header) . If the A-IoT device 102 has UL data to transmit to the reader device 104, both the UL data and ACK are sent together. Otherwise, the A-IoT device 102 only sends the ACK in a control header (and without any data in the message) . If the DL message is not successfully received, however, the A-IoT device 102 sends a NACK (in the same way as the ACK) . In scenarios where the A-IoT device 102 supports UL ARQ, and the device has a last segment stored in memory, if the device receives a NACK from the reader device 104, then the A-IoT device 102 retransmits the last segment.

[0049] FIG. 3A illustrates an example UL control header 300, according to some implementations. The UL control header 300 can be the control header 202 of FIG. 2A. That is, the UL control header 300 is the control header in a MAC PDU that the A-IoT device 102 sends to the reader device 104. In this example, the overall length of the UL control header 300 is 1 byte, but other examples are possible. As shown in FIG. 3A, the UL control header 300 includes Version (V) field 302, Message Type (T) field 304, ACK / NACK (A) bit 306, energy status alert indication (E) field 308, last segment / more data indication (S) field 310, and Reserve bit 312.

[0050] The Version 302 carries a protocol version that the A-IoT device 102 supports. In particular, the A-IoT device 102 sets the version that it supports when sending a UL message to the reader device 104. The Version 302 can have a fixed length, e.g., 2 bits.

[0051] The Message Type 304 specifies the type of UL message carrying the UL control header 300. The A-IoT device 102 sets the field according to the type of UL message that is being transmitted. Among other examples, the message type can be “data, ” “msg1, ” or “msg3. ” The Message Type 304 can have a fixed length, e.g., 2 bits.

[0052] The ACK / NACK bit 306 indicates ACK or NACK in response to a DL message sent by the reader device 104. In examples where the ACK / NACK bit 306 has a length of 1 bit, “1” can indicate ACK and “0” can indicate NACK, or vice versa. In scenarios where the A-IoT device 102 supports DL ARQ, the device sets the field based on whether the previously received DL message was received. Note that if the A-IoT device 102 does not support DL ARQ, then the bit 306 is Reserved (R) .

[0053] The energy status alert indication (E) field 308 indicates whether the remaining energy estimate is sufficient for more than the currently transmitted UL message. In examples where the field 308 has a length of 1 bit, “1” indicates that the remaining energy estimate is sufficient for more than the current message transmission and “0” indicates otherwise, or vice versa. Note that if the A-IoT device 102 does not support this feature, then the device can set the field to “1. ”

[0054] The last segment / more data indication (S) field 310 indicates whether the A-IoT device 102 has more data to transmit (if the A-IoT device 102 supports this feature) . In examples where the field 310 has a length of 1 bit, “1” indicates that the A-IoT device 102 has more data to transmit (beyond the current grant) and “0” indicates otherwise, or vice versa.

[0055] FIG. 3B illustrates an example DL control header 320, according to some implementations. The DL control header 320 can be the control header 212 of FIG. 2B. That is, the DL control header 320 is the control header in a MAC PDU that the reader device 104 sends to the A-IoT device 102. In this example, the overall length of the DL control header 320 is 1 byte, but other examples are possible. As shown in FIG. 3B, the DL control header 320 includes Version (V) field 322, Message Type (T) field 324, ACK / NACK (A) bit 326, and Reserve bit 328.

[0056] The Version 322 carries a protocol version set by the reader device 104. Upon receipt of a DL message, the A-IoT device 102 uses the Version 322 to determine whether the device supports the protocol version of the DL message. If the A-IoT device 102 does not support the protocol version, the device ignores the DL message. Otherwise, the A-IoT device 102 processes the rest of the DL message. The Version 322 can have a fixed length, e.g., 2 bits.

[0057] The Message Type 324 specifies the type of the message carrying the DL control header 320. Among other examples, the message type can be “data, ” “paging, ” “paging+data, ” “msg2, ” or “msg4” for ACK of “msg3” (no data) . In some examples, the A-IoT device 102 uses the Message Type 324 to determine how to respond to the DL message. If the DL message type is “data, ” then the A-IoT device 102 transfers the payload to the device’s “upper layers” for further processing. If the DL message type is “paging, ” then the A-IoT device 102 initiates a random access procedure. And if the message type is “paging+data, ” then the A-IoT device 102 transfers the payload to the “upper layers” and initiates a random access procedure. Note that for this message type, the A-IoT device 102 may hold the data until an authentication procedure is completed and authentication is confirmed (after paging) . The Message Type 324 can have a fixed length, e.g., 2 bits.

[0058] The ACK / NACK bit 326 indicates ACK or NACK in response to a UL message sent by the A-IoT device 102. In examples where the ACK / NACK bit 326 has a length of 1 bit, “1” can indicate ACK and “0” can indicate NACK, or vice versa. If NACK is received, the A-IoT device 102 retransmits the last segment stored in memory. And if ACK is received, the A-IoT device 102 discards the last (previously transmitted) segment stored in memory. Further, if the A-IoT device 102 has more data to transmit, the device initiates transmission of the next segment.

[0059] FIG. 4 illustrates a data field 400 in a MAC PDU, according to some implementations. The data field 400 can be data field 204 of FIG. 2A or data field 218 of FIG. 2B. That is, the data field 400 can be the data field in a UL MAC PDU or a DL MAC PDU. As shown in FIG. 4, the data field 400 includes a length field 402 and a payload / SDU 404. In some examples, the length field 402 may not be needed, perhaps if a physical layer (PHY) postamble (e.g., a predefined sequence of bits or symbols) is used instead. In some examples, the length of the data field 400 can be optimized using a lookup table. Further, the length can be 0 (e.g., for paging or ACK / NACK messages) . As discussed, if the payload / SDU includes data, then the device-whether the A-IoT device 102 or the reader device 104-transfers the payload to the upper layers for further processing.

[0060] In some implementations, the UL MAC PDU design includes two embodiments for the UL grant (e.g., UL grant 216) . In a first embodiment, the UL grant includes a single entry of resources, e.g., a “start time” and an “end time. ” In a second embodiment, the UL grant includes a list of such resource entries. In both embodiments, an empty UL grant (i.e., all “0s” ) indicates “no grant. ” In some examples, “start time” can be encoded as the time displacement (e.g., number of ODFM symbols or slots) after the DL MAC PDU. And the “end time” can be encoded as the length of the allocated UL resource. This can save signaling overhead as only 4-bits is needed for each, so only 1-byte is needed for the signaling.

[0061] In some implementations, in response to receiving a UL grant, the A-IoT device 102 uses UL resources for the upcoming UL transmission. In some examples, if the UL grant is larger than the UL data, the A-IoT device 102 can use only part of the UL grant. In these examples, the A-IoT device 102 can zero-pad the unused portion of the UL transmission. If the UL grant is smaller than the UL data (and segmentation is supported) , the A-IoT device 102 can use stop-and-wait ARQ. In these scenarios, the A-IoT device 102 sends one segment and waits for ACK. Then, depending on whether ACK or NACK is received, the A-IoT device 102 either retransmits the last segment (if NACK is received) or sends the next segment (if ACK is received) .

[0062] In some implementations, if the A-IoT device 102 does not receive an UL grant, the device is configured not to transmit regardless of whether the device has UL data to transmit. In some examples, the exception is a case in which at least one UL resource is implicitly configured as a default configuration. This default grant does not need to be included in a DL message. In these examples, the DL control portion may also include a one-bit indication that suppresses this “implicit grant” in cases where the network does not want the device to send anything at all.

[0063] In some implementations, the UL grant can be shared or dedicated. In these implementations, the UL grant can include information indicating whether an UL grant is shared with other UEs or dedicated solely to the UE. The indication can be implicit or explicit. As an example, the UL grant can include the number of resources dedicated for the corresponding UL transmission. If only one resource is dedicated to the UL transmission, then that can serve as an implicit indication that the UL grant is dedicated. Conversely, having more than one resource listed in the UL grant can serve as an implicit indication that the UL grant is shared.

[0064] In some implementations, the UL grant can include frequency domain resources in addition to time domain resource. The frequency domain resource can include (start-time, stop-time, granularity) or (start time, number of slots or number of transmit opportunities) . Note that the UL grant can have a fixed size in the MAC PDU. The benefit of having a fixed size “UL grant” portion is simpler device implementation. From this perspective, all fields, if defined, have to be included in the MAC PDU-even if the value of the field is 0.

[0065] As stated previously, in some implementations, the DL MAC PDU is used as a paging message. In some examples, the paging message can include a single identifier (1 identifier) , which indicates that the paging message is directed to an A-IoT device with that identifier. In other examples, the paging message can include no identifiers (0 identifiers) , which indicates that the paging message is a broadcast paging message directed to any A-IoT device that receives the paging message. In yet other examples, the paging message include multiple identifiers, which indicates that the single page message is directed to multiple A-IoT devices with the listed identifiers. In some examples, a respective design for the 0 / 1 identifier and multiple identifier messages can be developed. In other examples, one common design is developed for both. Both approaches can be standardized, perhaps through different message types or a bit in control header to differentiate between the messages.

[0066] In some implementations, the control header of a paging DL MAC PDU may include additional information elements that specify a transaction identifier (ID) and / or a session ID. The transaction ID or session ID can be used to avoid duplicate responses in the case of group paging. In some implementations, the A-IoT device 102 can be configured to ignore paging messages in certain scenarios. As an example, if the A-IoT device 102 is currently engaged with a reader device already, the A-IoT device 102 can be configured to ignore any new paging messages, perhaps until the device is no longer communicating with the reader.

[0067] In some implementations, the paging DL MAC PDU has the same format as the data DL MAC PDU (shown in FIG. 2B) . In these implementations, the address field (e.g., address field 214) carries the address of the target A-IoT device. As stated, the target A-IoT device can be a single A-IoT device. In this scenario, the address field includes the address of the single A-IoT device. Alternatively, the target A-IoT device can be any device that receives the paging message. In this scenario, one address value (e.g., all 0s or all 1s) is allocated to indicate “No identifier” for the broadcast paging message. As also stated, the paging message can optionally include data. If the paging message does not include data, then the data field length is set to “0. ” This approach of using the same format as the data DL MAC PDU reduces A-IoT device complexity. It also enables support of paging+data transmissions in the paging message. This approach may not even need a dedicated message type, which saves on overhead. However, this approach does not support multiple address identifiers.

[0068] In some implementations, the paging DL MAC PDU has a type-length-value (TLV) design. In this design, the paging DL MAC PDU can include multiple address identifiers, and therefore, can be directed to multiple A-IoT devices. To do so, the paging DL MAC PDU includes a respective Address, UL grant, and Data field for each A-IoT device addressed by the message. Additionally, the paging DL MAC PDU includes a length or number of entries field that indicates how many address / UL grant / data entries the paging message is carrying.

[0069] FIG. 5 illustrates an example paging DL MAC PDU 500 with TLV design, according to some implementations. As shown in FIG. 5, the DL MAC PDU 500 includes a control header 502 and a length / number of entries field 504. Additionally, the DL MAC PDU 500 includes N Address, UL grant, and Data fields, where N is the number of A-IoT devices addressed by the message. As illustrated, the DL MAC PDU 500 includes a respective address 506A, UL grant 508A, and data field 510A for a first A-IoT device. The DL MAC PDU 500 includes the same respective fields for each of the N A-IoT devices targeted by the DL MAC PDU 500.

[0070] In the solutions discussed above, there is an assumption that the A-IoT device is within coverage of a single reader (e.g., reader device 104) . However, the A-IoT device can be in the coverage of more than one reader. In these scenarios, the readers can coordinate to make sure that each A-IoT device communicates only with one reader. If coordination cannot be achieved, then a “transaction ID”can be added to each DL and UL message, where the “transaction ID” is assigned by the reader. The A-IoT device always includes the “transaction ID” received in the previous DL message when transmitting the following UL message. Alternatively, a “reader ID” can be used in a similar fashion to achieve the same goal. In some examples, the “transaction ID” is included only when the “Message Type” is “Paging. ” This solution works because multiple readers sending DL data will not occur in normal A-IoT Command delivery.

[0071] In some implementations, multiple MAC PDUs may be included in one TB. In these implementations, one MAC PDU may include multiple MAC subPDUs. Each subPDU can be any of the PDUs discussed above. Having multiple MAC subPDUs addresses the “paging with multiple identifiers” issue since each PDU can be addressed to a different A-IoT device. In these implementations, the recipient A-IoT device processes each subPDU in sequential order. Note that in cases where the subPDU length is not fixed, then a “length” field may be required.

[0072] As discussed above, in some implementations, the control headers of the UL and DL MAC PDUs include reserved bits. In some examples, the reserved bits can be assigned to new features. In these examples, a feature should be designed assuming: (1) in the UL, an A-IoT device that does not support the feature will indicate “0” in the corresponding bit, and (2) in the DL, an A-IoT device that does support the feature will ignore the corresponding bit.

[0073] In some implementations, a new protocol version can be introduced. As stated above, devices that do not support the version indicated in the control header do not respond to that message. In some examples, a reader may implement multiple versions of the same message to communicate with devices of different versions, perhaps in a round-robin manner or using a-priori knowledge of which versions are deployed. From the perspective of reader devices, when the protocol is extended through a new version and if it is expected that there is a “mixed” population of devices with different versions, a reader may need to implement both versions. The reader would then communicate separately with devices supporting different versions.

[0074] In some implementations, the control header does not include a “Version (V) ” field. Instead, the control header includes “eXtension (X) ” field. When it is set to 0, this indicates that this is the last bit of the control header. When it is set to 1, this indicates there is one more byte in the header (to be defined) . Note that in these implementations, the legacy bits are not re-defined and not re-assigned in future extensions. If there is a need to re-define a legacy function, new bits are assigned in the extension and the legacy bits become obsolete (for new devices) .

[0075] FIG. 6 illustrates different topologies of A-IoT communications, 600A and 600B, according to some implementations. In both topologies 600A and 600B, base station 604 can be similar to base station 900 of FIG. 9. In topology 600B, UE 602 can be similar to UE 800 of FIG. 8. Further, A-IoT device 606 can be similar to A-IoT device 1000 of FIG. 10. In topology 600A, base station 604 serves as the A-IoT reader in communication with A-IoT device 606. For example, base station 604 and A-IoT device 606 can be both located indoor. Base station 604 can operate an indoor micro-cell to allow direct communication with A-IoT device 606.

[0076] In topology 600B, UE 602 serves as the A-IoT reader in communication with A-IoT device 606. For example, UE 602 and A-IoT device 606 can be both located indoor, while base station 604 can be located outdoor. Base station 604 can operate an outdoor-to-indoor (O2I) macro-cell to cover the locations of UE 602 and A-IoT device 606. In this scenario, UE 602 can function as an intermediate node under the control of base station 604.

[0077] FIG. 7 illustrates a flowchart of an example method 700, according to some implementations. For clarity of presentation, the description that follows generally describes method 700 in the context of the other figures in this description. For example, method 700 can be performed by A-IoT device 606 of FIG. 6. It will be understood that method 700 can be performed, for example, by any suitable system, environment, software, hardware, or a combination of systems, environments, software, and hardware, as appropriate. In some implementations, various steps of method 700 can be run in parallel, in combination, in loops, or in any order.

[0078] At step 702, method 700 involves receiving, from a reader and by an Ambient Internet-of-Things (A-IoT) device, a paging medium access control (MAC) protocol data unit (PDU) .

[0079] At step 704, method 700 involves determining that the paging MAC PDU is addressed to the A-IoT device.

[0080] At step 706, method 700 involves responsively initiating a random access procedure with the reader to establish a communication channel.

[0081] At step 708, method 700 involves transmitting an uplink (UL) MAC PDU to the reader via the communication channel.

[0082] In some implementations, the paging MAC PDU includes at least one of a control header, an address field, a UL grant, or a data field.

[0083] In some implementations, a format of the paging MAC PDU matches a format of a downlink (DL) data MAC PDU.

[0084] In some implementations, the control header includes at least one of a protocol version, a message type, or an acknowledgement bit.

[0085] In some implementations, the message type is: (i) data, (ii) paging, (iii) paging and data, or (iv) a random access procedure message.

[0086] In some implementations, the UL grant includes at least one of time resources or frequency resources for an upcoming UL transmission.

[0087] In some implementations, the UL grant is a shared UL grant or a dedicated UL grant.

[0088] In some implementations, the UL MAC PDU includes a control header and a data field.

[0089] In some implementations, the control header includes a protocol version, a message type, an acknowledgement bit, an energy status alert indication, and a last segment / additional data indication.

[0090] In some implementations, the A-IoT device does not support UL data segmentation, and where transmitting the uplink MAC PDU to the reader device involves: transmitting UL data up to a predetermined transport block (TB) size; and setting an additional data bit in the UL MAC PDU to 0.

[0091] In some implementations, the A-IoT device supports UL data segmentation, and where transmitting the uplink MAC PDU to the reader device involves determining whether UL data for transmission fits into a predetermined transport block size; if the UL data fits into the predetermined TB size: transmitting the UL data in a TB; and setting an additional data bit in the UL MAC PDU to 0.

[0092] In some implementations, the method further involves if the UL data does not fit into the predetermined TB size: transmitting a first portion of the UL data in the TB; storing the first portion of the UL data in memory; and setting the additional data bit in the UL MAC PDU to 1.

[0093] In some implementations, the method further involves receiving, from the reader device, a NACK in response to the uplink MAC PDU; and retransmitting the first portion of the UL data to the reader device.

[0094] In some implementations, the paging MAC PDU includes a single paging address field indicating the address of the UE and where determining that the paging MAC PDU is addressed to the A-IoT device involves determining that the single paging address field indicates the address of the A-IoT device.

[0095] In some implementations, the paging PDU includes a plurality of device field groups, each device field group including: a paging address field indicating an address of a respective A-IoT device corresponding to the device field group; and a paging UL grant field indicating a quantity of uplink resources allocated for the respective A-IoT device, and where determining that the paging MAC PDU is addressed to the A-IoT device involves identifying a device field group including a paging address field indicating the address of the A-IoT device.

[0096] In some implementations, the paging MAC PDU includes a single paging address field, and where determining that the paging MAC PDU is addressed to the A-IoT device involves determining that an address within the single paging address field is indicative of a broadcast message.

[0097] In some implementations, at least one of the paging MAC PDU and the UL MAC PDU have a fixed control header format, where the fixed control header format specifies a corresponding location within a control header for each field in the control header.

[0098] In some implementations, one or more processors are configured to perform method 700.

[0099] In some implementations, a device includes one or more processors configured to perform method 700.

[0100] In some implementations, a non-transitory computer storage medium encoded with instructions that, when executed by one or more processors, cause the one or more processors to perform method 700.

[0101] FIG. 8 illustrates an example UE 800. The UE 800 may be any mobile or non-mobile computing device, such as, for example, a mobile phone, computer, tablet, industrial wireless sensors, video device (for example, cameras, video cameras, etc. ) , wearable devices (for example, a smart watch) , relaxed-IoT devices, etc.

[0102] The UE 800 may include any / all of processor 802, RF interface circuitry 804, memory / storage 806, user interface 808, sensors 810, driver circuitry 812, power management integrated circuit (PMIC) 814, one or more antenna (s) 816, and battery 818. The components of the UE 800 may be implemented as integrated circuits (ICs) , portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof. The block diagram of FIG. 8 is intended to show a high-level view of some of the components of the UE 800. However, some of the components shown may be omitted, additional components may be present, and a different arrangement of the components shown may occur in other implementations.

[0103] The components of the UE 800 may be coupled with various other components over one or more interconnects 820, which may represent any type of interface, input / output, bus (local, system, or expansion) , transmission line, trace, optical connection, etc., that allows various circuit components (on common or different chips or chipsets) to interact with one another.

[0104] The processor 802 may include one or more processors. For example, the processor 802 may include processor circuitry such as, for example, baseband processor circuitry (BB) 822A, central processor unit circuitry (CPU) 822B, and graphics processor unit circuitry (GPU) 822C. The processor 802 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory / storage 806 to cause the UE 800 to perform operations as described herein.

[0105] In some implementations, the baseband processor circuitry 822A may access a communication protocol stack 824 in the memory / storage 806 to communicate over a 3GPP compatible network. In general, the baseband processor circuitry 822A may access the communication protocol stack to: perform user plane functions at a physical (PHY) layer, medium access control (MAC) layer, radio link control (RLC) layer, packet data convergence protocol (PDCP) layer, service data adaptation protocol (SDAP) layer, and PDU layer; and perform control plane functions at a PHY layer, MAC layer, RLC layer, PDCP layer, RRC layer, and a non-access stratum layer. In some implementations, the PHY layer operations may additionally / alternatively be performed by the components of the RF interface circuitry 804. The baseband processor circuitry 822A may generate or process baseband signals or waveforms that carry information in 3GPP-compatible networks. In some implementations, the waveforms for NR may be based cyclic prefix orthogonal frequency division multiplexing (OFDM) “CP-OFDM” in the uplink or downlink, and discrete Fourier transform spread OFDM “DFT-S-OFDM” in the uplink.

[0106] The memory / storage 806 may include one or more non-transitory, computer-readable media that includes instructions (for example, communication protocol stack 824) that may be executed by the processor 802 to cause the UE 800 to perform various operations described herein. The memory / storage 806 include any type of volatile or non-volatile memory that may be distributed throughout the UE 800. In some implementations, some of the memory / storage 806 may be located on the processor 802 itself (for example, L1 and L2 cache) , while other memory / storage 806 is external to the processor 802 but accessible thereto via a memory interface. The memory / storage 806 may include any suitable volatile or non-volatile memory such as, but not limited to, 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 memory, or any other type of memory device technology.

[0107] The RF interface circuitry 804 may include transceiver circuitry and radio frequency front module (RFEM) that allows the UE 800 to communicate with other devices over a radio access network. The RF interface circuitry 804 may include various elements arranged in transmit or receive paths. These elements may include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, control circuitry, etc.

[0108] In the receive path, the RFEM may receive a radiated signal from an air interface via antenna (s) 816 and proceed to filter and amplify (with a low-noise amplifier) the signal. The signal may be provided to a receiver of the transceiver that downconverts the RF signal into a baseband signal that is provided to the baseband processor.

[0109] In the transmit path, the transmitter of the transceiver up-converts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM may amplify the RF signal through a power amplifier prior to the signal being radiated across the air interface via the antenna (s) 816. In various implementations, the RF interface circuitry 804 may be configured to transmit / receive signals in a manner compatible with NR access technologies.

[0110] The antenna (s) 816 may include one or more antenna elements to convert electrical signals into radio waves to travel through the air and to convert received radio waves over the air into electrical signals. In some implementations, the antenna elements may be arranged into one or more antenna panels. The antenna (s) 816 may have antenna panels that are omnidirectional, directional, or a combination thereof, to enable beamforming and multiple input, multiple output communications. The antenna (s) 816 may include any / all of microstrip antennas, printed antennas fabricated on the surface of one or more printed circuit boards, patch antennas, phased array antennas, etc. The antenna (s) 816 may have one or more panels designed for one or more specific frequency bands, such as bands in FR1 or FR2.

[0111] The user interface 808 includes various input / output (I / O) devices designed to enable user interaction with the UE 800. The user interface 808 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for accepting an input including, inter alia, one or more physical or virtual buttons (for example, a reset button) , a physical keyboard, keypad, mouse, touchpad, touchscreen, microphones, scanner, headset, or the like. The output device circuitry includes any physical or virtual means for showing information or otherwise conveying information, such as sensor readings, actuator position (s) , or other like information. Output device circuitry may include any number or combinations of audio or visual display, including, inter alia, one or more simple visual outputs / indicators (for example, binary status indicators such as light emitting diodes “LEDs” and multi-character visual outputs) , or more complex outputs such as display devices or touchscreens (for example, liquid crystal displays “LCDs, ” LED displays, quantum dot displays, projectors, etc. ) , with the output of characters, graphics, multimedia objects, and the like being generated or produced from the operation of the UE 800.

[0112] The sensors 810 may include devices, modules, or subsystems whose purpose is to detect events or changes in its environment and send the information (sensor data) about the detected events to some other device, module, subsystem, etc. Examples of such sensors include, inter alia, inertia measurement units including accelerometers, gyroscopes, or magnetometers; microelectromechanical systems or nanoelectromechanical systems including 3-axis accelerometers, 3-axis gyroscopes, or magnetometers; level sensors; temperature sensors (for example, thermistors) ; pressure sensors; image capture devices (for example, cameras or lensless apertures) ; light detection and ranging sensors; proximity sensors (for example, infrared radiation detector and the like) ; depth sensors; ambient light sensors; ultrasonic transceivers; microphones or other like audio capture devices; etc.

[0113] The driver circuitry 812 may include software and hardware elements that operate to control particular devices that are embedded in the UE 800, attached to the UE 800, or otherwise communicatively coupled with the UE 800. The driver circuitry 812 may include individual drivers allowing other components to interact with or control various input / output (I / O) devices that may be present within, or connected to, the UE 800. For example, driver circuitry 812 may include a display driver to control and allow access to a display device, a touchscreen driver to control and allow access to a touchscreen interface, sensor drivers to obtain sensor readings of sensors 810 and control and allow access to sensors 810, drivers to obtain actuator positions of electro-mechanic components or control and allow access to the electro-mechanic components, a camera driver to control and allow access to an embedded image capture device, audio drivers to control and allow access to one or more audio devices.

[0114] The PMIC 814 may manage power provided to various components of the UE 800. In particular, with respect to the processor 802, the PMIC 814 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion.

[0115] In some implementations, the PMIC 814 may control, or otherwise be part of, various power saving mechanisms of the UE 800. A battery 818 may power the UE 800, although in some examples the UE 800 may be mounted deployed in a fixed location, and may have a power supply coupled to an electrical grid. The battery 818 may be a lithium ion battery, a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and the like. In some implementations, such as in vehicle-based applications, the battery 818 may be a typical lead-acid automotive battery.

[0116] FIG. 9 illustrates an example access node 900 (e.g., a base station or gNB) , according to some implementations. The access node 900 may be similar to and substantially interchangeable with base station 604. The access node 900 may include one or more of processor 902, RF interface circuitry 904, core network (CN) interface circuitry 906, memory / storage circuitry 908, and one or more antenna (s) 910. The processor 902 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory / storage circuitry 908 to cause the access node 900 to perform operations as described herein.

[0117] The components of the access node 900 may be coupled with various other components over one or more interconnects 912. The processor 902, RF interface circuitry 904, memory / storage circuitry 908 (including communication protocol stack 914) , antenna (s) 910, and interconnects 912 may be similar to like-named elements shown and described with respect to FIG. 8. For example, the processor 902 may include processor circuitry such as, for example, baseband processor circuitry (BB) 916A, central processor unit circuitry (CPU) 916B, and graphics processor unit circuitry (GPU) 916C.

[0118] The CN interface circuitry 906 may provide connectivity to a core network, for example, a 5th Generation Core network (5GC) using a 5GC-compatible network interface protocol such as carrier Ethernet protocols, or some other suitable protocol. Network connectivity may be provided to / from the access node 900 via a fiber optic or wireless backhaul. The CN interface circuitry 906 may include one or more dedicated processors or FPGAs to communicate using one or more of the aforementioned protocols. In some implementations, the CN interface circuitry 906 may include multiple controllers to provide connectivity to other networks using the same or different protocols.

[0119] As used herein, the terms “access node, ” “access point, ” or the like may describe equipment that provides the radio baseband functions for data and / or voice connectivity between a network and one or more users. These access nodes can be referred to as BS, gNBs, RAN nodes, eNBs, NodeBs, RSUs, TRxPs or TRPs, and so forth, and can include ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell) . As used herein, the term “NG RAN node” or the like may refer to an access node 900 that operates in an NR or 5G system (for example, a gNB) , and the term “E-UTRAN node” or the like may refer to an access node 900 that operates in an LTE or 4G system (e.g., an eNB) . According to various implementations, the access node 900 may be implemented as one or more of a dedicated physical device such as a macrocell base station, and / or a low power (LP) base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.

[0120] In some implementations, all or parts of the access node 900 may be implemented as one or more software entities running on server computers as part of a virtual network, which may be referred to as a CRAN and / or a virtual baseband unit pool (vBBUP) . In V2X scenarios, the access node 900 may be or act as a “Road Side Unit. ” The term “Road Side Unit” or “RSU” may refer to any transportation infrastructure entity used for V2X communications. An RSU may be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE, where an RSU implemented in or by a UE may be referred to as a “UE-type RSU, ” an RSU implemented in or by an eNB may be referred to as an “eNB-type RSU, ” an RSU implemented in or by a gNB may be referred to as a “gNB-type RSU, ” and the like.

[0121] FIG. 10 illustrates an example A-IoT device 1000, according to some implementations. The example A-IoT device 1000 is based on the architecture of Device 1 of 3GPP TR 38.769. However, other architectures are possible including Device 2 of 3GPP TR 38.769 and future A-IoT device architectures.

[0122] In some examples, the A-IoT device 1000 operates on low power by harvesting RF energy from its environment. The A-IoT device 1000 includes an antenna 1026 that could be either shared or separate for RF energy harvester and receiver / transmitter. At the front end, the antenna 1026 is coupled to a matching network 1016, which is configured to match impedance between the antenna 1026 and other components (including an RF energy harvester 1018 and receiver related blocks) . The RF energy harvester 1018 can include rectifier performing RF signal (AC) to direct current (DC) conversion. In particular, the RF energy harvester 1018 converts a portion of the received RF power into a DC voltage that is stored in an energy storage module 1022. The energy storage module 1022 (e.g., capacitor) stores harvested energy from the RF energy harvester 1018. A power management unit (PMU) 1020 manages storing energy to energy storage from energy harvester and supplying power to active component blocks which needs power supply. In particular, the PMU 1020 can monitor the available energy and ensures that critical device components receive sufficient power while preventing depletion of the storage element.

[0123] Within the A-IoT device 1000 device enclosure, various functional blocks facilitate data processing and communication. A clock generator 1010 provides required clock signal (s) (timing signals) for the entire system, including digital BB logic 1012, which includes functional blocks like encoder, decoder, controller, etc. The digital BB logic 1012 can handle encoding, decoding, and high‐level control tasks. The memory 1014 block can include two types of memory: 1) Non-Volatile Memory (NVM) such as EEPROM for permanently storing device ID, etc., and 2) registers for temporarily keeping any information required for its operation only while energy is available in energy storage. By coordinating power delivery via the PMU 1020, these digital components can operate intermittently or at reduced duty cycles to remain within the strict energy constraints imposed by the ambient harvest.

[0124] On the receive path, the A-IoT device 1000 may incorporate an RF bandpass filter (RF BPF) 1024 for improving selectivity, e.g., selecting desired frequency bands and suppressing out‐of‐band interference. An RF envelope detector 1002 then down‐converts the filtered signal to baseband, which is further purified by a baseband low‐pass filter (BB LPF) 1006. The resulting signal is fed into a comparator 1008, transforming it into a digital representation for subsequent processing by the digital BB logic 1012. In particular, the comparator 1008 determines high / low of input signal.

[0125] For transmission, the A-IoT device 1000 includes a backscatter modulator 1004, which switches impedance to modulate backscattered signal with a transmitted signal from the digital BB logic 1012. By modulating these reflections according to data inputs from the digital BB logic 1012, the A-IoT device 1000 communicates with remote readers or gateways at low power cost.

[0126] Various components may be described as performing a task or tasks, for convenience in the description. Such descriptions should be interpreted as including the phrase “configured to. ” Reciting a component that is configured to perform one or more tasks is expressly intended not to invoke 35 U.S. C. § 112 (f) interpretation for that component.

[0127] 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, 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.

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

[0129] Although the embodiments above have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

[0130] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular, personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

Claims

1.A method comprising:receiving, from a reader and by an Ambient Internet-of-Things (A-IoT) device, a paging medium access control (MAC) protocol data unit (PDU) ;determining that the paging MAC PDU is addressed to the A-IoT device;responsively initiating a random access procedure with the reader to establish a communication channel; andtransmitting an uplink (UL) MAC PDU to the reader via the communication channel.2.The method of claim 1, wherein the paging MAC PDU comprises at least one of a control header, an address field, a UL grant, or a data field.3.The method of claim 2, wherein a format of the paging MAC PDU matches a format of a downlink (DL) data MAC PDU.4.The method of claim 2, wherein the control header comprises a protocol version, a message type, and an acknowledgement bit.5.The method of claim 4, wherein the message type is: (i) data, (ii) paging, (iii) paging and data, or (iv) a random access procedure message.6.The method of claim 2, wherein the UL grant comprises at least one of time resources or frequency resources for an upcoming UL transmission.7.The method of claim 2, wherein the UL grant is a shared UL grant or a dedicated UL grant.8.The method of claim 1, wherein the UL MAC PDU comprises a control header and a data field.9.The method of claim 8, wherein the control header comprises a protocol version, a message type, an acknowledgement bit, an energy status alert indication, and a last segment / additional data indication.10.The method of claim 1, wherein the A-IoT device does not support UL data segmentation, and wherein transmitting the uplink MAC PDU to the reader device comprises:transmitting UL data up to a predetermined transport block (TB) size; andsetting an additional data bit in the UL MAC PDU to 0.11.The method of claim 1, wherein the A-IoT device supports UL data segmentation, and wherein transmitting the uplink MAC PDU to the reader device comprises:determining whether UL data for transmission fits into a predetermined transport block size;if the UL data fits into the predetermined TB size:transmitting the UL data in a TB; andsetting an additional data bit in the UL MAC PDU to 0.12.The method of claim 11, further comprising:if the UL data does not fit into the predetermined TB size:transmitting a first portion of the UL data in the TB;storing the first portion of the UL data in memory; andsetting the additional data bit in the UL MAC PDU to 1.13.The method of claim 12, further comprising:receiving, from the reader device, a NACK in response to the uplink MAC PDU; andretransmitting the first portion of the UL data to the reader device.14.The method of claim 1, wherein the paging MAC PDU comprises a single paging address field indicating the address of the UE and wherein determining that the paging MAC PDU is addressed to the A-IoT device comprises:determining that the single paging address field indicates the address of the A-IoT device.15.The method of claim 1, wherein the paging PDU comprises a plurality of device field groups, each device field group including:a paging address field indicating an address of a respective A-IoT device corresponding to the device field group; anda paging UL grant field indicating a quantity of uplink resources allocated for the respective A-IoT device, andwherein determining that the paging MAC PDU is addressed to the A-IoT device comprises identifying a device field group including a paging address field indicating the address of the A-IoT device.16.The method of claim 1, wherein the paging MAC PDU comprises a single paging address field, and wherein determining that the paging MAC PDU is addressed to the A-IoT device comprises:determining that an address within the single paging address field is indicative of a broadcast message.17.The method of claim 1, wherein at least one of the paging MAC PDU and the UL MAC PDU have a fixed control header format, wherein the fixed control header format specifies a corresponding location within a control header for each field in the control header.18.One or more processors configured to perform the method of any of claims 1-17.19.A device comprising the one or more processors of claim 18.20.A non-transitory computer storage medium encoded with instructions that, when executed by one or more processors, cause the one or more processors to perform the method of any of claims 1-17.

Images