Medium access control layer data transmission in ambient internet-of-things communications

Abstract

A method is provided. The method includes obtaining a user plane data packet to be transmitted to an Ambient Internet-of-Things (AIoT) apparatus. The method includes generating a medium access control (MAC) message by multiplexing at least one of i) the user plane data packet, ii) a radio resource control (RRC) packet, or iii) a MAC control element (MAC CE), into at least one MAC protocol data unit (PDU). The method includes transmitting the MAC message to the AIoT apparatus. Also provided are one or more processors, a non-transitory computer-readable medium, and an apparatus.

Description

MEDIUM ACCESS CONTROL LAYER DATA TRANSMISSION IN AMBIENT INTERNET-OF-THINGS COMMUNICATIONSBACKGROUND

[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 wireless network protocols, such as protocols described in various telecommunication standards promulgated by the Third Generation Partnership Project (3GPP) . Example wireless communication networks include time division multiple access (TDMA) networks, frequency-division multiple access (FDMA) networks, orthogonal frequency-division multiple access (OFDMA) networks, Long Term Evolution (LTE) , and Fifth Generation New Radio (5G NR) . The wireless communication networks facilitate mobile broadband service using technologies such as OFDM, 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 is provided. The method includes obtaining a user plane data packet to be transmitted to an Ambient Internet-of-Things (AIoT) apparatus. The method includes generating a medium access control (MAC) message by multiplexing at least one of i) the user plane data packet, ii) a radio resource control (RRC) packet, or iii) a MAC control element (MAC CE) , into at least one MAC protocol data unit (PDU) . The method includes transmitting the MAC message to the AIoT apparatus.

[0004] In some implementations, the method further includes generating a MAC service data unit (SDU) for AIoT based on the user plane data packet.

[0005] In some implementations, the method further includes encapsulating the user plane data packet in an RRC container to generate an encapsulated data packet. Generating the MAC SDU for AIoT includes: generating the MAC PDU for AIoT using the encapsulated data packet.

[0006] In some implementations, wherein transmitting the MAC message includes associating the at least one MAC PDU in at least one logical channel according to a type of the at least one MAC PDU.

[0007] In some implementations, for each of the at least one MAC PDU, the MAC PDU corresponds to a MAC subheader that indicates at least one of: an identifier of the logical channel to which the MAC PDU is associated, or a length of the MAC PDU.

[0008] In some implementations, the method further includes assigning at least one priority value to the at least one logical channel.

[0009] In some implementations, the MAC message includes a MAC header that includes a MAC address field.

[0010] In some implementations, the MAC address field includes at least one of a destination identifier or a source identifier.

[0011] In some implementations, the destination identifier identifies the AIoT apparatus, and wherein the source identifier identifies an AIoT reader.

[0012] In some implementations, the source identifier identifies the AIoT apparatus, and wherein the destination identifier identifies an AIoT reader.

[0013] In some implementations, the MAC header further includes a message integrity check (MIC) field.

[0014] In some implementations, the MAC header further includes at least one of: an address type field, or a cast type field.

[0015] In some implementations, at least one of the destination identifier or the source identifier includes a temporary identifier. The method further includes increasing a counter value in response to transmitting the MAC message with the temporary identifier.

[0016] In some implementations, the method further includes discarding the temporary identifier in response to determining that the counter value reaches a threshold.

[0017] In some implementations, the MAC message includes a MAC header including a message type filed.

[0018] In some implementations, the message type field indicates at least one of: a) whether the MAC message contains a data payload or a control payload, or b) whether a subsequent transmission in a reverse direction is requested.

[0019] In some implementations, the MAC header further includes a length field indicating a size of a payload in the message.

[0020] In some implementations, the message type field indicates a trigger of uplink transmission. The MAC header further includes an uplink resource allocation grant for device-oriented transmission.

[0021] The above method can be implemented as instructions stored in a non-transitory computer-readable medium and executable by one or more processors of an apparatus.

[0022] The details of one or more implementations 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.

[0023] BRIEF DESCRIPTION OF THE FIGURES

[0024] FIG. 1 illustrates a wireless network, according to some implementations.

[0025] FIG. 2 is a table showing different types of Ambient Internet-of-Things (AIoT) devices, according to some implementations.

[0026] FIG. 3 illustrates different topologies of AIoT communications, according to some implementations.

[0027] FIGs. 4A and 4B each illustrate an example protocol stack of AIoT communications between an AIoT device, a gNB as an AIoT reader, and a core network (CN) , according to some implementations.

[0028] FIGs. 5A-5C each illustrate an example medium access control (MAC) header design, according to some implementations.

[0029] FIG. 6 illustrates example operations of an AIoT device that employes a counter in communications with an AIoT reader, according to some implementations.

[0030] FIGs. 7A and 7B each illustrate example frame structures at an upper layer, a radio resource control (RRC) layer, and the MAC layer, according to some implementations.

[0031] FIG. 8 is a table showing example mappings between logic channel IDs (LCIDs) and multiplexed elements of a MAC protocol data unit (PDU) , according to some implementations.

[0032] FIG. 9A illustrates an example frame structure of a MAC PDU 900, according to some implementations.

[0033] FIG. 9B is a table showing example mappings between a Message Type field and the type of the message in a MAC PDU, according to some implementations.

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

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

[0036] FIG. 12 illustrates an example access node, according to some implementations.DETAILED DESCRIPTION

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

[0038] Medium access control (MAC) layer is an important component of the AIoT protocol stack. When designing the MAC layer for AIoT, a number of factors and constraints are considered. For example, different from many user devices in cellular communications, an AIoT device typically runs only one application or communicates for only one purpose at a time. This means that the AIoT device usually does not generate a large amount of traffic with high complexity. Also, due to an AIoT device’s reliance on external energy harvesting, the power to support AIoT transmissions is usually limited and may be drained after only a small number of receptions and transmissions. This means that the AIoT device usually cannot support a large number of continuous receptions and transmissions. Additionally, an AIoT device often has registers made of a 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 AIoT device’s ability to continuously operate.

[0039] This disclosure addresses one or more technical problems identified above. As descried in detail below, implementations of the present disclosure provide a simplified and single-purpose MAC model that applies to various types and topologies of AIoT communications. The MAC model allows the AIoT reader and the AIoT device to implement a simple frame structure to deliver AIoT traffic and adopt a multiplexing scheme that is energy efficient.

[0040] FIG. 1 illustrates a wireless network 100, according to some implementations. The wireless network 100 includes a UE 102 and a base station 104 connected via one or more channels 106A, 106B across an air interface 108. The UE 102 and base station 104 communicate using a system that supports controls for managing the access of the UE 102 to a network via the base station 104.

[0041] In some implementations, the wireless network 100 may be a Non-Standalone (NSA) network that incorporates Long Term Evolution (LTE) and Fifth Generation (5G) New Radio (NR) communication standards as defined by the Third Generation Partnership Project (3GPP) technical specifications. For example, the wireless network 100 may be a E-UTRA (Evolved Universal Terrestrial Radio Access) -NR Dual Connectivity (EN-DC) network, or an NR-EUTRA Dual Connectivity (NE-DC) network. In some other implementations, the wireless network 100 may be a Standalone (SA) network that incorporates only 5G NR. Furthermore, other types of communication standards are possible, including future 3GPP systems (e.g., Sixth Generation (6G) ) , Institute of Electrical and Electronics Engineers (IEEE) 802.11 technology (e.g., IEEE 802.11a; IEEE 802.11b; IEEE 802.11g; IEEE 802.11-2007; IEEE 802.11n; IEEE 802.11-2012; IEEE 802.11ac; or other present or future developed IEEE 802.11 technologies) , IEEE 802.16 protocols (e.g., WMAN, WiMAX, etc. ) , or the like. While aspects may be described herein using terminology commonly associated with 5G NR, aspects of the present disclosure can be applied to other systems, such as 3G, 4G, and / or systems subsequent to 5G (e.g., 6G) .

[0042] In the wireless network 100, the UE 102 and any other UE in the system may be, for example, any of laptop computers, smartphones, tablet computers, machine-type devices such as smart meters or specialized devices for healthcare, intelligent transportation systems, or any other wireless device. In network 100, the base station 104 provides the UE 102 network connectivity to a broader network (not shown) . This UE 102 connectivity is provided via the air interface 108 in a base station service area provided by the base station 104. In some implementations, such a broader network may be a wide area network operated by a cellular network provider, or may be the Internet. Each base station service area associated with the base station 104 is supported by one or more antennas integrated with the base station 104. The service areas can be divided into a number of sectors associated with one or more particular antennas. Such sectors may be physically associated with one or more fixed antennas or may be assigned to a physical area with one or more tunable antennas or antenna settings adjustable in a beamforming process used to direct a signal to a particular sector.

[0043] The UE 102 includes control circuitry 110 coupled with transmit circuitry 112 and receive circuitry 114. The transmit circuitry 112 and receive circuitry 114 may each be coupled with one or more antennas. The control circuitry 110 may include various combinations of application-specific circuitry and baseband circuitry. The transmit circuitry 112 and receive  circuitry 114 may be adapted to transmit and receive data, respectively, and may include radio frequency (RF) circuitry and / or front-end module (FEM) circuitry.

[0044] In various implementations, aspects of the transmit circuitry 112, receive circuitry 114, and control circuitry 110 may be integrated in various ways to implement the operations described herein. The control circuitry 110 may be adapted or configured to perform various operations, such as those described elsewhere in this disclosure related to a UE. For instance, the control circuitry 110 can control the transmit circuitry 112 and receive circuitry 114 to read information from an AIoT device and pass the information to base station 104.

[0045] The transmit circuitry 112 may transmit using a plurality of multiplexed uplink physical channels. The plurality of uplink physical channels may be multiplexed, e.g., according to time division multiplexing (TDM) or frequency division multiplexing (FDM) along with carrier aggregation. The transmit circuitry 112 may be configured to receive block data from the control circuitry 110 for transmission across the air interface 108.

[0046] The receive circuitry 114 may receive a plurality of multiplexed downlink physical channels from the air interface 108 and relay the physical channels to the control circuitry 110. The plurality of downlink physical channels may be multiplexed, e.g., according to TDM or FDM along with carrier aggregation. The transmit circuitry 112 and the receive circuitry 114 may transmit and receive, respectively, both control data and content data (e.g., messages, images, video, etc. ) structured within data blocks that are carried by the physical channels.

[0047] FIG. 1 also illustrates the base station 104. In some implementations, the base station 104 may be a 5G radio access network (RAN) , a next generation RAN, a E-UTRAN, a non-terrestrial cell, or a legacy RAN, such as a UTRAN. As used herein, the term “5G RAN” or the like may refer to the base station 104 that operates in an NR or 5G wireless network 100, and the term “E-UTRAN” or the like may refer to a base station 104 that operates in an LTE or 4G wireless network 100. The UE 102 utilizes connections (or channels) 106A, 106B, each of which includes a physical communications interface or layer.

[0048] The base station 104 circuitry may include control circuitry 116 coupled with transmit circuitry 118 and receive circuitry 120. The transmit circuitry 118 and receive circuitry 120 may each be coupled with one or more antennas that may be used to enable communications via the air interface 108. The transmit circuitry 118 and receive circuitry 120 may be adapted to transmit and receive data, respectively, to any UE connected to the base station 104. The  receive circuitry 120 may receive a plurality of uplink physical channels from one or more UEs, including the UE 102.

[0049] In FIG. 1, the one or more channels 106A, 106B are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols, such as a UMTS protocol, a 3GPP LTE protocol, an Advanced long term evolution (LTE-A) protocol, a LTE-based access to unlicensed spectrum (LTE-U) , a 5G protocol, a NR protocol, an NR-based access to unlicensed spectrum (NR-U) protocol, and / or any other communications protocol (s) . In implementations, the UE 102 may directly exchange communication data via a ProSe interface. The ProSe interface may alternatively be referred to as a sidelink (SL) interface and may include one or more logical channels, including but not limited to a Physical Sidelink Control Channel (PSCCH) , a Physical Sidelink Discovery Channel (PSDCH) , and a Physical Sidelink Broadcast Channel (PSBCH) .

[0050] FIG. 2 is a table showing different types of AIoT devices, according to some implementations. As illustrated, there are three types of AIoT devices, Types 1, 2a, and 2b. All three types of AIoT devices can have energy storage, e.g., a battery, to provide power in addition to energy harvested from the environment. It is desirable that all three types are robust to frequency errors, which are likely common due to inferior oscillators equipped in AIoT devices. As described below, the MAC address and message designs according to some implementations can conveniently apply to these different types of AIoT devices, thereby resulting a harmonized AIoT air interface at the MAC layer.

[0051] As illustrated, the three types of AIoT devices differ in some parameters. For example, a Type 1 device can have a peak power consumption of about 1μW, whereas a Type 2a or 2b device can have a peak power consumption of up to a few hundred μW. Other parameters include: whether the device supports amplification of downlink or uplink signals, whether the device supports uplink transmission using backscattered carrier waves, and whether the device supports generating uplink transmission internally (e.g., without relying on external backscattered carrier waves) .

[0052] FIG. 3 illustrates different topologies of AIoT communications, 300A and 300B, according to some implementations. In both topologies 300A and 300B, base station 304 can be similar to base station 104 of FIG. 1. In topology 300B, UE 302 can be similar to UE 102 of FIG. 1. As described below, the MAC address and message designs according to some  implementations can conveniently apply to different AIoT topologies, thereby simplifying the deployment cost in AIoT communications.

[0053] In topology 300A, base station 304 serves as the AIoT reader in communication with AIoT device 306. For example, base station 304 and AIoT device 306 can be both located indoor. Base station 304 can operate an indoor micro-cell to allow direct communication with AIoT device 306.

[0054] In topology 300B, UE 302 serves as the AIoT reader in communication with AIoT device 306. For example, UE 302 and AIoT device 306 can be both located indoor, while base station 304 can be located outdoor. Base station 304 can operate an outdoor-to-indoor (O2I) macro-cell to cover the locations of UE 302 and AIoT device 306. In this scenario, UE 302 can function as an intermediate node under the control of base station 304.

[0055] AIoT communication can be classified into multiple types of traffic at the application layer. A first type is device-terminated (DT) traffic, which is often used to give commands to an AIoT device. A second type is device-originated-device-terminated-triggered (DO-DTT) traffic, which is often used in applications of inventory management. A third type is device-originated-autonomous (DO-A) traffic, which is often used for sensor devices. Depending on the type of traffic, some AIoT scenarios support communicating the traffic using internally stored energy, whereas some AIoT scenarios support communicating the traffic using energy from backscattered carrier wave.

[0056] FIGs. 4A and 4B each illustrate an example protocol stack of AIoT communications between an AIoT device, a gNB as an AIoT reader, and a core network (CN) , according to some implementations. Similar protocol stacks may apply to scenarios where a UE, instead of a gNB, serves as an AIoT reader.

[0057] In FIG. 4A, AIoT device 407 has AIoT layer 408 that communicates, through gNB 403, AIoT control plane messages with AIoT function 402, which can be a network function of CN 401. For AIoT data packets, AIoT device 407 does not have a separate user plane connection with gNB 403 or CN 401. Instead, AIoT device 407 encapsulates AIoT data packets in one or more RRC containers in AIoT RRC layer 409 and passes the RRC containers to AIoT MAC layer. The MAC layer of AIoT device 407 then transmits RRC packets including the AIoT data packets to the MAC layer of gNB 403. After RRC layer 404 of gNB 403 decapsulates the  received RRC containers to obtain AIoT data packets , gNB 403 can deliver the AIoT data packets to CN 401.

[0058] In FIG. 4B, AIoT device 457 has both control plane and user plane communications with AIoT function 452 of CN 451. For example, AIoT layer 458 of AIoT device 457 can exchange user plane information with MAC layer 460 and exchange control plane information with RRC layer 459. In this case, the communication between RRC layer 459 of AIoT device 457 and RRC layer 454 of gNB 453 does not contain user plane information, as no RRC container is supposed to be used.

[0059] FIGs. 5A-5C each illustrate an example MAC header design, according to some implementations. These designs can be flexibly used for addressing in AIoT communications depending on device type, topology, and traffic type.

[0060] Starting from FIG. 5A, headers 501 and 502 can be used for downlink and uplink communications, respectively. For example, header 501 can include a source ID identifying the AIoT reader (which can be a gNB or a UE) and a destination ID identifying the AIoT device. The source ID can indicate beam information if directional transmission is used in the transmission. The destination ID can be a local / temporary ID (e.g., an ID temporarily assigned to identify the device within a group and / or to facilitate multiple transmissions within a limited time period) having a short format (e.g., 8 bits or 16 bits) or a global / permanent ID (e.g., an ID preconfigured or assigned by upper layers, the CN, or the AIoT layer) having a long format (e.g., 96 bits or 128 bits) . Correspondingly, header 502 can include a destination ID identifying the AIoT reader and a source ID identifying the AIoT device. These IDs can be used for uplink transmissions from the AIoT device to the AIoT reader. In some implementations of uplink and / or downlink communications, either or both of the source ID and the destination ID can be omitted.

[0061] Moving to FIG. 5B, header 511 includes one or more addresses accompanied by a field indicating the type of the addresses. For example, the Address (es) field can indicate where the MAC message should be sent and the Address Type field can indicate whether the addresses identified by the Address (es) field should be treated as permanent device IDs or temporary local IDs.

[0062] Moving to FIG. 5C, header 521 includes a Cast Type field accompanying each of the source ID and destination ID fields. The Cast Type field can indicate whether the MAC  message is broadcast (e.g., sent to all devices within a proximity) , groupcast (e.g., sent to all devices within a certain group) , or unicast (e.g., sent to only a target device) .

[0063] Besides the fields illustrated in FIGs. 5A-5C, a MAC header according to some implementations can have one or more additional fields. For example, a MAC header can have a message integrity check (MIC) field for integrity protection.

[0064] The MAC address in a MAC header can be used in a variety of scenarios. In broadcast, a MAC PDU can use the broadcast MAC address to ping all AIoT devices to initiate decoding of downlink messages. The MAC PDU can contain paging records or downlink data for multiple of AIoT devices. In unicast, a MAC PDU can use the MAC address to ping a specific AIoT device to initiate decoding. The MAC PDU can contain paging records or downlink data for the specific AIoT device. In groupcast, a MAC PDU can use the MAC address or a group paging message to ping a group of AIoT devices, e.g., AIoT devices of the same type within a cell, to initiate decoding.

[0065] The implementations described above provide flexibility for a variety of AIoT communication scenarios. For example, including a MAC address in downlink communication can help the MAC layer of a receiving AIoT device to filter and process the incoming signal and make a quick decision based on the MAC header whether to continue decoding. Also, it is possible a message broadcast by an AIoT reader does not have a MAC header or MAC addresses, or have a MAC address with all bits set to ‘1’ or ‘0. ’ In these cases, each AIoT device receiving the broadcast message can be configured to always decode the message. For uplink communication, it is possible to omit the MAC address under the assumption that the AIoT reader can collect all incoming uplink data and forward the data to a CN for processing.

[0066] FIG. 6 illustrates example operations of AIoT device 604 that employes a counter in communications with AIoT reader 602, according to some implementations. The counter can be used along with a temporary ID to track the number of transmissions ( “transactions” ) between AIoT device 604 and AIoT reader 602.

[0067] At 606, AIoT reader 602 sends a paging signal to AIoT device 604 and possibly to one or more other AIoT devices in the same AIoT device group. The paging signal can include a global / permanent ID of AIoT device 604 to identify AIoT device 604 as the intended receiver of the paging signal.

[0068] At 608, AIoT device 604 and AIoT reader 602 performs a random access procedure to establish an AIoT session.

[0069] At 610, AIoT device 604 performs initial access with AIoT reader 602, e.g., to synchronize the with AIoT reader 602. AIoT device 604 can transmit an initial access message to AIoT device 604. In the initial access message, AIoT device 604 can provide AIoT reader 602 with a proposed temporary ID that AIoT device 604 can use to identify AIoT device 604 within the device group that participates in the AIoT session. The temporary ID, which can be stored in registers of AIoT device 604, typically has a shorter format than the permanent device ID. AIoT reader 602 can use the temporary ID as an alternative to the device ID to identify AIoT reader 602 among all AIoT devices involved in the AIoT session. Because the temporary ID has a shorter format than the device ID, the AIoT traffic between AIoT device 604 and AIoT reader 602 can be reduced. The temporary ID can be stored in both AIoT device 604 and AIoT reader 602 throughout the AIoT session.

[0070] At 612 and 614, AIoT reader 602 configures AIoT device 604 such that AIoT device 604 is ready to perform MAC transactions with AIoT reader 602. A MAC transaction can include either a one-way downlink transmission of a MAC PDU or a two-way uplink and downlink exchange change of MAC PDUs. Along with the configuration, AIoT reader 602 can provide AIoT device 604 with a counter to track how many MAC transactions have taken place.

[0071] At 616, AIoT device 604 starts the counter and being performing MAC transactions at 618. Each time a MAC transaction is performed, AIoT device 604 changes the counter value at 620 up or down to record the MAC transaction.

[0072] In some implementations, once the counter value reaches a predefined threshold (e.g., an upper limit for a count-up counter or zero for a count-down counter) , AIoT reader 602 and / or AIoT device 604 determine that the MAC address corresponding to the temporary ID expires. As such, AIoT reader 602 and AIoT device 604 can discard the MAC address and / or the temporary ID. AIoT reader 602 and AIoT device 604 can then use the device ID or a new temporary ID of AIoT device 604 to continue AIoT transactions. In some implementations, AIoT reader 602 can send a commend, e.g., via RRC signaling or a MAC control element (MAC CE) , to AIoT device 604 to extend the use of a MAC address that would otherwise be discarded.

[0073] In some implementations, it is possible that AIoT reader 602 and AIoT device 604 communicate without using a counter. In these scenarios, the AIoT reader 602 may or may not use the temporary ID as the MAC address to identify AIoT device 604. Further, when AIoT reader 602 receives no response after initiating a MAC transaction toward a given MAC address, AIoT reader 602 can discard that MAC address and restart the paging procedure at 606.

[0074] FIGs. 7A and 7B each illustrate example frame structures at an upper layer, a radio resource control (RRC) layer, and the MAC layer, according to some implementations. The frame structures in FIGs. 7A and 7B can correspond to the protocol stacks illustrated in FIGs. 4A and 4B, respectively.

[0075] In FIG. 7A, a user plane AIoT data packet at the upper layer (e.g., application layer) is encapsulated in an RRC container to become an AIoT PDU at the RRC layer. The AIoT PDU along with an RRC header ( “H” ) is then used as input to construct a MAC SDU. Additionally, any RRC packets are similarly used to construct one or more MAC SDUs. Accordingly, a MAC message, such as at least one MAC PDU, is formed at the MAC layer to have: a) a MAC header ( “MH” ) , b) the MAC SDUs constructed based on the AIoT PDU and the RRC packet (s) , with each MAC SDU preceded by a sub-header ( “SH” ) , and c) one or more MAC CEs, each preceded by a sub-header.

[0076] In FIG. 7B, an AIoT data packet at the upper layer (e.g., application layer) is directly used to construct a MAC SDU, which is then used as an input to construct a MAC PDU, as opposed to FIG. 7A where the AIoT data packet is first encapsulated in an RRC container. Additionally, any RRC packets are used to construct one or more MAC SDUs. Accordingly, a MAC message, such as at least one MAC PDU, is formed at the MAC layer to have: a) a MAC header ( “MH” ) , b) the MAC SDUs constructed based on the AIoT data packet and the RRC packet (s) , with each MAC SDU preceded by a sub-header ( “SH” ) , and c) one or more MAC CEs, each preceded by a sub-header. The MAC SDUs and the MAC CEs are concatenated to each other and can differ in size. This way, the same MAC message, such as a MAC PDU, is constructed to transmit multiple elements of AIoT traffic of different types.

[0077] Based on their sub-headers, the MAC SDUs and MAC CEs in a MAC message can be mapped to a plurality of logic channels, each associated with an LCID. For example, RRC packets (with or without encapsulated AIoT data packets) , user plane data packets, and MAC CEs towards the same AIoT device can be multiplexed as elements of the same MAC PDU  with different LCIDs. The sub-headers preceding each multiplexed element can indicate the corresponding LCID and / or the length of the multiplexed element.

[0078] FIG. 8 is a table showing example mappings between LCIDs and multiplexed elements of a MAC PDU, according to some implementations. As illustrated, logic channel #1 can be used to transmit downlink or uplink AIoT PDUs, such as the AIoT PDU of FIG. 7A, and logic channel #2 can be used to transmit downlink or uplink RRC signaling PDUs, such as the RRC packet of FIG. 7A or the RRC SDU of FIG. 7B. The use of other logic channels can be similarly derived from the table of FIG. 8.

[0079] In some scenarios, the size of a transport block for the MAC PDU may be inadequate for transmitting all buffered uplink data after multiplexing. To address this issue, the mapping of MAC elements and logic channels can prioritize some types of traffic. For example, the UE can assign the highest priority to the logic channels mapped to MAC CEs, e.g., by indicating ‘1’ in a logic channel priority field. As another example, AIoT data packets can have priority over RRC packets. The priority of each type of traffic can be predefined, e.g., in 3GPP standards, or can be configured by the network.

[0080] The above-described multiplexing of MAC elements to logic channels can be advantageous for transmitting multiple elements of traffic of varying types and sizes. However, when the traffic to transmit is of a single type, a simplified approach of constructing the MAC PDU based on message type can be utilized as an alternative to the above approach. In the message type-based approach, each MAC PDU is constructed to transmit a single type of payload (e.g., one of AIoT data packet, RRC packet, and MAC CE) . The message type (i.e. the type of traffic in the payload) can be indicated in a “Message Type” field. All MAC PDUs under this approach can have the same fixed size, with any unused payload bits padded with, e.g., ‘0’s or ‘1’s. This approach simplifies the communication protocol and can be suitable for AIoT communications whose traffic is usually sporadic and limited in size and data rate.

[0081] FIG. 9A illustrates an example frame structure of a MAC PDU 900, according to some implementations. MAC PDU 900 can be constructed in accordance with the message type-based approach described above.

[0082] As illustrated, MAC PDU 900 may have in the header an Address field that can indicate one or more MAC addresses, such as a source ID and / or a destination ID of the AIoT communications. In some other implementations, this Address filed can be omitted. For  example, a MAC PDU without the Address field may be intended to be received by any AIoT reader (s) or any AIoT device (s) .

[0083] MAC PDU 900 has in the header a Message Type field to indicate the type of the message (e.g., the type of payload) , such as control PDU, data PDU, or MAC CE, transmitted by the MAC PDU in payload 905. An example table with more detailed mappings between the value of the Message Type field and the type of the message is provided in FIG. 9B.

[0084] MAC PDU 900 has a DTT Flag field in the header, which can be a one-bit field used in downlink to indicate the trigger of uplink traffic. It is noted that the name “DTT Flag” of this field is just an example. More generally, the field can represent an indication to request a subsequent transmission in a reverse direction. For example, in some implementations, this field can be used in uplink MAC PDUs to request subsequent transmission in downlink (e.g., as an acknowledgement or confirmation) . Alternatively or additionally, , the Message Type field (described above) itself can be used to indicate whether the message is used as the trigger for uplink traffic in a reversed direction, or downlink traffic in the reverse direction.

[0085] MAC PDU 900 also has a Length field in the header. The value of the Length field can indicate the actual length of payload 905 before padding.

[0086] MAC PDU 900 has payload 905 to transmit the AIoT traffic, whose type is indicated by the Message Type field. As mentioned above, for a given MAC PDU 900, only one type of AIoT traffic is included in payload 905. The size of payload 905 can be fixed. Any unused bits of payload 905 can be padded.

[0087] When an AIoT reader transmits a downlink message, such as a downlink command or inventory management message, the AIoT reader can assign an uplink resource for the AIoT device to send an uplink response. Accordingly, in some implementations, MAC PDU 900 further includes a field of Uplink Resource Indication Grant to indicate the assigned uplink resource, e.g., for DO transmission, to the AIoT reader.

[0088] FIG. 9B is a table showing example mappings between a Message Type field and the type of the message in a MAC PDU, according to some implementations. The table lists six message types with indices 1 to 6. The table can be used to set the value of the Message Type field in MAC PDU 900.

[0089] It is noted that the fields of MAC PDU 900 illustrated in FIG. 9A are not limiting. For examples, some implementations can have a MAC PDU frame structure with fewer or more  fields. Similarly, the message types supported by a MAC PDU are not limited to those illustrated in FIGs. 9A and 9B. Some implementations can define additional message types or use the same Message Type field to indicate two or more illustrated message types.

[0090] FIG. 10 illustrates a flowchart of an example method 1000, according to some implementations. For clarity of presentation, the description that follows generally describes method 1000 in the context of the other figures in this description. For example, method 1000 can be performed by AIoT device 306, UE 302, or base station 304 of FIG. 3. It will be understood that method 1000 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 1000 can be run in parallel, in combination, in loops, or in any order.

[0091] At 1002, method 1000 involves obtaining a user plane data packet to be transmitted to an AIoT apparatus, which can be an AIoT reader or an AIoT device.

[0092] At 1004, method 1000 involves generating a MAC message, such as a MAC PDU, by multiplexing at least one of i) the user plane data packet, ii) an RRC packet, or iii) a MAC CE, into at least one MAC PDU. The generation of the MAC message can involve mapping any of elements i) to iii) to one or more logic channels, as described with reference to FIGs. 7 and 8. Alternatively or additionally, the generation of the MAC message can use the message type-based approach when only one type of AIoT traffic is included in the MAC message, as described with reference to FIGs. 9A and 9B.

[0093] At 1006, method 1000 involves transmitting the MAC message to the AIoT apparatus. The transmitted MAC message can include one or more MAC addresses in a MAC header, as described with reference to FIGs. 5A-5C.

[0094] FIG. 11 illustrates an example UE 1100, according to some implementations. The UE 1100 may be similar to and substantially interchangeable with UE 102 of FIG. 1.

[0095] The UE 1100 may be any mobile or non-mobile computing device, such as, for example, mobile phones, computers, tablets, industrial wireless sensors (for example, microphones, pressure sensors, thermometers, motion sensors, accelerometers, inventory sensors, electric voltage / current meters, etc. ) , video devices (for example, cameras, video cameras, etc. ) , wearable devices (for example, a smart watch) , relaxed-IoT devices.

[0096] The UE 1100 may include processors 1102, RF interface circuitry 1104, memory / storage 1106, user interface 1108, sensors 1110, driver circuitry 1112, power management integrated circuit (PMIC) 1114, one or more antenna (s) 1116, and battery 1118. The components of the UE 1100 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. 11 is intended to show a high-level view of some of the components of the UE 1100. However, some of the components shown may be omitted, additional components may be present, and different arrangement of the components shown may occur in other implementations.

[0097] The components of the UE 1100 may be coupled with various other components over one or more interconnects 1120, 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.

[0098] The processors 1102 may include processor circuitry such as, for example, baseband processor circuitry (BB) 1122A, central processor unit circuitry (CPU) 1122B, and graphics processor unit circuitry (GPU) 1122C. The processors 1102 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 1106 to cause the UE 1100 to perform operations as described herein.

[0099] In some implementations, the baseband processor circuitry 1122A may access a communication protocol stack 1124 in the memory / storage 1106 to communicate over a 3GPP compatible network. In general, the baseband processor circuitry 1122A 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 1104. The baseband processor circuitry 1122A 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.

[0100] The memory / storage 1106 may include one or more non-transitory, computer-readable media that includes instructions (for example, communication protocol stack 1124) that may be executed by one or more of the processors 1102 to cause the UE 1100 to perform various operations described herein. The memory / storage 1106 include any type of volatile or non-volatile memory that may be distributed throughout the UE 1100. In some implementations, some of the memory / storage 1106 may be located on the processors 1102 themselves (for example, L1 and L2 cache) , while other memory / storage 1106 is external to the processors 1102 but accessible thereto via a memory interface. The memory / storage 1106 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.

[0101] The RF interface circuitry 1104 may include transceiver circuitry and radio frequency front module (RFEM) that allows the UE 1100 to communicate with other devices over a radio access network. The RF interface circuitry 1104 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.

[0102] In the receive path, the RFEM may receive a radiated signal from an air interface via antenna (s) 1116 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 of the processors 1102.

[0103] 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) 1116. In various implementations, the RF interface circuitry 1104 may be configured to transmit / receive signals in a manner compatible with NR access technologies.

[0104] The antenna (s) 1116 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 into  electrical signals. The antenna elements may be arranged into one or more antenna panels. The antenna (s) 1116 may have antenna panels that are omnidirectional, directional, or a combination thereof to enable beamforming and multiple input, multiple output communications. The antenna (s) 1116 may include microstrip antennas, printed antennas fabricated on the surface of one or more printed circuit boards, patch antennas, phased array antennas, etc. The antenna (s) 1116 may have one or more panels designed for specific frequency bands including bands in FR1 or FR2.

[0105] The user interface 1108 includes various input / output (I / O) devices designed to enable user interaction with the UE 1100. The user interface 1108 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 1100.

[0106] The sensors 1110 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.

[0107] The driver circuitry 1112 may include software and hardware elements that operate to control particular devices that are embedded in the UE 1100, attached to the UE 1100, or otherwise communicatively coupled with the UE 1100. The driver circuitry 1112 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 1100. For example, driver circuitry 1112 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 1110 and control and allow access to sensors 1110, 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.

[0108] The PMIC 1114 may manage power provided to various components of the UE 1100. In particular, with respect to the processors 1102, the PMIC 1114 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion.

[0109] In some implementations, the PMIC 1114 may control, or otherwise be part of, various power saving mechanisms of the UE 1100. A battery 1118 may power the UE 1100, although in some examples the UE 1100 may be mounted deployed in a fixed location, and may have a power supply coupled to an electrical grid. The battery 1118 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 1118 may be a typical lead-acid automotive battery.

[0110] FIG. 12 illustrates an example access node 1200 (e.g., a base station or gNB) , according to some implementations. The access node 1200 may be similar to and substantially interchangeable with base station 104. The access node 1200 may include processors 1202, RF interface circuitry 1204, core network (CN) interface circuitry 1206, memory / storage circuitry 1208, and one or more antenna (s) 1210.

[0111] The components of the access node 1200 may be coupled with various other components over one or more interconnects 1212. The processors 1202, RF interface circuitry 1204, memory / storage circuitry 1208 (including communication protocol stack 1214) , antenna (s) 1210, and interconnects 1212 may be similar to like-named elements shown and described with respect to FIG. 11. For example, the processors 1202 may include processor  circuitry such as, for example, baseband processor circuitry (BB) 1216A, central processor unit circuitry (CPU) 1216B, and graphics processor unit circuitry (GPU) 1216C.

[0112] The CN interface circuitry 1206 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 1200 via a fiber optic or wireless backhaul. The CN interface circuitry 1206 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 1206 may include multiple controllers to provide connectivity to other networks using the same or different protocols.

[0113] 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 1200 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 1200 that operates in an LTE or 4G system (e.g., an eNB) . According to various implementations, the access node 1200 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.

[0114] In some implementations, all or parts of the access node 1200 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 1200 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.

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

[0116] Although the implementations 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.

[0117] 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:obtaining a user plane data packet to be transmitted to an Ambient Internet-of-Things (AIoT) apparatus;generating a medium access control (MAC) message by multiplexing at least one of i) the user plane data packet, ii) a radio resource control (RRC) packet, or iii) a MAC control element (MAC CE) , into at least one MAC protocol data unit (PDU) ; andtransmitting the MAC message to the AIoT apparatus.2.The method of claim 1, further comprising generating a MAC service data unit (SDU) for AIoT based on the user plane data packet.3.The method of claim 2, further comprising encapsulating the user plane data packet in an RRC container to generate an encapsulated data packet, wherein generating the MAC SDU for AIoT comprises: generating the MAC SDU for AIoT using the encapsulated data packet.4.The method of claim 1, wherein transmitting the MAC message comprises:associating the at least one MAC PDU to at least one logical channel according to a type of the at least one MAC PDU.5.The method of claim 4, wherein, for each of the at least one MAC PDU, the MAC PDU corresponds to a MAC subheader that indicates at least one of: an identifier of the logical channel to which the MAC PDU is associated, or a length of the MAC PDU.6.The method of claim 4, further comprising assigning at least one priority value to the at least one logical channel.7.The method of claim 1, wherein the MAC message comprises a MAC header that comprises a MAC address field.8.The method of claim 7, wherein the MAC address field comprises at least one of a destination identifier or a source identifier.9.The method of claim 8, wherein the destination identifier identifies the AIoT apparatus, and wherein the source identifier identifies an AIoT reader.10.The method of claim 8, wherein the source identifier identifies the AIoT apparatus, and wherein the destination identifier identifies an AIoT reader.11.The method of claim 7, wherein the MAC header further comprises a message integrity check (MIC) field.12.The method of claim 7, wherein the MAC header further comprises at least one of: an address type field, or a cast type field.13.The method of claim 8, wherein at least one of the destination identifier or the source identifier comprises a temporary identifier, and wherein the method further comprises increasing a counter value in response to transmitting the MAC message with the temporary identifier.14.The method of claim 13, further comprising discarding the temporary identifier in response to determining that the counter value reaches a threshold.15.The method of claim 1, wherein the MAC message comprises a MAC header including a message type filed.16.The method of claim 15, wherein the message type field indicates at least one of: a) whether the MAC message contains a data payload or a control payload, or b) whether a subsequent transmission in a reverse direction is requested.17.The method of claim 15, the MAC header further comprises a length field indicating a size of a payload in the message.18.The method of claim 15, wherein the message type field indicates a trigger of uplink transmission, and wherein the MAC header further comprises an uplink resource allocation grant for device-oriented transmission.19.One or more processors comprising circuitry configured to execute instructions that cause an apparatus to perform the method of any of claims 1-18.20.A non-transitory computer-readable medium storing instructions that, when executed, cause one or more processors to perform the method of any of claims 1-18.21.An apparatus comprising one or more processors configured to perform the method of any of claims 1-18.

Images