Reader control techniques for a-IOT wireless communication

Abstract

Systems, methods, and processors are provided for reader control of Ambient Internet-of-Things (A-IoT) communication. In some aspects, a baseband processor is configured to perform operations including receiving, at a base station (BS), an authorization message indicating at least one of the BS being authorized to operate as an A-IoT reader device or the BS being authorized to service at least one user equipment (UE) operating as an A-IoT reader device; and performing at least one of: communicating with at least one A-IoT device in response to the authorization message indicating that the BS is authorized to operate as an A-IoT reader device; or transmitting a notification message to one or more UEs indicating the BS supports at least one UE operating as an A-IoT reader device in response to the authorization message indicating that the BS is authorized to service at least one UE operating as an A-IoT reader device.

Description

READER CONTROL TECHNIQUES FOR A-IOT WIRELESS COMMUNICATIONFIELD

[0001] This disclosure relates to reader control techniques for Ambient Internet-of-Things (A-IoT) wireless communication.BACKGROUND

[0002] The Internet-of-Things (IoT) is a network of physical devices that can connect and exchange data with other devices and systems over the Internet via wired or wireless networks. Ambient IoT (A-IoT) is a use case of low-power wide-area (LPWA) IoT, in which battery-free devices may harvest energy from ambient energy sources, such as light, motion, radio waves, heat, and / or other sources. As an example, A-IoT devices may reflect or “backscatter” radio (e.g., carrier) waves and send sensing or identity data to wireless devices, such as phones, smart speakers, smart cameras, Wi-Fi access points, and electronic shelf labels. A-IoT is an alternative to Radio-Frequency Identification (RFID) technology and has the potential to enable a number of connections and / or device density that are orders of magnitude higher than those of the existing 3rd Generation Partnership Project (3GPP) IoT technologies. A-IoT can provide complexity and power consumption that are orders of magnitude lower than existing 3GPP LPWA technologies, such as Narrowband IoT (NB-IoT) and Long-Term Evolution Machine Type Communication (LTE-MTC) .BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The present disclosure will be readily understood and enabled by the detailed description and accompanying figures of the drawings. Like reference numerals may designate like features and structural elements. Figures and corresponding descriptions are provided as non-limiting examples of aspects, implementations, etc., of the present disclosure, and references to "an" or “one” aspect, implementation, etc., may not necessarily refer to the same aspect, implementation, etc., and may mean at least one, one or more, etc.

[0004] FIG. 1 is a block diagram of an example wireless network, including an Ambient IoT (A-IoT) device, according to various aspects of the present disclosure.

[0005] FIG. 2 is a block diagram of an example A-IoT wireless network exhibiting two topologies associated with operating A-IoT devices and employing first and second interfaces, according to various aspects of the present disclosure.

[0006] FIGS. 3A through 3D are message flow diagrams illustrating messaging between an A-IoT base station (BS) or an A-IoT BS reader device and an A-IoT core network (CN) over the  first interface to provide authorization functionality, according to various aspects of the present disclosure.

[0007] FIGS. 4A and 4B are message flow diagrams illustrating messaging between an A-IoT BS or an A-IoT BS reader device and an A-IoT core network (CN) over the first interface to provide paging functionality, according to various aspects of the present disclosure.

[0008] FIGS. 5A and 5B are message flow diagrams illustrating messaging between an A-IoT BS or an A-IoT BS reader device and an A-IoT core network (CN) over the first interface to control radio resources, according to various aspects of the present disclosure.

[0009] FIGS. 6A through 6E are message flow diagrams illustrating messaging between an A-IoT BS and an A-IoT user equipment (UE) reader device over the second interface, according to various aspects of the present disclosure.

[0010] FIG. 7 is a block diagram of an example A-IoT wireless network exhibiting two topologies associated with operating A-IoT devices and employing a third interface, according to various aspects of the present disclosure.

[0011] FIG. 8 is a block diagram of an example A-IoT CN, according to various aspects of the present disclosure.

[0012] FIG. 9 is a block diagram of an example A-IoT architecture and control plane protocol stack for a first topology when employing the third interface, according to various aspects of the present disclosure.

[0013] FIG. 10 is a block diagram of an example A-IoT architecture and control plane protocol stack for a second topology when employing the third interface, according to various aspects of the present disclosure.

[0014] FIG. 11 is a block diagram of an example A-IoT wireless network exhibiting two topologies associated with operating A-IoT devices and employing first, second, and fourth interfaces, according to various aspects of the present disclosure.

[0015] FIGS. 12A and 12B are message flow diagrams illustrating messaging between A-IoT BSs and / or A-IoT BS reader devices over the fourth interface, according to various aspects of the present disclosure.

[0016] FIGS. 13A and 13B are flow diagrams outlining example methods employable by an A-IoT UE regarding an A-IoT configuration during Radio Resource Control (RRC) _CONNECTED, RRC_IDLE, and RRC_INACTIVE states, according to various aspects of the present disclosure.

[0017] FIG. 14 is a diagram of an example of components of a device according to various aspects of the present disclosure.DETAILED DESCRIPTION

[0018] The following detailed description refers to the accompanying drawings. Like reference numbers in different drawings may identify the same or similar features, elements, operations, etc. Additionally, the present disclosure is not limited to the following description, as other implementations may be utilized, and structural or logical changes made, without departing from the scope of the present disclosure.

[0019] Ambient Internet-of-Things (A-IoT) devices are often specialized low-power devices that operate within a large wireless network (e.g., a 3GPP network, such as a Fifth Generation (5G) network, also referred to as New Radio (NR) ) that may service many other wireless communication devices. This communication service is often provided to an A-IoT device by way of a “reader” device configured to communicate with both the A-IoT device and the network. Such a reader device may be a typical communication device (e.g., a user equipment (UE) , a base station (BS) , etc. ) that is suitable for ordinary use in the network, but may also possess enhanced or additional capabilities for servicing an A-IoT device. In other examples, the A-IoT reader device may be a dedicated A-IoT reader device that is only or primarily employed for A-IoT service while facilitating connection to the communication network.

[0020] As the various reader devices interact with the communication network while servicing the A-IoT devices, the reader devices consume some level of communication resources within that network. Accordingly, some level of control over the use of the communication resources by the reader device may be beneficial. However, as the nature of the reader devices, as well as the protocols or interfaces of the reader devices with the network, may vary considerably (e.g., UEs versus BSs, as mentioned above) , and the functionality of the reader devices themselves may differ greatly (e.g., typical network devices enhanced for A-IoT use versus dedicated A-IoT reader devices) , existing communications protocols between the wide spectrum of A-IoT reader devices and the network may also be quite diverse. In addition, an A-IoT core network (CN) configured to control A-IoT reader devices may possess some high level of control, while an A-IoT BS may provide control that is of a finer granularity than that possible via an A-IoT CN, potentially leading to complexity in the various types of reader device control available.

[0021] As is discussed in greater detail below, some aspects of the present disclosure facilitate the employment of techniques, such as communication protocols (e.g., commands, responses, and so on) that are the same or similar in substantive ways (e.g., from the perspective of an A-IoT CN) , thus facilitating a level of commonality that promotes consistent and effective  control of a variety of A-IoT reader device types within a wireless communication network.

[0022] FIG. 1 is an example network 100 according to one or more implementations described herein. Example network 100 may include one or more A-IoT devices 111, one or more user equipment (UEs) 110, a radio access network (RAN) 120 including one or more base stations (BSs) , a core network (CN) 130, application servers 140, and external networks 150.

[0023] The systems and devices of example network 100, other than A-IoT devices 111, may operate in accordance with one or more communication standards, such as Second-Generation (2G) , Third-Generation (3G) , Fourth-Generation (4G) (e.g., Long-Term Evolution (LTE) ) , and / or Fifth-Generation (5G) (e.g., New Radio (NR) ) communication standards of the Third-Generation Partnership Project (3GPP) . Additionally, or alternatively, one or more of the systems and devices of example network 100 may operate in accordance with other communication standards and protocols discussed herein, including future versions or generations of 3GPP standards (e.g., Sixth-Generation (6G) standards, Seventh-Generation (7G) standards, etc. ) , Institute of Electrical and Electronics Engineers (IEEE) standards (e.g., Wireless Metropolitan Area Network (WMAN) , Worldwide Interoperability for Microwave Access (WiMAX) , etc. ) , and more.

[0024] A-IoT devices 111 may be specialized low-power devices, as described above, that may be sensors or other data-generating devices that may be communicated with (e.g., “read” , “written” , and so on) by other devices of the network 100, such as UEs 110 (e.g., over a communication path or A-IoT link 112) or RAN nodes 122-1 and / or 122-2 (collectively, RAN nodes 122) , including one or more BSs (e.g., over a communication path 115) , each of which may operate as an A-IoT reader device. In some aspects, A-IoT devices 111 may engage in communications with an A-IoT reader device that may be logically subdivided into “inventory” communications (e.g., communications in which the reader device determines which A-IoT devices 111 are present and available) and “command” communications (e.g., communications in which reading of data, writing of data, and other A-IoT operations may be initiated) . A-IoT devices 111 may be objects having a digital identity, connectivity, and intelligence. Examples of A-IoT devices 111 may include devices provided by or for consumer merchants or manufacturers, such as those related to food, medicine, clothing, luggage, documents, industry, and so on.

[0025] UEs 110 may include smartphones (e.g., handheld touchscreen mobile computing devices connectable to one or more wireless communication networks) . Additionally, or alternatively, UEs 110 may include other types of mobile or non-mobile computing devices capable of wireless communications, such as personal data assistants (PDAs) , pagers, laptop  computers, desktop computers, wireless handsets, smartwatches, etc.

[0026] If or when UE 110 operates as a reader device for one or more A-IoT devices 111, UE 110 may be referred to as an “intermediate node” that is configured to perform bidirectional communication with a base station 120 over an access link 114 and perform bidirectional communication with A-IoT device 111 over A-IoT link 112.

[0027] UEs 110 may communicate and establish a connection (e.g., be communicatively coupled) with RAN 120, which may involve one or more wireless channels 114, each of which may include a physical communications interface / layer.

[0028] RAN 120 may include one or more RAN nodes 122-1 and 122-2 (referred to collectively as RAN nodes 122, and individually as RAN node 122) that enable channels 114 to be established between UEs 110 and RAN 120. RAN nodes 122 may include network access points configured to provide radio baseband functions for data and / or voice connectivity between users and the network based on one or more of the communication technologies described herein (e.g., 2G, 3G, 4G, 5G, WiFi, etc. ) . As examples, therefore, a RAN node may be an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (e.g., an enhanced Node B, eNodeB, eNB, 4G base station, etc. ) , a next-generation base station (e.g., a 5G base station, NR base station, next-generation eNBs (gNB) , etc. ) . RAN nodes 122 may include a roadside unit (RSU) , a transmission reception point (TRxP or TRP) , and one or more other types of ground stations (e.g., terrestrial access points) . In some scenarios, RAN node 122 may be a dedicated physical device, such as a macrocell base station, and / or a low power (LP) base station for providing femtocells, picocells, or the like having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells. Additionally, or alternatively, one or more of RAN nodes 122 can be next-generation eNBs (i.e., gNBs) that can provide E-UTRA user plane and control plane protocol terminations 126, 128 toward UEs 110, and that can be connected to a 5G core network (5GC) 130 via a Next Generation (NG) interface 124.

[0029] Any of the RAN nodes 122 can terminate an air interface protocol and can be the first point of contact for UEs 110. In some implementations, any of the RAN nodes 122 can fulfill various logical functions for the RAN 120, including, but not limited to, radio network controller (RNC) functions, such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management. UEs 110 can be configured to communicate using orthogonal frequency-division multiplexing (OFDM) communication signals with each other or with any of the RAN nodes 122 over a multicarrier communication channel in accordance with various communication techniques, such as, but not limited to, an orthogonal frequency-division multiple-access (OFDMA) communication  technique (e.g., for downlink communications) or a single-carrier frequency-division multiple-access (SC-FDMA) communication technique (e.g., for uplink and ProSe or sidelink (SL) communications) , although the scope of such implementations is not necessarily limited in this regard. The OFDM signals can include a plurality of orthogonal subcarriers.

[0030] In some implementations, a downlink resource grid may be used for downlink transmissions from any of the RAN nodes 122 to UEs 110, and uplink transmissions may utilize similar techniques. The grid may be a time-frequency grid (e.g., a resource grid or time-frequency resource grid) that represents the physical resource for downlink in each slot. Such a time-frequency plane representation is a common practice for OFDM systems, which makes it intuitive for radio resource allocation. Each column and each row of the resource grid corresponds to one OFDM symbol and one OFDM subcarrier, respectively. The duration of the resource grid in the time domain corresponds to one slot in a radio frame. The smallest time-frequency unit in a resource grid is denoted as a resource element (RE) . Each resource grid includes resource blocks (RBs) , which describe the mapping of certain physical channels to resource elements. Each RB may include a collection of REs; in the frequency domain, this may represent the smallest quantity of resources that currently may be allocated. There are several different physical downlink channels that are conveyed using such RBs.

[0031] The RAN nodes 122 may be configured to communicate with one another via interface 123. In implementations where the system is an LTE system, interface 123 may be an X2 interface. In NR systems, interface 123 may be an Xn interface. The X2 interface may be defined between two or more RAN nodes 122 (e.g., two or more eNBs / gNBs or a combination thereof) that connect to Evolved Packet Core (EPC) or CN 130, or between two eNBs connecting to an EPC.

[0032] CN 130 may include a plurality of network elements 132, which are configured to offer various data and telecommunications services to customers / subscribers (e.g., users of UEs 110) who are connected to the CN 130 via the RAN 120. In some implementations, CN 130 may include an EPC, a 5G CN, and / or one or more additional or alternative types of CNs. The components of the CN 130 may be implemented in one physical node or separate physical nodes including components to read and execute instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) .

[0033] As shown, CN 130, application servers 140, and external networks 150 may be connected to one another via interfaces 134, 136, and 138, which may include IP network interfaces.

[0034] FIG. 2 is a block diagram of an example A-IoT wireless network 100A exhibiting two network topologies associated with operating A-IoT devices 111. One or more of the devices depicted in A-IoT wireless network 100A may be enhanced 3GPP wireless network devices that include functionality for operating with A-IoT devices 111 while retaining a wide range of 3GPP functionality. In other examples, one or more of the devices in A-IoT wireless network 100A may be dedicated devices that are particularly configured for operating with A-IoT devices 111 while providing sufficient functionality for providing 3GPP connectivity to A-IoT devices 111. For example, A-IoT CN 230 may be an enhanced 3GPP CN (e.g., a 5G core (5GC) network or a dedicated A-IoT CN) . The same may be true of A-IoT AMF 232 within A-IoT CN 230 and / or other network elements within A-IoT CN 230. Similarly, A-IoT BS reader device 222A and / or an A-IoT BS 222B may be an enhanced 3GPP network node (e.g., a 5G New Radio (NR) next-generation NodeB (gNB) ) .

[0035] Two network topologies are illustrated in FIG. 2: Topology 1 200A, in which a base station (e.g., RAN node 122) operates as an A-IoT BS reader device 222A that communicates directly with A-IoT device 111; and Topology 2 200B, in which a UE 110 operates as an A-IoT UE reader device 210 that communicates directly with A-IoT device 111. Further, in Topology 1 200A, A-loT BS reader device 222A provides connectivity for A-IoT device 111 to A-IoT CN 230, which may include an A-IoT AMF 232. In Topology 2 200B, A-IoT UE reader device 210 (e.g., functioning as an intermediate node) may provide similar connectivity for A-IoT device 111 to A-IoT CN 230 by way of an A-IoT BS 222B. In this topology, A-IoT BS 222B is not operating as an A-IoT reader device; however, in some aspects, a BS may operate as both an A-IoT BS reader device 222A and an A-IoT BS 222B, depending on the particular A-IoT devices 111 involved, as well as other parameters.

[0036] FIG. 2 further depicts two types of interfaces or communication protocols for A-IoT reader device control: an ‘Xx’ interface that communicatively couples A-IoT BS reader device 222A or A-IoT BS 222B to A-IoT CN 230, and a ‘Yy’ interface that communicatively couples A-IoT BS 222B to A-IoT UE reader device 210. As employed herein, each of the interface names ‘Xx’ , ‘Yy’ , ‘Zz’ , and ‘Ww’ employed herein are “placeholders” that identify example protocols (e.g., including particular commands, responses, data, and so on) that may be employed to provide A-IoT reader device control, as described in greater detail below. As with the particular devices involved, in some aspects, such interfaces may be preexisting interfaces  (e.g., 3GPP-related interfaces) that are enhanced or augmented to provide A-IoT reader control. In other aspects, the interfaces may be new interfaces particularly dedicated to A-IoT reader device control.

[0037] The Xx interface, for example, may be an extension of the Next Generation Application Protocol (NGAP) , which may be used on the NG / N2 interface (e.g., as described in 3GPP Technical Specification (TS) 38.413) , or may be a dedicated protocol having at least some of the characteristics described below. To promote understanding, however, various aspects of the Xx interface are described as NGAP extensions.

[0038] FIGS. 3A through 3D are message flow diagrams illustrating messaging between A-IoT base station (BS) 222B or A-IoT BS reader device 222A and A-IoT core network (CN) 230 over the Xx interface to provide authorization functionality, according to various aspects of the present disclosure. In some aspects, one or more devices may be authorized to operate as an A-IoT reader device within the network under the control of A-IoT CN 230. More specifically, in some aspects, multiple authorization types or levels may be supported in which A-IoT CN 230 (1) may authorize an A-IoT BS to operate as A-Iot BS reader device 222A, (2) may authorize A-IoT BS to operate as A-IoT BS 222B to service one or more A-IoT UE reader devices 210, and / or (3) may authorize one or more individual UEs 110 to operate as A-IoT UE reader devices 210.

[0039] In FIG. 3A, for example, message flow 300A may include an NG Setup Response message 304 (e.g., a message of the NGAP) that includes an information element (IE) indicating that A-IoT BS reader device 222A is authorized to operate as a reader device. In some aspects, NG Setup Response message 304 may be transmitted in response to receiving an NG Setup Request message 302 from A-IoT BS reader device 222A. Further, in some aspects, NG Setup Request message 302 may include an IE indicating that A-IoT BS reader device 222A is explicitly requesting the authorization. Alternatively, in some aspects, the request for authorization may be implicit (e.g., A-IoT CN 230 may assume that every A-IoT BS that possesses reader device capability implicitly requests such authorization in every NG Setup Request message 302) .

[0040] In another aspect, as depicted in FIG. 3B, message flow 300B may include an NG Setup Response message 314 that includes an IE indicating that A-IoT BS 222B is authorized to service one or more A-IoT UE reader devices 210. In some aspects, NG Setup Response message 314 may be transmitted in response to receiving an NG Setup Request message 312 from A-IoT BS 222B. Additionally, in some aspects, NG Setup Request message 302 may include an IE indicating that A-IoT BS 222B is explicitly requesting the authorization.  Alternatively, in some aspects, the request for authorization may be implicit (e.g., A-IoT CN 230 may assume that every A-IoT BS 222B implicitly requests such authorization in every NG Setup Request message 312) .

[0041] Further, in some aspects, a single IE or multiple IEs may indicate authorization as both an A-IoT BS reader device 222A and an A-IoT BS 222B that services one or more A-IoT UE reader devices 210 within a single NG Setup Response message 304 and 314. Also, in some aspects, a single NG Setup Request message 302 and 312 may include one or multiple IEs that indicate a request for authorization as an A-IoT BS reader device 222A and / or an A-IoT BS that services one or more A-IoT UE reader devices 210.

[0042] With respect to authorization of one or more individual UEs 110 to operate as A-IoT UE reader devices 210, FIG. 3C depicts a message flow 300C in which A-IoT CN 230 transmits an Initial Context Setup Request message 324 that may include an indication as to whether a particular one or more UEs 110 is granted such authorization. In some aspects, Initial Context Setup Request message 324 may be transmitted in response to receiving an Initial UE message 322 from A-IoT BS 222B. In some aspects, Initial UE message 322 may be transmitted in response to an associated UE 110 connecting or registering with the network. Additionally, in some aspects, Initial UE message 322 may include an explicit indication that A-IoT BS 222B is requesting the authorization. Alternatively, in some aspects, the request for authorization may be implicit (e.g., A-IoT CN 230 may assume that every UE 110 implicitly requests authorization as an A-IoT UE reader device 210 in every Initial UE message 322) .

[0043] FIG. 3D illustrates a message flow 300D in which A-IoT CN 230 transmits a message 334 (e.g., a UE Context Modification Request message) that includes an indication as to whether a particular one or more UEs 110 is granted authorization as A-IoT UE reader device 210. In some aspects, the use of the UE Context Modification Request message may facilitate the granting of authorization at some point after connection of UE 110 to the network (e.g., when such authorization was not initially requested) .

[0044] Also as shown in FIG. 3D, as was the case with Initial Context Setup Request message 324, message 334, which may be a Downlink Non-Access-Stratum (NAS) Transport message or a UE Context Modification Request message, may include an unsolicited indication as to whether one or more UEs 110 are authorized to operate as A-IoT UE reader devices 210 (e.g., in response to UEs 110 connecting to the network via A-IoT BS 222B) .

[0045] Further, with respect to FIGS. 3C and 3D, A-IoT CN 230 may grant such authorization to one or more UEs 110 based on subscription information.

[0046] Moreover, with respect to all authorization types discussed above, A-IoT CN 230  may transmit or include a separate indication as to whether the reader device to be authorized (e.g., A-IoT BS reader device 222A or A-IoT UE reader device 210) is authorized to transmit a carrier wave (CW) that may employed by an A-IoT device to reflect or backscatter to the reader device with data (e.g., sensor data) encoded thereon.

[0047] FIGS. 4A and 4B are message flow diagrams illustrating messaging between A-IoT BS 222B or A-IoT BS reader device 222A and A-IoT CN 230 over the Xx interface to provide paging functionality, according to various aspects of the present disclosure. In some aspect, the paging described herein refers to paging of an A-IoT device 111 (e.g., for inventory purposes, to discover A-IoT devices 111 available to the reader device) , as opposed to paging of an A-IoT UE reader device 210. Further, such paging may be optional in some aspects (e.g., when paging is employed by way of the Zz interface, described in greater detail below) .

[0048] In some aspects, messages that employ the paging functionality for A-IoT devices may be provided in an extension of the paging messages provide for UEs 110 in the NGAP, in which UE 110 paging may be differentiated from the paging of A-IoT devices 111 described herein, such as by determining whether the identities included in the paging messages are A-IoT identities instead of UE 110 identities. In other aspects, new NGAP paging messages may be specifically defined for A-IoT devices 111 (e.g., messages in which information specific to paging of UEs 110, such as a UE Paging Identity, a Tracking Area Identifier (TAI) , and so on, may be omitted) .

[0049] In either network topology (e.g., Topology 1 200A or Topology 2 200B) , a transmission of the same paging message may result in a paging operation that is appropriate for the topology. For example, FIG. 4A illustrates a message flow 400A for Topology 1 200A, in which A-IoT CN 230 transmits an NGAP Paging message 404 to A-IoT BS reader device 222A, which may cause A-IoT BS reader device 222A to perform an A-IoT air interface paging / inventory operation to determine which A-IoT devices 111 are present and available to A-IoT BS reader device 222A.

[0050] FIG. 4B illustrates a message flow 400B for Topology 2 200B) , in which A-IoT CN 230 transmits an NGAP Paging message 414 (e.g., including the same information as NGAP Paging message 404 of FIG. 4A) to A-IoT BS 222B, which, in turn may transmit an Radio Resource Control (RRC) message to one or more A-IoT UE reader devices 210, causing such reader devices to perform an A-IoT air interface paging / inventory operation, as described above.

[0051] In some aspects, NGAP Paging message 404 and / or 414 may include one or more identity types to be used for identifying A-IoT devices 111 to be paged, including, but not limited to, a single A-IoT device 111 identity (e.g., distinguished from a UE 110 ID) , a list of a  plurality of A-IoT device 111 identities, a single group of A-IoT device 111 identities, or a list of a plurality of A-IoT device 111 group identities.

[0052] In some aspects, one or more data elements provided in Assistance Data for Paging of UEs 110 (e.g. as discussed in Section 9.3.1.69 of 3GPP TS 38.413) may be repurposed for A-IoT device 111 paging. Moreover, additional paging assistance data specific to A-IoT device 111 use may be considered. For example, such assistance data may include, but is not limited to, an A-IoT device type (e.g. a device type related to a level or range of A-IoT power consumption, a device type associated with upper-layer functionality (e.g., a particular A-IoT communication protocol) , and so on) .

[0053] Further, in some aspects, an A-IoT device 111 paging message (e.g., NGAP Paging message 404 or 414) may include one or more data elements (e.g., IEs) of the NGAP Paging message for UEs repurposed for paging of A-IoT devices 111. In some aspects, such data elements may include, but are not limited to, an A-IoT device 111 Paging Identity IE, an A-IoT Assistance Data for Paging IE, an A-IoT Radio Capability for Paging IE, and / or an A-IoT Paging Cause IE. In some aspects, an A-IoT Paging Cause IE may include an indication whether the paging is for “inventory” purposes (e.g., to determine what A-IoT devices are present and available) or “command” purposes (e.g., for the reading and writing of data) . In some aspects, such a distinction between inventory and command operations may be useful, as additional radio resources may be provided to facilitate the reading and / or writing of data associated with a command operation.

[0054] FIGS. 5A and 5B are message flow diagrams illustrating messaging between an A-IoT BS 222B or an A-IoT BS reader device 222A and an A-IoT CN 230 over the Xx interface to control radio resources used for A-IoT communications, according to various aspects of the present disclosure. In some aspects, such radio resource control may be high-level control of various radio resources, as distinguished from more detailed control (e.g., scheduling) , as may be provided over the Yy interface, as discussed below.

[0055] FIG. 5A, for example, illustrates a message flow 500A including an NG Setup Response message 504 transmitted from A-IoT CN 230 that may include an authorization to operate as A-IoT BS reader device 222A, along with control information for A-IoT BS reader device 222A of Topology 1 200A or A-IoT BS 222B of Topology 2 200B. Such control information may include, but is not limited to, frequencies in which A-IoT communication (e.g., between an A-IoT device 111 and a reader device) is allowed, locations (e.g., in the form of geographic coordinates, cell IDs, TAIs, or the like) where such A-IoT communication is allowed (e.g., as defined by regulatory restrictions in certain areas) , transmission power allowed for A- IoT communication in the specified location or geographic area, and so on.

[0056] FIG. 5B illustrates a message flow 500B including an AMF Configuration Update message 514 that may include the same or similar control information as that listed above in conjunction with NG Setup Response message 504 of FIG. 5A. In some aspects, while NG Setup Response message 504 may be the first message received by A-IoT BS reader device 222A or A-IoT BS 222B (e.g., as described above in connection with FIGS. 3A and 3B depicting authorization for a device to operate as an A-IoT reader device) , AMF Configuration Update message 514 may be transmitted by A-IoT CN 230 to A-IoT BS reader device 222A or A-IoT BS 222B at any time thereafter.

[0057] In yet other aspects, a separate dedicated A-IoT configuration message associated with the NG interface may provide the same or similar radio resource control information presented above. Also, in some aspects, alternative or additionally, the radio resource control information outlined above may be communicated to A-IoT BS reader device 222A or A-IoT BS 222B by way of an operations, administration, and maintenance (OAM) protocol used for network management.

[0058] FIGS. 6A through 6E are message flow diagrams illustrating messaging between an A-IoT BS 222B and an A-IoT UE reader device 210 over the Yy interface, according to various aspects of the present disclosure. In some aspects, the Yy interface may be employed in conjunction with the Xx interface (e.g., to forward messages received over the Xx interface at A-IoT BS 222B to A-IoT UE reader device 210 via the Yy interface) . More specifically, in some aspects, the Yy interface may be an air control plane interface connecting A-IoT BS 222B and A-IoT UE reader device 210, and thus may be particularly relevant to Topology 2 200B of FIG. 2. In some aspects, the Yy interface may employ some characteristics of a Uu radio interface between a RAN node 122 (e.g., a BS) and a UE 110. Accordingly, in some aspects, the Yy interface may employ characteristics of an RRC protocol, which may include extensions that provide more radio control functionality that may be desirable for A-IoT operation, although a dedicated A-IoT proposed with similar messages and / or IEs as those described below may be employed in lieu of an RRC protocol.

[0059] FIG. 6A illustrates a message flow 600A in which system information (e.g., a system information block, such as SIB1) 602 transmitted from A-IoT BS 222B to A-IoT UE reader device 210 may provide an indication as to whether A-IoT BS 222B (e.g., a cell associated with A-IoT BS 222B) supports A-IoT UE reader device 210. In some aspects, such an indication of support may be unsolicited by A-IoT UE reader device 210, as A-IoT BS 222B may presume that connection therewith may only be desirable within the A-IoT reader device context.  Additionally, in some aspects, an indication of direct support by A-IoT BS 222B as an I-IoT BS reader device 222A for an A-IoT device 111, may also be included in SIB1 602.

[0060] Additionally or alternatively, the RRC protocol may be employed to provide similar support information. For example, FIG. 6B illustrates a message flow 600B in which an RRCSetup or RRCResume message 612 transmitted by A-IoT BS 222B to A-IoT UE reader device 210 may include an indication as to whether A-IoT BS 222B supports A-IoT UE reader device 210. Further, in some aspects, RRCSetup or RRCResume message 612 may include, but is not limited to, an indication as to whether the cell of A-IoT BS 222B supports A-IoT UE reader devices (e.g., including A-IoT UE reader device 210 of FIG. 6A) .

[0061] In response to RRCSetup or RRCResume message 612, the responding UE 110 may transmit a message 614. In some aspects, message 614 may include RRC capabilities signaling, including, but not limited to, whether UE 110 is an A-IoT UE reader device 210 and / or which types of A-IoT device 111 are supported by A-IoT UE reader device 210. Further, in some aspects, the capabilities information listed above may be provided in message 614 that is an RRCSetupComplete or RRCResumeComplete message (e.g., as an immediate indication that may be provided to A-IoT BS 222B in response to RRCSetup or RRCResume message 612) .

[0062] Moreover, in some aspects, to provide the above capabilities information, A-IoT UE reader device 210 may transmit to A-IoT BS 222B a UEAssistanceIndication message as message 614. Such a message may be employed by A-IoT UE reader device 210 to provide a more dynamic and timely indication that A-IoT UE reader device 210 currently intends to operate as an A-IoT reader device, along with the relevant capabilities information. Otherwise, in some aspects, A-IoT BS 222B may presume that A-IoT UE reader device 210 always operates as an A-IoT reader device.

[0063] FIG. 6C illustrates a message flow 600C in which A-IoT BS 222B transmits to A-IoT UE reader device 210 an RRCReconfiguration message 622, which may include, for example, radio resources that A-IoT UE reader device 210 is allowed to use for communicating with one or more A-IoT devices 111. In some aspects, reception of RRCReconfiguration message 622 may implicitly indicate that A-IoT UE reader device 210 is authorized or allowed to begin operating as an A-IoT reader device. In some aspects, RRCReconfiguration message 622 may be transmitted in response to A-IoT BS 222B receiving a message from A-IoT CN 230 authorizing A-IoT UE reader device 210 to operate as a reader device (e.g., Initial Context Setup Request message 324 of FIG. 3C, or UE Context Modification Request message or Downlink NAS Transport messsage 334 of FIG. 3D) . Consequently, use of RRCReconfiguration message 622 may allow A-IoT BS 222B to control radio resources that are scheduled by A-IoT UE reader  device 210. In some aspects, other radio-related control information (e.g., power control) may be included in RRCReconfiguration message 622. Moreover, in some aspects, RRCReconfiguration message 622 may include an indication to activate or deactivate the reader device functionality of A-IoT UE reader device 210. Additionally or alternatively, as shown in message flow 600D of FIG. 6D, A-IoT BS 222B may transmit a Media Access Control (MAC) Control Element (CE) 632 to A-IoT UE reader device 210 that includes an indication to activate or deactivate the reader device functionality of A-IoT UE reader device 210 (e.g., as an alternative to RRC activation / deactivation) .

[0064] FIG. 6E illustrates a message flow 600E in which A-IoT BS 222B transmits to A-IoT UE reader device 210 a paging message 642, which, in some aspects, may serve as a paging relay of an NGAP Paging message (e.g., NGAP Paging message 414 of FIG. 4B, as used in Topology 2 200B) from A-IoT CN 230 to A-IoT UE reader device 210. In some aspects, paging message 642 may be one or more of an extension of an RRC Paging message, another RRC message (e.g., an RRCReconfiguration message) , a MAC CE, or a packet data unit (PDU) . Further, in some aspects, all of these messages may employ the same A-IoT device identifiers mentioned above in conjunction with the NGAP Paging messages 404 and 414 of FIGS. 4A and 4B.

[0065] FIG. 7 is a block diagram of an example A-IoT wireless network 100B exhibiting two topologies (e.g., Topology 1 200A and Topology 2 200B) associated with operating A-IoT devices and employing a Zz interface, according to various aspects of the present disclosure. As depicted in FIG. 7, the Zz interface may extend from A-IoT CN 230 to both A-IoT BS reader device 222A of Topology 1 200A to A-IoT UE reader device 210 in Topology 2 200B. In some aspects, the Zz interface may replace some functionalities (e.g., paging) described above in connection with the Xx and Yy interfaces (e.g., with respect to A-IoT inventory signaling) . In some aspects, the Zz interface may also be used for A-IoT command signaling, such as described above. Further, in some aspects, in Topology 2 200B, the Zz interface may transparently “pass through” A-IoT BS 222B, as A-IoT BS 222B may not be required to process or otherwise be aware of the information being passed from A-IoT CN 230 to A-IoT UE reader device 210. Alternatively, in some aspects, A-IoT BS 222B may interpret at least some of the information passing therethrough to facilitate efficient operation of the Zz interface.

[0066] Further, use of the Zz interface may be accompanied with some reduced functionality of the Xx and Yy interfaces, as those interfaces are described above. Also, in some aspects, some non-A-IoT-specific enhancements to the NG / N2 interface (e.g., associated above with some aspects of the Xx interface) and to the Uu interface (e.g., associated above with some  aspects of the Yy interface) may be desirable to implement the Zz interface. Some aspects, as discussed in greater detail below, may include an extension of the NAS protocol, or may be a separate, dedicated protocol.

[0067] In some aspects in which the Zz interface supports inventory-related messages, paging mechanisms discussed above in association with the Xx and Yy interfaces may not be implemented. In such aspects, other portions of the Xx and Yy interfaces, as described, may still be implemented in conjunction with the Zz interface.

[0068] In some aspects, different variants of the Zz interface may be employed respectively for Topology 1 200A and Topology 2 200B. From the perspective of A-IoT CN 230, possibly including an A-IoT Application Function (AF) mentioned below, the different variants may appear to be the same. However, differences may exist in how A-IoT BS reader device 222A and A-IoT BS 222B implement the Zz interface.

[0069] In the discussion below, according to some aspects, inventory and command signaling may be referred to as A-IoT data. Also, in some aspects, enhancements of the NAS protocol may be used to carry A-IoT data regardless of whether Topology 1 200A or Topology 2 200B is being utilized. However, use of Topology 1 200A, in which A-IoT BS reader device 222A interfaces directly with one or more A-IoT devices 111, may represent a departure from a typical use of the NAS protocol. In other aspects, a protocol other than NAS may be employed that may terminate in A-IoT BS reader device 222A in Topology 1 200A and in A-IoT UE reader device 210 in Topology 2 200B.

[0070] FIG. 8 is a block diagram of an example A-IoT CN 230 in an A-IoT network 800, according to various aspects of the present disclosure. As depicted in FIG. 8, A-IoT CN 230 is coupled with A-IoT device 111 via A-IoT BS reader device 222A in Topology 1 200A. However, in other examples, A-IoT CN 230 may be coupled with A-IoT device 111 via A-IoT BS 222B and A-IoT BS reader device 222A. In both topologies, although the Zz interface extends between A-IoT CN 230 and a reader device, IoT data may be transported to the corresponding A-IoT device 111.

[0071] As depicted in FIG. 8, A-IoT CN 230 may include a plurality of functional elements, including, but not limited to, Network Slice Selection Function (NSSF) 802, Network Exposure Function (NEF) 804, Network Repository Function (NRF) 806, Policy Control Function (PCF) 808, United Data Management (UDM) 810, Authentication Server Function (AUSF) 812, Application Function (AF) 814, A-IoT Control Function (AIOTCF) 816, Access and Mobility Management Function (AMF) 818, Session Management Function (SMF) 820, and Service Communication Proxy (SCP) 822. In some aspects, AIOTCF 816 may be integrated with AMF  818. Additionally, in some aspects, SMF 820 may be coupled to a data network (DN) 826 by way of a User Plane Function (UPF) 824.

[0072] FIG. 9 is a block diagram of an example A-IoT architecture and control plane protocol stack for Topology 1 200A when employing the Zz interface, according to various aspects of the present disclosure. In the example of FIG. 9, while A-IoT NAS may be employed for transferring A-IoT data between AF 814 and A-IoT device 111 via A-IoT BS reader device 222A, in other aspects, A-IoT data may be encapsulated into the NGAP protocol, thus potentially eliminating the need for A-IoT NAS messaging.

[0073] In some aspects, A-IoT BS reader device 222A may receive A-IoT data from AF 814 via the NGAP or NAS protocol, as discussed above, extract one or more A-IoT data PDUs, and forward the A-IoT data to A-IoT device 111 using an A-IoT control plane protocol. Additionally, in some aspects, A-IoT BS reader device 222A may inspect the A-IoT data being forwarded (e.g., to detect inventory-related data, as A-IoT BS reader device 222A may process A-IoT data differently compared to command-related data) .

[0074] FIG. 10 is a block diagram of an example A-IoT architecture and control plane protocol stack for Topology 2 200B when employing the Zz interface, according to various aspects of the present disclosure. In some aspects, A-IoT data is transferred between A-IoT AF 814 and A-IoT device 111 by way of NAS messaging employed to transmit data between A-IoT UE reader device 210 and AIOTCF 816 via A-IoT BS 222B.

[0075] In some aspects, A-IoT UE reader device 210 may receive A-IoT data encapsulated in NAS messaging via A-IoT BS 222B, extract one or more A-IoT data PDUs, and forward the A-IoT data to A-IoT device 111 using an A-IoT control plane protocol. Additionally, in some aspects, A-IoT UE reader device 210 may inspect the A-IoT data being forwarded (e.g., to detect inventory-related data, as A-IoT UE reader device 210 may process A-IoT data differently compared to command-related data) .

[0076] FIG. 11 is a block diagram of an example A-IoT wireless network 100C exhibiting Topology 1 200A and Topology 2 200A associated with operating A-IoT devices 111 and employing interface Xx, interface Yy, and interface Ww, according to various aspects of the present disclosure. Particularly, interface Ww couples two BSs (e.g., a first A-IoT BS reader device 222A or A-IoT BS 222B and a second A-IoT BS reader device 222A or A-IoT BS 222B) . In some aspects, interface Ww may be an extension of an Xn interface, or a separate dedicated interface, that may facilitate coordination between A-IoT BSs and mobility of A-IoT UE reader devices 210. More specifically, messaging in the Ww interface may be implemented using XnAP extensions; however, a dedicated A-IoT protocol may be used in lieu of XnAP  messaging, with similar messages and associated IEs.

[0077] FIGS. 12A and 12B are message flow diagrams illustrating messaging between A-IoT BSs 222B and / or A-IoT BS reader devices 222A over the Ww interface, according to various aspects of the present disclosure. For example, FIG. 12A illustrates a message flow 1200A in which a first A-IoT BS 222B or A-IoT BS reader device 222A may transmit an Xn Setup Request / Response or NG-RAN Configuration Update message 1202 to a second A-IoT BS 222B or A-IoT BS reader device 222A. In some aspects, the Xn Setup Request / Response message may be an initial message passed between the BSs, while the NG-RAN Configuration Update message may be transmitted one or more times thereafter. In some aspects, Xn Setup Request / Response or NG-RAN Configuration Update message 1202 may include information such as whether the transmitting BS / cell supports A-IoT operations, and / or whether the transmitting BS / cell supports A-IoT devices 111, A-IoT UE reader devices 210, and / or A-IoT CW-transmitting UEs. Such information may include, in some aspects, indications of radio resources used for communicating with A-IoT devices 111.

[0078] FIG. 12B illustrates a message flow 1200B in which a first A-IoT BS 222B or A-IoT BS reader device 222A may transmit an Xn Resource Status Request / Update and / or Data Collection Request / Response message 1212. Message 1212 may carry information that includes one or more of a number of A-IoT UE reader devices 210 connected to the transmitting BS, a number of A-IoT CW-transmitting UEs connected to the transmitting BS, a number of A-IoT devices 111 connected to the transmitting BS, and a resource load generated by such A-IoT devices 111.

[0079] FIGS. 13A and 13B are flow diagrams outlining example methods employable by an A-IoT UE regarding an A-IoT configuration during Radio Resource Control (RRC) _CONNECTED, RRC_IDLE, and RRC_INACTIVE states, according to various aspects of the present disclosure. In some aspects, these flow diagrams are equally applicable to both A-IoT UE reader devices 210 and A-IoT CW-transmitting UEs, even if deployed as separate devices. In the descriptions that follow, both A-IoT UE reader devices 210 and A-IoT CW-transmitting UEs are collectively referred to as A-IoT UEs. Also, in some embodiments, the A-IoT configuration may include information such as whether the A-IoT UE is authorized to operate as an A-IoT UE reader device 210 or A-IoT CW-transmitting UE, radio resources allocated to the A-IoT UE, geolocation of the A-IoT UE, and / or additional information describing the A-IoT UE.

[0080] FIG. 13A, for example, illustrates a flow diagram of a method 1300A in which the A-IoT UE is presumed to remain in an RRC_CONNECTED state to an A-IoT BS 222B, and  thus under the control thereof, notwithstanding extraordinary conditions, such as becoming disconnected from A-IoT BS 222B due to signal interference or other factors.

[0081] In method 1300A, at Act 1302, if the A-IoT UE is handed over to another A-IoT BS, the A-IoT UE maintains its A-IoT configuration at Act 1304 (e.g., prior to the new A-IoT BS providing a new A-IoT configuration) . At Act 1306, if a radio link failure (RLF) or handover failure (HOF) occurs, the A-IoT UE releases its A-IoT configuration at Act 1308. At Act 1310, if the A-IoT UE is released to the RRC_IDLE state or the RRC_INACTIVE state, the A-IoT UE releases its A-IoT configuration (e.g., if not released explicitly by the network) at Act 1312.

[0082] FIG. 13B illustrates a flow diagram of a method 1300B in which the A-IoT UE may be released to the RRC_INACTIVE state while continuing to operate as an A-IoT UE reader device 210 and / or CW-transmitting UE, in which case the A-IoT UE may utilize small data transmission (SDT) for communications with the network.

[0083] In the method 1300B, at Act 1320, the A-IoT UE may reselect to another BS / cell (e.g., caused by mobility of the A-IoT UE) . At Act 1322, if the new BS / cell supports A-IoT operation, the A-IoT UE may maintain its IoT configuration (e.g., in anticipation of the new BS / cell providing a new A-IoT configuration for the A-IoT UE) at Act 1324. If, instead, the new BS / cell does not support A-IoT operations, the A-IoT UE may release its A-IoT configuration at Act 1326 (e.g., as A-IoT devices may not be authorized to initiate A-IoT transmissions in an uncontrolled manner without oversight from a BS / cell providing A-IoT support) .

[0084] As can be seen from the foregoing disclosure, aspects of the present disclosure may provide more consistent, and thus efficient, control of A-IoT reader devices (e.g., A-IoT BS reader devices 222A and / or A-IoT UE reader devices 210) in the presence of multiple network topologies, particularly from the viewpoint of an A-IoT CN 230 and included functional elements.

[0085] Above are several flow diagrams outlining example methods and exchanges of messages. In this description and the appended claims, use of the term “determine” with reference to some entity (e.g., parameter, variable, and so on) in describing a method step or function is to be construed broadly. For example, “determine” is to be construed to encompass, for example, receiving and parsing a communication that encodes the entity or a value of an entity. “Determine” should be construed to encompass accessing and reading memory (e.g., lookup table, register, device memory, remote memory, and so on) that stores the entity or value for the entity. “Determine” should be construed to encompass computing or deriving the entity or value of the entity based on other quantities or entities. “Determine” should be construed to encompass any manner of deducing or identifying an entity or value of the entity.

[0086] As used herein, the term “identify” , when used with reference to some entity or value of an entity, is to be construed broadly as encompassing any manner of determining the entity or value of the entity. For example, the term “identify” is to be construed to encompass, for example, receiving and parsing a communication that encodes the entity or a value of the entity. The term “identify” should be construed to encompass access... ing and reading memory (e.g., device queue, lookup table, register, device memory, remote memory, and so on) that stores the entity or value for the entity.

[0087] As used herein, the term “encode” , when used with reference to some entity or value of an entity, is to be construed broadly as encompassing any manner or technique for generating a data sequence or signal that communicates the entity to another component.

[0088] As used herein, the term “select” , when used with reference to some entity or value of an entity, is to be construed broadly as encompassing any manner of determining the entity or value of the entity from amongst a plurality or range of possible choices. For example, the term “select” is to be construed to encompass accessing and reading memory (e.g., lookup table, register, device memory, remote memory, and so on) that stores the entities or values for the entity and returning one entity or entity value from amongst those stored. The term “select” is to be construed as applying one or more constraints or rules to an input set of parameters to determine an appropriate entity or entity value. The term “select” is to be construed as broadly encompassing any manner of choosing an entity based on one or more parameters or conditions.

[0089] As used herein, the term “derive” , when used with reference to some entity or value of an entity, is to be construed broadly. “Derive” should be construed to encompass accessing and reading memory (e.g., lookup table, register, device memory, remote memory, and so on) that stores some initial value or foundational values and performing processing and / or logical / mathematical operations on the value or values to generate the derived entity or value for the entity. The term “derive” should be construed to encompass computing or calculating the entity or value of the entity based on other quantities or entities. The term “derive” should be construed to encompass any manner of deducing or identifying an entity or value of the entity.

[0090] As used herein, the term “indicate” , when used with reference to some entity (e.g., parameter or setting) or value of an entity, is to be construed broadly as encompassing any manner of communicating the entity or value of the entity, either explicitly or implicitly. For example, bits within a transmitted message may be used to explicitly encode an indicated value or may encode an index or other indicator that is mapped to the indicated value by prior configuration. The absence of a field within a message may implicitly indicate a value of an entity based on prior configuration.

[0091] Examples

[0092] Example 1 includes a baseband processor configured to perform operations including: receiving, at a base station (BS) , a first authorization message from a core network (CN) , the first authorization message indicating at least one of the BS being authorized to operate as an Ambient Internet-of-Things (A-IoT) reader device or the BS being authorized to service at least one user equipment (UE) operating as an A-IoT reader device; and performing at least one of: communicating, as an A-IoT reader device, with at least one A-IoT device in response to the first authorization message indicating that the BS is authorized to operate as an A-IoT reader device; or generating for transmission a notification message to one or more UEs indicating the BS supports at least one UE operating as an A-IoT reader device in response to the first authorization message indicating that the BS is authorized to service at least one UE operating as an A-IoT reader device.

[0093] Example 2 includes the subject matter of Example 1, including or omitting optional elements, wherein the first authorization message indicates the BS is authorized to operate as an A-IoT reader device and the BS is authorized to service at least one UE operating as an A-IoT reader device.

[0094] Example 3 includes the subject matter of Example 1, including or omitting optional elements, wherein the first authorization message includes a Next Generation (NG) Setup Response message.

[0095] Example 4 includes the subject matter of Example 3, including or omitting optional elements, wherein the operations further include generating for transmission, to the CN, an NG Setup Request message indicating a request for authorization of the BS to operate as an A-IoT reader device, wherein the NG Setup Response message is received in response to the NG Setup Request message.

[0096] Example 5 includes the subject matter of Example 1, including or omitting optional elements, wherein the operations further include receiving, at the BS, a second authorization message from the CN, the second authorization message indicating a UE communicatively coupled with the BS being authorized to operate as an A-IoT reader device.

[0097] Example 6 includes the subject matter of Example 5, including or omitting optional elements, wherein the second authorization message includes an Initial Context Setup Request message.

[0098] Example 7 includes the subject matter of Example 6, including or omitting optional elements, wherein the operations further include generating for transmission, to the CN, an Initial UE message indicating a request for authorization of the UE to operate as an A-IoT reader  device, wherein the Initial Context Setup Request message is received in response to the Initial UE message.

[0099] Example 8 includes the subject matter of Example 5, including or omitting optional elements, wherein the second authorization message includes at least one of a UE Context Modification Request message or a Downlink Non-Access Stratum (NAS) Transport message.

[0100] Example 9 includes the subject matter of Example 5, including or omitting optional elements, wherein the operations further include generating for transmission, to the UE, a third authorization message activating an A-IoT reader function of the UE in response to receiving the second authorization message.

[0101] Example 10 includes the subject matter of Example 9, including or omitting optional elements, wherein the third authorization message includes a Radio Resource Control (RRC) Reconfiguration message.

[0102] Example 11 includes the subject matter of Example 10, including or omitting optional elements, wherein the RRC Reconfiguration message further includes an indication of radio resources available to the UE for the A-IoT reader function.

[0103] Example 12 includes the subject matter of Example 1, including or omitting optional elements, wherein the operations further include receiving, from the CN, a first paging message after receiving the first authorization message, the first paging message including at least one A-IoT device identity.

[0104] Example 13 includes the subject matter of Example 12, including or omitting optional elements, wherein the first paging message includes a Next Generation Application Protocol (NGAP) Paging message.

[0105] Example 14 includes the subject matter of Example 12, including or omitting optional elements, wherein the first paging message includes at least one of a single A-IoT device identity, a list of a plurality of A-IoT device identities, a single A-IoT device group identity, or a list of a plurality of A-IoT device group identities.

[0106] Example 15 includes the subject matter of Example 12, including or omitting optional elements, wherein the first paging message further includes an A-IoT device type.

[0107] Example 16 includes the subject matter of Example 12, including or omitting optional elements, wherein the operations further include at least one of initiating, when the BS is authorized to operate as an A-IoT reader device, an A-IoT air interface inventory operation; or generating for transmission, when the BS is authorized to service at least one UE operating as an A-IoT reader device, a second paging message to an A-IoT UE reader device.

[0108] Example 17 includes the subject matter of Example 16, including or omitting  optional elements, wherein the second paging message includes one of a Radio Resource Control (RRC) Paging message, an RRC Reconfiguration message, a Media Access Control (MAC) Control Element (CE) , or a Packet Data Unit (PDU) .

[0109] Example 18 includes a method for a base station (BS) , wherein the method includes: receiving an authorization message from a core network (CN) , the authorization message indicating at least one of the BS being authorized to operate as an Ambient Internet-of-Things (A-IoT) reader device or the BS being authorized to service at least one user equipment (UE) operating as an A-IoT reader device; and performing at least one of: communicating, as an A-IoT reader device, with at least one A-IoT device in response to the authorization message indicating that the BS is authorized to operate as an A-IoT reader device; or generating for transmission a notification message to one or more UEs indicating the BS supports at least one UE operating as an A-IoT reader device in response to the authorization message indicating that the BS is authorized to service at least one UE operating as an A-IoT reader device.

[0110] Example 19 includes a baseband processor configured to perform operations including generating for transmission, to a base station (BS) , an authorization message indicating at least one of the BS being authorized to operate as an Ambient Internet-of-Things (A-IoT) reader device or the BS being authorized to service at least one user equipment (UE) operating as an A-IoT reader device.

[0111] Example 20 includes the subject matter of Example 19, including or omitting optional elements, wherein the authorization message includes a Next Generation (NG) Setup Response message.

[0112] Example 21 includes the subject matter of Example 20, including or omitting optional elements, wherein the operations further include receiving, from the BS, an NG Setup Request message indicating a request for authorization of the BS to operate as an A-IoT reader device, wherein the NG Setup Response message is generated for transmission in response to the NG Setup Request message.

[0113] Example 22 includes a baseband processor configured to perform operations including receiving, at a base station (BS) from a core network (CN) , first data for A-IoT inventory and command signaling for an A-IoT device; and generating for transmission, to the CN, second data for the A-IoT inventor and command signaling, wherein: when the BS operates as an A-IoT reader device, the first data and the second data are transported via a Next Generation Application Protocol (NGAP) .

[0114] Example 23 includes the subject matter of Example 22, including or omitting optional elements, wherein when the BS does not operate as an A-IoT reader device, the first  data and the second data are transported via a Non-Access Stratum (NAS) protocol.

[0115] Example 24 includes a baseband processor configured to perform operations including receiving, at a first base station (BS) from a second BS, a first message including an indication of support for at least one of A-IoT devices or A-IoT reader devices.

[0116] Example 25 includes the subject matter of Example 24, including or omitting optional elements, wherein the first message includes one of an Xn Setup Request message, an Xn Setup Response message, or an NG-RAN Configuration Update message.

[0117] Example 26 includes the subject matter of Example 24, including or omitting optional elements, wherein the operations further include receiving, at the first BS from the second BS, a second message including at least one of a number of A-IoT UE reader devices connected at the second BS and a number of A-IoT devices connected at the second BS.

[0118] Example 27 includes the subject matter of Example 26, including or omitting optional elements, wherein the second message includes one of an Xn Setup Request message, an Xn Setup Response message, or an NG-RAN Configuration Update message.

[0119] Example 28 includes a baseband processor configured to perform operations including generating for transmission, at a first base station (BS) for a second BS, a first message including an indication of support for at least one of A-IoT devices or A-IoT reader devices.

[0120] Example 29 includes the subject matter of Example 28, including or omitting optional elements, wherein the first message includes one of an Xn Setup Request message, an Xn Setup Response message, or an NG-RAN Configuration Update message.

[0121] Example 30 includes the subject matter of Example 28, including or omitting optional elements, wherein the operations further include generating for transmission, at the first BS for the second BS, a second message including at least one of a number of A-IoT UE reader devices connected at the first BS and a number of A-IoT devices connected at the first BS.

[0122] Example 31 includes the subject matter of Example 30, including or omitting optional elements, wherein the second message includes one of an Xn Setup Request message, an Xn Setup Response message, or an NG-RAN Configuration Update message.

[0123] Example 32 includes a baseband processor configured to perform operations including performing, by an A-IoT UE, a handover operation from a first base station (BS) to a second base station; and maintaining, after the handover operation, a current A-IoT configuration of the A-IoT UE, wherein the A-IoT configuration includes an indication whether the A-IoT is authorized to operate as an A-IoT UE reader device.

[0124] Example 33 includes the subject matter of Example 32, including or omitting  optional elements, wherein the operations further include determining, at the A-IoT UE, whether at least one of a radio link failure (RLF) occurs or a handover failure (HOF) occurs; and releasing, in response to determining that at least one of an RLF or an HOF occurs, the current A-IoT configuration.

[0125] Example 34 includes the subject matter of Example 32, including or omitting optional elements, wherein the operations further include determining whether the A-IoT UE is released to a Radio Resource Control (RRC) _IDLE state or an RRC_INACTIVE state; and releasing, in response to determining that the A-IoT UE is released to the RRC_IDLE state or the RRC_INACTIVE state, the current A-IoT configuration.

[0126] Example 35 includes a baseband processor configured to perform operations including performing, by an A-IoT UE, reselection to a base station (BS) ; determining whether the BS supports A-IoT operation; maintaining, in response to determining that the BS supports A-IoT operation, a current A-IoT configuration of the A-IoT UE; and releasing, in response to determining that the BS does not support A-IoT operation, the current A-IoT configuration, wherein the A-IoT configuration includes an indication whether the A-IoT is authorized to operate as an A-IoT UE reader device.

[0127] FIG. 14 is a diagram of an example of components of a wireless communication device according to one or more implementations described herein. In some implementations, the device 1400 can include application circuitry 1402, baseband circuitry 1404, RF circuitry 1406, front-end module (FEM) circuitry 1408, one or more antennas 1410, and power management circuitry (PMC) 1412 coupled together at least as shown. The components of the illustrated device 1400 can be included in a UE or a RAN node. In some implementations, the device 1400 can include fewer elements (e.g., a RAN node may not utilize application circuitry 1402, and instead include a processor / controller to process IP data received from a CN or an Evolved Packet Core (EPC) ) . In some implementations, the device 1400 can include additional elements such as, for example, memory / storage, display, camera, sensor (including one or more temperature sensors, such as a single temperature sensor, a plurality of temperature sensors at different locations in device 1400, etc. ) , or input / output (I / O) interface. In other implementations, the components described below can be included in more than one device (e.g., said circuitries can be separately included in more than one device for Cloud-RAN (C-RAN) implementations) .

[0128] The application circuitry 1402 can include one or more application processors. For example, the application circuitry 1402 can include circuitry such as, but not limited to, one or more single-core or multi-core processors. The processor (s) can include any combination of  general-purpose processors and dedicated processors (e.g., graphics processors, application processors, etc. ) . The processors can be coupled with or can include memory / storage and can be configured to execute instructions stored in the memory / storage to enable various applications or operating systems to run on the device 1400. In some implementations, processors of application circuitry 1402 can process IP data packets received from an EPC.

[0129] The baseband circuitry 1404 can include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 1404 can include one or more baseband processors or control logic to process baseband signals received from a receive signal path of the RF circuitry 1406 and to generate baseband signals for a transmit signal path of the RF circuitry 1406. Baseband circuitry 1404 can interface with the application circuitry 1402 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 1406. For example, in some implementations, the baseband circuitry 1404 can include a 3G baseband processor 1404A, a 4G baseband processor 1404B, a 5G baseband processor 1404C, or other baseband processor (s) 1404D for other existing generations, generations in development or to be developed in the future (e.g., 5G, 6G, etc. ) .

[0130] The baseband circuitry 1404 (e.g., one or more of baseband processors 1404A-D) can handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 1406. In other implementations, some or all of the functionality of baseband processors 1404A-D can be included in modules (e.g., sets of executable instructions) stored in the memory 1404G or other machine-readable or computer-readable medium (e.g., a non-transitory machine-readable or computer-readable storage medium) and executed via a Central Processing Unit (CPU) 1404E or another type of processor (e.g., a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU) , a digital signal processor (DSP) such as a baseband processor, an application-specific integrated circuit (ASIC) , a radio-frequency integrated circuit (RFIC) , another processor, or any suitable combination thereof) .

[0131] The radio control functions can include, but are not limited to, signal modulation / demodulation, encoding / decoding, radio frequency shifting, etc. In some implementations, modulation / demodulation circuitry of the baseband circuitry 1404 can include Fast-Fourier Transform (FFT) , precoding, or constellation mapping / de-mapping functionality. In some implementations, encoding / decoding circuitry of the baseband circuitry 1404 can include convolution, tail-biting convolution, turbo, Viterbi, or Low-Density Parity Check (LDPC) encoder / decoder functionality. Implementations of modulation / demodulation and encoder / decoder functionality are not limited to these examples and can include other suitable  functionality in other implementations.

[0132] In some implementations, the baseband circuitry 1404 can include one or more audio digital signal processor (s) (DSP) 1404F. The audio DSPs 1404F can include elements for compression / decompression and echo cancellation and can include other suitable processing elements in other implementations. Components of the baseband circuitry 1404 can be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some implementations. In some implementations, some or all of the constituent components of the baseband circuitry 1404 and the application circuitry 1402 can be implemented together such as, for example, on a system-on-a-chip (SOC) .

[0133] In some implementations, the baseband circuitry 1404 can provide for communication compatible with one or more radio technologies. For example, in some implementations, the baseband circuitry 1404 can support communication with an NG-RAN, an E-UTRAN or other wireless metropolitan area networks (WMAN) , a wireless local area network (WLAN) , a wireless personal area network (WPAN) , etc. Implementations in which the baseband circuitry 1404 is configured to support radio communications of more than one wireless protocol can be referred to as multi-mode baseband circuitry.

[0134] RF circuitry 1406 can embody an RF transceiver that enables communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various implementations, the RF circuitry 1406 can include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. RF circuitry 1406 can include a receive signal path which can include circuitry to down-convert RF signals received from the FEM circuitry 1408 and provide baseband signals to the baseband circuitry 1404. RF circuitry 1406 can also include a transmit signal path which can include circuitry to up-convert baseband signals provided by the baseband circuitry 1404 and provide RF output signals to the FEM circuitry 1408 for transmission.

[0135] In some implementations, the receive signal path of the RF circuitry 1406 can include mixer circuitry 1406A, amplifier circuitry 1406B, and filter circuitry 1406C. RF circuitry 1406 can also include synthesizer circuitry 1406D for synthesizing a frequency for use by the mixer circuitry 1406A of the receive signal path and the transmit signal path.

[0136] The RF circuitry 1406 can include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry, and the baseband circuitry 1404 can include a digital baseband interface to communicate with the RF circuitry 1406.

[0137] Synthesizer circuitry 1406D of the RF circuitry 1406 can include a divider, a delay-locked loop (DLL) , a multiplexer, and a phase accumulator.

[0138] FEM circuitry 1408 can include a receive signal path which can include circuitry configured to operate on RF signals received from one or more antennas 1410, amplify the received signals, and provide the amplified versions of the received signals to the RF circuitry 1406 for further processing. FEM circuitry 1408 can also include a transmit signal path which can include circuitry configured to amplify signals for transmission provided by the RF circuitry 1406 for transmission by one or more of the one or more antennas 1410. In various implementations, the amplification through the transmit and / or receive signal paths can be done solely in the RF circuitry 1406, solely in the FEM circuitry 1408, or in both the RF circuitry 1406 and the FEM circuitry 1408.

[0139] In some implementations, the FEM circuitry 1408 can include a TX / RX switch to switch between transmit mode and receive mode operation. The FEM circuitry can include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry can include an LNA to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 1406) . The transmit signal path of the FEM circuitry 1408 can include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 1406) , and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 1410) .

[0140] Processors of the application circuitry 1402 and processors of the baseband circuitry 1404 can be used to execute elements of one or more instances of a protocol stack. For example, processors of the baseband circuitry 1404, alone or in combination, can be used to execute Layer 3, Layer 2, or Layer 1 functionality, while processors of the baseband circuitry 1404 can utilize data (e.g., packet data) received from these layers and further execute Layer 4 functionality (e.g., transmission communication protocol (TCP) and user datagram protocol (UDP) layers) . As referred to herein, Layer 3 can include a radio resource control (RRC) layer, described in further detail below. As referred to herein, Layer 2 can include a medium access control (MAC) layer, a radio link control (RLC) layer, and a PDCP layer, described in further detail below. As referred to herein, Layer 1 can include a physical (PHY) layer of a UE / RAN node.

[0141] In some implementations, the PMC 1412 can manage power provided to the baseband circuitry 1404. In particular, the PMC 1412 can control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion. The PMC 1412 can often be included when the device 1400 is capable of being powered by a battery, for example, when the device is included in a UE. The PMC 1412 can increase the power conversion efficiency while providing desirable implementation size and heat dissipation characteristics.

[0142] While FIG. 14 shows the PMC 1412 coupled only with the baseband circuitry 1404,  in other implementations, the PMC 1412 may be additionally or alternatively coupled with, and perform similar power management operations for, other components such as, but not limited to, application circuitry 1402, RF circuitry 1406, or FEM circuitry 1408.

[0143] In some implementations, the PMC 1412 can control, or otherwise be part of, various power saving mechanisms of the device 1400. For example, if the device 1400 is in an RRC_CONNECTED state, where it is still connected to the RAN node as it expects to receive traffic shortly, then it can enter a state known as Discontinuous Reception (DRX) mode after a period of inactivity. During this state, the device 1400 can power down for brief intervals of time and thus save power.

[0144] If there is no data traffic activity for an extended period of time, then the device 1400 can transition off to an RRC_IDLE state, where it disconnects from the network and does not perform operations such as channel quality feedback, handover, etc. The device 1400 goes into a very low power state and it performs paging where again it periodically wakes up to listen to the network and then powers down again. The device 1400 may not receive data in this state; in order to receive data, it can transition back to the RRC_CONNECTED state.

[0145] The baseband circuitry 1404, or the one or more baseband processors or control logic of the baseband circuitry 1404, may stand alone as the UE 110 or the RAN node 122 of FIG. 1 perform signaling and operation in the meaning as described throughout this disclosure.

[0146] Examples herein can include subject matter such as a method, means for performing acts or blocks of the method, at least one machine-readable medium including executable instructions that, when performed by a machine (e.g., a processor with memory, an application-specific integrated circuit (ASIC) , a field-programmable gate array (FPGA) , or the like) cause the machine to perform acts of the method or of an apparatus or system for concurrent communication using multiple communication technologies according to implementations and examples described.

[0147] In this regard, while the disclosed subject matter has been described in connection with various examples, implementations, aspects, etc., and corresponding Figures, where applicable, it is to be understood that other similar aspects can be used or modifications and additions can be made to the disclosed subject matter for performing the same, similar, alternative, or substitute function of the subject matter without deviating therefrom. Therefore, the disclosed subject matter should not be limited to any single example, implementation, or aspect described herein, but rather should be construed in breadth and scope in accordance with the appended claims below.

[0148] In particular regard to the various functions performed by the above-described  components or structures (assemblies, devices, circuits, systems, etc. ) , the terms (including a reference to a “means” ) used to describe such components are intended to correspond, unless otherwise indicated, to any component or structure which performs the specified function of the described component (e.g., that is functionally equivalent) , even though not structurally equivalent to the disclosed structure which performs the function in the herein illustrated exemplary implementations. In addition, while a particular feature may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given application.

[0149] As used herein, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or” . That is, unless specified otherwise, or clear from context, “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, if X employs A; X employs B;or X employs both A and B, then “X employs A or B” is satisfied under any of the foregoing instances. In addition, the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or clear from context to be directed to a singular form. Furthermore, to the extent that the terms “including” , “includes” , “having” , “has” , “with” , or variants thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term “comprising. ” Additionally, in situations wherein one or more numbered items are discussed (e.g., a “first X” , a “second X” , etc. ) , in general the one or more numbered items can be distinct, or they can be the same, although in some situations the context may indicate that they are distinct or that they are the same.

[0150] 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 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 baseband processor configured to perform operations comprising:receiving, at a base station (BS) , a first authorization message from a core network (CN) , the first authorization message indicating at least one of:the BS being authorized to operate as an Ambient Internet-of-Things (A-IoT) reader device, orthe BS being authorized to service at least one user equipment (UE) operating as an A-IoT reader device; andperforming at least one of:communicating, as an A-IoT reader device, with at least one A-IoT device in response to the first authorization message indicating that the BS is authorized to operate as an A-IoT reader device; orgenerating for transmission a notification message to one or more UEs indicating the BS supports at least one UE operating as an A-IoT reader device in response to the first authorization message indicating that the BS is authorized to service at least one UE operating as an A-IoT reader device.2.The baseband processor of claim 1, wherein the first authorization message indicates the BS is authorized to operate as an A-IoT reader device and the BS is authorized to service at least one UE operating as an A-IoT reader device.3.The baseband processor of claim 1, wherein the first authorization message comprises a Next Generation (NG) Setup Response message.4.The baseband processor of claim 3, the operations further comprising:generating for transmission, to the CN, an NG Setup Request message indicating a request for authorization of the BS to operate as an A-IoT reader device, wherein the NG Setup Response message is received in response to the NG Setup Request message.5.The baseband processor of claim 1, the operations further comprising:receiving, at the BS, a second authorization message from the CN, the second authorization message indicating a UE communicatively coupled with the BS being authorized to operate as an A-IoT reader device.6.The baseband processor of claim 5, wherein the second authorization message comprises an Initial Context Setup Request message.7.The baseband processor of claim 6, the operations further comprising:generating for transmission, to the CN, an Initial UE message indicating a request for authorization of the UE to operate as an A-IoT reader device, wherein the Initial Context Setup Request message is received in response to the Initial UE message.8.The baseband processor of claim 5, wherein the second authorization message comprises at least one of a UE Context Modification Request message or a Downlink Non-Access Stratum (NAS) Transport message.9.The baseband processor of claim 5, the operations further comprising:generating for transmission, to the UE, a third authorization message authorizing an A-IoT reader function of the UE in response to receiving the second authorization message.10.The baseband processor of claim 9, wherein the third authorization message comprises a Radio Resource Control (RRC) Reconfiguration message.11.The baseband processor of claim 10, wherein the RRC Reconfiguration message further comprises an indication of radio resources available to the UE for the A-IoT reader function.12.The baseband processor of claim 1, the operations further comprising:receiving, from the CN, a first paging message after receiving the first authorization message, the first paging message comprising at least one A-IoT device identity.13.The baseband processor of claim 12, the first paging message comprising a Next Generation Application Protocol (NGAP) Paging message.14.The baseband processor of claim 12, the first paging message comprising at least one of a single A-IoT device identity, a list of a plurality of A-IoT device identities, a single A-IoT device group identity, or a list of a plurality of A-IoT device group identities.15.The baseband processor of claim 12, wherein the first paging message further comprises an A-IoT device type.16.The baseband processor of claim 12, the operations further comprising at least one of:initiating, when the BS is authorized to operate as an A-IoT reader device, an A-IoT air interface inventory operation; orgenerating for transmission, when the BS is authorized to service at least one UE operating as an A-IoT reader device, a second paging message to an A-IoT UE reader device.17.The baseband processor of claim 16, the second paging message comprising one of a Radio Resource Control (RRC) Paging message, an RRC Reconfiguration message, a Media Access Control (MAC) Control Element (CE) , or a Packet Data Unit (PDU) .18.A method for a base station (BS) , the method comprising:receiving an authorization message from a core network (CN) , the authorization message indicating at least one of:the BS being authorized to operate as an Ambient Internet-of-Things (A-IoT) reader device, orthe BS being authorized to service at least one user equipment (UE) operating as an A-IoT reader device; andperforming at least one of:communicating, as an A-IoT reader device, with at least one A-IoT device in response to the authorization message indicating that the BS is authorized to operate as an A-IoT reader device; orgenerating for transmission a notification message to one or more UEs indicating the BS supports at least one UE operating as an A-IoT reader device in response to the authorization message indicating that the BS is authorized to service at least one UE operating as an A-IoT reader device.19.A baseband processor configured to perform operations comprising:generating for transmission, to a base station (BS) , an authorization message indicating at least one of the BS being authorized to operate as an Ambient Internet-of-Things (A-IoT) reader device or the BS being authorized to service at least one user equipment (UE) operating as an A-IoT reader device.20.The baseband processor of claim 19, wherein:the authorization message comprises a Next Generation (NG) Setup Response message; andthe operations further comprise receiving, from the BS, an NG Setup Request message indicating a request for authorization of the BS to operate as an A-IoT reader device, wherein the NG Setup Response message is generated for transmission in response to the NG Setup Request message.

Images