Authentication in communication network environments with ambient power-enabled devices

Abstract

In one non-limiting example, a method comprises selecting, at an activator device, an ambient power-enabled device from a plurality of ambient power-enabled devices supportable by an access point. The method further comprises sending, from the activator device, an identifier of the activator device and an identifier of the selected ambient power-enabled device, wherein at least the identifier of the activator device is encrypted, to the selected ambient power-enabled device in a request to activate the selected ambient power-enabled device, and then receiving, at the activator device, an authorization token from the access point which is usable to authenticate the activator device and the selected ambient power-enabled device with respect to subsequent data. A freshness parameter can be used for encryption in some alternative examples. In other alternative examples, an encryption key for a selected ambient power-enabled device can be generated from a set of home network keys.

Description

[0001] AUTHENTICATION IN COMMUNICATION NETWORK ENVIRONMENTS WITH AMBIENT POWER-ENABLED DEVICES

[0002] Field

[0003] The field relates generally to communication networks, and more particularly, but not exclusively, to security management in such communication networks.

[0004] Background

[0005] This section introduces aspects that may be helpful in facilitating a better understanding of the inventions. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.

[0006] While fourth generation (4G) wireless mobile telecommunications technology, also known as Long Term Evolution (LTE) technology, was designed to provide high-capacity mobile multimedia with high data rates particularly for human interaction, fifth generation (5G) technology is intended to be used not only for human interaction, but also for machine type communications in so-called Internet of Things (loT) networks.

[0007] More particularly, 5G networks are intended to enable massive loT services (e.g., very large numbers of limited capacity devices) and mission-critical loT services (e.g., requiring high reliability), while also providing improvements over legacy mobile communication services in the form of enhanced mobile broadband (eMBB) services with improved wireless Internet access for mobile devices.

[0008] In an example communication system, user equipment (5G UE in a 5G network or, more broadly, a UE) such as a mobile terminal (subscriber) communicates over an air interface with a base station or access point of an access network referred to as a 5G AN in a 5G network. The access point (e.g., gNB) is illustratively part of an access network of the communication system.

[0009] For example, in a 5G network, the access network referred to as a 5G AN is described in 5G Technical Specification (TS) 23.501, entitled “Technical Specification Group Services and System Aspects; System Architecture for the 5G System,” and TS 23.502, entitled “Technical Specification Group Services and System Aspects; Procedures for the 5G System (5GS),” the disclosures of which are incorporated by reference herein in their entireties. In general, the access point (e.g., gNB) provides access for the UE to a core network (CN or 5GC), which then provides access for the UE to other UEs and / or a data network such as a packet data network (e.g., Internet). TS 23.501 goes on to define a 5G Service-Based Architecture (SBA) which models services as network functions (NFs) that communicate with each other using representational state transfer application programming interfaces (Restful APIs). Furthermore, TS 33.501, entitled “Technical Specification Group Services and System Aspects; Security Architecture and Procedures for the 5G System,” the disclosure of which is incorporated by reference herein in its entirety, further describes security management details associated with a 5G network.

[0010] In some cases, however, devices that are part of an loT network, i.e., loT devices, can be configured to communicate with UEs or other communication network devices for one or more purposes, e.g., data sharing, device programming, etc. One example use case involves what are referred to as ambient loT devices which are loT devices that have no or limited energy storage capabilities and rely on, at least partially, the environment in which they operate for power (i.e., ambient power-enabled). However, due to continuing attempts to improve the architectures and protocols associated with 5G and future networks in order to increase network efficiency and / or subscriber convenience, security management issues associated with such ambient power-enabled loT devices can present a significant challenge.

[0011] Summary

[0012] Illustrative embodiments provide authentication techniques in a communication network environment with ambient loT functionalities.

[0013] In one illustrative embodiment, from an activator device perspective, a method comprises selecting, at the activator device, an ambient power-enabled device from a plurality of ambient power-enabled devices supportable by an access point to which the activator device is connected. The method further comprises sending, from the activator device, an identifier of the activator device and an identifier of the selected ambient power-enabled device, wherein at least the identifier of the activator device is encrypted, to the selected ambient power-enabled device in a request to activate the selected ambient power-enabled device. The method further comprises receiving, at the activator device via the selected ambient power-enabled device, an authorization token from the access point which is usable to authenticate the activator device and the selected ambient power-enabled device with respect to subsequent data. In some illustrative embodiments, a freshness parameter can be used to encrypt the identifier of the activator device and the ambient power-enabled device.

[0014] In another illustrative embodiment, from an ambient power-enabled device perspective, a method comprises receiving, from an activator device at the ambient power-enabled device selected from a plurality of ambient power-enabled devices supportable by an access point to which the ambient power-enabled device is connected, an identifier of the activator device and an identifier of the ambient power-enabled device, wherein at least the identifier of the activator device is encrypted, in a request to activate the ambient power-enabled device. The method further comprises sending, from the ambient power-enabled device to the access point, the request to activate the ambient power-enabled device. The method further comprises receiving, from the access point at the ambient power-enabled device, an authorization token which is usable to authenticate the ambient power-enabled device and the activator device with respect to subsequent data. The method further comprises sending the authorization token from the ambient power-enabled device to the activator device.

[0015] In a further illustrative embodiment, from an access point perspective, a method comprises receiving, at the access point from an ambient power-enabled device selected from a plurality of ambient power-enabled devices supported by the access point, an identifier of an activator device and an identifier of the ambient power-enabled device in a request to activate the ambient power-enabled device, wherein at least the identifier of the activator device is encrypted. The method further comprises causing, by the access point, verification of the activator device and the ambient power-enabled device. The method further comprises generating, by the access point, an authorization token, in response to verification of the ambient power-enabled device and the activator device, which is usable to authenticate the ambient power-enabled device and the activator device with respect to subsequent data. The method further comprises sending, from the access point, the authorization token to the ambient power-enabled device and the activator device.

[0016] In still further illustrative embodiments, a key can be generated for a selected ambient power-enabled device from a set of one or more keys associated with a home network (e.g., one or more access stratum keys) of an activator device and used to encrypt data from the activator device.

[0017] Further illustrative embodiments are provided in the form of a non-transitory computer- readable storage medium having embodied therein executable program code that when executed by a processor causes the processor to perform the above steps. Still further illustrative embodiments comprise an apparatus with a processor and a memory configured to perform the above steps.

[0018] Advantageously, illustrative embodiments provide authentication techniques for communication network environments with AIoT functionalities.

[0019] These and other features and advantages of embodiments described herein will become more apparent from the accompanying drawings and the following detailed description.

[0020] Brief Description of the Drawings

[0021] FIG. 1 illustrates a communication network environment with which one or more illustrative embodiments may be implemented.

[0022] FIG. 2 illustrates devices and entities with which one or more illustrative embodiments may be implemented.

[0023] FIG. 3 illustrates an authentication procedure in a communication network environment with ambient loT functionalities according to an illustrative embodiment.

[0024] FIGS. 4A and 4C illustrate an authentication procedure in a communication network environment with ambient loT functionalities according to another illustrative embodiment.

[0025] FIG. 5 illustrates an authentication procedure in a communication network environment with ambient loT functionalities according to yet another illustrative embodiment.

[0026] Detailed Description

[0027] Embodiments will be illustrated herein in conjunction with example communication systems and associated techniques for security management in communication systems. It should be understood, however, that the scope of the claims is not limited to particular types of communication systems and / or processes disclosed. Embodiments can be implemented in a wide variety of other types of communication systems, using alternative processes and operations. For example, although illustrated in the context of wireless cellular systems utilizing the 3rd Generation Partnership Project (3GPP) system elements such as a 3GPP next generation system (5G), the disclosed embodiments can be adapted in a straightforward manner to a variety of other types of communication systems such as 6G communication systems.

[0028] In accordance with illustrative embodiments implemented in 5G or future communication system environments, one or more 3GPP technical specifications (TS) and technical reports (TR) may provide further explanation of network elements / functions and / or operations that may interact with parts of the inventive solutions, e.g., the above-referenced 3GPP TS 23.501, TS 23.502, and TS 33.501. Other 3GPP TS / TR documents may provide other details that one of ordinary skill in the art will realize. For example, TR 22.840 entitled “Technical Specification Group Services and System Aspects; Study on Ambient Power- Enabled Internet of Things,” the disclosure of which is incorporated by reference herein in its entirety, discloses some background details of loT devices. Note that 3GPP TS / TR documents are non-limiting examples of communication network standards (e.g., specifications, procedures, reports, requirements, recommendations, and the like). However, while well- suited for 5G-related 3GPP standards, embodiments are not necessarily intended to be limited to any particular standards.

[0029] It is to be understood that the term 5G network, and the like (e.g., 5G system, 5G communication system, 5G environment, 5G communication environment etc.), in some illustrative embodiments, may be understood to comprise all or part of an access network and all or part of a core network. However, the term 5G network, and the like, may also occasionally be used interchangeably herein with the term 5GC network, and the like, without any loss of generality, since one of ordinary skill in the art understands any distinctions.

[0030] Prior to describing illustrative embodiments, a general description of certain main components of a 5G network will be described below in the context of FIGS. 1 and 2.

[0031] FIG. 1 shows a communication system 100 within which illustrative embodiments are implemented. It is to be understood that the elements shown in communication system 100 are intended to represent some main functions provided within the system, e.g., control plane functions, user plane functions, etc. As such, the blocks shown in FIG. 1 reference specific elements in 5G networks that provide some of these main functions. However, other network elements may be used to implement some or all of the main functions represented. Also, it is to be understood that not all functions of a 5G network are depicted in FIG. 1. Rather, at least some functions that facilitate an explanation of illustrative embodiments are represented. Subsequent figures may depict some additional elements / functions (i.e., network entities).

[0032] Accordingly, as shown, communication system 100 comprises user equipment (UE) 102 that communicates via an air interface with an access point 104. It is to be understood that UE 102 may use one or more other types of access points (e.g., access functions, networks, etc.) to communicate with the 5GC network other than a gNB. By way of example only, the access point 104 may be any 5G access network (gNB), an untrusted non-3GPP access network that uses a Non-3GPP Interworking Function (N3IWF), a trusted non-3GPP network that uses a Trusted Non-3GPP Gateway Function (TNGF) or wireline access that uses a Wireline Access Gateway Function (W-AGF) or may correspond to a legacy access point (e.g., eNB). Furthermore, access point 104 may be a wireless local area network (WLAN) access point as will be further explained in illustrative embodiments described herein.

[0033] The UE 102 may be a mobile station, and such a mobile station may comprise, by way of example, a mobile telephone, a computer, or any other type of communication device. The term “user equipment” as used herein is therefore intended to be construed broadly, so as to encompass a variety of different types of mobile stations, subscriber stations or, more generally, communication devices, including examples such as a combination of a data card inserted in a laptop or other equipment such as a smart phone. Such communication devices are also intended to encompass devices commonly referred to as access terminals.

[0034] In one illustrative embodiment, UE 102 is comprised of a Universal Integrated Circuit Card (UICC) part and a Mobile Equipment (ME) part. The UICC is the user-dependent part of the UE and contains at least one Universal Subscriber Identity Module (USIM) and appropriate application software. The USIM securely stores a permanent subscription identifier and its related key, which are used to uniquely identify and authenticate subscribers to access networks. The ME is the user-independent part of the UE and contains terminal equipment (TE) functions and various mobile termination (MT) functions. Alternative illustrative embodiments may not use UICC-based authentication, e.g., a Non-Public (Private) Network (NPN).

[0035] Note that, in one example, the permanent subscription identifier is an International Mobile Subscriber Identity (IMSI) unique to the UE. In one embodiment, the IMSI is a fixed 15 -digit length and consists of a 3 -digit Mobile Country Code (MCC), a 3 -digit Mobile Network Code (MNC), and a 9-digit Mobile Station Identification Number (MSIN). In a 5G communication system, an IMSI is referred to as a Subscription Permanent Identifier (SUPI). In the case of an IMSI as a SUPI, the MSIN provides the subscriber identity. Thus, only the MSIN portion of the IMSI typically needs to be encrypted. The MNC and MCC portions of the IMSI provide routing information, used by the serving network to route to the correct home network. When the MSIN of a SUPI is encrypted, it is referred to as Subscription Concealed Identifier (SUCI). Another example of a SUPI uses a Network Access Identifier (NAI). NAI is typically used for loT communication.

[0036] Additionally, as shown, an loT device 103 communicates via an air interface with access point 104, as well as UE 102. In one illustrative use case, as will be further described herein, loT device 103 may be an Ambient loT (AIoT) device, which as will be further explained herein can be a low power device (i.e., an ambient power-enabled device). While only one UE 102 and one loT device 103 are shown in FIG. 1, it is to be appreciated that pluralities of each of UE 102 and loT device 103 may typically communicate with access point 104.

[0037] The access point 104 is illustratively part of a radio access network (RAN), or more simply, access network (AN), of the communication system 100. Such a radio access network may comprise, for example, a 5G System having a plurality of base stations. Components of a radio access network may, more generally, be considered “radio access entities.” In one nonlimiting example, access point 104 may be referred to as a base transceiver station (BTS).

[0038] Further, the access point 104 in this illustrative embodiment is operatively coupled to an Access and Mobility Management Function (AMF / SEAF) 106. In a 5G network, the AMF / SEAF supports, inter alia, mobility management (MM) and security anchor (SEAF) functions.

[0039] AMF / SEAF 106 in this illustrative embodiment is operatively coupled to (e.g., uses the services of) other network functions 108. As shown, some of these other network functions 108 include, but are not limited to, a Unified Data Management (UDM) function and an Authentication Server Function (AUSF). These listed network function examples are typically implemented in the home network (HN) of the UE subscriber, further explained below. Note that, in a 5GC network, the 4G function of the HSS (home subscriber server) is split into the AUSF, UDM, and a Unified Data Repository (UDR, not expressly shown) functions. Typically, AUSF authenticates UEs and provides any needed cryptographic keys, while UDR stores the user data and UDM manages the user data.

[0040] Other network functions 108 may include network functions that can act as service producers (NFp) and / or service consumers (NFc). Note that any network function can be a service producer for one service and a service consumer for another service. Further, when the service being provided includes data, the data-providing NFp is referred to as a data producer, while the data-requesting NFc is referred to as a data consumer. A data producer may also be an NF that generates data by modifying or otherwise processing data produced by another NF. Note that NFs may, more generally, be considered “network entities.”

[0041] Note that a UE, such as UE 102, is typically subscribed to what is referred to as a Home Public Land Mobile Network (HPLMN or HN for short) in which some or all of the functions 106 and 108 reside. Alternatively the UE, such as UE 102, may receive services from an NPN where these functions may reside. The HPLMN is also referred to as the Home Environment (HE). If the UE is roaming (not in the HPLMN), it is typically connected with a Visited Public Land Mobile Network (VPLMN) also referred to as a visited network, while the network that is currently serving the UE is also referred to as a serving network (SN). In the roaming case, some of the network functions 106 and 108 can reside in the VPLMN, in which case, functions in the VPLMN communicate with functions in the HPLMN as needed. However, in a nonroaming scenario, access and mobility management functions 106 and the other network functions 108 reside in the same communication network, i.e., HPLMN. Embodiments described herein, unless otherwise specified, are not necessarily limited by which functions reside in which PLMN (i.e., HPLMN or VPLMN).

[0042] The access point 104 is also operatively coupled (via one or more of functions 106 and / or 108) to a Session Management Function (SMF) 110, which is operatively coupled to a User Plane Function (UPF) 112. UPF 112 is operatively coupled to a Packet Data Network, e.g., Internet 114. Note that the thicker solid lines in this figure denote a user plane (UP) of the communication network, as compared to the thinner solid lines that denote a control plane (CP) of the communication network. It is to be appreciated that network (e.g., Internet) 114 in FIG. 1 may additionally or alternatively represent other network infrastructures including, but not limited to, cloud computing infrastructure and / or edge computing infrastructure. Further typical operations and functions of such network elements are not described here since they are not the focus of the illustrative embodiments and may be found in appropriate 3GPP 5G documentation. Note that functions shown in 106, 108, 110 and 112 are examples of network functions (NFs).

[0043] It is to be appreciated that this particular arrangement of system elements is an example only, and other types and arrangements of additional or alternative elements can be used to implement a communication system in other embodiments. For example, in other embodiments, the communication system 100 may comprise other elements / functions not expressly shown herein. Accordingly, the FIG. 1 arrangement is just one example configuration of a wireless cellular system, and numerous alternative configurations of system elements may be used. For example, although only single elements / functions are shown in the FIG. 1 embodiment, this is for simplicity and clarity of description only. A given alternative embodiment may of course include larger numbers of such system elements, as well as additional or alternative elements of a type commonly associated with conventional system implementations.

[0044] It is also to be noted that while FIG. 1 illustrates system elements as singular functional blocks, the various subnetworks that make up the 5G network are partitioned into so-called network slices. Network slices (network partitions) are logical networks that provide specific network capabilities and network characteristics that can support a corresponding service type, optionally using network function virtualization (NFV) on a common physical infrastructure. With NFV, network slices are instantiated as needed for a given service, e.g., eMBB service, massive loT service, and mission-critical loT service. A network slice or function is thus instantiated when an instance of that network slice or function is created. In some embodiments, this involves installing or otherwise running the network slice or function on one or more host devices of the underlying physical infrastructure. UE 102 is configured to access one or more of these services via access point 104.

[0045] FIG. 2 is a block diagram illustrating computing architectures for various participants in methodologies according to illustrative embodiments. More particularly, system 200 is shown comprising a device 202 and a plurality of entities 204-1, . . . . , 204-N. For example, in illustrative embodiments and with reference back to FIG. 1 , device 202 can represent UE 102 or loT device 103, while entities 204-1, . . . , 204-N can represent functions 106 and 108 (i.e., network entities), as well as access point 104 (i.e., radio access entity). It is to be appreciated that the device 202 and entities 204-1, . . . . , 204-N are configured to interact to provide security management and other techniques described herein.

[0046] The device 202 comprises a processor 212 coupled to a memory 216 and interface circuitry 210. The processor 212 of the device 202 includes a security management processing module 214 that may be implemented at least in part in the form of software executed by the processor. The security management processing module 214 performs security management described in conjunction with subsequent figures and otherwise herein. The memory 216 of the device 202 includes a security management storage module 218 that stores data generated or otherwise used during security management operations. Each of the entities (individually or collectively referred to herein as 204) comprises a processor 222 (222-1, . . . , 222-N) coupled to a memory 226 (226-1, . . . , 226-N) and interface circuitry 220 (220-1, . . . , 220-N). Each processor 222 of each entity 204 includes a security management processing module 224 (224-1, . . . , 224-N) that may be implemented at least in part in the form of software executed by the processor 222. The security management processing module 224 performs security management operations described in conjunction with subsequent figures and otherwise herein. Each memory 226 of each entity 204 includes a security management storage module 228 (228-1, . . . , 228-N) that stores data generated or otherwise used during security management operations.

[0047] The processors 212 and 222 may comprise, for example, microprocessors such as central processing units (CPUs), application-specific integrated circuits (ASICs), digital signal processors (DSPs) or other types of processing devices, as well as portions or combinations of such elements.

[0048] The memories 216 and 226 may be used to store one or more software programs that are executed by the respective processors 212 and 222 to implement at least a portion of the functionality described herein. For example, security management operations and other functionality as described in conjunction with subsequent figures and otherwise herein may be implemented in a straightforward manner using software code executed by processors 212 and 222.

[0049] A given one of the memories 216 and 226 may therefore be viewed as an example of what is more generally referred to herein as a computer program product or still more generally as a processor-readable storage medium that has executable program code embodied therein. Other examples of processor-readable storage media may include disks or other types of magnetic or optical media, in any combination. Illustrative embodiments can include articles of manufacture comprising such computer program products or other processor-readable storage media.

[0050] Further, the memories 216 and 226 may more particularly comprise, for example, electronic random- access memory (RAM) such as static RAM (SRAM), dynamic RAM (DRAM) or other types of volatile or non-volatile electronic memory. The latter may include, for example, non-volatile memories such as flash memory, magnetic RAM (MRAM), phasechange RAM (PC-RAM) or ferroelectric RAM (FRAM). The term “memory” as used herein is intended to be broadly construed, and may additionally or alternatively encompass, for example, a read-only memory (ROM), a disk-based memory, or other type of storage device, as well as portions or combinations of such devices.

[0051] The interface circuitries 210 and 220 illustratively comprise transceivers or other communication hardware or firmware that allows the associated system elements to communicate with one another in the manner described herein.

[0052] It is apparent from FIG. 2 that device 202 and plurality of entities 204 are configured for communication with each other as security management participants via their respective interface circuitries 210 and 220. This communication involves each participant sending data to and / or receiving data from one or more of the other participants. The term “data” as used herein is intended to be construed broadly, so as to encompass any type of information that may be sent between participants including, but not limited to, identity data, key pairs, key indicators, tokens, secrets, security management messages, registration request / response messages and data, request / response messages, authentication request / response messages and data, metadata, control data, audio, video, multimedia, consent data, other messages, etc.

[0053] It is to be appreciated that the particular arrangement of components shown in FIG. 2 is an example only, and numerous alternative configurations may be used in other embodiments. For example, any given network element / function and / or access point can be configured to incorporate additional or alternative components and to support other communication protocols.

[0054] Other system elements such as access point 104, SMF 110, and UPF 112 may each be configured to include components such as a processor, memory and network interface. Also, entities such as third-party applications and network operators can participate in methodologies described herein via computing devices configured to include components such as a processor, memory and network interface. These elements and devices need not be implemented on separate stand-alone processing platforms, but could instead, for example, represent different functional portions of a single common processing platform.

[0055] More generally, FIG. 2 can be considered to represent processing devices configured to provide respective security management functionalities and operatively coupled to one another in a communication system. By way of example only, all or parts of each of device 202 and the plurality of entities 204 (e.g., processor and memory) can be considered examples of means for performing one or more operations, one or more steps, one or more functions, one or more processes, etc. as described herein. As mentioned above, the 3GPP TS 23.501 defines the 5GC network architecture as service-based, e.g., Service-Based Architecture (SBA). It is realized herein that in deploying different NFs, there can be many situations where an NF may need to interact with an entity external to the SBA-based 5GC network (e.g., including the corresponding PLMN(s), e.g., HPLMN and VPLMN). Thus, the term “internal” as used herein illustratively refers to operations and / or communications within the SBA-based 5GC network (e.g., SBA-based interfaces) and the term “external” illustratively refers to operations and / or communications outside the SBA-based 5GC network (non-SBA interfaces).

[0056] Given the above general description of some features of a 5GC network, problems with existing security approaches in a communication network environment with ambient loT functionalities, and solutions proposed in accordance with illustrative embodiments, will now be described herein below.

[0057] An ambient loT device (e.g., loT device 103) is typically either battery-less or has limited energy storage capability (e.g., using a capacitor). As such, ambient loT (AIoT) devices are typically powered by energy harvesting, e.g., deriving power from radio waves in the area of, e.g., ambient with respect to the loT devices. Such devices may generally be referred to as ambient power-enabled devices.

[0058] A communication network environment with AIoT functionalities typically also employs a store-and-forward communication model. Store-and-forward communication is an operation mode of a 5G system where a single UE can collect and store information from an AIoT device before forwarding this information to the 5GC.

[0059] Ambient loT is needed along with existing loT technologies such as NB-IoT / eMTC and NR RedCap that have been defined in 3GPP to cover additional use cases that demand more cost-effective, power-efficient, and particularly battery-less functionality.

[0060] The number of AIoT devices in a communication network environment is likely to significantly increase in the future and their lifespan should be more than 5 years. Charging or regular replacement of a battery for all AIoT devices will be impractical due to tremendous consumption of manpower and materials.

[0061] Some example use cases of AIoT devices include, but are not limited to, (i) identification (ID) tags (e.g., replacement of radio frequency ID (RFID) tags with wider range); (ii) sensors (e.g., temperature, humidity, etc.); (iii) healthcare devices (e.g., monitoring personal medical information); (iv) logistics (e.g., tracking objects). Some system architecture components of a communication network environment with AIoT functionalities include, but are not limited to: (i) an activator (also referred to as an illuminator) which is a device (more generally, an activator device) that sends an activation signal targeted at waking up a passive AIoT device; (ii) an AIoT device (e.g., a radio or a tag, or, more generally, an ambient power-enabled device); and (iii) a reader which is a device that listens and detects passive radio signals (note that the reader may or may not be collocated with the activator).

[0062] There are various types of AIoT devices including, but not limited to, the following three device types:

[0063] (i) Device type A (passive): Pure battery-less devices with no energy storage capability at all, no independent signal generation / amplification (i.e., capable of only backscattering), and completely dependent on the availability of an external source of energy;

[0064] (ii) Device type B (semi-passive): Devices with limited energy storage capability that do not need to be replaced or recharged manually, and no independent signal generation but backscattering potentially with reflection gain; and

[0065] (iii) Device type C (active): Actively transmitting device with limited energy storage capabilities based on ambient energy sources.

[0066] Various example AIoT device availability scenarios are contemplated with different kinds of communication patterns (operations) that could be dependent on power available for communication, e.g., harvesting and the availability of storage capability or a specific use case. Non-limiting example patterns may include:

[0067] (i) Normal operation: In this scenario, AIoT devices have power available continuously or at least for significant amounts of time, either because there is continuous power harvesting or possibly in combination with limited energy storage (e.g., in a capacitor) to overcome momentary variations in power harvesting. The main effect of this scenario is that a processor and communications module in the AIoT device can be continuously active. The communications module can listen to the network at regular intervals to determine if there is mobile terminated traffic (e.g., trigger messages) and can transmit data when relevant.

[0068] (ii) Device triggered operation: In this scenario, devices have power available only intermittently. The main effect of this scenario is that the AIoT device can only be active for short periods of time. It is the AIoT device that decides when to communicate with the network. It is possible that the AIoT device is not able to listen to the network for mobile terminated traffic for very long periods of time. This has an impact on service aspects such as provisioning.

[0069] (iii) On demand operation: In this scenario, the 5G network will wake up and trigger the AIoT device to communicate in a relevant manner. This scenario only considers the network triggering the communication and the AIoT device cannot determine when to communicate. Waking up of the AIoT device can be combined with a trigger to perform a specific action (e.g., do a measurement) or to communicate (e.g., send an identifier). Waking up can also imply that the AIoT device starts listening to the network for further instructions.

[0070] It is to be appreciated that the scenarios are not intended as definitions for device categories but rather to highlight service aspects that are associated with different scenarios.

[0071] While the above exemplary use cases and descriptions present some illustrative details of AIoT functionalities (see also the above-referenced 3GPP TR 22.840), it is realized herein that existing AIoT functionalities do not account for authentication (and authorization) of the tag (i.e., AIoT device) along with the activator or illuminator (e.g., UE).

[0072] Illustrative embodiments overcome the above and other technical deficiencies of existing AIoT functionalities by providing authentication techniques for communication network environments with AIoT functionalities.

[0073] FIG. 3 illustrates a procedure 300 for use in authentication in a communication network environment with ambient loT functionalities according to an illustrative embodiment. As shown, procedure 300 involves a first illuminator 302-1, a second illuminator 302-2, a first tag 304, a BTS 306 and an AMF 308 that are part of a serving network 310 (e.g., SN or VPEMN), and a UDM 312 that is part of a home network 314 (e.g., HN or HPEMN or HE). It is to be appreciated that first illuminator 302-1 and second illuminator 302-2 may also be referred to as activators, as explained above, and in one or more illustrative embodiments may be UEs (e.g., UE#1 and UE#2). However, in alternative embodiments, one or more of first illuminator 302-1 and second illuminator 302-2 may be devices other than UEs, e.g., an access network (AN) component such as a BTS or some other network or standalone component. First tag 304 is identified as Tag ID#1. In this example, BTS 306 is part of a receiver (RX) of a gNB.

[0074] Note that first and second illuminators 302-1 and 302-2 may be more generally referred to as activator devices, first tag 304 may be more generally referred to as an ambient power- enabled device, and BTS 306 may more generally be referred to as an access point. In the illustrative embodiment of FIG. 3, as will be further explained below, the HN, SN and AN private keys are respectively pre-provisioned in the gNB (BTS / RX 306), AMF 308, and UDM 312, and the HN, SN and AN public keys are each pre-provisioned in first and second illuminators 302-1 and 302-2. An illuminator, in this example (and in the illustrative procedures to follow), first illuminator 302-1, encrypts using the HN public key and also provides the TAG_ID for first tag 304 (Tag ID#1) with encrypted data. An authorization token is generated by BTS 306 and is shared to first illuminator 302-1 using first tag 304. First tag 304 can store the authorization token for future verification as any data from first illuminator 302-1 will be forwarded to BTS 306 only when the authorization token matches. After the authorization token expiry, the same procedure needs to be repeated for new token generation.

[0075] Referring now to procedure 300 in FIG. 3, in a pre -provisioned phase:

[0076] Step 1 (sub steps 1.1, 1.2 and 1.3): Long term keys for a USIM#1 of UE#1 (first illuminator 302-1) and a USIM#2 of UE#2 (second illuminator 302-2) are provisioned in UDM 312 and also in the corresponding first and second illuminators 302-1 and 302-2 (UE#1 containing USIM#1 and UE#2 containing USIM#2).

[0077] Step 2 (sub steps 2.1, 2.2 and 2.3): The HN 314 private key is available in UDM 312 and the corresponding HN 314 public key is available in first and second illuminators 302-1 and 302-2 (UE#1 and UE#2).

[0078] Step 3 (sub steps 3.1 , 3.2 and 3.3): SN 310 private key and public key pair are generated and provisioned with the SN 310 private key in AMF 308 and the SN 310 public key in first and second illuminators 302-1 and 302-2 (UE#1 and UE#2).

[0079] It is to be appreciated that, in some illustrative embodiments, first tag 304 and first and second illuminators 302-1 and 302-2 are expected not be in roaming scenarios and more of fixed entities such that they will be connected the same serving network, e.g., SN 310. However, alternative embodiments contemplate one or more of first tag 304 and first and second illuminators 302-1 and 302-2 being mobile.

[0080] Step 4 (sub steps 4.1, 4.2 and 4.3): Similar to HN 314 and SN 310 key provisioning, key provisioning for the access network (AN including BTS 306) with which first tag 304 and first and second illuminators 302-1 and 302-2 connect are the same. More particularly, the AN private key is provisioned in BTS 306 and the AN public key is provisioned in the corresponding first and second illuminators 302-1 and 302-2 (UE#1 and UE#2). Step 5: Following the pre-provisioned phase, a system information type 2 (SIB2) message is broadcasted with a list of Tag ID#s which are supported by BTS 306 along with the public key ID. The public key ID is used to identify the corresponding HN, SN and AN public key in the USIM of each of first and second illuminators 302-1 and 302-2.

[0081] Continuing with procedure 300, in an authentication phase:

[0082] Step 6 (sub steps 6.1a through 6.10): First illuminator 302-1 select first tag 304 (6.1a). The HN public key is used for encryption of the UE_ID#1 (6.1b). The initial access (activation) request with encrypted UE_ID#1 and plain text TAG_ID#1 is sent in this message to first tag 304 (6.2). First tag 304 forwards the same request to BTS 306 (6.3). BTS 306 with AMF 308 check with UDM 312 whether or not UE_ID#1 is a valid identity (6.4). If verification is completed, BTS 306 generates the authorization token (6.5). Note that, in some illustrative embodiments, the AN private key can be used to protect the authorization token or any further communications between BTS 306 and first illuminator 302-1.

[0083] First tag 304 receives the authorization token (6.6) and stores the authorization token for future verifications (6.7). The initial response with the authorization token from BTS 306 is forwarded by first tag 304 to first illuminator 302-1 (6.8). The authorization token is valid only for a certain time and after timer expiry, a new request is made (6.9). The AN public key used for encrypting the data and authorization token is sent from first illuminator 302-1 to first tag 304 (i.e., first tag 304 verifies the authorization token with the expected authorization token), and if verification is successful, the data from first illuminator 302-1 is sent to BTS 306 (6.10).

[0084] Turning now to FIG. 4A, a procedure 400 for use in authentication in a communication network environment with ambient loT functionalities according to another illustrative embodiment is depicted. As shown, similar to procedure 300 of FIG. 3, procedure 400 of FIG. 4A involves first illuminator 302-1, second illuminator 302-2, first tag 304, BTS 306 and AMF 308 that are part of SN 310, and UDM 312 that is part of HN 314.

[0085] In this illustrative embodiment, symmetric keys such as access stratum (AS) keys are used to generate a new TAG key KTAG- The authorization token is generated in this embodiment also but is only for first tag 304 and not for first illuminator 302-1. When data is encrypted using the key KTAG by first illuminator 302-1 and forwarded to first tag 304, then first tag 304 adds the authorization token as an extra parameter along with encrypted data. BTS 306 verifies the encrypted data using KTAG and also MAC-I (integrity-protected message authentication code) of the received data. Also, the authorization token is verified. This way, both first illuminator 302- 1 and first tag 304 are verified.

[0086] As shown in procedure 400, in an integrated authentication phase:

[0087] Step 1 (sub steps 1.1, 1.2 and 1.3): As compared to procedure 300 of FIG. 3, only the long term keys for USIM are provisioned in first illuminator 302-1 and UDM 312. BTS 306 broadcasts a system information type 2 (SIB2) message with a list of tag IDs supported.

[0088] Step 2 (sub step 2.1): The registration request with TAG_ID#1 is requested by first illuminator 302-1 (UE#1) and the primary authentication is successful. NAS and AS Security modes are complete.

[0089] Step 3 (sub step 3.1, 3.2, 3.3 and 3.4): After the security mode commend (SMC) procedure is complete, the KAUSF key is used to derive the NAS and AS keys on both the network side and the UE side.

[0090] Step 4 (sub steps 4.1 and 4.2): Using the AS keys, the key KTAG is generated in both first illuminator 302-1 and BTS 306. FIG. 4B illustrates a procedure 420 for generating KTAG in accordance with an illustrative embodiment. For KTAG generation, in this illustrative embodiment, the key K8NB is used by the key derivation function (KDF) along with two other parameters TAG_ID and the length of TAG_ID to generate KTAG.

[0091] Continuing with procedure 400, in a data processing phase:

[0092] Step 5 (sub steps 5.1 through 5.8): the data (initially the data could be just TAG_ID#1) is encrypted using KTAG for encryption and integrity protection (5.1). The protected and secured data along with MAC-I is sent in initial request towards first tag 304 (5.2). FIG. 4C illustrates a procedure 430 for generating MAC-I (e.g., MAC-ITAG) in accordance with an illustrative embodiment. For the MAC-I generation, in this illustrative embodiment, the newly generated key KTAG along with first illuminator 302-1 data and the length of the data are used by the New Radio (NR) Integrity Algorithm (NIA) to generate MAC-ITAG. Encryption protection is provided by New Radio Encryption Algorithm (NEA) along with NIA.

[0093] First tag 304 forwards the initial request content along with TAG_ID towards BTS 306 (5.3). BTS checks if the TAG_ID is allowed and an authenticated one. If an allowed TAG_ID, then KTAG is used to decrypt the data and also verify if the received MAC-I is the same as the expected MAC-I. If MAC-I verification is successful, then BTS 306 generates the authorization token (5.4). The generated authorization token is sent to first tag 304 with result (ACK / NACK) (5.5). First tag 304 stores the token for future use for verification (5.6). Only the result (ACK7NACK) is sent to first illuminator 302-1 (5.7). After this, tag programming is allowed for first illuminator 302-1 (UE#1) (5.8), i.e., UE#1 is permitted to program first tag 304.

[0094] FIG. 5 illustrates a procedure 500 in a communication network environment with ambient loT functionalities according to yet another illustrative embodiment. As shown, similar to procedure 300 of FIG. 3, procedure 500 of FIG. 5 involves first illuminator 302-1, second illuminator 302-2, first tag 304, BTS 306 and AMF 308 that are part of SN 310, and UDM 312 that is part of HN 314.

[0095] The illustrative embodiment of FIG. 5 can be considered an asymmetric key-based procedure with a freshness parameter. More particularly, as all UEs (302-1 and 302-2) can use the same public key of HN 314 for the encryption of UE_ID, the freshness parameter, in this example, a newly generated random number RAND, is generated and used to encrypt the UE_ID#n and also to encrypt the Tag_ID#n. The plain text RAND is also sent from first illuminator 302-1 towards the BTS 306. First tag 304 adds its own plain text TAG_ID along with encrypted UE_ID#1 and encrypted TAG_ID#1 received from first illuminator 302-1 and sends this information to BTS 306, so that BTS 306 can verify the same.

[0096] It is to be appreciated that, in alternative embodiments, a parameter other than RAND can be used as the freshness parameter. By way of further example only, a Sequence Number or SQN can be used as the freshness parameter for encryption. Accordingly, SQN can be maintained and incremented in first and second illuminators 302-1 and 302-2 and in a network entity such as, e.g., BTS 306

[0097] Procedure 500 protects against a man-in-the-middle attack. In the pre -provisioned phase, steps 1 through 4 are the same as steps 1 through 4 of procedure 300, as is step 5. Then, in the authentication phase, step 6 (sub steps 6.1a through 6.10) is the same as step 6 (sub steps 6.1a through 6.10) of procedure 300 with the following exceptions as shown.

[0098] In sub step 6.2 of procedure 500, the plain text of the freshness parameter, e.g., plain text RAND, is also sent from first illuminator 302-1 to first tag 304. In sub step 6.3., as mentioned above, first tag 304 adds its own plain text TAG_ID along with encrypted UE_ID#1 and encrypted TAG_ID#1 received from first illuminator 302-1 and sends this information to BTS 306. In sub steps 6.4a and 6.4b, BTS 306 respectively verifies with UDM 312 that the UE_ID#1 and TAG_ID#1 are valid to enable generation of the authorization token to proceed. Sub steps 6.5 through 6.10 then proceed the same as sub steps 6.5 through 6.10 of procedure 300 as described above.

[0099] In an alternative embodiment, a symmetric key-based procedure with use of a freshness parameter is the same as procedure 500 of FIG. 5. But for TAG_ID protection, if the identifier TAG_ID#n is encrypted by a pre-shared key or derived key (similar to key generation described above for procedure 400 of FIG. 4B) and RAND in first illuminator 302-1, and sent to first tag 304, and first tag 304 also includes the TAG_ID#n (in plain text) itself in the message sent to BTS 306, BTS 306 will check, or cause to be checked, the decrypted TAG_ID#n and the TAG_ID#n itself for verification.

[0100] Advantageously, embodiments described and supported herein may be realized in various implementations and forms such as, but not limited to, methods, systems, articles or manufacture, computer program products, devices, etc. By way of further example only, embodiments may take the form of an apparatus comprising at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform one or more functions.

[0101] For example, from an activator device perspective, an apparatus may comprise at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: select a device from a plurality of devices which are ambient power-enabled and supportable by an access point to which the apparatus is connected; send an identifier of the apparatus and an identifier of the selected device, wherein at least the identifier of the apparatus is encrypted, to the selected device in a request to activate the selected device; and receive, via the selected device, an authorization token from the access point which is usable to authenticate the apparatus and the selected device with respect to subsequent data.

[0102] The apparatus, in some embodiments, may further be caused to one or more of: receive a list identifying the plurality of devices; store public keys associated with a home network, an access network of the access point, and a serving network associated with the access network; receive a public key identifier to enable the apparatus to identify one or more of the home network, the serving network, and the access network; use a freshness parameter to encrypt the identifier of the apparatus and the identifier of the selected device; and send the freshness parameter, in plain text, with the encrypted identifier of the apparatus and the encrypted identifier of the selected device in the request to activate the selected device. In another illustrative embodiment, from an activator device perspective, an apparatus may comprise at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: select a device from a plurality of devices which are ambient power-enabled and supportable by an access point to which the apparatus is connected; send a request to a home network for the apparatus to register the selected device; generate a key for the selected device from a set of one or more keys associated with the home network; use the key generated for the selected device to encrypt data; and send the encrypted data to the selected device in a request to activate the selected device.

[0103] Furthermore, for example, from an ambient power-enabled device perspective, an apparatus may comprise at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive, from an activator device, an identifier of the activator device and an identifier of the apparatus in a request to activate the apparatus, wherein at least the identifier of the activator device is encrypted, and wherein the apparatus is an ambient power-enabled device from a plurality of ambient power-enabled devices supportable by an access point to which the apparatus is connected; send the request to activate the apparatus to the access point; receive, from the access point, an authorization token which is usable to authenticate the apparatus and the activator device with respect to subsequent data; and send the authorization token to the activator device.

[0104] In some embodiments, the request received from the activator device may further comprise a freshness parameter, in plain text, used to encrypt the identifier of the activator device and the identifier of the apparatus. The apparatus may further be caused to add the identifier of the apparatus, in plain text, to the request, and send the request to the access point.

[0105] In another illustrative embodiment, from an ambient power-enabled device perspective, an apparatus may comprise at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive data from an activator device in a request to activate the apparatus, wherein the data is encrypted using a key generated for the apparatus from a set of one or more keys associated with a home network of the activator device, and wherein the apparatus is an ambient power-enabled device from a plurality of ambient power-enabled devices supportable by an access point to which the apparatus is connected; add an identifier for the apparatus to the request; send the request to the access point; receive, from the access point, an acknowledgement that the apparatus is verified; and send the acknowledgement to the activator device.

[0106] Still further, for example, from an access point perspective, an apparatus may comprise at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive, from an ambient power-enabled device selected from a plurality of ambient power-enabled devices supported by the apparatus, an identifier of an activator device and an identifier of the ambient power-enabled device in a request to activate the ambient power-enabled device, wherein at least the identifier of the activator device is encrypted; cause verification of the activator device and the ambient power- enabled device; generate an authorization token, in response to verification of the ambient power-enabled device and the activator device, which is usable to authenticate the ambient power-enabled device and the activator device with respect to subsequent data; and send the authorization token to the ambient power-enabled device and the activator device.

[0107] In some embodiments, the request received from the ambient power-enabled device further comprises a freshness parameter, in plain text, used to encrypt the identifier of the activator device and the identifier of the ambient power-enabled device.

[0108] In another illustrative embodiment, from an access point perspective, an apparatus may comprise at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to: receive, from an ambient power-enabled device supported by the apparatus, data from an activator device in a request to activate the ambient power-enabled device, wherein the data is encrypted using a key generated for the ambient power-enabled device from a set of one or more keys associated with a home network of the activator device, and wherein the request further comprises an identifier for the ambient power-enabled device; verify the ambient power-enabled device using the identifier for the ambient power-enabled device; decrypt the encrypted data using the key for the ambient power-enabled device; and send, to the ambient power-enabled device, an acknowledgement.

[0109] As used herein, it is to be understood that the term “communication network” in some embodiments can comprise two or more separate communication networks. Further, the particular processing operations and other system functionality described in conjunction with the diagrams described herein are presented by way of illustrative example only and should not be construed as limiting the scope of the disclosure in any way. Alternative embodiments can use other types of processing operations and messaging protocols. For example, the ordering of the steps may be varied in other embodiments, or certain steps may be performed at least in part concurrently with one another rather than serially. Also, one or more of the steps may be repeated periodically, or multiple instances of the methods can be performed in parallel with one another. It should again be emphasized that the various embodiments described herein are presented by way of illustrative example only and should not be construed as limiting the scope of the claims. For example, alternative embodiments can utilize different communication system configurations, user equipment configurations, base station configurations, provisioning and usage processes, messaging protocols and message formats than those described above in the context of the illustrative embodiments. These and numerous other alternative embodiments within the scope of the appended claims will be readily apparent to those skilled in the art.

Claims

ClaimsWhat is claimed is:

1. An apparatus comprising: means for selecting a device from a plurality of devices which are ambient power- enabled and supportable by an access point to which the apparatus is connected; means for sending an identifier of the apparatus and an identifier of the selected device, wherein at least the identifier of the apparatus is encrypted, to the selected device in a request to activate the selected device; and means for receiving, via the selected device, an authorization token from the access point which is usable to authenticate the apparatus and the selected device with respect to subsequent data.

2. The apparatus of claim 1, wherein the apparatus further comprises means for receiving a list identifying the plurality of devices.

3. The apparatus of claim 1, wherein the apparatus further comprises means for storing public keys associated with a home network, an access network of the access point, and a serving network associated with the access network.

4. The apparatus of claim 3, wherein the apparatus further comprises means for receiving a public key identifier to enable the apparatus to identify one or more of the home network, the serving network, and the access network.

5. The apparatus of claim 1, wherein the authorization token comprises a time period the expiry of which necessitates generation of a new authorization token.

6. The apparatus of claim 1, wherein the apparatus further comprises means for using a freshness parameter to encrypt the identifier of the apparatus and the identifier of the selected device.

7. The apparatus of claim 6, further wherein the means for sending further comprises sending the freshness parameter, in plain text, with the encrypted identifier of the apparatus and the encrypted identifier of the selected device in the request to activate the selected device.

8. A method comprising: selecting, at an activator device, an ambient power-enabled device from a plurality of ambient power-enabled devices supportable by an access point to which the activator device is connected; sending, from the activator device, an identifier of the activator device and an identifier of the selected ambient power-enabled device, wherein at least the identifier of the activator device is encrypted, to the selected ambient power-enabled device in a request to activate the selected ambient power-enabled device; and receiving, at the activator device via the selected ambient power-enabled device, an authorization token from the access point which is usable to authenticate the activator device and the selected ambient power-enabled device with respect to subsequent data.

9. An apparatus comprising: means for receiving, from an activator device, an identifier of the activator device and an identifier of the apparatus in a request to activate the apparatus, wherein at least the identifier of the activator device is encrypted, and wherein the apparatus is an ambient power-enabled device from a plurality of ambient power-enabled devices supportable by an access point to which the apparatus is connected; means for sending the request to activate the apparatus to the access point; means for receiving, from the access point, an authorization token which is usable to authenticate the apparatus and the activator device with respect to subsequent data; and means for sending the authorization token to the activator device.

10. The apparatus of claim 9, wherein the request received from the activator device further comprises a freshness parameter, in plain text, used to encrypt the identifier of the activator device and the identifier of the apparatus.

11. The apparatus of claim 10, wherein the apparatus further comprises: means for adding the identifier of the apparatus, in plain text, to the request; and means for sending the request to the access point.

12. A method comprising: receiving, from an activator device at an ambient power-enabled device selected from a plurality of ambient power-enabled devices supportable by an access point to which the ambient power-enabled device is connected, an identifier of the activator device and an identifier of the ambient power-enabled device, wherein at least the identifier of the activator device is encrypted, in a request to activate the ambient power-enabled device; sending, from the ambient power-enabled device to the access point, the request to activate the ambient power-enabled device; receiving, from the access point at the ambient power-enabled device, an authorization token which is usable to authenticate the ambient power-enabled device and the activator device with respect to subsequent data; and sending the authorization token from the ambient power-enabled device to the activator device.

13. An apparatus comprising: means for receiving, from an ambient power-enabled device selected from a plurality of ambient power-enabled devices supported by the apparatus, an identifier of an activator device and an identifier of the ambient power-enabled device in a request to activate the ambient power-enabled device, wherein at least the identifier of the activator device is encrypted; means for causing verification of the activator device and the ambient power-enabled device; means for generating an authorization token, in response to verification of the ambient power-enabled device and the activator device, which is usable to authenticate the ambient power-enabled device and the activator device with respect to subsequent data; and means for sending the authorization token to the ambient power-enabled device and the activator device.

14. The apparatus of claim 13, wherein the request received from the ambient power- enabled device further comprises a freshness parameter, in plain text, used to encrypt the identifier of the activator device and the identifier of the ambient power-enabled device.

15. A method comprising: receiving, at an access point from an ambient power-enabled device selected from a plurality of ambient power-enabled devices supported by the access point, an identifier of an activator device and an identifier of the ambient power-enabled device in a request to activate the ambient power-enabled device, wherein at least the identifier of the activator device is encrypted; causing, by the access point, verification of the activator device and the ambient power- enabled device; generating, by the access point, an authorization token, in response to verification of the ambient power-enabled device and the activator device, which is usable to authenticate the ambient power-enabled device and the activator device with respect to subsequent data; and sending, from the access point, the authorization token to the ambient power-enabled device and the activator device.

16. An apparatus comprising: means for selecting a device from a plurality of devices which are ambient power- enabled and supportable by an access point to which the apparatus is connected; means for sending a request to a home network for the apparatus to register the selected device; means for generating a key for the selected device from a set of one or more keys associated with the home network; means for using the key generated for the selected device to encrypt data; and means for sending the encrypted data to the selected device in a request to activate the selected device.

17. The apparatus of claim 16, wherein the means for sending at least the encrypted data to the selected device in the request to activate the selected device further comprises alsosending a message authentication code, generated using the key for the selected device, in the request.

18. The apparatus of claim 16, wherein the set of one or more keys associated with the home network comprise one or more access stratum keys.

19. The apparatus of claim 16, wherein the data is encrypted using a freshness parameter.

20. An apparatus comprising: means for receiving data from an activator device in a request to activate the apparatus, wherein the data is encrypted using a key generated for the apparatus from a set of one or more keys associated with a home network of the activator device, and wherein the apparatus is an ambient power-enabled device from a plurality of ambient power-enabled devices supportable by an access point to which the apparatus is connected; means for adding an identifier for the apparatus to the request; means for sending the request to the access point; means for receiving, from the access point, an acknowledgement that the apparatus is verified; and means for sending the acknowledgement to the activator device.

21. The apparatus of claim 20, further comprising means for receiving an authorization token from the access point.

22. The apparatus of claim 20, wherein the means for receiving the encrypted data from the activator device in the request further comprises also receiving a message authentication code, generated using the key for the apparatus, in the request.

23. An apparatus comprising: means for receiving, from an ambient power-enabled device supported by the apparatus, data from an activator device in a request to activate the ambient power-enabled device, wherein the data is encrypted using a key generated for the ambient power-enableddevice from a set of one or more keys associated with a home network of the activator device, and wherein the request further comprises an identifier for the ambient power-enabled device; means for verifying the ambient power-enabled device using the identifier for the ambient power-enabled device; means for decrypting the encrypted data using the key for the ambient power-enabled device; and means for sending, to the ambient power-enabled device, an acknowledgement.

24. The apparatus of claim 23, further comprising means for sending an authorization token to the ambient power-enabled device.

25. The apparatus of claim 23, wherein the means for receiving the encrypted data from the ambient power-enabled device in the request further comprises also receiving a message authentication code, generated using the key for the ambient power-enabled device, in the request.

Images