Ambient internet-of-things device authentication method and apparatus

Abstract

A method of digital communication includes transmitting, by a first network function to a radio access network (RAN) device, a reader request; receiving, by the first network function, from the RAN device, a reader response in response to the reader request; transmitting, by the first network function, a service request based on the reader response; receiving, by the first network function, a service response for the service request; and performing further network operations based on the service response.

Description

AMBIENT INTERNET-OF-THINGS DEVICE AUTHENTICATION METHOD AND APPARATUSTECHNICAL FIELD

[0001] This document is directed generally to wireless communications.BACKGROUND

[0002] Wireless communication technologies are moving the world toward an increasingly connected and networked society. The rapid growth of wireless communications and advances in technology has led to greater demand for capacity and connectivity. Other aspects, such as energy consumption, device cost, spectral efficiency, and latency are also important to meeting the needs of various communication scenarios. In comparison with the existing wireless networks, next generation systems and wireless communication techniques need to provide support for an increased number of users and devices, as well as support an increasingly mobile society.SUMMARY

[0003] Various techniques are disclosed related to authentication of ambient internet-of-things (AIOT) devices that can be implemented by embodiments in mobile communication technology, including various protocol suites specified by the Third Generation Partnership Project (3GPP) .

[0004] In one example aspect, a wireless communication method is disclosed. The method includes transmitting, by a first network function, a service request; receiving, by the first network function, a service response for the service request; and performing further network operations based on the service response.

[0005] In another example aspect, another wireless communication method is disclosed. The method includes receiving, by a wireless device, a service request message from a user device or a RAN device, determining whether the service request message is authentic by processing the one or more parameters; discarding the service request message in case it is determined that the service request message is not authentic; and performing one or more service response operations in case it is determined that the service request message is authentic.

[0006] In another example aspect, another wireless communication method is disclosed. The method includes receiving, by a network device, a reader request from a first network function; determining, by the network device, whether the reader request can be forwarded to a radio access network; and sending a response to the first network function according to the determining.

[0007] In another example aspect, another wireless communication method is disclosed. The method includes receiving, by a user device from a network device, a service request message for a wireless device; forwarding, by the user device, the service request message to the wireless device; receiving, by the user device from the wireless device, a service response message; and sending, by the user device, the service response message to the network device.

[0008] In yet another exemplary aspect, the above-described methods are embodied in the form of a computer-readable medium that stores processor-executable code that, upon execution by one or more processors, cause an apparatus to implement the method.

[0009] In yet another exemplary embodiment, a device that is configured or operable to perform the above-described methods is disclosed. The device comprises at least one processor configured to implement the method.

[0010] The above and other aspects and their implementations are described in greater detail in the drawings, the descriptions, and the claims.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG. 1 shows an example network architecture.

[0012] FIG. 2A-2B show example signal exchange diagrams according to an embodiment.

[0013] FIG. 3A-3B show example signal exchange diagrams according to an embodiment.

[0014] FIG. 4A-4B show example signal exchange diagrams according to an embodiment.

[0015] FIG. 5A-5B show example signal exchange diagrams according to an embodiment.

[0016] FIG. 6 is a flowchart illustrating an example method.

[0017] FIG. 7 is a flowchart illustrating an example method.

[0018] FIG. 8 is a flowchart illustrating an example method.

[0019] FIG. 9 is a flowchart illustrating an example method.

[0020] FIG. 10 is a block diagram example of a wireless communication system.

[0021] FIG. 11 is a block diagram of an example hardware platform.DETAILED DESCRIPTION

[0022] Section headings are used in the present document only to improve readability and do not limit scope of the disclosed embodiments and techniques in each section to only that section. Certain features are described using the example of Fifth Generation (5G) wireless protocol. However, applicability of the disclosed techniques is not limited to only 5G wireless systems.

[0023] Initial discussion

[0024] Recently, 3GPP has introduced a class of devices called ambient internet of things (AIOT) devices. These devices are typically intended to provide communication connectivity without needing local energy source such as a battery, which may need maintenance and operation. The AIOT devices are intended to operate by consuming very low power (e.g., 1 to 100 microWatts) and may be powered up only during actual communication usage. It is expected that such devices will provide more versatile and ubiquitous deployments than present day technologies such as QR codes, barcodes or radio frequency tags (RFID) .

[0025] The AIOT devices may be configured into operate in a communication network by supporting a number of services. For example, an inventory service is a fundamental process for AIoT devices, which includes both "inventory only" and "inventory and command" cases. In both scenarios, the mandatory steps involve AIoT paging and Device ID transmission. The AIoT paging message may contain an ID of a single A-IoT device, a group ID that maps to multiple A-IoT devices, or multiple IDs of A-IoT devices. If AIoT paging message does not contain an ID, it will map to all the A-IoT devices. After these steps, the network can calculate the quantity of device IDs for this inventory.

[0026] The inventory device quantity may contain business information, such as the quantity of stock in a shopping mall. If this information falls into the hands of competitors, they may adjust their sales strategy to attract more customers from that shopping mall.

[0027] By broadcasting a fake inventory message with a group ID, an attacker could potentially calculate the quantity of devices in a group by observing the differences in reported device IDs, even if the IDs are encrypted. This could lead to the exposure of the inventory device quantity associated with the group ID. For example, in a shopping mall, assuming the attacker has knowledge of the link between the group ID and goods (such as knowledge of the link between SUPI and the real subscriber) , the attacker could use a fake reader to broadcast this group ID. Subsequently, the attacker would receive multiple device IDs and calculate the device quantity for this group ID, allowing them to determine the number of specific goods.

[0028] An attacker could calculate the quantity of all devices by observing differences in reported device IDs, even if the IDs are encrypted, after sending a fake inventory message without any IDs. This could result in the exposure of the inventory device quantity within an area. For instance, in a shopping mall, if an attacker can control the broadcast scope into the shopping mall, they could utilize a fake reader to broadcast an inventory message without any ID. Subsequently, the attacker would receive multiple device IDs, enabling them to calculate the device quantity in this area and determine the stock levels of all the goods of this shopping mall.

[0029] The present document discloses techniques that may be adopted by embodiments to address the above discussed technical problems, and others, including providing a secure mechanism for inventory services in an AIOT network.

[0030] The following abbreviations are used in the present document.

[0031] Introduction

[0032] With reference to the network architecture in FIG. 1, some embodiments are disclosed using examples of functional entities defined in 3GPP TS 23.501, with the exception for the following additions:

[0033] - Ambient IoT Function (AIOTF) : AIOTF is introduced to support AIoT services, with some AMF's functionalities integrated, which includes:

[0034] - Ambient IoT RAN connectivity.

[0035] - Inventory handling and device context management.

[0036] - Authentication and authorization for the access, which triggers interaction with AUSF / UDM.

[0037] - Collect charging data and interact with CHF for charging.

[0038] - Routing the request from AF (via NEF) to RAN

[0039] - Routing the response from RAN to AF (via NEF)

[0040] - UDM: UDM is enhanced to store and manage the AIoT device information. The device information contains the device ID, device status information (e.g. enabled / disabled / permanently disabled) , as well as CN related information (e.g. serving NF) .

[0041] - NEF: NEF is enhanced to expose AIoT specific services towards AF.

[0042] - CHF: CHF is enhanced for the charging for AIoT services.

[0043] - NRF: NRF is enhanced to support the new NF type AIOTF and the corresponding NF profile.

[0044] - AUSF: AUSF is enhanced for the authentication for the access from AIoT devices.

[0045] - NG-RAN: Determine Intermediate UEs, allocate radio resources for communication between Intermediate UEs and AIoT devices, forwards device NAS messages to Intermediate UEs, and forwards the response to AIOTF.

[0046] Various aspects of the disclosed techniques are described through several example embodiments. It will be understood that the example embodiments are presented as different sections only for ease of reading and do not limit scope of the disclosed techniques to the embodiment in which the technique is disclosed. Furthermore, these embodiments are disclosed with reference to FIGS. 2A to 5B that depict messages exchanged among various actors operating in a communication network including an AIOT device (151) , a user equipment UE (152) , NG-RAN (153) , AMF (154) , AIOTF (155) , AUSF (156) , UDM (157) , NRF (158) , NEF (159) , AF (160) .

[0047] Example Embodiment 1

[0048] In some embodiments, the AIOTF sends Reader ID to AIOT device. This may be performed if the Reader ID is changed.

[0049] The AIoT device may check Reader ID, the AIoT device may request Reader ID from the UE.

[0050] With reference to FIGS. 2A and 2B, the following operations may be performed.

[0051] 101. The AF sends a service request message such as an Inventory Message Request to the NEF, containing the area information, AIOT device information, optional inventory strategy information, and optional report aggregation info.

[0052] - The area information could be the external geographical area information.

[0053] - The device information could be device ID, device group ID, and / or device type.

[0054] - The inventory strategy information contains, e.g. the inventory frequency and inventory period to guide the readers to perform the inventory periodically. It also indicates whether all the targeted devices need to respond (full inventory) , or only those who haven't performed the inventory procedure (delta inventory) should respond.

[0055] - The location required indicates whether the AF requests the location information of the AIoT devices provided.

[0056] - The report aggregation info indicates whether the reports need to be aggregated or not for a specific aggregation period, and whether the reports are needed after the aggregation period.

[0057] The NEF authorizes the request from the AF and performs the area translation to translate external area information to the internal area information. Within the authorization, the NEF further check whether the AF is authorized to get the location information of the device.

[0058] The NEF sends NRF query with internal area information to query AIOTFs serving the area. The NEF sends the Inventory Request to the AIOTFs with the internal area information, device information and optionally inventory strategy information, optional location required information.

[0059] 102. The AIOTF may generate the candidate UE list inside the intended area, if the NG-RAN may release the intermediate UEs to RRC_IDLE state. The AIOTF holds a root key or a derived key (e.g. Kaiot) based on the root key between the AIOT device and AIOTF.

[0060] 103. The AIOTF sends enable UE reachability request with the UE list towards the AMF to page the intermediate UEs inside the intended area. The AMF checks the CM states of those intermediate UEs, and triggers paging towards the NG-RAN (s) for those UEs in CM-IDLE state.

[0061] 104. The AIOTF discovers NG-RANs based on the intended area and sends Reader Request towards the NG-RAN with the area info, device info, inventory strategy and location required. The AIOTF uses non-UE associated signalling towards NG-RAN.

[0062] 105. The NG-RAN checks whether the Reader request can be performed. The NG-RAN triggers RAN paging for the intermediate UEs in RRC_INACTIVE state and then selects intermediate UEs. The NG-RAN should select intermediate UE among the authorized intermediate UEs.

[0063] 106. The NG-RAN sends Reader response to AIOTF, include the selected UE ID.

[0064] 107. The AIOTF sends inventory request towards the NG-RAN, include a freshness parameter and Message authentication code (MAC) . If the AIOTF wants to change the Reader ID, the message may also include a Reader ID. Based on the UE ID received from the NG-RAN, the AIOTF finds a Reader ID. If there is none, the AIOTF generates a Reader ID or gets Reader ID from the AF. The AIOTF may also generate a new Reader ID itself or gets a new Reader ID from AF based on its local policy such as the Reader ID has been used in a long time. Based on the root key, may also include the Reader ID, the AIOTF derive a Kaiot. If the AIOTF does not have the root key, the AIOTF gets the Kaiot from other AF which holds the root key of the AIOT device. Furthermore, the AIOTF generate a freshness parameter. The AIOTF use the Kaiot, Reader ID, device ID and freshness parameter to generate a MAC. The Reader ID can be generated based on the UE ID or a random number or can be a combination of a UE ID and the location information or the RAN ID that serves the Intermediate UE. If the AIoTF decides not to change the Reader ID, the Reader ID is not included in the message. If the Reader ID is not included, a Reader ID check indication may be included.

[0065] 108. The NG-RAN determines radio resource for the AIoT service operation between the intermediate UEs and AIoT devices, and sends inventory request towards determined intermediate UEs, together with the determined radio resources. The message may also include a freshness parameter and MAC, and a Reader ID if received from the AIOTF.

[0066] Then, according to the whether the Reader ID is included, there are two cases:

[0067] Case 1: Inventory When Reader ID is changed.

[0068] 109a. The Intermediate UE initiates inventory based on device information as well as the inventory strategy information provided by the AF. The message may also include a freshness parameter and MAC and a Reader ID, if received from the AIOTF. The Intermediate UE store the Reader ID.

[0069] 110a. The AIoT Device generates a Kaiot and MAC uses the same method with AIOTF in step 107. If the Reader ID is included in the inventory message, the AIOT device derives the Kaiot and MAC based on the received Reader ID. If the generated MAC is the same as the received MAC, the AIOT device stores new Kaiot and Reader ID. Otherwise, the AIoT device discards the message and keeps the old Kaiot and Reader ID.

[0070] Case 2: Inventory When Reader ID is not changed:

[0071] 109b. The Intermediate UE initiates inventory based on device information as well as the inventory strategy information provided by the AF. The Intermediate UE may provide reader identity information to enable the AIoT devices to understand they are read by which Intermediate UE. The message may also include a freshness parameter and MAC, and a Reader ID check indication.

[0072] 110b. If the Reader ID is not included in the inventory message, the AIoT Device use old Kaiot and Reader ID to generate a MAC, in the same way as step 107. If the generated MAC is the same as the received MAC, and no Reader ID check indication is received, the AIOT device go to step 111. If Reader ID check indication is received, the AIOT device sends a Reader ID request message to The Intermediate UE. Otherwise, the AIoT device discard the message and keep the old Kaiot and Reader ID

[0073] 110c. If Reader ID check indication is received or based on the AIoT device local policy, the AIOT device sends a Reader ID request message to The Intermediate UE.

[0074] 110d. The Intermediate UE response the Reader ID to the AIOT device.

[0075] 110e. The AIoT device check whether the received Reader ID is the same as the stored Reader ID. If all the check passed, then go to step 111.

[0076] 111. The AIoT Device reports the device ID in an AIOT device NAS message to the Intermediate UE.If the Inventory procedure indicates delta inventory only, and the AIoT Device has performed the inventory procedure towards this UE reader in the same location or served by the same RAN node, it should skip the reporting. The device capability index can be provided by AIoT device optionally.

[0077] 112. The Intermediate UE forwards AIOT device NAS message towards the NG-RAN, including the AIoT Device ID and optional device capability index. The NG-RAN forwards the AIoT device NAS message towards the AIOTF.

[0078] The Intermediate UE may further provide location information (ULI) of the device, if requested from the AIOTF and allowed by local policy. The Intermediate UE may further provide an end indicator to inform the NG-RAN that will inform AIOTF whether it is the last inventory response for the inventory round, e.g. based on timeout in Intermediate UE.

[0079] 113. The AIOTF validates the concealed device ID via interacting with AUSF and UDM. The AIOTF may further get the device capability information from the device capability profile stored in the UDM based on the device capability index provided by the device.

[0080] 114. The AIOTF together with AUSF and UDM, triggers authentication and authorization procedures (e.g., similar to the authentication request / response between UE and network) towards the AIoT device. The message between the AIOTF and the AIOT device is transmitted via the NG-RAN and the Intermediate UE.

[0081] Based on the device capability information from UDM, if the AIoT device is capable of storing received parameters for a longer period, step 115 -step 117 are executed i.e. the AIOT device is then considered registered:

[0082] 115. The security mode negotiation and security parameter exchanges are performed (i.e. like the security mode command / complete between UE and network) . In Topology 2, the message between the AIOTF and the AIOT device is transmitted via the NG-RAN and the Intermediate UE.

[0083] 116. The AIOTF may further allocate CN device ID and sends it to the AIoT device.

[0084] 117. The AIOTF registers with the UDM (UECM) for the AIoT device access.

[0085] 118. The AIOTF may further aggregate the reported device IDs and send them to AF via the NEF.

[0086] Example Embodiment 2

[0087] In some embodiments, the AIOTF sends an encrypted Reader ID.

[0088] With reference to FIGS. 3A and 3B, the following operations may be performed.

[0089] 201. The AF sends Inventory Message Request to the NEF, containing the area information, device information, optional inventory strategy information, and optional report aggregation info.

[0090] - The area information could be the external geographical area information.

[0091] - The device information could be device ID, device group ID, and / or device type.

[0092] - The inventory strategy information contains, e.g. the inventory frequency and inventory period to guide the readers to perform the inventory periodically. It also indicates whether all the targeted devices need to respond (full inventory) , or only those who haven't performed the inventory procedure (delta inventory) should respond.

[0093] - The location required indicates whether the AF requests the location information of the AIoT devices provided.

[0094] - The report aggregation info indicates whether the reports need to be aggregated or not for a specific aggregation period, and whether the reports are needed after the aggregation period.

[0095] The NEF authorizes the request from the AF and perform the area translation to translate external area information to the internal area information. Within the authorization, the NEF further check whether the AF is authorized to get the location information of the device.

[0096] The NEF sends NRF query with internal area information to query AIOTF’s serving the area. The NEF sends the Inventory Request to the AIOTFs with the internal area information, device information and optionally inventory strategy information, optional location required information.

[0097] 202. The AIOTF may generate the candidate UE list inside the intended area, if the NG-RAN may release the intermediate UEs to RRC_IDLE state. The AIOTF holds the root key or a derived key (e.g., Kaiot) based on the root key between the AIOT device and AIOTF.

[0098] 203. The AIOTF sends enable UE reachability request with the UE list towards the AMF to page the intermediate UEs inside the intended area. The AMF checks the CM states of those intermediate UEs, and triggers paging towards the NG-RAN (s) for those UEs in CM-IDLE state.

[0099] 204. The AIOTF discovers NG-RANs based on the intended area and sends Reader Request towards the NG-RAN with the area info, device info, inventory strategy and location required. The AIOTF uses non-UE associated signalling towards NG-RAN.

[0100] 205. The NG-RAN checks whether the Reader request can be performed. The NG-RAN triggers RAN paging for the intermediate UEs in RRC_INACTIVE state and then selects intermediate UEs. The NG-RAN should select intermediate UE among the authorized intermediate UEs.

[0101] 206. The NG-RAN sends Reader response to AIOTF, include the selected UE ID.

[0102] 207. The AIOTF sends inventory request towards the NG-RAN, include a freshness parameter and Message authentication code (MAC) . If the AIOTF wants to change the Reader ID, the message may also include a Reader ID. Based on the UE ID received from the NG-RAN, the AIOTF finds a Reader ID. If there is none, the AIOTF generate a Reader ID or gets Reader ID from the AF. The AIOTF may also generate a new Reader ID itself or gets a new Reader ID from AF based on its local policy such as the Reader ID has been used in a long time. Based on the root key, may also include the Reader ID, the AIOTF derive a Kaiot. If the AIOTF does not have the root key, the AIOTF gets the Kaiot from other AF which holds the root key of the AIOT device. Furthermore, the AIOTF generate a freshness parameter. The AIOTF use the Kaiot, Reader ID, device ID and freshness parameter to generate a MAC. The Reader ID can be generated based on the UE ID or a random number or can be a combination of a UE ID and the location information or the RAN ID that serves the Intermediate UE. If the AIoTF decides not to change the Reader ID, the Reader ID is not include in the message. If the Reader ID is not included, an encrypted Reader ID may be included. The encrypted Reader ID is used for Reader ID check.

[0103] 208. The NG-RAN determines radio resource for the AIoT service operation between the intermediate UEs and AIoT devices, and sends inventory request towards determined intermediate UEs, together with the determined radio resources. The message may also include a freshness parameter and MAC, and a Reader ID and an encrypted Reader ID if received from the AIOTF.

[0104] Then, according to the whether the Reader ID is included, there are two cases:

[0105] Case 1: Inventory When Reader ID is changed.

[0106] 209a. The Intermediate UE initiates inventory based on device information as well as the inventory strategy information provided by the AF. The message may also include a freshness parameter and MAC. And a Reader ID if received from the AIOTF. The Intermediate UE store the Reader ID.

[0107] 210a. The AIoT Device generates a Kaiot and MAC use the same method with AIOTF in step 207. If the Reader ID is included in the inventory message, the AIOT device derive the Kaiot and MAC based on the received Reader ID. If the generated MAC is the same as the received MAC, the AIOT device store new Kaiot and Reader ID. Otherwise, the AIoT device discard the message and keep the old Kaiot and Reader ID.

[0108] Case 2: Inventory When Reader ID is not changed:

[0109] 209b. The Intermediate UE initiates inventory based on device information as well as the inventory strategy information provided by the AF. The Intermediate UE may provide reader identity information to enable the AIoT devices to understand they are read by which Intermediate UE. The message may also include a freshness parameter and MAC, and an encrypted Reader ID.

[0110] 210b. If the Reader ID is not included in the inventory message, the AIoT Device use old Kaiot and Reader ID to generate a MAC, in the same with step 207. If the generated MAC is the same as the received MAC, then the AIOT device decrypt the encrypted Reader ID. The AIoT device check whether the received Reader ID is the same as the stored Reader ID, If all the check passed, then go to step 11. Otherwise, the AIoT device discard the message and keep the old Kaiot and Reader ID

[0111] 211. The AIoT Device reports the device ID in an AIOT device NAS message to the Intermediate UE.If the Inventory procedure indicates delta inventory only, and the AIoT Device has performed the inventory procedure towards this UE reader in the same location or served by the same RAN node, it should skip the reporting. The device capability index can be provided by AIoT device optionally.

[0112] 212. The Intermediate UE forwards AIOT device NAS message towards the NG-RAN, including the AIoT Device ID and optional device capability index. The NG-RAN forwards the AIoT device NAS message towards the AIOTF.

[0113] The Intermediate UE may further provide location information (ULI) of the device, if requested from the AIOTF and allowed by local policy. The Intermediate UE may further provide an end indicator to inform the NG-RAN that will inform AIOTF whether it is the last inventory response for the inventory round, e.g. based on timeout in Intermediate UE.

[0114] 213. The AIOTF validates the concealed device ID via interacting with AUSF and UDM. The AIOTF may further get the device capability information from the device capability profile stored in the UDM based on the device capability index provided by the device.

[0115] 214. The AIOTF together with AUSF and UDM, triggers authentication and authorization procedures (i.e. like the authentication request / response between UE and network) towards the AIoT device. The message between the AIOTF and the AIOT device is transmitted via the NG-RAN and the Intermediate UE.

[0116] Based on the device capability information from UDM, if the AIoT device is capable of storing received parameters for a longer period, step 215 -step 217 are executed i.e. the AIOT device is then considered registered:

[0117] 215. The security mode negotiation and security parameter exchanges are performed (i.e. like the security mode command / complete between UE and network) . In Topology 2, the message between the AIOTF and the AIOT device is transmitted via the NG-RAN and the Intermediate UE.

[0118] 216. The AIOTF may further allocate CN device ID and sends it to the AIoT device.

[0119] 217. The AIOTF registers with the UDM (UECM) for the AIoT device access.

[0120] 218. The AIOTF may further aggregate the reported device IDs and send them to AF via the NEF.

[0121] Example Embodiment 3

[0122] With reference to FIGS. 4A-4B, in some embodiments, Reader ID is updated from the device side. Here, 301～310 may be similar to corresponding steps 201-210 described with respect to FIGS. 3A-3B. This section focuses on how to update the Reader ID from the device side, such as AIoT device trigger, the Intermediate UE trigger, the RAN trigger. If AIOTF include a new Reader ID in the next message (Inventory message, command message, discard message, etc. ) to AIoT device if a Reader ID update indication is received.

[0123] 311. The AIoT Device reports the device ID in an AIOT device NAS message to the Intermediate UE. If the Inventory procedure indicates delta inventory only, and the AIoT Device has performed the inventory procedure towards this UE reader in the same location or served by the same RAN node, it should skip the reporting. The device capability index can be provided by AIoT device optionally. The AIoT device may include a Reader ID update indication

[0124] 312. The Intermediate UE forwards AIOT device NAS message towards the NG-RAN, including the AIoT Device ID and optional device capability index, The Intermediate UE may include a Reader ID update indication. The NG-RAN forwards the AIoT device NAS message towards the AIOTF, The NG-RAN may include a Reader ID update indication.

[0125] The Intermediate UE may further provide location information (ULI) of the device, if requested from the AIOTF and allowed by local policy. The Intermediate UE may further provide an end indicator to inform the NG-RAN that will inform AIOTF whether it is the last inventory response for the inventory round, e.g. based on timeout in Intermediate UE.

[0126] 313. The AIOTF validates the concealed device ID via interacting with AUSF and UDM. The AIOTF may further get the device capability information from the device capability profile stored in the UDM based on the device capability index provided by the device.

[0127] 314. The AIOTF together with AUSF and UDM, triggers authentication and authorization procedures (i.e. like the authentication request / response between UE and network) towards the AIoT device. The message between the AIOTF and the AIOT device is transmitted via the NG-RAN and the Intermediate UE.

[0128] Based on the device capability information from UDM, if the AIoT device is capable of storing received parameters for a longer period, step 15 -step 17 are executed i.e. the AIOT device is then considered registered:

[0129] 315. The security mode negotiation and security parameter exchanges are performed (i.e. like the security mode command / complete between UE and network) . In Topology 2, the message between the AIOTF and the AIOT device is transmitted via the NG-RAN and the Intermediate UE.

[0130] 316. The AIOTF may further allocate CN device ID, a new Reader ID and sends it to the AIoT device.

[0131] 317. The AIOTF registers with the UDM (UECM) for the AIoT device access.

[0132] 318. The AIOTF may further aggregate the reported device IDs and send them to AF via the NEF.

[0133] Example Embodiment 4

[0134] With reference to FIGS. 5A-5B, in some embodiments, the RAN acts as a Reader that reads the AIOT device. In case there is no UE reader, the Reader ID check can also happen between the AIOT device and RAN.

[0135] 401. The AF sends Inventory Message Request to the NEF, containing the area information, device information, optional inventory strategy information, and optional report aggregation info.

[0136] - The area information could be the external geographical area information.

[0137] - The device information could be device ID, device group ID, and / or device type.

[0138] - The inventory strategy information contains, e.g. the inventory frequency and inventory period to guide the readers to perform the inventory periodically. It also indicates whether all the targeted devices need to respond (full inventory) , or only those who haven't performed the inventory procedure (delta inventory) should respond.

[0139] - The location required indicates whether the AF requests the location information of the AIoT devices provided.

[0140] - The report aggregation info indicates whether the reports need to be aggregated or not for a specific aggregation period, and whether the reports are needed after the aggregation period.

[0141] The NEF authorizes the request from the AF and perform the area translation to translate external area information to the internal area information. Within the authorization, the NEF further check whether the AF is authorized to get the location information of the device.

[0142] The NEF sends NRF query with internal area information to query AIOTFs serving the area. The NEF sends the Inventory Request to the AIOTFs with the internal area information, device information and optionally inventory strategy information, optional location required information.

[0143] 402. The AIOTF discovers RANs based on internal area information. The AIOTF holds the root key or a derived key (e.g. Kaiot) based on the root key between the AIOT device and AIOTF.

[0144] 403. The AIOTF sends inventory request towards the NG-RAN with the area info, device info, inventory strategy and location required. The message also include a freshness parameter and Message authentication code (MAC) . If the AIOTF wants to change the Reader ID, the message may also include a Reader ID. Based on the RAN ID, the AIOTF finds a Reader ID. If there is none, the AIOTF generate a Reader ID.The AIOTF may also generate a new Reader ID based on its local policy such as the Reader ID has been used in a long time. Based on the root key, may also include the Reader ID, the AIOTF derive a Kaiot. Furthermore, the AIOTF generate a freshness parameter. The AIOTF use the Kaiot, Reader ID, device ID and freshness parameter to generate a MAC. The Reader ID can be generated based on the RAN ID or a random number. If the AIoTF decides not to change the Reader ID, the Reader ID is not included in the message. If the Reader ID is not included, an encrypted Reader ID may be included. The encrypted Reader ID is used for Reader ID check.

[0145] Then, according to the whether the Reader ID is included, there are two cases:

[0146] Case 1: Inventory When Reader ID is changed.

[0147] 404a. The RAN initiates inventory based on device information as well as the inventory strategy information provided by the AF. The message may also include a freshness parameter and MAC. And a Reader ID if received from the AIOTF. The RAN store the Reader ID.

[0148] 405a. The AIoT Device generate a Kaiot and MAC use the same method with AIOTF in step 3. If the Read ID is included in the inventory message, the AIOT device derive the Kaiot and MAC based on the received Reader ID. If the generated MAC is the same as the received MAC, the AIOT device store new Kaiot and Reader ID. Otherwise, the AIoT device discard the message and keep the old Kaiot and Reader ID.

[0149] Case 2: Inventory When Reader ID is not changed:

[0150] 404b. The RAN initiates inventory based on device information as well as the inventory strategy information provided by the AF. The message may also include a freshness parameter and MAC, and an encrypted Reader ID.

[0151] 405b. If the Read ID is not included in the inventory message, the AIoT Device use old Kaiot and Reader ID to generate a MAC, in the same with step 3. If the generated MAC is the same as the received MAC, then the AIOT device decrypt the encrypted Reader ID. The AIoT device check whether the received Reader ID is the same as the stored Reader ID, If all the check passed, then go to step 6. Otherwise, the AIoT device discard the message and keep the old Kaiot and Reader ID

[0152] 406. The AIoT Device reports the device ID in an AIOT device NAS message to the RAN. I

[0153] 407. The NG-RAN forwards the AIoT device NAS message towards the AIOTF.

[0154] Example technical solutions implemented by preferred embodiments

[0155] 1. A method of digital communication (e.g., method 600 depicted in FIG. 6) , comprising transmitting (606) , by the first network function, a service request; receiving (608) , by the first network function, a service response for the service request; and performing (610) further network operations based on the service response. The first network function may be the AIOTF described with reference to FIGS. 2A to 5B. Additional network functions (e.g., second, third, etc. ) are depicted with reference to FIG. 1. Various examples of the further network operations are also disclosed with reference to FIGS. 2A to 5B.

[0156] 2. The method of solution 1, wherein the service request comprises an inventory request, a command request or a disable request. Correspondingly, the service response may include an inventory response, a command response or a disable response. For example, the command request may be issued to instruct the AIOT device to implement a specific command or query whether a specific command was executed by the AIOT device. For example, the disable request may be issued to instruct the AIOT device to disable a certain function or disable its communication with a reader device with which the AIOT device is currently communicating.

[0157] 3. The method of any of above solutions, wherein the service request includes at least one of following parameters: a freshness parameter, a message authentication code, a reader identifier (reader ID) , a check indication or an encrypted reader ID.

[0158] 4. The method of solution 3, wherein the freshness parameter comprises a random number or a counter value.

[0159] 5. The method of claim 3, including, prior to the transmitting service request, transmitting, by the first network function to a radio access network (RAN) device or a second network function, a reader request; and receiving, by the first network function, from the RAN device or the second network function, a reader response in response to the reader request. In some embodiments, the ensuing service request may be transmitted based on the response to the reader request (e.g., if a discrepancy is found) . Various examples of the RAN device (e.g., UE or NG-RAN base station) and the second network function are described with reference to FIGS. 2A –5B.

[0160] 6. The method of any of above solutions, wherein the service request includes the reader ID, wherein the first network function determines the reader ID based on user device information in the reader response.

[0161] 7. The method of any of above solutions, wherein the message authentication code and the encrypted reader ID are generated using a key stored at the first network function. The key is derived based on the root key of the wireless device.

[0162] 8. A method of digital communication (e.g., method 700 depicted in FIG. 7) , comprising: receiving (702) , by a wireless device, a service request message from a user device or a RAN device, determining (704) whether the service request message is authentic by processing the one or more parameters in the service request message; discarding (706) the service request message in case it is determined that the service request message is not authentic; and performing (708) one or more service response operations in case it is determined that the service request message is authentic. The wireless device may be an AIOT device (e.g., 151) . The AIOT device may be as described with reference to FIGS. 2A to 5B. Various examples of the service operations are also disclosed with reference to FIGS. 2A to 5B.

[0163] 9. The method of solution 8, wherein the service request comprises an inventory request, a command request or a disable request and correspondingly the service response comprises an inventor response, a command response or a disable response.

[0164] 10. The method of solution 8, wherein the service request message indicates one or more parameters from a freshness parameter, a message authentication code, a reader identifier, a check indication or an encrypted reader identifier.

[0165] 11. The method of solution 10, wherein the freshness parameter comprises a random number or a counter value.

[0166] 12. The method of any of solutions 8-11, wherein the determining whether the service request message is authentic includes generating a local message authentication code based on at least some of the one or more parameters received in the service request message; and comparing the local message authentication code with the message authentication code received in the service request message. Some examples are disclosed with reference to FIGS. 2A to 5B.

[0167] 13. The method of any of solutions 9-12, wherein, upon detecting that the service request message includes the check indication, the wireless device transmits a reader identifier request message to the user device.

[0168] 14. The method of any of solutions 9-12, wherein, upon detecting that the service request message includes the encrypted reader identifier, the wireless device determines whether the service request message is authentic by generating a local message authentication code based on a previously stored local reader identifier and a previous key; and comparing the local message authentication code with the message authentication code received in the service request message; and upon detecting that the local message authentication code is identical to the message authentication code received in the service request message, decrypting the encrypted reader identifier and checking whether a result of the decrypting is same as the previously stored local reader identifier.

[0169] 15. A method of digital communication (e.g., method 800 depicted in FIG. 8) , comprising: receiving (802) , by a network device, a reader request from a first network function; determining (804) , by the network device, whether the reader request can be forwarded to a radio access network; and sending (806) a response to the first network function according to the determining. The method 800 may be performed by the NG-RAN (e.g., 153) . The NG-RAN functionalities may be implemented by one or more network-side devices as described with reference to FIGS. 2A to 5B.

[0170] 16. The method of solution 15, wherein transmitting a paging signal to the radio access network upon determining that the reader request can be forwarded to the radio access network,

[0171] 17. A method of digital communication (e.g., method 900 depicted in FIG. 9) , comprising: receiving (902) , by a user device from a network device, a service request message for a wireless device; forwarding (904) , by the user device, the service request message to the wireless device; receiving (906) , by the user device from the wireless device, a service response message; and sending (908) , by the user device, the service response message to the network device. The method 900 may be performed by a wireless device that is user equipment 152. Further functionalities and features of the wireless device are disclosed with reference to FIGS. 2A to 5B.

[0172] 18. The method of solution 17, wherein the service request comprises an inventory request, a command request or a disable request and correspondingly the service response comprises an inventor response, a command response or a disable response.

[0173] 19. The method of any of solutions 17-18, wherein the service request message indicates one or more parameters from a freshness parameter, a message authentication code, a reader identifier, a check indication or an encrypted reader identifier.

[0174] 20. The method of solution 19, wherein the freshness parameter comprises a random number or a counter value.

[0175] 21. The method of solution 17, further including, storing, by the user device, the reader identifier in a local memory, in case that the service request message includes the reader identifier.

[0176] 22. The method of any of solutions 17-21, further including: receiving a reader identifier request message from the wireless device; and transmitting a reader identifier response to the wireless device.

[0177] 23. A communication apparatus comprising at least one processor configured to cause the communication apparatus to implement a method recited in any one or more of solutions 1-22.

[0178] 23. A computer-readable medium having code stored thereon, the code, upon execution by at least one processor of an apparatus, causing the apparatus to implement any one or more of solutions 1-22.

[0179] In some embodiments, an AMF may be configured to transmit, or receive and process, messages as disclosed with reference to FIGS. 2A to 5B.

[0180] In various embodiments, AUSF, UDM, NRF, NEF and AF may be configured to transmit, or receive and process, messages as disclosed with reference to FIGS. 2A to 5B.

[0181] FIG. 10 shows an example of a wireless communication system (e.g., a long term evolution (LTE) , 5G or NR cellular network) that includes a base station BS 1201 and one or more user equipment (UE) 1111, 1121 and 1131. In some embodiments, the uplink transmissions (1311, 1321, 1331) can include uplink control information (UCI) , higher layer signaling (e.g., UE assistance information or UE capability) , or uplink information. In some embodiments, the downlink transmissions (1411, 1421, 1431) can include downlink control information, DCI or medium access control (MAC) information or high layer signaling or downlink information. The UE may be, for example, a smartphone, a tablet, a mobile computer, a machine to machine (M2M) device, a terminal, a mobile device, an Internet of Things (IoT) device, and so on. Various core network functions depicted in FIG. 1 may be communicatively coupled (directly or indirectly) to the BS 1201.

[0182] FIG. 11 is a block diagram representation of a portion of an apparatus, in accordance with some embodiments of the presently disclosed technology. An apparatus 1105 such as a network device or a base station or a wireless device (or UE) , can include processor electronics 1110 such as one or more processors, one or more microprocessors, or the like, which implements one or more of the techniques presented in this document. The apparatus 1105 can include transceiver electronics 1115 to send or transmit and / or receive signals and messages over one or more communication interfaces such as antenna (s) 1120 or a wired interface (not explicitly shown) . The apparatus 1105 can include other communication interfaces for transmitting and receiving data. Apparatus 1105 can include one or more memories (not explicitly shown) configured to store information such as data and / or instructions. In some implementations, the processor electronics 1110 can include at least a portion of the transceiver electronics 1115. In some embodiments, at least some of the disclosed techniques, actors (refer to FIGS. 2A to 5B) modules or functions are implemented using the apparatus 1105.

[0183] It will be appreciated that the present document discloses at least the following techniques.

[0184] 1. In some embodiments, AIOTF generates one or more of a Reader ID, a freshness parameter, a MAC, or an encrypted Reader ID. If AIoT device receives Reader ID, the AIoT device checks the MAC and stores the new Reader ID.

[0185] 2. In some embodiments, if AIoTF wants the AIoT device double check the Reader ID without Reader ID changed, the AIoTF may include a Reader ID check indication or an encrypted Reader ID.

[0186] 3. In some embodiments, if an AIOT device receives Reader ID check indication, the AIOT device requests Reader ID from the Reader and checks the received Reader ID and stored Reader ID.

[0187] 4. In some embodiments, if AIOT device receives an encrypted Reader ID, the AIOT device decrypted the Reader ID and checks the received Reader ID and stored Reader ID.

[0188] It will be appreciated that the above-disclosed techniques are useful in making AIOT service request / response tasks more robust to unauthorized access to the information stored in AIOT devices. In one aspect, authentication of a service request is performed such that the AIOT device discards a service request upon not being able to authorize the service request from its previously stored information about a reader ID with which the AIOT device had previously communicated in an authenticated manner.

[0189] Some of the embodiments described herein are described in the general context of methods or processes, which may be implemented in one embodiment by a computer program product, embodied in a computer-readable medium, including computer-executable instructions, such as program code, executed by computers in networked environments. A computer-readable medium may include removable and non-removable storage devices including, but not limited to, Read Only Memory (ROM) , Random Access Memory (RAM) , compact discs (CDs) , digital versatile discs (DVD) , etc. Therefore, the computer-readable media can include a non-transitory storage media. Generally, program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-or processor-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps or processes.

[0190] Some of the disclosed embodiments can be implemented as devices or modules using hardware circuits, software, or combinations thereof. For example, a hardware circuit implementation can include discrete analog and / or digital components that are, for example, integrated as part of a printed circuit board. Alternatively, or additionally, the disclosed components or modules can be implemented as an Application Specific Integrated Circuit (ASIC) and / or as a Field Programmable Gate Array (FPGA) device. Some implementations may additionally or alternatively include a digital signal processor (DSP) that is a specialized microprocessor with an architecture optimized for the operational needs of digital signal processing associated with the disclosed functionalities of this application. Similarly, the various components or sub-components within each module may be implemented in software, hardware or firmware. The connectivity between the modules and / or components within the modules may be provided using any one of the connectivity methods and media that is known in the art, including, but not limited to, communications over the Internet, wired, or wireless networks using the appropriate protocols.

[0191] While this document contains many specifics, these should not be construed as limitations on the scope of an invention that is claimed or of what may be claimed, but rather as descriptions of features specific to particular embodiments. Certain features that are described in this document in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or a variation of a sub-combination. Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results.

[0192] Only a few implementations and examples are described, and other implementations, enhancements, and variations can be made based on what is described and illustrated in this document.

Claims

1.A method of digital communication, comprising:transmitting, by a first network function, a service request;receiving, by the first network function, a service response for the service request; andperforming further network operations based on the service response.2.The method of claim 1, wherein the service request comprises an inventory request, a command request or a disable request, and correspondingly the service response comprises an inventory response, a command response or a disable response.3.The method of any of claims 1-2, wherein the service request includes at least one of following parameters: a freshness parameter, a message authentication code, a reader identifier (reader ID) , a check indication or an encrypted reader ID.4.The method of claim 3, wherein the freshness parameter comprises a random number or a counter value.5.The method of claim 3, including, prior to the transmitting service request:transmitting, by the first network function to a radio access network (RAN) device or a second network function, a reader request; andreceiving, by the first network function, from the RAN device or the second network function, a reader response in response to the reader request.6.The method of claim 3, wherein the service request includes the reader ID, wherein the first network function determines the reader ID based on user device information in the reader response.7.The method of claim 3, wherein the message authentication code and the encrypted reader ID are generated using a key stored at the first network function, wherein the key is derived based on the root key of the wireless device.8.A method of digital communication, comprising:receiving, by a wireless device, a service request message from a user device or a radio access network (RAN) device,determining whether the service request message is authentic by processing the one or more parameters in the service request message;discarding the service request message in case it is determined that the service request message is not authentic; andperforming one or more service response operations in case it is determined that the service request message is authentic.9.The method of claim 8, wherein the service request comprises an inventory request, a command request or a disable request and correspondingly the service response comprises an inventor response, a command response or a disable response.10.The method of claim 8, wherein the service request message indicates one or more parameters from a freshness parameter, a message authentication code, a reader identifier, a check indication or an encrypted reader identifier.11.The method of claim 10, wherein the freshness parameter comprises a random number or a counter value.12.The method of any of claims 8-11, wherein the determining whether the service request message is authentic includes:generating a local message authentication code based on at least some of the one or more parameters received in the service request message; andcomparing the local message authentication code with the message authentication code received in the service request message.13.The method of claim 9, wherein, upon detecting that the service request message includes the check indication, the wireless device transmits a reader identifier request message to the user device.14.The method of claim 9, wherein, upon detecting that the service request message includes the encrypted reader identifier, the wireless device determines whether the service request message is authentic by:generating a local message authentication code based on a previously stored local reader identifier and a previous key; andcomparing the local message authentication code with the message authentication code received in the service request message; andupon detecting that the local message authentication code is identical to the message authentication code received in the service request message, decrypting the encrypted reader identifier and checking whether a result of the decrypting is same as the previously stored local reader identifier.15.A method of digital communication, comprising:receiving, by a network device, a reader request from a first network function;determining, by the network device, whether the reader request can be forwarded to a radio access network; andsending a response to the first network function according to the determining.16.The method of claim 15, whereintransmitting a paging signal to the radio access network upon determining that the reader request can be forwarded to the radio access network.17.A method of digital communication, comprising:receiving, by a user device from a network device, a service request message for a wireless device;forwarding, by the user device, the service request message to the wireless device;receiving, by the user device from the wireless device, a service response message; andsending, by the user device, the service response message to the network device.18.The method of claim 17, wherein the service request comprises an inventory request, a command request or a disable request and correspondingly the service response comprises an inventor response, a command response or a disable response.19.The method of any of claims 17-18, wherein the service request message indicates one or more parameters from a freshness parameter, a message authentication code, a reader identifier, a check indication or an encrypted reader identifier.20.The method of claim 19, wherein the freshness parameter comprises a random number or a counter value.21.The method of claim 17, further including,storing, by the user device, the reader identifier in a local memory, in case that the service request message includes the reader identifier.22.The method of any of claims 17-21, further including:receiving a reader identifier request message from the wireless device; andtransmitting a reader identifier response to the wireless device.23.A communication apparatus comprising at least one processor configured to cause the communication apparatus to implement a method recited in any one or more of claims 1-22.24.A computer-readable medium having code stored thereon, the code, upon execution by at least one processor of an apparatus, causing the apparatus to implement any one or more of claims 1-22.

Images