Method and apparatus for contextual network architecture and security

Abstract

Methods and apparatus for a network architecture and security with context are disclosed. In one aspect, a network may support a plurality of client devices. In such a network, a client device transmits a request to communicate with the network, establishes a security context, and receives one or more encrypted client device contexts from the network. The encrypted client device context enables a context for communicating with the client device to be reconstructed at the network, wherein the context includes network state information associated with the client device. The client device transmits a message (e.g., including an uplink data packet) including at least one encrypted client device context to the network. Because the network device is able to reconstruct a context about the client device based on the encrypted client device context, the network device can reduce the amount of context maintained at the network device, thereby supporting a larger number of client devices.

Description

[0001] This application is a divisional application of the Chinese invention patent application with application date of June 13, 2016, application number 201680040888.9 (international application number PCT / US2016 / 037279), and invention name “Method and device for network architecture and security with context”.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims priority to Provisional Application No. 62 / 191,457 filed in the U.S. Patent and Trademark Office on July 12, 2015, Provisional Application No. 62 / 320,506 filed in the U.S. Patent and Trademark Office on April 9, 2016, and Non-Provisional Application No. 15 / 160,198 filed in the U.S. Patent and Trademark Office on May 20, 2016, the entire contents of which are incorporated herein by reference.

[0004] introduction Technical Field

[0005] Aspects of the present disclosure relate generally to network communications, and more particularly, but not exclusively, to Internet of Things (IoT) network architectures. Background Art

[0006] The ability of electronic devices to collect, process, and exchange data continues to grow. Furthermore, a growing number of these electronic devices are provided with network connectivity. Such capabilities and features are enabling many electronic devices to evolve into Internet of Things (IoT) devices. As the number of these types of electronic devices continues to increase rapidly, the network may not have the resources to fully support these electronic devices.

[0007] For example, in an IoT environment, a network (e.g., an LTE network) may need to support a large number (e.g., billions) of IoT devices. Since the amount of resources allocated by the network for IoT purposes may be limited, the network may not be able to maintain all context about these types of devices. Furthermore, since IoT devices may be infrequently active and have limited resources, these devices may not be able to perform the complex signaling required for connectivity. Summary of the invention

[0008] A brief summary of some aspects of the present disclosure is given below to provide a basic understanding of these aspects. This summary is not an exhaustive overview of all conceived features of the present disclosure, and is neither intended to identify the key or decisive elements of all aspects of the present disclosure nor to attempt to define the scope of any or all aspects of the present disclosure. Its only purpose is to present various concepts of some aspects of the present disclosure in a simplified form as a prelude to a more detailed description given later.

[0009] In one aspect, a method for a network access node is provided. The network access node obtains a key for an encrypted client device context associated with a client device, receives a first data packet and an encrypted client device context from the client device, obtains a security context about the client device from the encrypted client device context using the key, decrypts and / or verifies the first data packet based on the security context, and forwards the first data packet to a service network when the decryption and verification are successful. In one aspect, the network access node obtains a security context by decrypting the encrypted client device context based on the key, and wherein the security context includes at least a user plane encryption key, a user plane integrity protection key, or a combination thereof. In one aspect, the first data packet is at least verified with the user plane integrity protection key or decrypted with the user plane encryption key. In one aspect, the security context includes a user plane encryption key and a user plane integrity protection key. In such aspects, the network access node may receive a second data packet from a server or a packet data network gateway, encrypt or integrity protect the second data packet using the user plane encryption key or the user plane integrity protection key, and forward the second data packet to the client device. The network access node may remove the at least one context. The network access node may receive a message including a resource establishment request and at least one of the one or more encrypted client device contexts from a client device. The network access node may obtain a network address for the client device in response to the message. The network access node may transmit the network address to the client device. In one aspect, the network access node may receive a resource release request message from the client device and may forward the resource release request message from the client device to a gateway, wherein the resource release request message enables the gateway to release one or more resources for the client device. In one aspect, the one or more resources include at least a network address or a bearer for the client device. In another aspect, when a timer expires before a transmission from the client device to the network or before a transmission from the network to the client device, the network access node may transmit a resource release request message to the gateway, wherein the resource release request message enables the gateway to release one or more resources for the client device. In one aspect, the one or more resources include at least a network address or a bearer for the client device. In one aspect, when a timer expires before a transmission from the client device to the network or before a transmission from the network to the client device, the network access node may release one or more resources for the client device. In one aspect, the one or more resources include at least a network address or a bearer for the client device. In another aspect, the network access node may receive a resource release request message from the client device. In such aspects, the network access node may release one or more resources for the client device in response to the resource release request message.In one aspect, the one or more resources include at least a network address or a bearer for the client device.

[0010] In one aspect, a network access node is provided. The network access node includes: a device for obtaining a key for an encrypted client device context associated with a client device, a device for receiving a first data packet and an encrypted client device context from the client device, a device for obtaining a security context about the client device from the encrypted client device context using the key, a device for decrypting and / or verifying the first data packet based on the security context, and a device for forwarding the first data packet to a service network when the decryption and verification are successful. In one aspect, the device for obtaining the security context is configured to decrypt the encrypted client device context based on the key, and the security context includes at least a user plane encryption key, a user plane integrity protection key, or a combination thereof. In one aspect, the first data packet is at least verified with the user plane integrity protection key or decrypted with the user plane encryption key. In one aspect, the security context includes a user plane encryption key and a user plane integrity protection key. In such aspects, the network access node may include: means for receiving a second data packet from a server or a packet data network gateway, means for encrypting or integrity protecting the second data packet using the user plane encryption key or the user plane integrity protection key, and means for forwarding the second data packet to a client device. In one aspect, the network access node includes means for removing the at least one context. In one aspect, the network access node includes means for receiving a message including a resource establishment request and at least one of the one or more encrypted client device contexts from a client device. In one aspect, the network access node includes means for obtaining a network address for the client device in response to the message. In one aspect, the network access node includes means for transmitting the network address to the client device. In one aspect, the network access node includes means for receiving a resource release request message from a client device and means for forwarding the resource release request message from the client device to a gateway, wherein the resource release request message enables the gateway to release one or more resources for the client device. In one aspect, the one or more resources include at least a network address or bearer for the client device. In another aspect, the network access node includes means for transmitting a resource release request message to a gateway when a timer expires prior to transmission from a client device to a network or prior to transmission from a network to a client device, wherein the resource release request message enables the gateway to release one or more resources for the client device. In one aspect, the one or more resources include at least a network address or a bearer for the client device. In one aspect, the network access node includes means for releasing one or more resources for the client device when a timer expires prior to transmission from a client device to a network or prior to transmission from a network to a client device.In one aspect, the one or more resources include at least a network address or a bearer for the client device. In another aspect, the network access node includes means for receiving a resource release request message from the client device. In such aspects, the network access node includes means for releasing one or more resources for the client device in response to the resource release request message. In one aspect, the one or more resources include at least a network address or a bearer for the client device.

[0011] In one aspect, a method for a client device is provided. The client device transmits a request to communicate with a network; establishes a security context for a connection with the network, wherein the security context includes at least an encryption algorithm, an encryption key, an integrity protection algorithm, an integrity protection key, or a combination thereof; and receives one or more encrypted client device contexts from the network in response to the request. The client device transmits a message including at least one of the one or more encrypted client device contexts to the network, wherein the one or more encrypted client device contexts enable a context for communicating with the client device to be reconstructed at the network, the context including network state information associated with the client device. In one aspect, the context is removed at the network. In one aspect, the client device determines at least one encrypted client device context to be used in the one or more encrypted client device contexts based on whether the message includes data or control information. In one aspect, the one or more encrypted client device contexts include a first context to be used for data-related communications with the client device and a second context to be used for control-related communications with the client device. In one aspect, the one or more encrypted client device contexts include at least one of the following: a security context, a quality of service of a bearer, a tunnel endpoint identifier, or a combination thereof. In one aspect, the request includes an indication that the client device is requesting one or more encrypted client device contexts. In one aspect, the request includes an indication of the service being requested by the client device. In one aspect, the one or more encrypted client device contexts include a user plane encrypted client device context and a control plane encrypted client device context. In such aspects, the message includes a first data packet with a user plane encrypted client device context or a control packet with a control plane encrypted client device context. In one aspect, the encryption key is a user plane encryption key and the integrity protection key is a user plane integrity protection key, wherein the user plane encryption key and the user plane integrity protection key are maintained at the client device, and wherein the first data packet is integrity protected with at least the user plane integrity protection key or encrypted with the user plane encryption key. In one aspect, transmitting a message including the first data packet does not establish a radio resource control connection with a network access node of the network. In one aspect, the client device enters an idle mode immediately after transmitting the message including the first data packet. In one aspect, the client device receives a second data packet, wherein receiving the second data packet does not establish a radio resource control connection with a network access node.In one aspect, the encryption key is a user plane encryption key and the integrity protection key is a user plane integrity protection key, wherein the user plane encryption key and the user plane integrity protection key are maintained at the client device, and wherein receiving the second data packet comprises at least one of: verifying the second data packet with the user plane integrity protection key, or decrypting the second data packet with the user plane encryption key. In one aspect, the control packet is a tracking area update. In one aspect, the client device receives a paging message from a network. In one aspect, the client device transmits an empty packet with a user plane encrypted client device context to the network. In one aspect, the encrypted client device context is received from the network as a result of successful authentication with the network. In one aspect, the successful authentication with the network does not establish an access layer security context. In one aspect, the client device stores the one or more encrypted client device contexts in a local storage. In one aspect, the one or more encrypted client device contexts are not decrypted at the client device, and the one or more encrypted client device contexts are only decrypted by a network device that generates the one or more encrypted client device contexts. In one aspect, the message further comprises a resource establishment request. In such aspects, the client device receives a network address for the client device in response to the message and transmits a plurality of data packets including the network address to the network. In one aspect, the client device transmits a resource release request message to the network, wherein the resource release request message enables the network to release one or more resources for the client device. In one aspect, after receiving the one or more encrypted client device contexts from the network, the contexts are removed at the network.

[0012] In one aspect, a client device is provided. The client device includes: a device for transmitting a request to communicate with a network; a device for establishing a security context for a connection with the network, wherein the security context includes at least an encryption algorithm, an encryption key, an integrity protection algorithm, an integrity protection key, or a combination thereof; a device for receiving one or more encrypted client device contexts from the network in response to the request; and a device for transmitting a message including at least one of the one or more encrypted client device contexts to the network, wherein the one or more encrypted client device contexts enable a context for communicating with the client device to be reconstructed at the network, the context including network state information associated with the client device. In one aspect, the context is removed at the network. In one aspect, the client device includes a device for determining at least one encrypted client device context to be used in the one or more encrypted client device contexts based on whether the message includes data or control information. In one aspect, the one or more encrypted client device contexts include a first context to be used for data-related communications with the client device and a second context to be used for control-related communications with the client device. In one aspect, the one or more encrypted client device contexts include at least one of the following: a security context, a quality of service of a bearer, a tunnel endpoint identifier, or a combination thereof. In one aspect, the request includes an indication that the client device is requesting one or more encrypted client device contexts. In one aspect, the request includes an indication of the service being requested by the client device. In one aspect, the one or more encrypted client device contexts include a user plane encrypted client device context and a control plane encrypted client device context. In such aspects, the message includes a first data packet with a user plane encrypted client device context or a control packet with a control plane encrypted client device context. In one aspect, the encryption key is a user plane encryption key and the integrity protection key is a user plane integrity protection key, wherein the user plane encryption key and the user plane integrity protection key are maintained at the client device, and wherein the first data packet is integrity protected with at least the user plane integrity protection key or encrypted with the user plane encryption key. In one aspect, transmitting a message including the first data packet does not establish a radio resource control connection with a network access node of the network. In one aspect, the client device includes a device for entering an idle mode immediately after transmitting a message including the first data packet. In one aspect, the client device includes a device for receiving a second data packet, wherein receiving the second data packet does not establish a radio resource control connection with a network access node.In one aspect, the encryption key is a user plane encryption key and the integrity protection key is a user plane integrity protection key, wherein the user plane encryption key and the user plane integrity protection key are maintained at the client device, and wherein receiving the second data packet comprises at least one of: verifying the second data packet with the user plane integrity protection key, or decrypting the second data packet with the user plane encryption key. In one aspect, the control packet is a tracking area update. In one aspect, the client device comprises means for receiving a paging message from a network. In one aspect, the client device comprises means for transmitting a null packet with a user plane encrypted client device context to the network. In one aspect, the encrypted client device context is received from the network as a result of a successful authentication with the network. In one aspect, the successful authentication with the network does not establish an access layer security context. In one aspect, the client device comprises means for storing the one or more encrypted client device contexts in a local storage. In one aspect, the one or more encrypted client device contexts are not decrypted at the client device, and wherein the one or more encrypted client device contexts are only decrypted by a network device that generates the one or more encrypted client device contexts. In one aspect, the message further comprises a resource establishment request. In such aspects, the client device includes means for receiving a network address for the client device in response to the message, and means for transmitting a plurality of data packets including the network address to the network. In one aspect, the client device includes means for transmitting a resource release request message to the network, wherein the resource release request message enables the network to release one or more resources for the client device. In one aspect, after receiving the one or more encrypted client device contexts from the network, the contexts are removed at the network.

[0013] In one aspect, a method for a client device is provided. The client device transmits a request to communicate with a network; establishes a security context for a connection with the network, wherein the security context includes at least an encryption algorithm, an encryption key, an integrity protection algorithm, an integrity protection key, or a combination thereof; and receives one or more encrypted client device contexts from the network in response to the request. The client device transmits a message including at least one of the one or more encrypted client device contexts to the network. In one aspect, the one or more encrypted client device contexts enable at least a portion of a context for communicating with the client device to be reconstructed at the network, the context including network state information associated with the client device. In one aspect, each of the one or more encrypted client device contexts is associated with one of a plurality of services provided by the network. In one aspect, the client device obtains a message, wherein the message is associated with a service provided by the network. In such aspects, the client device determines at least one encrypted client device context of the one or more encrypted client device contexts that is associated with a service, wherein the at least one encrypted client device context of the one or more encrypted client device contexts enables reconstruction of a portion of a client device context that supports the service. For example, the plurality of services may include mobile broadband services, ultra-reliable low latency communications (URLLC) services, high priority access services, delay-tolerant access services, and / or machine type communications (MTC) services. The client device obtains usage information associated with at least one of the one or more encrypted client device contexts. In one aspect, the usage information associated with at least one of the one or more encrypted client device contexts indicates whether the transmission of the message is reduced data transmission or burst data transmission. In one aspect, the usage information may include a value (e.g., an index number or other value) associated with a context (or a portion of a context) to be reconstructed by the network for a type of service provided by the network. In one aspect, the portion of the context is maintained at the network for a period of time determined based on whether the transmission of the message is reduced data transmission or burst data transmission. In one aspect, the message includes usage information. In one aspect, the one or more encrypted client device contexts include a first user-plane encrypted client device context that enables reconstruction of a first context about the client device at a first entity in the network, and a second user-plane encrypted client device context that enables reconstruction of a second context about the client device at a second entity in the network. In such aspects, the message includes at least a first user plane encrypted client device context and a second user plane encrypted client device context.

[0014] In one aspect, a client device is provided. The client device includes: a device for transmitting a request to communicate with a network; a device for establishing a security context for a connection with the network, wherein the security context includes at least an encryption algorithm, an encryption key, an integrity protection algorithm, an integrity protection key, or a combination thereof; and receiving one or more encrypted client device contexts from the network in response to the request. The client device further includes a device for transmitting a message including at least one of the one or more encrypted client device contexts to the network. In one aspect, the one or more encrypted client device contexts enable at least a portion of a context for communicating with the client device to be reconstructed at the network, the context including network state information associated with the client device. In one aspect, each of the one or more encrypted client device contexts is associated with one of a plurality of services provided by the network. In one aspect, the client device includes a device for obtaining a message, wherein the message is associated with a service provided by the network. In such aspects, the client device includes a device for determining at least one encrypted client device context associated with a service in the one or more encrypted client device contexts, wherein the at least one encrypted client device context in the one or more encrypted client device contexts enables the reconstruction of a portion of a client device context supporting the service. For example, the plurality of services may include mobile broadband services, ultra-reliable low latency communications (URLLC) services, high priority access services, delay-tolerant access services, and / or machine type communications (MTC) services. In one aspect, the client device includes a device for obtaining usage information associated with at least one of the one or more encrypted client device contexts. In one aspect, the usage information associated with at least one of the one or more encrypted client device contexts indicates whether the transmission of the message is a reduced data transmission or a burst data transmission. In one aspect, the usage information may include a value (e.g., an index number or other value) associated with a context (or a portion of a context) to be reconstructed by the network for a type of service provided by the network. In one aspect, the portion of the context is maintained at the network for a period of time determined based on whether the transmission of the message is a reduced data transmission or a burst data transmission. In one aspect, the message includes usage information. In one aspect, the one or more encrypted client device contexts include a first user-plane encrypted client device context that enables a first context about the client device to be reconstructed at a first entity in the network, and a second user-plane encrypted client device context that enables a second context about the client device to be reconstructed at a second entity in the network. In such aspects, the message includes at least a first user plane encrypted client device context and a second user plane encrypted client device context.

[0015] In one aspect, a method for a network device is provided. The network device receives a request from a client device to communicate with a network; establishes at least one context with the client device, the at least one context including network state information associated with a connection between the client device and the network, wherein the network state information includes at least an encryption algorithm, an encryption key, an integrity protection algorithm, an integrity protection key, or a combination thereof; generates one or more encrypted client device contexts, wherein the one or more encrypted client device contexts enable at least one context for communicating with the client device to be reconstructed at the network; and transmits the one or more encrypted client device contexts to the client device. In one aspect, the network device determines to generate the one or more encrypted client device contexts, wherein the determination is based on at least one of: encrypted client device context usage information indicated in the request, a subscription of the client device, a policy, or a combination thereof. In one aspect, the one or more encrypted client device contexts include a first context to be used for data-related communications and a second context to be used for control-related communications. In one aspect, the network device requests authentication information from a home subscriber server (HSS) / authentication authorization accounting (AAA) server, and performs mutual authentication with the client device. In one aspect, the network device receives a control packet and an encrypted client device context from a client device; verifies the encrypted client device context received from the client device; reconstructs at least one context from the encrypted client device context; processes the control packet using the at least one context, wherein the processing includes at least one of: verifying the control packet using the context, decrypting the control packet, or a combination thereof; storing a temporary identifier for a downlink packet for the client device; and forwarding a payload portion of the control packet to an application server or a packet data network gateway. In one aspect, the encryption key includes at least a control plane encryption key, a user plane encryption key, or a combination thereof, and the integrity protection key includes at least a user plane integrity protection key, a control plane integrity protection key, or a combination thereof. In one aspect, verifying the encrypted client device context includes: determining whether the encrypted client device context has expired, generating one or more new encrypted client device contexts when the previous encrypted client device context has expired, and transmitting the one or more new encrypted client device contexts to the client device when the previous encrypted client device context has expired. In one aspect, the network device receives a control packet from a second client device, requests a context about the second client device from the second network device, the request including a control plane encrypted client device context, receives the context about the second client device from the second network device, generates a new encrypted client device context, and transmits the new encrypted client device context to the second client device.In one aspect, verifying the encrypted client device context includes determining a key for verifying the encrypted client device context. In one aspect, the network device removes the at least one context, receives a message from the client device including a resource establishment request and at least one of the one or more encrypted client device contexts, obtains a network address for the client device in response to the message, and transmits the network address to the client device. In one aspect, the network device receives a resource release request message from the client device and transmits the resource release request message from the client device to a gateway, wherein the resource release request message enables the gateway to release one or more resources for the client device. In one aspect, when a timer expires prior to transmission from the client device to the network or prior to transmission from the network to the client device, the network device transmits a resource release request message to the gateway, wherein the resource release request message enables the gateway to release one or more resources for the client device.

[0016] In one aspect, a network device is provided. The network device includes: a device for receiving a request to communicate with a network from a client device; a device for establishing at least one context with the client device, the at least one context including network state information associated with a connection between the client device and the network, wherein the network state information includes at least an encryption algorithm, an encryption key, an integrity protection algorithm, an integrity protection key, or a combination thereof; a device for generating one or more encrypted client device contexts, wherein the one or more encrypted client device contexts enable at least one context for communicating with the client device to be reconstructed at the network; and a device for transmitting the one or more encrypted client device contexts to the client device. In one aspect, the network device includes a device for determining to generate the one or more encrypted client device contexts, wherein the determination is based on at least one of the following: encrypted client device context usage information indicated in the request, a subscription of the client device, a policy, or a combination thereof. In one aspect, the one or more encrypted client device contexts include a first context to be used for data-related communications and a second context to be used for control-related communications. In one aspect, the network device includes a device for requesting authentication information from a home subscriber server (HSS) / authentication authorization accounting (AAA) server, and a device for performing mutual authentication with the client device. In one aspect, the network device comprises: a device for receiving a control packet and an encrypted client device context from a client device; a device for verifying the encrypted client device context received from the client device; a device for reconstructing at least one context from the encrypted client device context; a device for processing the control packet using the at least one context, wherein the processing comprises at least one of: verifying the control packet using the context, decrypting the control packet, or a combination thereof; a device for storing a temporary identifier for a downlink packet for the client device; and a device for forwarding a payload portion of the control packet to an application server or a packet data network gateway. In one aspect, the encryption key comprises at least a control plane encryption key, a user plane encryption key, or a combination thereof, and the integrity protection key comprises at least a user plane integrity protection key, a control plane integrity protection key, or a combination thereof. In one aspect, the device for verifying the encrypted client device is configured to: determine whether the encrypted client device context has expired, generate one or more new encrypted client device contexts when the previous encrypted client device context has expired, and transmit the one or more new encrypted client device contexts to the client device when the previous encrypted client device context has expired.In one aspect, the network device comprises: means for receiving a control packet from a second client device; means for requesting a context about the second client device from the second network device, the request comprising a control plane encrypted client device context; means for receiving a context about the second client device from the second network device; means for generating a new encrypted client device context; and means for transmitting the new encrypted client device context to the second client device. In one aspect, the means for verifying the encrypted client device context is configured to determine a key for verifying the encrypted client device context. In one aspect, the network device comprises: means for removing the at least one context, means for receiving a message including a resource establishment request and at least one of the one or more encrypted client device contexts from the client device, means for obtaining a network address for the client device in response to the message, and means for transmitting the network address to the client device. In one aspect, the network device comprises: means for receiving a resource release request message from the client device, and means for transmitting the resource release request message from the client device to the gateway, wherein the resource release request message enables the gateway to release one or more resources for the client device. In one aspect, the network device includes means for transmitting a resource release request message to a gateway when a timer expires prior to a transmission from a client device to a network or prior to a transmission from a network to a client device, wherein the resource release request message enables the gateway to release one or more resources for the client device.

[0017] In one aspect, a method for a network device is provided. The network device receives a request to communicate with a network from a client device. The network device establishes at least one context with the client device, the at least one context including network state information associated with a connection between the client device and the network, wherein the network state information includes at least an encryption algorithm, an encryption key, an integrity protection algorithm, an integrity protection key, or a combination thereof. The network device may generate one or more encrypted client device contexts. In one aspect, the one or more encrypted client device contexts enable at least one context for communicating with the client device to be reconstructed at the network. The network device may transmit the one or more encrypted client device contexts to the client device. The network device removes the at least one context. The network device receives a message from the client device, the message including at least one of the one or more encrypted client device contexts and usage information associated with the one or more encrypted client device contexts. In one aspect, the usage information indicates whether the transmission of the message is a reduced data transmission or a burst data transmission. In one aspect, the network device may reconstruct at least a portion of the context based on at least one of the one or more encrypted client device contexts and the usage information. In one aspect, the network device maintains the at least a portion of the context for a first threshold time period when the usage information indicates reduced data transmission or maintains the at least a portion of the context for a second threshold time period when the usage information indicates bursty data transmission, the second threshold time period being greater than the first threshold time period.

[0018] In one aspect, a network device is provided. The network device includes a device for receiving a request to communicate with a network from a client device. The network device further includes a device for establishing at least one context with the client device, the at least one context including network state information associated with a connection between the client device and the network, wherein the network state information includes at least an encryption algorithm, an encryption key, an integrity protection algorithm, an integrity protection key, or a combination thereof. In one aspect, the network device includes a device for generating one or more encrypted client device contexts. In one aspect, the one or more encrypted client device contexts enable at least one context for communicating with the client device to be reconstructed at the network. In one aspect, the network device includes a device for transmitting the one or more encrypted client device contexts to the client device. In one aspect, the network device includes a device for removing the at least one context. In one aspect, the network device includes a device for receiving a message from the client device, the message including at least one of the one or more encrypted client device contexts and usage information associated with the one or more encrypted client device contexts. In one aspect, the usage information indicates whether the transmission of the message is a reduced data transmission or a burst data transmission. In one aspect, the network device includes means for reconstructing at least a portion of the context based on at least one of the one or more encrypted client device contexts and the usage information. In one aspect, the network device includes means for maintaining the at least a portion of the context for a first threshold time period when the usage information indicates reduced data transmission or maintaining the at least a portion of the context for a second threshold time period when the usage information indicates bursty data transmission, the second threshold time period being greater than the first threshold time period.

[0019] In one aspect, a method for a network device is provided. The network device obtains a key for an encrypted client device context associated with a client device, receives a first data packet and an encrypted client device context from the client device, obtains a security context about the client device from the encrypted client device context using the key, decrypts and verifies the first data packet based on the security context, and forwards the first data packet to a service network when the decryption and verification are successful. In one aspect, the network device obtains the security context by decrypting the encrypted client device context based on the key, and wherein the security context includes at least a user plane encryption key, a user plane integrity protection key, or a combination thereof. In one aspect, the first data packet is at least verified with the user plane integrity protection key or decrypted with the user plane encryption key. In one aspect, the security context includes a user plane encryption key and a user plane integrity protection key. In such aspects, the network device receives a second data packet from a server or a packet data network gateway, determines a network access node to which the second data packet is forwarded, adds a temporary identifier to the second data packet, the temporary identifier enabling the network access node to determine the client device, encrypts or integrity protects the second data packet using the user plane encryption key or the user plane integrity protection key, and forwards the second data packet to the client device.

[0020] In one aspect, a network device is provided. The network device includes: a device for obtaining a key for an encrypted client device context associated with a client device, a device for receiving a first data packet and an encrypted client device context from the client device, a device for obtaining a security context about the client device from the encrypted client device context using the key, a device for decrypting and verifying the first data packet based on the security context, and a device for forwarding the first data packet to a service network when the decryption and verification are successful. In one aspect, the device for obtaining the security context is configured to decrypt the encrypted client device context based on the key, and wherein the security context includes at least a user plane encryption key, a user plane integrity protection key, or a combination thereof. In one aspect, the first data packet is at least verified with the user plane integrity protection key or decrypted with the user plane encryption key. In one aspect, the security context includes a user plane encryption key and a user plane integrity protection key. In such aspects, the network device includes: means for receiving a second data packet from a server or a packet data network gateway, means for determining a network access node to which the second data packet is forwarded, means for adding a temporary identifier to the second data packet, the temporary identifier enabling the network access node to determine a client device, means for encrypting or integrity protecting the second data packet using the user plane encryption key or the user plane integrity protection key, and means for forwarding the second data packet to the client device.

[0021] In one aspect, a method for a network access node is provided. The network access node receives a first data packet with a request to communicate with a network from a client device, determines a network node to which the first data packet is intended, receives a second data packet from a network function implemented at the network node, and determines a client device to which the second data packet is to be forwarded. In one aspect, the network access node stores a temporary identifier for the client device, wherein the temporary identifier is a cellular cell radio network temporary identifier (C-RNTI), and wherein the temporary identifier is stored for a predetermined period of time. In one aspect, the network access node adds a temporary identifier to the first data packet. In one aspect, the network access node determines a network function to which the request is to be forwarded, wherein the determination is preconfigured at the network access node, and forwards the first data packet to the network function. In one aspect, the network access node removes the temporary identifier in the second data packet, and forwards the second data packet to the client device. In one aspect, the network access node determines the client device to which the second data packet is to be forwarded by identifying the client device from the temporary identifier in the second data packet.

[0022] In one aspect, a network access node is provided. The network access node comprises: means for receiving a first data packet with a request to communicate with a network from a client device, means for determining a network node to which the first data packet is intended, means for receiving a second data packet from a network function implemented at the network node, and means for determining a client device to which the second data packet is to be forwarded. In one aspect, the network access node comprises means for storing a temporary identifier for the client device, wherein the temporary identifier is a cellular cell radio network temporary identifier (C-RNTI), and wherein the temporary identifier is stored for a predetermined period of time. In one aspect, the network access node comprises means for adding the temporary identifier to the first data packet. In one aspect, the network access node comprises means for determining a network function to which the request is to be forwarded, wherein the determination is preconfigured at the network access node; and means for forwarding the first data packet to the network function. In one aspect, the network access node comprises means for removing the temporary identifier in the second data packet, and means for forwarding the second data packet to the client device. In an aspect, the means for determining a client device to which the second data packet is to be forwarded is configured to identify the client device from a temporary identifier in the second data packet.

[0023] These and other aspects of the present disclosure will be more fully understood after reading the following detailed description. After reading the description of the specific implementation of the present disclosure below in conjunction with the accompanying drawings, other aspects, features and implementations of the present disclosure will be obvious to those of ordinary skill in the art. Although the features of the present disclosure may be discussed below for certain implementations and accompanying drawings, all implementations of the present disclosure may include one or more of the advantageous features discussed herein. In other words, although one or more implementations may be discussed to have certain advantageous features, one or more of such features may also be used according to the various implementations of the present disclosure discussed herein. In a similar manner, although some implementations may be discussed below as devices, systems or methods, it should be understood that such implementations can be implemented in various devices, systems, and methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1 is a block diagram of an Internet of Things (IoT) network architecture in accordance with various aspects of the present disclosure.

[0025] Figure 2 is a diagram illustrating a key hierarchy for an IoT network architecture in accordance with various aspects of the present disclosure.

[0026] Figure 3 is a diagram illustrating a key hierarchy for encryption contexts in an IoT network architecture in accordance with various aspects of the present disclosure.

[0027] Figure 4 is a diagram illustrating various contexts (eg, network status information) regarding a client device in a network.

[0028] Figure 5 is a block diagram illustrating an initial attach procedure by a client device in an IoT network architecture in accordance with various aspects of the present disclosure.

[0029] Figure 6 is a signal flow diagram of an attach procedure performed by a client device in an IoT network architecture according to various aspects of the present disclosure.

[0030] Figure 7 is a block diagram illustrating data transmission initiated by a client device in an IoT network architecture in accordance with various aspects of the present disclosure.

[0031] Figure 8 is a signal flow diagram illustrating data transmission initiated by a client device in an IoT network architecture in accordance with various aspects of the present disclosure.

[0032] Fig. 9 is a signal flow diagram of client device terminated data transmission in an IoT network architecture according to various aspects of the present disclosure.

[0033] Fig.10 is a signal flow diagram of exemplary resource establishment and release in an IoT network architecture according to various aspects of the present disclosure.

[0034] Fig.11 is a signal flow diagram of an exemplary attach procedure performed by a client device in an IoT network architecture according to various aspects of the present disclosure.

[0035] Fig.12 is a signal flow diagram of exemplary resource establishment and release in an IoT network architecture according to various aspects of the present disclosure.

[0036] Fig.13 A control plane protocol stack for IoT data transmission according to various aspects of the present disclosure.

[0037] Fig.14 is a diagram illustrating a user plane protocol stack for IoT data transmission according to various aspects of the present disclosure.

[0038] Fig.15 is a diagram of a packet format in accordance with various aspects of the present disclosure.

[0039] Fig.16 is a signal flow diagram of a Tracking Area Update (TAU) procedure in an IoT network architecture according to various aspects of the present disclosure.

[0040] Fig.17 is an illustration of an apparatus configured to support operations related to communications in an IoT network architecture in accordance with various aspects of the present disclosure.

[0041] Figure 18 (including Fig.18A and 18B ) illustrates a method for communicating in an IoT network architecture according to various aspects of the present disclosure.

[0042] Fig.19 Methods for communicating with a network according to various aspects of the present disclosure are illustrated.

[0043] Fig. 20 Methods for communicating with a network according to various aspects of the present disclosure are illustrated.

[0044] Fig.21 is an illustration of an apparatus configured to support operations related to communications in an IoT network architecture in accordance with various aspects of the present disclosure.

[0045] Figure 22 (including Fig.22A and 22B ) illustrates a method for communicating in an IoT network architecture according to various aspects of the present disclosure.

[0046] Figure 23 (including Fig.23A and 23B ) illustrates a method for communicating in an IoT network architecture according to various aspects of the present disclosure.

[0047] Fig.24 Methods operable in an apparatus for communicating in an IoT network architecture according to various aspects of the present disclosure are illustrated.

[0048] Figure 25 (including Fig.25A and 25B ) illustrates a method for communicating in an IoT network architecture according to various aspects of the present disclosure.

[0049] Figure 26 (including Fig.26A and 26B ) illustrates a method for communicating in an IoT network architecture according to various aspects of the present disclosure.

[0050] Fig. 27 is an illustration of an apparatus configured to support operations related to communications in an IoT network architecture in accordance with various aspects of the present disclosure.

[0051] Fig.28 Methods for communicating in an IoT network architecture according to various aspects of the present disclosure are illustrated.

[0052] Figure 29 (including Fig.29A and 29B) illustrates a method for communicating in an IoT network architecture according to various aspects of the present disclosure. DETAILED DESCRIPTION

[0053] The detailed description set forth below in conjunction with the accompanying drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. This detailed description includes specific details to provide a thorough understanding of the various concepts. However, it will be apparent to those skilled in the art that these concepts may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form to avoid diluting such concepts.

[0054] As discussed above, in an IoT environment, a network (e.g., an LTE network) may need to support a large number (e.g., billions) of client devices (also referred to as Internet of Things (IoT) devices). A client device may be a cellular phone (e.g., a smartphone), a personal computer (e.g., a laptop), a gaming device, a user equipment (UE), or any other suitable device configured to communicate with a network (e.g., an LTE network). Each client device may have different requirements for data transmission and security. For example, client device traffic (also referred to as IoT traffic) may be delay-tolerant or may not require reliable transmission. In another example, client device traffic may not require access stratum (AS) security to reduce overhead.

[0055] Conventionally, when a client device transitions from idle mode to connected mode, signaling overhead may be incurred. For example, the client device may establish a connection with a network access node (e.g., an evolved Node B (eNB), a base station, or a network access point), and the network access node may generate a context about the client device. When the client device subsequently enters idle mode, the network access node may no longer maintain the client device context.

[0056] When a client device connects to a network, the context of the client device in the network may allow the device to perform less signaling to transmit data. For example, a registered client device may not be required to perform a full authentication procedure. However, to achieve such efficiency, the network may use a large amount of resources to maintain one or more contexts for each of a large number of connected client devices.

[0057] As used herein, the "context" of a client device may refer to network state information associated with the client device. For example, the context may refer to a client device security context, a context associated with an E-UTRAN radio access bearer (eRAB), and / or a context associated with a radio bearer and an S1 bearer.

[0058] Because the amount of resources (e.g., equipment implementing network functions) allocated by the network for IoT purposes may be limited, the network functions may not be able to maintain all context (e.g., network state information) for client devices that are not frequently active. For example, some client devices may wake up every 10 minutes or more, send traffic (e.g., transmit data) to the server, and immediately enter sleep mode. As another example, some client devices may send warnings to the server when unexpected events occur. In addition, some client devices may have limited resources (e.g., memory, processor, battery) and may not be suitable for handling complex protocol stacks and / or signaling procedures.

[0059] Long Term Evolution (LTE) mobility management and session management incur too much overhead to scale to potentially billions of client devices. In particular, context management and storage at network nodes may pose challenges.

[0060] For example, when a client device wakes up from idle mode and enters connected mode, the network access node establishes a new client device context via a service request to a mobility management entity (MME). When the client device is in an Evolved Packet System Mobility Management (EMM) registered state, the client device context may be maintained at the MME and the Serving Gateway (S-GW). Therefore, in order to support many client devices, the MME and S-GW need to be equipped with a large amount of storage to maintain context about client devices that may remain in idle mode most of the time.

[0061] Aspects disclosed herein include a network architecture for client devices, also referred to as Internet of Things (IoT) devices, that from a high-level perspective is used to achieve ultra-low client device power consumption, a large number of client devices per cell, a small spectrum, and / or an increased coverage area in a cell. Dedicated network functions are introduced to enable independent deployment and remove scalability / interworking requirements. Security is anchored at the IoT network function, also referred to as IoT function (IoTF).

[0062] According to various aspects, the architecture may allow data transmission to or from a client device without a security context at a network access node (e.g., eNB, base station, network access point). In order to avoid affecting the PDN connection / traffic of normal client devices, dedicated core network resources are allocated for small data transmission. The network may allocate dedicated physical (PHY) layer resources for access control in order to also limit small data traffic. The client device context is used for small data transmission to eliminate the semi-permanent context about the client device at the IoTF during the idle state. In order to achieve efficient data transmission of IoT devices, the disclosed network architecture may include an IoTF implemented at a network device. Such IoTF may include a control plane IoTF (IoTF-C) and a user plane IoTF (IoTF-U). In one aspect, IoTF-C may have similar functions to a mobility management entity. In one aspect, IoTF-U may be a mobility and security anchor for user plane data traffic. In one aspect, IoTF-U may have similar functions to a serving gateway (S-GW) and / or a network access node (e.g., an evolved B node (eNB), a base station, or a network access point).

[0063] In order to allow network functions (e.g., IoTF-C, IoTF-U) to optimize resource usage for client devices, various aspects of the disclosed IoT network architecture can implement a design protocol in which the client device context is carried in a packet (e.g., an IP packet) and the IoTF (e.g., an IoTF including IoTF-C and IoTF-U) opportunistically creates a client device context. This allows the network function to maintain almost no network state information about the client device and almost no signaling overhead. The client device may be, for example, a cellular phone (e.g., a smart phone), a personal computer (e.g., a laptop), a gaming device, a car, an appliance, or any other suitable device configured to communicate with a network. In some aspects, the client device may be referred to as a user equipment (UE) or an access terminal (AT). In some aspects, the client device cited herein may be a mobile device or a static device. It should be understood that the disclosed IoT network architecture and the functions included therein may be used to transmit small data with devices other than client devices. On the one hand, the client device may have a nominal mode in which it establishes a connection and transfers data, but also uses the procedures disclosed herein to transfer data using the client device context.

[0064] IoT Network Architecture

[0065] Figure 1 1 is a block diagram of an IoT network architecture 100 according to various aspects of the present disclosure. Figure 1As shown in FIG, IoT network architecture 100 includes client devices 102 (also referred to as IoT devices), network access nodes 104, network devices 105, service networks 110, and home subscriber servers (HSS) / authentication authorization accounting (AAA) servers 112. In one aspect, network access nodes 104 may be eNBs, base stations, or network access points.

[0066] In one aspect, the network device 105 may include one or more processing circuits and / or other appropriate hardware configured to implement the IoTF. In one aspect of the present disclosure, the IoTF may include a control plane IoT function (IoTF-C) 106 and a user plane IoT function (IoTF-U) 108. For example, the IoTF-C 106 may be implemented at a first network node 107, and the IoTF-U 108 may be implemented at a second network node 109. According to various aspects disclosed herein, the term "node" may represent a physical entity included in the network device 105, such as a processing circuit, a device, a server, or a network entity. Accordingly, for example, a network node may be referred to as a network node device.

[0067] In one aspect, IoTF-C 106 and IoTF-U 108 may be implemented at the same hardware platform (e.g., processing circuitry and other associated hardware components, such as memory). In such aspects, for example, IoTF-C 106 may be implemented at a first virtual machine (e.g., a first operating system) provided on a hardware platform (e.g., network device 105), and IoTF-U 108 may be implemented at a second virtual machine (e.g., a second operating system) provided on the hardware platform.

[0068] like Figure 1 As shown in , IoTF-C 106 is in communication with network access node 104 via first S1 connection 116, and IoTF-U 108 is in communication with network access node 104 via second S1 connection 114. In one aspect, service network 110 may include several entities, functions, gateways, and / or servers configured to provide various types of services. For example, service network 110 may include short message entity (SME) 118, machine type communication interworking function (MTC-IWF) 120, IoT server 122, and / or packet data network (PDN) gateway (P-GW) 124. It should be understood that Figure 1 The service network 110 disclosed in is used as an example, and in other aspects, the service network 110 may include Figure 1 The different types of entities, functions, and / or servers disclosed in .

[0069] In one aspect of the present disclosure, the IoTF implemented at the network device 105 may provide control plane and user plane functionality. In one aspect, the IoTF-C 106 handles control plane signaling for the client device (e.g., packets carrying control information, referred to herein as "control packets"). For example, the IoTF-C 106 may perform mobility and session management of the client device, perform authentication and key agreement (also referred to as AKA procedures) with the client device, and / or may create a security context for the client device. In one aspect, the IoTF-C 106 may derive a control plane (CP) key 126 for control plane traffic associated with the client device 102, a user plane (UP) key 128 for user plane traffic associated with the client device 102, and / or a context key 130 for generating an encrypted context for the client device 102. In one aspect, the IoTF-C 106 may provide the user plane key 128 and / or at least one context key 130 to the IoTF-U 108. Accordingly, in some aspects, the IoTF-U 108 may include user plane keys 128 and / or context keys 130 provided by the IoTF-C 106 .

[0070] In one aspect, the IoTF-U 108 can handle user plane traffic for client devices. For example, the IoTF-U 108 can derive encryption and integrity keys (e.g., using an authenticated encryption with associated data (AEAD) cipher using the UP key 128), create client device contexts on the fly, authenticate and decrypt uplink packets sent by client devices and forward these uplink packets to the PDN or P-GW (e.g., P-GW 124), encrypt and authenticate downlink packets for connected client devices and forward these downlink packets to the next hop network access node (e.g., eNB), and / or buffer downlink packets for idle client devices during paging. In one aspect, the IoTF-U 108 can be considered a mobility and security anchor for data traffic.

[0071] Example key hierarchy for IoT networks

[0072] Figure 2 is a diagram illustrating a key hierarchy 200 for an IoT network architecture (eg, IoT network architecture 100 ) in accordance with various aspects of the present disclosure. Figure 2 The key K IoT 202 may be a secret key permanently stored in a Universal Mobile Telecommunications System (UMTS) Subscriber Identity Module (USIM) of a client device (e.g., client device 102) and an Authentication Center (AuC) of the network. The integrity key (IK) and the cipher key (CK) (in Figure 2IK, CK 204) is a key pair derived in AuC and USIM during the AKA procedure. Figure 1 During the AKA procedure, the IoTF-C 106 may receive authentication vectors (AVs) from the HSS / AAA server 112, which contain keys from the Access Security Management Entity (ASME) (in Figure 2 The key K ASME 206). IoTF-C 106 can obtain the key K ASME 206 Derivation of the control plane key (K CP )208 and the user plane key (K UP )214. IoTF-C 106 may use the key K UP 214 is provided to IoTF-U 108. IoTF-C 106 can obtain the key K CP 208 Derivation of encryption key K IoT-CPenc 210 and integrity protection key K IoT-CPint 212. IoTF-U 108 can obtain the key K UP 214 Derivation of encryption key K IoT-UPenc 216 and integrity protection key K IoT-UPint 218.

[0073] Figure 3 is a diagram illustrating a key hierarchy 300 for encrypting context in an IoT network architecture (e.g., IoT network architecture 100) according to various aspects of the present disclosure. In one aspect of the present disclosure, with reference to Figure 1 , IoTF-C 106 may be based on the context key K of the client device CDC-IoTF 302 randomly generates a control plane client device context encryption key (K CDC-IoTF-C ) 304 and the user plane client device context encryption key (K CDC-IoTF-U )306.

[0074] Exemplary Network Status of Client Device

[0075] In a wireless communication system (eg, an LTE network), network states are defined for client devices for mobility management (eg, Evolved Packet System Mobility Management (EMM)). Such network states enable efficient communication between client devices and other entities in the network.

[0076] In one aspect of the present disclosure, a client device (e.g., Figure 1The client device 102 in the example may be in a deregistered state or a registered state. For example, when the client device is in a deregistered state, the context of the client device may be stored in the HSS. The network does not maintain valid location or routing information for the client device, and the client device is unreachable.

[0077] As another example, a client device may enter a REGISTERED state by a successful registration with a network. In one aspect of the present disclosure, a client device may perform such a registration by performing an Attach procedure with a network. In the REGISTERED state, the client device has at least one active PDN connection. The client device also has an Evolved Packet System (EPS) security context established. It should be noted that the DE-LOGGED state and REGISTERED state assume that the client device has credentials for the network (e.g., a subscription available in the HSS).

[0078] The wireless communication network (eg, LTE network) may further include a network state for Evolved Packet System Connection Management (ECM) defined for the client device. Accordingly, a client device (eg, Figure 1 The client device 102 in the RAN may be in one of two states (also referred to as sub-states of the registered state), such as an idle state or a connected state. In the idle state, there is no non-access stratum (NAS) signaling connection between the client device and other network entities. In addition, the client device may perform cell selection / reselection and public land mobile network (PLMN) selection, and there may be no context about the client device in the RAN (e.g., network access node). In addition, a client device in the idle state may not have S1-MME and S1-U connections.

[0079] In the connected state, the location of the client device is known in the MME with the accuracy of the serving access network identifier (e.g., eNB identifier (ID), base station ID, or network access point ID). The mobility of the client device is handled by the handover procedure. In the connected state, there is a signaling connection between the client device and the MME. The signaling connection may consist of two parts: a radio resource control (RRC) connection and an S1-MME connection.

[0080] Figure 4 4 is a diagram illustrating example network states of client devices maintained at various entities in network 400. Figure 4 As shown in FIG. 4 , network 400 includes client device 402, network access node 404, and evolved packet core (EPC) 406. Figure 4As further shown in FIG. 4 , EPC 406 includes a home subscriber server (HSS) 412, a mobility management entity (MME) 408, and a packet data network gateway (P-GW) / serving gateway (S-GW) 410. In one aspect of the present disclosure, network 400 may be a 4G network. In other aspects, network 400 may be a 3G network, an LTE network, a 5G network, or other appropriate network.

[0081] For example, refer to Figure 4 , the network access node 404 may maintain a context 414 (also referred to as network state information) about the client device 402 when the client device 402 is in a connected state. The MME 408 may maintain a context 416 about the client device 402 when the client device 402 is in a connected state, and a context 418 about the client device 402 when the client device 402 is in an idle state. The P-GW / S-GW 410 may maintain a context 426 about the client device 402 when the client device 402 is in a connected state, and a context 428 about the client device 402 when the client device 402 is in an idle state. The HSS 412 may maintain a context 420 about the client device 402 when the client device 402 is in a connected state, a context 422 about the client device 402 when the client device 402 is in an idle state, and a context 424 about the client device 402 when the client device 402 is in a deregistered state. In an aspect of the present disclosure, if the network 400 is implemented as a 3G network, the P-GW / S-GW 410 may not maintain a context about the client device 402 when the client device 402 is in an idle state.

[0082] In one aspect of the present disclosure, an encrypted client device context may be generated to enable network functions such as Figure 1 The IoTF-C 106 and IoTF-U 108 in the embodiment of the present invention enable opportunistic reconstruction of the context about the client device (also referred to as the client device context). For example, the encrypted client device context may enable the network entity to reconstruct the client device context without maintaining almost any network state information about the client device. Therefore, the encrypted client device context may enable the network entity to reconstruct the client device context without storing or caching any network state information.

[0083] It should be noted that with potentially billions of client devices that transmit traffic infrequently, it is undesirable for network functions (e.g., MME 408, P-GW / S-GW 410) to maintain context (including security context) about client devices. Moreover, encrypted client device context can eliminate signaling overhead at a network access node (e.g., eNB, base station, or network access point) during handover or during transition from idle mode to connected mode. Encrypted client device context can be used to significantly reduce or eliminate signaling overhead because communication with the MME / controller can be avoided.

[0084] User interface encrypted client device context

[0085] In one aspect of the present disclosure, a user plane (UP) encrypted client device context may be generated for a client device. Figure 1 , the user plane encrypted client device context may be used at the IoTF-U 108 for uplink (UL) data transmission. In one aspect of the present disclosure, the user plane encrypted client device context may include a bearer ID, an evolved packet system (EPS) bearer quality of service (QoS), an S5 tunnel endpoint identifier (TEID) for the user plane general packet radio service (GPRS) tunneling protocol (GTP-U), a P-GW Internet Protocol (IP) address (or equivalent information) to which the IoTF-U 108 forwards the UL data, a security context (e.g., a selected encryption algorithm and a user plane (UP) key 128), and any other parameters, values, settings, or features that may be required for the network to provide services to the client device. For example, the UP key 128 may be a key K UP 214, from key K UP 214 can derive the key K IoT-UPenc 216 and key K IoT-UPint 218. This can be accomplished by using a secret key of IoTF-U 108 (such as Figure 3 The key K shown in CDC-IoTF-U 306) encrypts the user plane context about the client device to generate a user plane encrypted client device context. In one aspect of the present disclosure, the secret key of IoTF-U 108 (such as the key K CDC-IoTF-U 306) may be provisioned by IoTF-C 106. The user plane encrypted client device context may be provided by a user having the secret key (e.g., key K CDC-IoTF-U 306). Accordingly, the user plane encrypted client device context may be decrypted by the IoTF that generated the user plane encrypted client device context.

[0086] Control plane encrypted client device context

[0087] A control plane (CP) encrypted client device context may be generated by encrypting a control plane client device context for a control message (e.g., a control packet or a message including a control packet). In one aspect, the control plane encrypted client device context may include a client device identifier, a client device security context (e.g., a control plane key, such as a key K IoT (K ASME Equivalent), key K IoT-CPenc 210. Key K IoT-CPint 212), client device security capabilities (e.g., Evolved Packet System Encryption Algorithm (EEA), Evolved Packet System Integrity Algorithm (EIA)), and / or next hop (S5 / S8) configuration information. For example, the next hop configuration information may include an IoT server address, a P-GW address, and / or a TEID. For example, referring to Figure 1 , the control plane client device context for control messages may be used by IoTF-C 106 with a secret key (such as Figure 3 The key K shown in CDC-IoTF-C 304). The control plane encrypted client device context may be encrypted by a user having the secret key (eg, key K CDC-IoTF-C 304). Accordingly, the control plane encrypted client device context may be decrypted by the IoTF that generated the control plane encrypted client device context.

[0088] Initial Attachment Procedure

[0089] Figure 5 is a block diagram illustrating an initial attach procedure by a client device in an IoT network architecture 500 in accordance with various aspects of the present disclosure. In some aspects, an attach procedure as described herein is also referred to as a network attach procedure or a registration procedure.

[0090] like Figure 5 As shown in the figure, the IoT network architecture 500 includes a client device 502 (also referred to as an IoT device), a network access node 504 (e.g., an eNB, a base station, a network access point), a network device 505, a service network 510, and a home subscriber server (HSS) / authentication authorization accounting (AAA) server 512.

[0091] In one aspect, the network device 505 may include one or more processing circuits and / or other appropriate hardware configured to implement the IoTF. For example, the IoTF may include a control plane IoT function (IoTF-C) 506 and a user plane IoT function (IoTF-U) 508. In such aspects, the IoTF-C 506 may be implemented at the network node 507, and the IoTF-U 508 may be implemented at the network node 509. In one aspect, the IoTF-C 506 and the IoTF-U 508 may be implemented at the same hardware platform so that the IoTF-C 506 and the IoTF-U 508 each represent an independent node in the architecture 500. In such aspects, for example, the IoTF-C 506 may be implemented at a first virtual machine (e.g., a first operating system) provided on a hardware platform (e.g., the network device 505), and the IoTF-U 508 may be implemented at a second virtual machine (e.g., a second operating system) provided on the hardware platform.

[0092] like Figure 5 As shown in , IoTF-C 506 is in communication with network access node 504 via a first S1 connection 516, and IoTF-U 508 is in communication with network access node 504 via a second S1 connection 514. In one aspect of the present disclosure, service network 510 may include several entities, functions, gateways, and / or servers configured to provide various types of services. For example, service network 510 may include a short message entity (SME) 518, a machine type communication interworking function (MTC-IWF) 520, an IoT server 522, and / or a packet data network (PDN) gateway (P-GW) 524. It should be understood that Figure 5 The service network 510 disclosed in is used as an example, and in other aspects, the service network 510 may include Figure 5 The different types of entities, functions, and / or servers disclosed in .

[0093] like Figure 5 As shown in , the client device 502 may transmit an attachment request 532 to the network, which may be received by the network access node 504. In one aspect of the present disclosure, the attachment request 532 may provide one or more indications. For example, the attachment request 532 may indicate: 1) the client device 502 will attach as an IoT device, 2) the attachment request 532 is a request to perform a small amount (reduced) data transmission, and / or 3) the client device 502 is operating in a low power consumption mode. The attachment request 532 may further indicate the home domain (e.g., HPLMN ID or fully qualified domain name (FQDN)) from which authentication information should be retrieved. The network access node 504 may forward the request to the IoTF-C 506 to which it belongs.

[0094] IoTF-C 506 can determine the address of HSS / AAA server 512 from the home domain information provided by client device 502, and can transmit a request 534 to HSS / AAA server 512 for authentication information about client device 502. IoTF-C 506 can receive authentication information 535 from HSS / AAA server 512.

[0095] The IoTF-C 506 can perform mutual authentication (e.g., AKA procedure) with the client device 502. During the AKA procedure, the IoTF-C 506 can receive an AV from the HSS / AAA server 512 via authentication information 535. For example, the AV can include a key from an access security management entity (ASME) (in Figure 2 The key K ASME 206). For example, IoTF-C 506 may transmit the key K via signal 536. ASME 206 is provided to the client device 502. When the AKA procedure is completed, IoTF-C 506 and the client device 502 can obtain the key K ASME 206 or from key K IoT 202 derive CP key 526 (such as key K CP 208. Key K IoT-CPenc 210 and / or key K IoT-CPint 212), and the UP key 528 (such as the key K UP 214. Key K IoT-UPenc 216 and / or key K IoT-UPint 218).

[0096] In some aspects, IoTF-C 506 may send the key K to UP 214 and user plane encryption key and integrity protection key (such as key K IoT-UPenc 216 and key K IoT-UPint 218) is transmitted to IoTF-U 508.

[0097] In one aspect of the present disclosure, IoTF-C 506 may generate one or more encrypted client device contexts about client device 502 by encrypting the client device context using context key 530. IoTF-C 506 may then transmit the one or more encrypted client device contexts to client device 502. For example, IoTF-C 506 may generate an encrypted client device context for a control plane and an encrypted client device context for a user plane. In such examples, context key 530 may include a first context key (e.g., key K ) for generating an encrypted client device context for the control plane. CDC-IoTF-C304) and a second context key (eg, key K) for generating an encrypted client device context of the user plane. CDC-IoTF-U In one aspect of the disclosure, IoTF-C 506 may provide one or more context keys 530 to IoTF-U 508. For example, IoTF-C 506 may provide a second context key (e.g., key K ) used to generate an encrypted client device context for the user plane via message 538. CDC-IoTF-U 306) to the IoTF-U 508. Accordingly, in some aspects, the IoTF-U 508 may include the context key 531 provided by the IoTF-C 506.

[0098] Figure 6 6 is a signal flow diagram 600 of an exemplary attach procedure performed by a client device in an IoT network architecture (eg, IoT network architecture 100, 500) according to various aspects of the present disclosure. Figure 6 As shown in , the signal flow diagram 600 includes a client device 602 (also referred to as an IoT device), a network access node 604 (e.g., an eNB, a base station, or a network access point), an IoTF-C 606 implemented at a network node 605, an IoTF-U 608 implemented at a network node 607, a service network 609, and a home subscriber server (HSS) 610.

[0099] like Figure 6 As shown in , the client device 602 may transmit a request 612 (e.g., an RRC connection request) to the network access node 604 to communicate with the network. The client device 602 may receive an RRC connection setup message 614, which may include a signaling radio bearer (SRB) configuration (e.g., an SRB1 configuration for transmitting NAS messages on a dedicated control channel (DCCH). The client device 602 may transmit an RRC connection setup complete message 616 to the network access node 604. For example, the RRC connection setup complete message 616 may indicate an attach request.

[0100] The network access node 604 may transmit an initial client device message 618 to the IoTF-C 606. The IoTF-C 606 may determine the address of the HSS server 610 from the home domain information provided by the client device 602, and may communicate with the HSS 610 (621). For example, the IoTF-C 606 may transmit a request for authentication information about the client device 602 to the HSS server 610, and may receive authentication information from the HSS server 610.

[0101] like Figure 6As shown in FIG. 6 , IoTF-C 606 can perform mutual authentication (e.g., AKA procedure 620) with client device 602. When AKA procedure 620 is completed, IoTF-C 606 and client device 602 can obtain a key K from the client device 602. ASME 206 or from key K IoT 202 derive a control plane key, such as a key K IoT-CPenc 210 and / or key K IoT-CPint 212. IoTF-C 606 and client device 602 may further obtain the key K ASME 206 or from key K IoT 202 derive a user plane key, such as a key K IoT-UPenc 216 and / or key K IoT-UPint 218.

[0102] In one aspect of the present disclosure, IoTF-C 606 may use a key K CDC-IoTF-C 304 encrypts the control plane context of the client device 602 to generate a control plane encrypted client device context, and / or may be performed by using a key K CDC-IoTF-U 306 encrypts the user plane context of the client device 602 to generate a user plane encrypted client device context. The IoTF-C 606 may transmit one or more keys (e.g., user plane keys, such as a key K IoT-UPenc 216 and / or key K IoT-UPint 218, and / or key K CDC-IoTF-U 306) passed to IoTF-U 608.

[0103] The IoTF-C 606 may transmit an initial context setup request message 623 with an encrypted client device context (e.g., a control plane encrypted client device context and / or a user plane encrypted client device context) to the client device 602. Thus, the encrypted client device context may include a client device context associated with the IoTF-C 606 and / or the IoTF-U 608, wherein the client device context may be used for uplink data transmission by the client device 602.

[0104] In one aspect of the present disclosure, the encryption key is known only to the IoTF (e.g., the client device security context may be exclusively retrieved by the IoTF-C 606 and / or IoTF-U 608). Accordingly, in such aspects, the encryption key may be K CDC- IoTF-U 306, which is unknown to network entities external to the IoTF, such as network access node 604 or client device 602. In one aspect of the disclosure, each encrypted client device context corresponds to one data radio bearer (DRB).

[0105] The network access node 604 may transmit an RRC connection reconfiguration message 626 to the client device 602. In an aspect of the disclosure, the RRC connection reconfiguration message 626 may include an encrypted client device context. The client device 602 may transmit an RRC connection reconfiguration complete message 628 to the network access node 604.

[0106] The client device 602 may transmit a first message 630 including a data packet (eg, a UL data packet) to the network access node 604. The network access node 604 may forward the data packet to the service network 609 via a second message 632. For example, and as Figure 6 As shown in , the second message 632 can be forwarded by the network access node 604 and the IoTF-U 608 to the service network 609.

[0107] The service network 609 may transmit a third message 634 including a data packet (eg, a DL data packet) to the client device 602. For example, and as Figure 6 As shown in , the third message 634 can be forwarded by IoTF-U 608 and network access node 604 to client device 602. Client device 602 can then transition (636) to idle mode. Network access node 604, IoTF-C 606, and IoTF-U 608 can proceed to remove (638) the client device context.

[0108] IoT Uplink (UL) Data Transmission

[0109] Figure 7 7 is a block diagram illustrating data transmission initiated by a client device in an IoT network architecture 700 according to various aspects of the present disclosure. Figure 7 As shown in the figure, the IoT network architecture 700 includes a client device 702 (also referred to as an IoT device), a network access node 704 (e.g., an eNB, a base station, a network access point), a network device 705, a service network 710, and a home subscriber server (HSS) / authentication authorization accounting (AAA) server 712.

[0110] In one aspect, the network device 705 may include one or more processing circuits and / or other appropriate hardware configured to implement the IoTF. For example, the IoTF may include a control plane IoT function (IoTF-C) 706 and a user plane IoT function (IoTF-U) 708. In such aspects, the IoTF-C 706 may be implemented at the network node 707, and the IoTF-U 708 may be implemented at the network node 709. In one aspect, the IoTF-C 706 and the IoTF-U 708 may be implemented at the same hardware platform so that the IoTF-C 706 and the IoTF-U 708 each represent an independent node in the architecture 700. In such aspects, for example, the IoTF-C 706 may be implemented at a first virtual machine (e.g., a first operating system) provided on a hardware platform (e.g., the network device 705), and the IoTF-U 708 may be implemented at a second virtual machine (e.g., a second operating system) provided on the hardware platform.

[0111] In one aspect of the present disclosure, the service network 710 may include several entities, functions, gateways, and / or servers configured to provide various types of services. For example, the service network 710 may include a short message entity (SME) 718, a machine type communication interworking function (MTC-IWF) 720, an IoT server 722, and / or a packet data network (PDN) gateway (P-GW) 724. It should be understood that Figure 7 The service network 710 disclosed in is used as an example, and in other aspects, the service network 710 may include Figure 7 The different types of entities, functions, and / or servers disclosed in .

[0112] exist Figure 7 In one aspect, IoTF-C 706 may have generated an encrypted client device context for the control plane and an encrypted client device context for the user plane. In such aspects, context keys 730 may include a first context key (e.g., key K) for generating an encrypted client device context for the control plane. CDC-IoTF-C 304) and a second context key (eg, key K) for generating an encrypted client device context of the user plane. CDC-IoTF-U 306). For example, IoTF-C 706 may have used the second context key (eg, key K) used to generate the encrypted client device context of the user plane. CDC-IoTF-U 306) is transmitted to IoTF-U 708. Accordingly, in such examples, IoTF-U 708 may include context key 731 provided by IoTF-C 706, such as Figure 7 As shown in Figure 7In this aspect, the client device 702 has derived the CP key 726 and the UP key 728 in the manner previously discussed.

[0113] like Figure 7 As shown in , the client device 702 may transmit a first message 732 including a data packet and an encrypted client device context provided by the IoTF-C 706 to the network access node 704. The network access node 704 may determine the address of the IoTF-U 708 from the IoTF-U identifier in the data packet and may forward the data packet to the IoTF-U 708 via a second message 734. In an aspect, the network access node 704 may forward the packet to the next hop node (e.g., IoTF-U 708) indicated by the client device 702 without verifying the data packet. The IoTF-U 708 may verify the encrypted client device context and may use the context key 731 (e.g., the key K for generating the encrypted client device context of the user plane) to generate the encrypted client device context of the user plane. CDC-IoTF-U The IoTF-U 708 may then decrypt the encrypted client device context using the encryption key and the integrity key (e.g., UP key 728) to verify the data packet.

[0114] Figure 8 8 is a signal flow diagram 800 illustrating an exemplary data transmission initiated by a client device in an IoT network architecture (e.g., IoT network architecture 700) according to various aspects of the present disclosure. Figure 8 As shown in FIG. 8 , a signal flow diagram 800 includes a client device 802 (also referred to as an IoT device), a network access node 804 (e.g., an eNB, a base station, or a network access point), an IoTF-U 806 implemented at a network node 805, and a serving network 808. The client device 802 may transmit a data transfer request message 810 including an encrypted client device context and a data packet (e.g., a UL data packet) to the network access node 804. In an aspect, the data transfer request message 810 may be sent by the client device 802 without establishing an RRC connection with the network access node 804.

[0115] Upon receiving the data transmission request message 810, the network access node 804 may assign (812) a temporary identifier (TID) to the client device 802 for potential downlink (DL) traffic. For example, the TID may be a cellular cell radio network temporary identifier (C-RNTI). The network access node 804 may determine the IoTF-U identifier included in the header of the data packet. An example format of a data packet including such a header is referred to herein. Fig.12 Let's discuss.

[0116] The network access node 804 may determine the IP address of the IoTF-U 806 and may forward the data packet to the IoTF-U 806 via the first message 814. For example, as part of an operations and maintenance (OAM) procedure, the network access node 804 may be configured with a set of IoTF-U identifiers and corresponding IP addresses, or alternatively, the network access node 804 may determine the IP address of the IoTF-U 806 using a domain name system (DNS) query based on the IoTF-UID. In one aspect of the present disclosure, and as Figure 8 As shown in , the network access node 804 may include the TID and the encrypted client device context in a first message 814 along with the data packet. In one aspect of the present disclosure, the TID is stored at the network access node 804 for a predefined time interval. In such aspects, the network access node 804 may transmit the TID expiration time to the IoTF-U 806 along with the TID in the first message 814. The IoTF-U 806 may decrypt the encrypted client device context and may reconstruct (816) the client device context (e.g., S5 bearer). The IoTF-U 806 may forward the data packet to the service network 808 (e.g., a P-GW in the service network 808 or other entity in the service network 808) via a second message 818.

[0117] In response to uplink data (e.g., UL data packets in the second message 818), the IoTF-U 806 may receive data packets (e.g., DL data packets) from the service network 808 (e.g., a P-GW in the service network 808 or a corresponding entity in the service network 808) via a third message 820. The IoTF-U 806 may transmit the received data packets along with the TID to the network access node 804 in a fourth message 822. The network access node 804 may use the TID to identify the client device 802 and may transmit the data packets to the client device 802 in a fifth message 824. The client device 802 may transition (826) to an idle mode based on a preconfigured timer. The network access node 804 and the IoTF-U 806 may proceed to remove (828) the client device context created on the fly from the encrypted client device context.

[0118] Client equipment terminated data transmission (paging)

[0119] Fig. 9 FIG. 9 is a signal flow diagram 900 of an exemplary client device terminated data transmission in an IoT network architecture (e.g., IoT network architecture 100) according to various aspects of the present disclosure. Fig. 9As shown in FIG. 9 , the signal flow graph 900 includes a client device 902 (also referred to as an IoT device), a network access node 904 (e.g., an eNB, a base station, a network access point), an IoTF-C 906 implemented at a network node 905 and an IoTF-U 908 implemented at a network node 907, a P-GW 910, and an IoT server 912. The IoT server 912 may transmit a downlink (DL) message 914 to the P-GW 910, which includes a DL data packet and a global IoTF identifier (GIOTFI). The P-GW 910 may locate the IoTF-U 908 based on the GIOTFI and may forward the DL data packet to the IoTF-U 908 in a forwarding message 916. The IoTF-U 908 may transmit a DL data notification message 918 to the IoTF-C 906. In an aspect of the present disclosure, if the DL data packet is small enough to be carried in a paging message, the DL data notification message 918 may include the DL data packet. The IoTF-C 906 may transmit a paging message 920 to one or more network access nodes (e.g., network access node 9014). The network access node 904 may then page the client device 902 by transmitting a paging message 922.

[0120] The client device 902 may transmit an RRC connection request message 924 including an UL data packet to the IoTF-U 908. In one aspect of the present disclosure, the UL data packet transmitted by the client device 902 may be empty. The network access node 904 may assign (926) a temporary identifier (TID) to the client device 902 for potential downlink (DL) traffic. For example, the TID may be a cellular cell radio network temporary identifier (C-RNTI). The network access node 904 may then forward the UL data packet along with the TID and the encrypted client device context to the IoTF-U 908 in a forwarding message 928. The IoTF-U 908 may store (930) the TID and the ID of the network access node 904.

[0121] The IoTF-U 908 may transmit a client device response notification message 932 to the IoTF-C 906. In one aspect of the present disclosure, if the IoTF-U 908 cannot include the DL data packet in the DL data notification message 918, the IoTF-U 908 may transmit a message 934 including the DL data packet and the TID of the client device 902 to the client device 902. The network access node 904 may forward the DL data packet to the client device 902 in a forward message 936. The client device 902 may then transition (938) to an idle mode. The network access node 904 and the IoTF-C 906 may remove (940) the client device context.

[0122] Resource creation and release

[0123] Fig.10 1 is a signal flow diagram 1000 of exemplary resource establishment and release in an IoT network architecture (e.g., IoT network architecture 100) according to various aspects of the present disclosure. Fig.10 As shown in , the signal flow graph 1000 includes a client device 1002 (also referred to as an IoT device), an IoTF-C 1004 implemented at a network node 1006, an IoTF-U 1008 implemented at a network node 1010, and a P-GW 1012.

[0124] like Fig.10 As shown in FIG. 1 , IoTF-C 1004, IoTF-U 1008, and / or P-GW 1012 may remove 1014 the context regarding client device 1002. In one aspect, IoTF-C 1004 and / or IoTF-U 1008 may remove the context regarding client device 1002 after IoTF-C 1006 has provided encrypted client device context to client device 1002. Fig.10 As shown in , the client device 1002 may transmit a resource setup request message 1016 to the IoTF-C 1004. For example, when the client device 1002 is to transmit an infrequent burst data transmission to the network (e.g., to the P-GW 1012), the client device 1002 may transmit a resource setup request message 1016. For example, the burst data transmission may include a sequence of protocol data units (PDUs) (such as IP packets). In one aspect, the resource setup request message 1016 may include an encrypted client device context (e.g., a client device context of the control plane).

[0125] During the resource establishment operation 1018, the IoTF-C 1004 can verify the encrypted client device context from the client device 1002, and upon successful verification, the IoTF-C 1004 can decrypt the encrypted client device context. The IoTF-C 1004 can then reconstruct the context about the client device 1002. In one aspect, the IoTF-U 1008 and the P-GW 1012 can also reconstruct the context about the client device 1002. In one aspect, the IoTF-C 1004 can obtain a network address (e.g., an IP address) for the client device 1002 and can provide the network address to the client device 1002 during the resource establishment operation 1018. Fig.10As shown in FIG. 1 , the client device 1002 may transmit uplink (UL) data 1020 to the P-GW 1012 via the IoTF-U 1008. In one aspect, the client device 1002 may transmit the UL data 1020 in one or more PDUs including a network address of the client device 1002.

[0126] In one aspect, the client device 1002 may determine that no further data transmission will be made to the network. In such aspects, the client device 1002 may optionally transmit a resource release request message 1 1022 to the IoTF-C 1004. The client device 1002 may then enter an idle mode 1024. The IoTF-C 1004 may transmit the resource release request message 1 1022 to the P-GW 1012. In one aspect, the resource release request message 1 1022 enables the P-GW 1012 to release one or more resources for the client device 1002. For example, the one or more resources may include a network address assigned to the client device 1002 (e.g., to allow the network address to be reassigned), a bearer for the client device 1002, and / or other resources for the client device 1002. The IoTF-C 1004 and the IoTF-U 1008 may then remove (1030) the context regarding the client device 1002. On the other hand, after receiving the UL data 1020 at the IoTF-U 1008, the IoTF-C 1004 and / or the IoTF-U 1008 may initiate a timer 1026. If the timer 1026 expires before any new UL data (e.g., additional UL data after the UL data 1020) is received from the client device 1002 and / or before any downlink (DL) data is transmitted to the client device 1002, the IoTF-C 1004 and / or the IoTF-U 1008 may determine that the client device 1002 is in idle mode 1024. In such a scenario, the IoTF-C 1004 may transmit a resource release request message 2 1028 to the P-GW 1012. In one aspect, the resource release request message 2 1028 enables the P-GW 1012 to release one or more resources for the client device 1002. For example, the one or more resources may include a network address assigned to the client device 1002 (e.g., to allow for reallocation of the network address), a bearer for the client device 1002, and / or other resources for the client device 1002. The IoTF-C 1004 and the IoTF-U 1008 may then remove 1030 the context regarding the client device 1002. In one aspect, the timer 1026 may be reset by the IoTF-C 1004 and / or the IoTF-U 1008 when a new UL data transmission (e.g., additional UL data subsequent to the UL data 1020) is received at the IoTF-U 1008 from the client device 1002 before the timer 1026 expires.

[0127] Fig.11 FIG. 11 is a signal flow diagram 1100 of an exemplary attachment procedure performed by a client device in an IoT network architecture according to various aspects of the present disclosure. Fig.11As shown in , the signal flow diagram 1100 includes a client device 1102 (also referred to as an IoT device), a user plane function 1112 implemented at a network access node 1104 (e.g., an eNB, a base station, or a network access point), a control plane function 1114 implemented at a network node 1106, a serving network 1108, and a home subscriber server (HSS) 1110.

[0128] like Fig.11 As shown in , the client device 1102 may transmit a request 1116 (e.g., an RRC connection request) to the network access node 1104 to communicate with the network. The client device 1102 may receive an RRC connection setup message 1118, which may include a signaling radio bearer (SRB) configuration (e.g., an SRB1 configuration for transmitting NAS messages on a dedicated control channel (DCCH). The client device 1102 may transmit an RRC connection setup complete message 1120 to the network access node 1104. For example, the RRC connection setup complete message 1120 may indicate an attach request.

[0129] The network access node 1104 may transmit an initial client device message 1122 to the network node 1106. The control plane function 1114 may determine an address of the HSS server 1110 from the home domain information provided by the client device 1102, and may communicate 1126 with the HSS 1110. For example, the control plane function 1114 may transmit a request for authentication information about the client device 1102 to the HSS server 1110, and may receive authentication information from the HSS server 1110.

[0130] like Fig.11 As shown in FIG. 1 , the control plane function 1114 may perform mutual authentication (such as an AKA procedure 1124) with the client device 1102. Upon completion of the AKA procedure 1124, the control plane function 1114 and the client device 1102 may obtain a key K ASME 206 or from key K IoT 202 derive a control plane key, such as a key K IoT-CPenc 210 and / or key K IoT-CPint 212. The control plane function 1114 and the client device 1102 may further obtain the key K ASME 206 or from key K IoT 202 derive a user plane key, such as a key K IoT-UPenc 216 and / or key K IoT-UPint 218.

[0131] In one aspect of the present disclosure, the control plane function 1114 may use the key K CDC-IoTF-C304 encrypts the control plane context of the client device 1102 to generate a control plane encrypted client device context, and / or may be performed by using a key K CDC-IoTF-U 306 encrypts the user plane context of the client device 1102 to generate a user plane encrypted client device context.

[0132] The control plane function 1114 may transmit an initial context setup request message 1128 with an encrypted client device context (e.g., a control plane encrypted client device context and / or a user plane encrypted client device context) to the client device 1102. Thus, the encrypted client device context may include a client device context associated with the control plane function 1114 and / or the user plane function 1112, wherein the client device context may be used for uplink data transmission by the client device 1102. In an aspect, the control plane function 1114 may transmit one or more keys (e.g., a user plane key, such as a key K) via the message 1128. IoT-UPenc 216 and / or key K IoT-UPint 218, and / or key K CDC-IoTF-U 306) is passed to the user plane function 1112.

[0133] In one aspect of the present disclosure, the encryption key is known only to the user plane function 1112 and / or the control plane function 1114 (e.g., the client device security context may be exclusively retrieved by the user plane function 1112 and / or the control plane function 1114). In such aspects, for example, the encryption key may be K CDC - IoTF-U 306. In one aspect of the disclosure, each encrypted client device context corresponds to a data radio bearer (DRB).

[0134] The network access node 1104 may transmit an RRC connection reconfiguration message 1130 to the client device 1102. In an aspect of the disclosure, the RRC connection reconfiguration message 1130 may include an encrypted client device context. The client device 1102 may transmit an RRC connection reconfiguration complete message 1132 to the network access node 1104.

[0135] The client device 1102 may transmit a first message 1134 including a data packet (e.g., a UL data packet) to the network access node 1104. The user plane function 1112 implemented at the network access node 1104 may forward the data packet to the service network 1108. The service network 1108 may transmit a second message 1136 including a data packet (e.g., a DL data packet) to the client device 1102. For example, and as Fig.11As shown in , the second message 1136 may be forwarded by the user plane function 1112 at the network access node 1104 to the client device 1102. The client device 1102 may then transition 1138 to an idle mode. The network access node 1104 and the network node 1106 may proceed to remove 1140 the client device context.

[0136] Fig.12 1200 is a signal flow diagram of exemplary resource establishment and release in an IoT network architecture according to various aspects of the present disclosure. Fig.12 As shown in FIG. 1 , the signal flow diagram 1200 includes a client device 1202 (also referred to as an IoT device), a user plane function 1210 implemented at a network access node 1204, a control plane function 1212 implemented at a network node 1206, and a P-GW 1208. In one aspect, Fig.12 The network access node 1204, the user plane function 1210, the network node 1206, and the control plane function 1212 may correspond to Fig.11 network access node 1104, user plane function 1112, network node 1106, and control plane function 1114.

[0137] like Fig.12 As shown in FIG. 1 , the network access node 1204, the network node 1206, and / or the P-GW 1208 may remove 1214 the context regarding the client device 1202. In one aspect, the network access node 1204 and / or the network node 1206 may remove the context regarding the client device 1202 after the control plane function 1212 has provided the encrypted client device context to the client device 1202. Fig.12 As shown in , the client device 1202 may transmit a resource establishment request 1216 to the network access node 1204. For example, when the client device 1202 is to transmit an infrequent burst data transmission to the network (e.g., to the P-GW 1208), the client device 1202 may transmit the resource establishment request 1216. For example, the burst data transmission may include a sequence of protocol data units (PDUs) such as IP packets. In an aspect, the resource establishment request 1216 may include an encrypted client device context (e.g., a client device context of a control plane).

[0138] During resource establishment operation 1218, control plane function 1212 may verify the encrypted client device context from client device 1202, and upon successful verification, control plane function 1212 may decrypt the encrypted client device context. Control plane function 1212 may then reconstruct context about client device 1202. In one aspect, user plane function 1210 and P-GW 1208 may also reconstruct context about client device 1202. In one aspect, control plane function 1212 may obtain a network address (e.g., an IP address) for client device 1202 and may provide the network address to client device 1202 during resource establishment operation 1218. Fig.12 As shown in FIG. 1 , a client device 1202 may transmit uplink (UL) data 1220 to a P-GW 1208 via a network access node 1204. In an aspect, the client device 1202 may transmit the UL data 1220 in one or more PDUs that include a network address of the client device 1202.

[0139] In one aspect, the client device 1202 may determine that no further data transmission will be made to the network. In such aspects, the client device 1202 may optionally transmit a resource release request message 1222 to the network access node 1204. The client device 1202 may then enter an idle mode 1224. Fig.12, the network access node 1204 may transmit a resource release request message 11222 to the P-GW 1208 via the network node 1206. In an aspect, the resource release request message 11222 enables the P-GW 1208 to release one or more resources for the client device 1202. For example, the one or more resources may include a network address assigned to the client device 1202 (e.g., to allow for reallocation of the network address), a bearer for the client device 1202, and / or other resources for the client device 1202. The control plane function 1212 and the user plane function 1210 may then remove 1232 the context regarding the client device 1202. In another aspect, after receiving the UL data 1220, the user plane function 1210 and / or the control plane function 1212 may initiate a timer 1226. If the timer 1226 expires before any new UL data (e.g., additional UL data following the UL data 1220) is received from the client device 1202 and / or before any downlink (DL) data is transmitted to the client device 1202, the control plane function 1212 and / or the user plane function 1210 may determine that the client device 1202 is in idle mode 1224. In such a scenario, according to one aspect, the user plane function 1210 may transmit a resource release request message 2 1228 to the P-GW 1208 via the network node 1206. Alternatively, according to another aspect, the control plane function 1212 may transmit a resource release request message 3 1230 to the P-GW 1208. In one aspect, the resource release request message 2 1228 or the resource release request message 3 1230 enables the P-GW 1208 to release one or more resources for the client device 1202. For example, the one or more resources may include a network address assigned to the client device 1202 (e.g., to allow for reallocation of the network address), bearers for the client device 1202, and / or other resources for the client device 1202. The control plane function 1212 and the user plane function 1210 may then remove 1232 the context regarding the client device 1202. In one aspect, the timer 1226 may be reset by the control plane function 1212 and / or the user plane function 1210 when a new UL data transmission (e.g., additional UL data subsequent to the UL data 1220) is received at the user plane function 1210 from the client device 1202 before the timer 1226 expires.

[0140] Control plane protocol stack

[0141] Fig.13 1 is a diagram illustrating a control plane protocol stack 1300 for IoT data transmission according to various aspects of the present disclosure. Fig.13As shown in , the protocol stack 1300 may include a client device protocol stack 1302 (also referred to as an IoT device protocol stack), a network access node protocol stack 1304, an IoTF protocol stack 1306 implemented at a network node 1305, and a service network protocol stack 1308. For example, the network access node protocol stack 1304 may be implemented in an eNB, a base station, or a network access point. As another example, the service network protocol stack 1308 may be implemented in a P-GW. Fig.13 As shown in , the client device protocol stack 1302 may include a physical (PHY) layer 1310, a media access control (MAC) layer 1312, a radio link control (RLC) layer 1314, a packet data convergence protocol (PDCP) layer 1316, and a control (Ctrl) layer 1320. Fig.13 As further shown in FIG. 1 , the client device protocol stack 1302 may implement a method for communicating a control plane encrypted client device context (in Fig.13 The abbreviation "CDC CP ”) of the context protocol layer 1318. The context protocol layer 1318 may further enable the communication of an IoTF ID (IID) and / or a security header (in Fig.13 abbreviated as "Sec" in the

[0142] like Fig.13 As shown in FIG. 1 , the network access node protocol stack 1304 may include a PHY layer 1322, a MAC layer 1324, an RLC layer 1326, and a PDCP layer 1328, which are respectively connected to the PHY layer 1310, the MAC layer 1312, the RLC layer 1314, and the PDCP layer 1316 of the client device protocol stack 1302. The network access node protocol stack 1304 may further include an Ethernet layer 1330, a MAC layer 1332, an Internet Protocol (IP) layer 1334, a User Datagram Protocol (UDP) layer 1336, and a Control Plane GPRS Tunneling Protocol (GTP-C) layer 1338.

[0143] like Fig.13 As shown in , the IoTF protocol stack 1306 may include an Ethernet layer 1340, a MAC layer 1342, an IP layer 1344, a UDP layer 1346, a GTP-C layer 1348, and a control (Ctrl) layer 1352. Fig.13 As further shown in FIG. 1 , the IoTF protocol stack 1306 may implement a method for communicating the encrypted client device context (in Fig.13 The abbreviation "CDC CP ”) of the context protocol layer 1350. The context protocol layer 1350 may also enable the communication of an IoTF ID (IID) and / or a security header (in Fig.13 Abbreviated as "Sec" in Fig.13 As shown in FIG. 1 , the context protocol layer 1318 of the client device protocol stack 1302 is in communication with the context protocol layer 1350 of the IoTF protocol stack 1306. Fig.15 An exemplary IoT packet format is described that may carry encrypted client device context in a packet header outside of a user plane message.

[0144] The service network protocol stack 1308 may include an IP layer 1354, a UDP layer 1356, a GTP-C layer 1358, and a Ctrl layer 1360, which are respectively interfaced with the IP layer 1344, the UDP layer 1346, the GTP-C layer 1348, and the Ctrl layer 1352 of the IoTF protocol stack 1306. In one aspect of the present disclosure, if the network architecture is implemented as a GSM EDGE radio access network (GERAN), a protocol different from the IP protocol 1364 may be used. In one aspect of the present disclosure, the GTP-C and UDP protocols indicated by areas 1362 and 1366 may be omitted.

[0145] User plane protocol stack

[0146] Fig.14 1 is a diagram illustrating a user plane protocol stack 1400 for IoT data transmission according to various aspects of the present disclosure. Fig.14 As shown in , the protocol stack 1400 may include a client device protocol stack 1402 (also referred to as an IoT device protocol stack), a network access node protocol stack 1404, an IoTF protocol stack 1406 implemented at a network node 1405, and a service network protocol stack 1408. For example, the network access node protocol stack 1404 may be implemented at an eNB, a base station, or a network access point. As another example, the service network protocol stack 1408 may be implemented in a P-GW. Fig.14 As shown in , the client device protocol stack 1402 may include a physical (PHY) layer 1410, a media access control (MAC) layer 1412, a radio link control (RLC) layer 1414, a packet data convergence protocol (PDCP) layer 1416, and a user plane (UP) layer 1420. Fig.14 As further shown in FIG. 1 , the client device protocol stack 1402 may implement a method for communicating a user plane encrypted client device context (in Fig.14 The abbreviation "CDC UP ”) of the context protocol layer 1418. The context protocol layer 1418 may further enable the communication of an IoTF ID (IID) and / or a security header (in Fig.14 abbreviated as "Sec" in the

[0147] like Fig.14 As shown in FIG. 1 , the network access node protocol stack 1404 may include a PHY layer 1422, a MAC layer 1424, an RLC layer 1426, and a PDCP layer 1428, which are respectively connected to the PHY layer 1410, the MAC layer 1412, the RLC layer 1414, and the PDCP layer 1416 of the client device protocol stack 1402. The network access node protocol stack 1404 may further include an Ethernet layer 1430, a MAC layer 1432, an Internet Protocol (IP) layer 1434, a User Datagram Protocol (UDP) layer 1436, and a User Plane GPRS Tunneling Protocol (GTP-U) layer 1438.

[0148] like Fig.14 As shown in , IoTF protocol stack 1406 may include Ethernet layer 1440, MAC layer 1442, IP layer 1444, UDP layer 1446, and GTP-U layer 1448. Fig.14 As further shown in FIG. 14 , the IoTF protocol stack 1406 may implement a method for communicating encrypted client device context (in Fig.14 The abbreviation "CDC UP ”) of the context protocol layer 1450. The context protocol layer 1450 may also enable the communication of an IoTF ID (IID) and / or a security header (in Fig.14 Abbreviated as "Sec" in Fig.14 As shown in FIG. 1 , the context protocol layer 1418 of the client device protocol stack 1402 is in communication with the context protocol layer 1450 of the IoTF protocol stack 1406. Fig.15 The exemplary IoT packet format described may carry the user plane encrypted client device context in a packet header outside of a UP message.

[0149] The service network protocol stack 1408 may include an IP layer 1454, a UDP layer 1456, a GTP-U layer 1458, and a UP layer 1460, which are respectively interfaced with the IP layer 1444, the UDP layer 1446, the GTP-U layer 1448, and the UP layer 1452 of the IoTF protocol stack 1406. In one aspect of the present disclosure, if the network architecture is implemented as a GSM EDGE radio access network (GERAN), a protocol different from the IP protocol 1464 may be used. In one aspect of the present disclosure, the GTP-U and UDP protocols indicated by areas 1462 and 1466 may be omitted. In one aspect of the present disclosure, if the IP protocol is used for UP message delivery, the user plane encrypted network reachability context may be carried in the IP option field (IPv4) or the IP extension header (IPv6).

[0150] IoT Packet Format

[0151] Fig.15 is a diagram of a packet format 1500 for transmission in an IoT network architecture according to various aspects of the present disclosure. Fig.15 , a temporary identifier (TID) field 1502 may be used by a network access node (e.g., an eNB, a base station, or a network access point) to locally identify a client device (also referred to as an IoT device). For example, the value assigned to the TID field 1502 by the network access node for identifying the client device may be a C-RNTI or equivalent.

[0152] In one aspect of the present disclosure, the IoTF ID (IID) field 1504 may include a globally unique temporary identifier (GUTI). For example, the GUTI may include an identifier associated with the IoTF and an identifier associated with the client device (e.g., a temporary identifier, such as a mobility management entity (MME) temporary mobile subscriber identity (M-TMSI)). For example, the GUTI may be used by a network access node to identify the IoTF, and the GUTI may be used by the IoTF to identify the client device. On the other hand, the IID field 1504 may include a global IoTF identifier (GIOTFI) and an identifier associated with the client device (e.g., a temporary identifier, such as an M-TMSI). For example, the GIOTFI may be an equivalent of a globally unique mobility management entity identifier (GUMMEI) of the IoTF. In one aspect of the present disclosure, the M-TMSI may be encrypted for client device privacy. It should be noted that the use of the IoTF IP address may disclose the network topology.

[0153] The security header field 1506 may indicate the presence of an encrypted client device context, a control plane (CP) / user plane (UP) indication, a sequence number, a timestamp value, and / or a random value. For example, the timestamp value may be based on a time and a counter, where the time is a network access node time or an IoTF time. The client device context field 1508 may include an encrypted client device context. It should be noted that if a timestamp is used for encryption instead of a sequence number, the IoTF may not need to maintain any client device network state. The random value may be based on a random number and a counter. The random value is generated by a network access node or a client device, or a combination thereof. The counter may be incremented by a specific value (e.g., 1) for each packet. If a random value is used for encryption instead of a sequence number, the client device may generate a new encryption key based on an encryption key in the security context and a random number. If a random value is used for integrity protection instead of a sequence number, the client device may generate a new integrity protection key based on an integrity protection key in the security context and a random number, and the message may be protected using the new integrity protection key. The payload field 1510 may include data or control information (e.g., a data packet or a control packet).

[0154] The message authentication code (MAC) field 1512 may be used for integrity protection. For example, the MAC field 1512 may include a message authentication code generated by a transmitting device or entity. The message authentication code in the MAC field 1512 may then be used by the receiving device or entity to verify whether the integrity of the message has been compromised (e.g., whether the content of the message has been altered or manipulated). In one aspect, the message authentication code in the MAC field 1512 may be generated at the transmitting device or entity by applying a message authentication code generation algorithm (e.g., AEAD cipher), wherein the message (e.g., packet) and the user plane key or the control plane key are used as inputs to the message authentication code generation algorithm. The output of the message authentication code generation algorithm may be the message authentication code included in the MAC field 1512. The receiving device or entity may verify the integrity of the message by applying the message authentication code generation algorithm (e.g., AEAD cipher) to the received message. For example, the received message (e.g., packet) and the user plane key or the control plane key may be used as inputs to the message authentication code generation algorithm. The receiving device or entity may then compare the output of the message authentication code generation algorithm with the message authentication code included in the MAC field 1512. In such examples, when the output of the message authentication code generation algorithm matches the message authentication code included in the MAC field 1512, the receiving device or entity may determine that the message has been successfully authenticated.

[0155] Design and generation of encrypted client device context

[0156] According to various aspects disclosed herein, the encrypted client device context may include information that the network may need to provide services to the client device. For example, the client device context may include security context, bearer ID, Evolved Packet System (EPS) bearer quality of service (QoS) and S5-TEID, and / or other services, parameters, values, settings, or features that the network may need to provide services to the client device. In some aspects, the client device context may be established during an AKA procedure.

[0157] In some aspects, the encrypted client device context may include one or more information items in addition to the client device context. For example, the encrypted client device context may include an expiration time set by the IoTF-C 106 (or indicated in the client device context) that limits the lifetime of the encrypted client device context (e.g., to prevent permanent reuse). As another example, the encrypted client device context may have a key index that identifies a key used to generate the encrypted client device context.

[0158] In some aspects, the encrypted client device context may be generated using a secret key known only to entities in the network, and thus cannot be interpreted and / or modified by the client device. For example, the encrypted client device context may be generated by encrypting the client device context using a secret key of an IoTF-U (e.g., IoTF-U 108). In some aspects, the encrypted client device context may be integrity protected using a secret key of an IoTF-U (e.g., IoTF-U 108), and thus cannot be manipulated and / or modified by the client device.

[0159] In one aspect, the encrypted client device context may be provided by the IoTF-C (e.g., IoTF-C 106) to the client device (e.g., client device 102) as a successful completion of authentication and context (e.g., bearer) establishment. In one aspect, the client device may include the encrypted client device context in one or more user plane packets (e.g., UL data packets) to enable the IoTF-U (e.g., IoTF-U 108) to reconstruct the client device context on the fly. For example, if the client device needs to transmit multiple packets sequentially, the client device may include the encrypted client device context in the first packet and not include the encrypted client device context in subsequent packets. In some aspects, the encrypted client device context may be client device specific, and thus an encrypted client device context issued to a client device cannot be used by any other client device.

[0160] Control plane encrypted client device context

[0161] In one aspect of the present disclosure, IoTF (e.g., Figure 1 IoTF-C 106 in the control plane (CP) can generate an encrypted client device context by cascading one or more information items. For example, the control plane (CP) encrypted client device context (CDC CP ) can be based on the expression KeyID||Enc_K CDC-IoTF-C (CDC CP )||MAC to generate. In one aspect of the present disclosure, the key K CDC-IoTF-C (For example, Figure 3 The key K in CDC-IoTF-C 304) can be used with the key K CDC-IoTF (For example, Figure 3 The key K in CDC-IoTF 302) same as or from key K CDC-IoTF The term KeyID may represent the key index (used to generate the encrypted client device context). The term CDC CPThe control plane client device context may represent a control plane client device context. For example, the control plane client device context may include a client device identifier, a client device security context (eg, a control plane key, such as a key K IoT (K ASME Equivalent), key K IoT-CPenc 210. Key K IoT-CPint 212), client device security capabilities (e.g., Evolved Packet System Encryption Algorithm (EEA), Evolved Packet System Integrity Algorithm (EIA)), and / or next hop (S5 / S8) configuration information. For example, the next hop configuration information may include the IoT server address, P-GW address, and / or TEID. The item MAC may indicate an encryption mode and / or a message authentication code generation algorithm (also referred to as a MAC algorithm), which may be selected and configured to the IoTF by a mobile network operator (MNO). Therefore, the item Enc_K CDC-IoTF-C (CDC CP ) can be used to represent the use of key K CDC-IoTF-C The result of a cryptographic operation performed on the control plane client device context.

[0162] User interface encrypted client device context

[0163] As another example, the user plane (UP) is encrypted by the client device context (CDC UP ) can be based on the expression KeyID||Enc_K CDC-IoTF-U (CDC UP )||MAC to generate. Item CDC UP The user plane client device context may represent a user plane client device context. For example, the user plane client device context may include a client device identifier, a bearer ID, an Evolved Packet System (EPS) bearer quality of service (QoS), an S5 tunnel endpoint identifier (TEID) for a user plane general packet radio service (GPRS) tunneling protocol (GTP-U), an Internet Protocol (IP) address (or equivalent information) of the P-GW to which the IoTF-U 108 forwards UL data, a client device security context (e.g., a selected encryption algorithm and a user plane key, such as a key K IoT-UPenc 216. Key K IoT-UPint 218), client device security capabilities (e.g., Evolved Packet System Encryption Algorithm (EEA), Evolved Packet System Integrity Algorithm (EIA)), and / or next hop (S5 / S8) configuration information. For example, the next hop configuration information may include an IoT server address, a P-GW address, and / or a TEID. Therefore, item Enc_K CDC-IoTF-U (CDC UP ) can be used to represent the use of key K CDC-IoTF-UThe result of the encryption operation performed on the user plane client device context. In one aspect of the present disclosure, the encrypted client device context can be decrypted only by the IoTF (e.g., IoTF-C 106 and / or IoTF-U 108) to which the client device is attached / associated. In one aspect of the present disclosure, the client device context can be compressed before encryption.

[0164] The encrypted client device context may have one or more characteristics. For example, the encrypted client device context may include network status information associated with a specific client device and therefore cannot be passed to other client devices. The IoTF-C / U (e.g., IoTF-C 106 and / or IoTF-U 108) does not include the context of the client device (e.g., network status information). Accordingly, such IoTF-C / U can use its own secret key to recover the client device context from the encrypted client device context, and thus the IoTF-C / U does not need to store any additional information to recover the client device context. The IoTF-C / U can remove the client device context under certain conditions (e.g., Evolved Packet System Connection Management (ECM) is idle or immediately after a small data transfer) and recover the client device context when needed (e.g., for data transfer).

[0165] The client device may store the encrypted client device context provided by IoTF-C for fast UL data transfer / fast control plane message transfer. The client device may enter sleep mode immediately after transmitting one or more data packets. Since IoTF-U may not have message exchange overhead for reconstructing the client device context, small data packet transmission may not experience delays. In one aspect of the present disclosure, when the client device is in idle mode, user plane data transmission may not use control plane messages.

[0166] Tracking Region Updates

[0167] When a client device enters a new tracking area during idle mode, the client device may perform a tracking area update (TAU) procedure. The TAU message may include the current tracking area id (TAI) and the GIOTFI or equivalent (e.g., globally unique mobility management entity identifier (GUMMEI)) of the source IoTF-C. The target IoTF-C may update the location of the client device and the mobility anchor (e.g., IoTF-U ID) to one or more network entities (e.g., P-GW) along with the encrypted network reachability context. In one aspect of the present disclosure, the encrypted network reachability context may enable the IoTF-U to verify downlink packets. In one aspect of the present disclosure, an application server (e.g., IoT server) and / or P-GW may transmit a downlink (DL) packet with an encrypted network reachability context to the IoTF-U / C (identified by the GIOTFI).

[0168] Fig.16 1600 is a signal flow diagram of a TAU procedure in an IoT network architecture (e.g., IoT network architecture 100) according to various aspects of the present disclosure. Fig.16 As shown in FIG. 1 , the signal flow graph 1600 includes a client device 1602 (also referred to as an IoT device), a network access node 1604 (e.g., an eNB, a base station, a network access point), a target IoTF-C 1606 implemented at a target network device 1605, a source IoTF-C 1608 implemented at a source network device 1607, a P-GW 1610, and an IoT server 1612 (also referred to as an application server). The client device 1602 may transmit a data transmission request message 1614 including an encrypted client device context (e.g., a control plane (CP) encrypted client context) and a TAU request to the network access node 1604. In an aspect of the present disclosure, the data transmission request message 1614 may be sent by the client device 1602 without establishing an RRC connection.

[0169] The network access node 1604 may determine (1616) the target IoTF-C identifier included in the TAU request. The network access node 1604 may then determine the IP address of the target IoTF-C 1606 and may transmit a message 1618 including the TID associated with the client device 1602, the encrypted client device context, and the TAU request to the target IoTF-C 1606. The target IoTF-C 1606 may transmit a message 1620 including the request for the client device context and the encrypted client device context to the source IoTF-C 1608.

[0170] The source IoTF-C 1608 may transmit a message 1622 including a client device context to the target IoTF-C 1606. The target IoTF-C 1606 may store (1624) the TID of the client device and the ID of the network access node 1604, and may generate (1624) a new GUTI and a new encrypted client device context for the client device 1602 based on the received client device context. In one aspect of the present disclosure, the target IoTF-C 1606 may generate a user plane (UP) key and a context generation key and may provide these keys to the IoTF-U.

[0171] The target IoTF-C 1606 may transmit a message 1626 including a tracking area ID (TAI) and an ID (e.g., GIOTFI) of the target IoTF-C 1606 to the IoT server 1612 (or P-GW 1610). The target IoTF-C 1606 may transmit a message 1628 including the TID, the new GUTI, the new encrypted client device context, and the TAU response to the client device 1602. The network access node 1604 may forward the new GUTI, the new encrypted client device context, and the TAU response to the client device 1602 in a message 1630 based on the TID.

[0172] The various aspects disclosed herein provide an architecture with new dedicated network functions that enable independent deployment and avoid scalability / interworking requirements. The various aspects disclosed herein can enable a network access node (e.g., a base station) to pass data to or from a client device without storing or maintaining a security context about the client device, thereby avoiding consuming a large amount of resources at the network access node (or other network entity). Security features can be anchored at a new network function (referred to as an IoT function (IoTF)). Dedicated resources are allocated for IoT data transmission to avoid affecting the PDN connection / traffic of normal client devices. Encrypted UE contexts can be used for data transmission to eliminate the semi-permanent context about the UE at the IoTF when the UE is in an idle state. MME / S-GW should not maintain a large amount of state (i.e., context) for IoT devices that do not frequently transmit traffic. IoT devices may only require cost-effective data delivery without exhausting expensive core network resources.

[0173] Encrypted client device context usage information

[0174] According to various aspects of the present disclosure, a client device (e.g., Figure 7 The client device 702 in FIG. 7 may transmit usage information associated with the encrypted client device context (also referred to as encrypted client device context usage information) when it transmits the encrypted client device context to the network.

[0175] In one aspect, the encrypted client device context usage information may indicate an amount of data to be transmitted from the client device. For example, the amount of data may be indicated as a reduced data transmission (e.g., a transmission comprising a single data packet) or a burst data transmission (e.g., one or more transmissions comprising several data packets). In one aspect, the amount of data to be transmitted from the client device may be indicated using a single bit (e.g., as part of an information element (IE) in a packet header). In such aspects, for example, the client device may enable the bit (e.g., set the bit to '1') to indicate that the amount of data to be transmitted from the client device is a reduced data transmission, or may disable the bit (e.g., set the bit to '0') to indicate that the amount of data to be transmitted from the client device is a burst data transmission.

[0176] In one aspect, when the client device indicates that the amount of data to be transmitted is a reduced data transmission, the network (e.g., a network node (such as network nodes 707, 709), and / or a network access node (such as network access node 704)) may remove the context about the client device immediately after receiving the reduced data transmission from the client device. On the other hand, when the client device indicates that the amount of data to be transmitted is a reduced data transmission, the network may maintain the context about the client device for a first threshold time period. For example, the network may implement a first timer configured to measure a first threshold time period. In this regard, the network may remove the context about the client device upon expiration of the first timer. In one aspect, if the network receives a data transmission (e.g., a packet) from the client device before the first timer expires, the network may reset the first timer and may maintain the context about the client device until the first timer expires.

[0177] On the other hand, when the client device indicates that the amount of data to be transmitted is a burst data transmission, the network may maintain the context about the client device for a second threshold time period. For example, the network may implement a second timer configured to measure the second threshold time period. In this regard, the network may remove the context about the client device when the second timer expires. In one aspect, if the network receives a data transmission (e.g., a packet) from the client device before the second timer expires, the network may reset the second timer and may maintain the context about the client device until the second timer expires. For example, the second threshold time period may be greater than the first threshold time period.

[0178] In one aspect, the encrypted client device context usage information may be included in a header of a packet transmitted to the network. In another aspect, the client device may provide the encrypted client device context usage information to the network during an RRC signaling procedure.

[0179] In one aspect, a network (e.g., Figure 6 The network node 605 in the example may provide a client device (e.g., Figure 6 In such aspects, each type of encrypted client device context may be accessed by a network (e.g., Fig. 9 The encrypted client device context of the first type may be associated with a first service (e.g., a mobile broadband service) provided by the network, wherein the encrypted client device context of the first type enables the network to reconstruct a first portion of the client device context required to support the first service. In such examples, the encrypted client device context of the second type may be associated with a second service (e.g., ultra-reliable low latency communication (URLLC)) provided by the network, wherein the encrypted client device context of the second type enables the network to reconstruct a second portion of the client device context required to support the second service. In one aspect, the first portion of the client device context and the second portion of the client device context may include less context information than the client device context originally generated by the network for the client device.

[0180] In one aspect, the client device may determine one or more encrypted client device contexts to be used from the multiple types of encrypted client device contexts based on the type of transmission to be sent to (or received from) the network. By way of example, and with reference to the examples provided above, if the client device is to transmit data associated with a mobile broadband service, the client device may transmit an encrypted client device context of a first type to the network. As another example, if the client device is to transmit data associated with a URLLC service, the client device may transmit an encrypted client device context of a second type to the network. It should be understood that in addition to or in lieu of the examples provided above, the network may provide other types of services, such as high priority access services, delay-tolerant access services, or machine type communication (MTC) services.

[0181] According to various aspects of the present disclosure, when a client device transmits an encrypted client device context to a network, the client device may indicate the type of the encrypted client device context in the previously described usage information. In one aspect, the encrypted client device context usage information may indicate the type of information being transmitted from the client device. For example, the encrypted client device context usage information may indicate that the information being transmitted from the client device is associated with a user plane (e.g., data) or a control plane (e.g., control information). It can be appreciated that since each of the different types of encrypted client device contexts discussed previously can be used by the network to reconstruct a portion of a context about a client device (e.g., a subset of a context about a client device), such different types of encrypted client device contexts can be reduced in size compared to an encrypted client device context that enables reconstruction of an entire (e.g., complete) client device context.

[0182] In one aspect, for a network (e.g., Fig. 9 The type of service provided by the IoT server 912 in will be determined by the network (e.g., Fig. 9 The context (or portion of the context) reconstructed at the network node 907 in the client device (e.g., Fig. 9 The client device 902 in FIG. 1 may transmit an index number along with the encrypted client device context to facilitate reconstruction of the context at the network for a particular service (or other specific use or application). For example, the index number "1" may indicate a particular quality of service (QoS) for a mobile broadband service and the information needed to reconstruct the context to support that QoS. In such an example, the client device may transmit the encrypted client device context associated with the mobile broadband service and the index number "1" to facilitate reconstruction of the portion of the client device context that supports the mobile broadband service.

[0183] Multiple user plane network functions

[0184] In one aspect of the present disclosure, a network may include, among other things, a client device, a network access node (e.g., an eNB, a base station, a network access point), and a network entity (e.g., a serving gateway (S-GW), a packet data network gateway (P-GW)). In such aspects, the network access node may implement a first user plane network function, and the network entity may implement a second user plane network function. Accordingly, the network access node may obtain a first user plane encrypted client device context and transmit it to the client device, and the network entity may obtain a second user plane encrypted client device context and transmit it to the client device. In one aspect, the first user plane encrypted client device context may enable the first user plane network function to reconstruct a first context (e.g., a first security context) about the client device for processing user data traffic of the client device (e.g., for authenticating and / or decrypting user data packets), and the second user plane encrypted client device context may enable the second user plane network function to reconstruct a second context (e.g., a second security context) about the client device for processing user data traffic of the client device (e.g., for authenticating and / or decrypting user data packets). In one aspect, the client device may transmit multiple encrypted client device contexts to the network along with the UL data traffic. For example, the client device may transmit both a first user plane encrypted client device context and a second user plane encrypted client device context along with the UL data traffic. In one aspect, the first and second user plane encrypted client device contexts may be transmitted simultaneously (e.g., in the same packet transmitted from the client device). Thus, it can be appreciated that in some aspects, multiple encrypted client device contexts transmitted from the client device may enable reconstruction of independent client device contexts associated with different entities in the network (e.g., network access node, S-GW).

[0185] Exemplary apparatus (eg, client device) and method on the apparatus

[0186] Fig.17 1700 is an illustration of an apparatus 1700 configured to communicate with a network based on an IoT network architecture according to one or more aspects of the present disclosure (e.g., aspects related to the methods of FIGS. 18-20 described below). The apparatus 1700 includes a communication interface (e.g., at least one transceiver) 1702, a storage medium 1704, a user interface 1706, a memory device 1708, and a processing circuit 1710.

[0187] These components can be connected via a signaling bus or other suitable components (by Fig.17The signaling bus may include any number of interconnecting buses and bridges, depending on the specific application and overall design constraints of the processing circuit 1710. The signaling bus links the various circuits together so that each of the communication interface 1702, the storage medium 1704, the user interface 1706, and the memory device 1708 is coupled to and / or in electrical communication with the processing circuit 1710. The signaling bus may also link various other circuits (not shown), such as timing sources, peripherals, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further.

[0188] The communication interface 1702 may be adapted to facilitate wireless communication of the apparatus 1700. For example, the communication interface 1702 may include circuitry and / or code (e.g., instructions) adapted to facilitate bidirectional information communication about one or more communication devices in a network. The communication interface 1702 may be coupled to one or more antennas 1712 for wireless communication within a wireless communication system. The communication interface 1702 may be configured with one or more stand-alone receivers and / or transmitters and one or more transceivers. In the illustrated example, the communication interface 1702 includes a transmitter 1714 and a receiver 1716.

[0189] Memory device 1708 may represent one or more memory devices. As indicated, memory device 1708 may maintain network related information / along with other information used by apparatus 1700. In some implementations, memory device 1708 and storage medium 1704 are implemented as a shared memory component. Memory device 1708 may also be used to store data manipulated by processing circuit 1710 or by some other component of apparatus 1700.

[0190] Storage media 1704 may represent one or more computer-readable, machine-readable, and / or processor-readable devices for storing code, such as processor-executable code or instructions (e.g., software, firmware), electronic data, databases, or other digital information. Storage media 1704 may also be used to store data manipulated by processing circuit 1710 when executing code. Storage media 1704 may be any available media that can be accessed by a general or special purpose processor, including portable or fixed storage devices, optical storage devices, and various other media capable of storing, containing, or carrying code.

[0191] By way of example and not limitation, storage medium 1704 may include: a magnetic storage device (e.g., a hard disk, a floppy disk, a magnetic stripe), an optical disk (e.g., a compact disk (CD) or a digital versatile disk (DVD)), a smart card, a flash memory device (e.g., a memory card, a memory stick, or a key drive), a random access memory (RAM), a read-only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), a register, a removable disk, and any other suitable medium for storing code that can be accessed and read by a computer. Storage medium 1704 may be implemented in an article of manufacture (e.g., a computer program product). As an example, a computer program product may include a computer-readable medium in packaging material. In view of the foregoing, in some implementations, storage medium 1704 may be a non-transitory (e.g., tangible) storage medium.

[0192] Storage medium 1704 may be coupled to processing circuit 1710 such that processing circuit 1710 can read information from and write information to storage medium 1704. That is, storage medium 1704 may be coupled to processing circuit 1710 such that storage medium 1704 is at least accessible by processing circuit 1710, including examples in which at least one storage medium is integrated into processing circuit 1710 and / or examples in which at least one storage medium is separate from processing circuit 1710 (e.g., resident in device 1700, external to device 1700, distributed across multiple entities, etc.).

[0193] The codes and / or instructions stored by the storage medium 1704, when executed by the processing circuit 1710, cause the processing circuit 1710 to perform one or more of the various functional and / or process operations described herein. For example, the storage medium 1704 may include operations configured for the following actions: regulating operations at one or more hardware blocks of the processing circuit 1710 and utilizing the communication interface 1702 to communicate wirelessly by utilizing its corresponding communication protocol.

[0194] The processing circuitry 1710 is generally adapted for processing, including executing, such code / instructions stored on the storage medium 1704. As used herein, the terms "code" or "instructions" should be interpreted broadly to include, but are not limited to, programming, instructions, instruction sets, data, code, code segments, program code, programs, subroutines, software modules, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or other terminology.

[0195] Processing circuit 1710 is arranged to obtain, process and / or send data, control data access and storage, issue commands, and control other desired operations. In at least one example, processing circuit 1710 may include a circuit system configured to implement the desired code provided by an appropriate medium. For example, processing circuit 1710 may be implemented as one or more processors, one or more controllers, and / or other structures configured to execute executable code. Examples of processing circuit 1710 may include a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field programmable gate array (FPGA) or other programmable logic component designed to perform the functions described herein, discrete gate or transistor logic, discrete hardware components, or any combination thereof. A general-purpose processor may include a microprocessor, as well as any conventional processor, controller, microcontroller, or state machine. Processing circuit 1710 may also be implemented as a combination of computing components, such as a combination of DSP and microprocessor, several microprocessors, one or more microprocessors cooperating with a DSP core, ASIC and microprocessor, or any other number of variations. These examples of processing circuit 1710 are for illustration, and other suitable configurations falling within the scope of the present disclosure are also contemplated.

[0196] According to one or more aspects of the present disclosure, the processing circuit 1710 may be adapted to perform any or all of the features, processes, functions, operations, and / or routines for any or all of the devices described herein. As used herein, the term "adapted" in relation to the processing circuit 1710 may refer to the processing circuit 1710 being configured, employed, implemented, and / or programmed (one or more of the above) to perform specific processes, functions, operations, and / or routines according to the various features described herein.

[0197] According to at least one example of the apparatus 1700, the processing circuit 1710 may include one or more of a transmitting circuit / module 1720, a receiving circuit / module 1722, an encrypted client device context storage circuit / module 1724, an encrypted client device context determination circuit / module 1726, an idle mode entry circuit / module 1728, a security context establishment circuit / module 1730, a message obtaining circuit / module 1732, and a usage information obtaining circuit / module 1733, which are adapted to perform any or all of the features, processes, functions, operations, and / or routines described herein (e.g., the features, processes, functions, operations, and / or routines described with respect to FIGS. 18-20 ).

[0198] The transmission circuit / module 1720 may include a circuit system and / or instructions (e.g., transmission instructions 1734 stored on the storage medium 1704) adapted to perform several functions related to, for example, the following operations: transmitting a request to communicate with a network, transmitting a message to the network including at least one of one or more encrypted client device contexts, transmitting an empty packet with a UP encrypted client device context to the network, transmitting multiple data packets including a network address to the network, and transmitting a resource release request message to the network, wherein the resource release request message enables the network to release one or more resources for the client device.

[0199] The receiving circuit / module 1722 may include a circuit system and / or instructions (e.g., receiving instructions 1736 stored on the storage medium 1704) adapted to perform several functions related to, for example, the following operations: receiving one or more encrypted client device contexts from the network in response to a request, receiving a second data packet, wherein receiving the second data packet does not establish a radio resource control (RRC) connection with a network access node, receiving a paging message from the network, and receiving a network address of the client device in response to the message.

[0200] The encrypted client device context storage circuit / module 1724 may include circuit systems and / or instructions (e.g., encrypted client device context storage instructions 1738 stored on storage medium 1704) adapted to perform several functions related to, for example, the following operations: storing one or more encrypted client device contexts in local storage.

[0201] The encrypted client device context determination circuit / module 1726 may include circuit systems and / or instructions (e.g., encrypted client device context determination instructions 1740 stored on storage medium 1704) adapted to perform several functions related to, for example, the following operations: determining at least one of the one or more encrypted client device contexts to be used based on whether the communication includes data or control information, and determining at least one of the one or more encrypted client device contexts that is associated with a service, wherein the at least one of the one or more encrypted client device contexts enables reconstruction of the portion of the client device context that supports the service.

[0202] Idle mode entry circuit / module 1728 may include circuit systems and / or instructions (e.g., idle mode entry instructions 1742 stored on storage medium 1704) adapted to perform several functions related to, for example, the following operations: entering idle mode immediately after transmitting a message including a first data packet.

[0203] The security context establishment circuit / module 1730 may include a circuit system and / or instructions (e.g., security context establishment instructions 1744 stored on the storage medium 1704) adapted to perform several functions related to, for example, the following operations: establishing a security context for a connection with a network, wherein the security context includes at least an encryption algorithm, an encryption key, an integrity protection algorithm, an integrity protection key, or a combination thereof.

[0204] The message obtaining circuit / module 1732 may include circuit systems and / or instructions (e.g., message obtaining instructions 1746 stored on the storage medium 1704) adapted to perform several functions related to, for example, the following operations: obtaining a message, wherein the message is associated with a service provided by the network.

[0205] The usage information acquisition circuit / module 1733 may include a circuit system and / or instructions (e.g., usage information acquisition instructions 1747 stored on storage medium 1704) adapted to perform several functions related to, for example, the following operations: obtaining usage information associated with at least one of the one or more encrypted client device contexts.

[0206] As mentioned above, the instructions stored by the storage medium 1704, when executed by the processing circuit 1710, cause the processing circuit 1710 to perform one or more of the various functional and / or process operations described herein. For example, the storage medium 1704 may include one or more of the following: transmit instructions 1734, receive instructions 1736, encrypted client device context storage instructions 1738, encrypted client device context determination instructions 1740, idle mode entry instructions 1742, security context establishment instructions 1744, message obtain instructions 1746, and usage information obtain instructions 1747.

[0207] Figure 18 (including Fig.18A and 18B ) is a flowchart 1800 illustrating a method for communicating with a network according to various aspects of the present disclosure. The method may be performed by an apparatus such as a client device (e.g., client device 102, 502 or apparatus 1700). It should be understood that the operations indicated by dashed lines in FIG. 18 represent optional operations.

[0208] The client device transmits a request to communicate with the network (1802). In one example, the request may be a request previously made regarding Figure 6The request 612 described above. In one aspect, the request may include an indication that the client device is requesting an encrypted client device context and / or an indication of a service that the client device is requesting. The client device establishes a security context for a connection with a network, wherein the security context includes at least an encryption algorithm, an encryption key, an integrity protection algorithm, and / or an integrity protection key (1803). In one aspect, the encryption key is a user plane encryption key and the integrity protection key is a user plane integrity protection key, the user plane encryption key and the user plane integrity protection key are maintained at the client device, and the first data packet is integrity protected with at least the user plane integrity protection key or encrypted with the user plane encryption key.

[0209] The client device receives one or more encrypted client device contexts from the network in response to the request (1804). In one example, the one or more encrypted client device contexts may be Figure 6 , an encrypted client device context in an RRC connection reconfiguration message 626 received by the client device 602. In one aspect, the encrypted client device context may be received from the network as a result of successful authentication with the network. In such aspects, successful authentication with the network does not establish an access stratum (AS) security context. For example, the one or more encrypted client device contexts may include at least one of: a security context, a quality of service (QoS) of a bearer, and / or a tunnel endpoint identifier (TEID). In one aspect, the one or more encrypted client device contexts may include a first context to be used for data-related communications with the client device and a second context to be used for control-related communications with the client device. In one aspect, the one or more encrypted client device contexts cannot be decrypted at the client device. In such aspects, the one or more encrypted client device contexts can only be decrypted by the network device that generated the one or more encrypted client device contexts.

[0210] The client device stores the one or more encrypted client device contexts in local storage (1806). The client device determines at least one encrypted client device context to be used from the one or more encrypted client device contexts based on whether a message (e.g., a packet) to be transmitted from the client device includes data or control information (1808). For example, the one or more encrypted client device contexts may include a user plane (UP) encrypted client device context and a control plane (CP) encrypted client device context. In such examples, the client device may transmit a first data packet with a UP encrypted client device context, or a control packet with a CP encrypted client device context. For example, the control packet may be a tracking area update (TAU) packet.

[0211] The client device transmits a message including at least one of the one or more encrypted client device contexts to the network (1810). In one example, the message may include the encrypted client device context and Figure 8 804. In one aspect, the encrypted client device context enables a context for communicating with the client device to be reconstructed at the network, the context comprising network state information associated with the client device. In one aspect, the context is removed (e.g., deleted or no longer maintained) at the network. In one aspect, the client device may transmit a message comprising a first data packet without establishing a radio resource control (RRC) connection with a network access node of the network. The client device enters an idle mode (1812) immediately after transmitting the message comprising the first data packet.

[0212] The client device receives a second data packet, wherein receiving the second data packet does not establish an RRC connection with the network access node (1814). In one example, the second data packet may be Figure 8 802 from the network access node 804 to the client device 802. In one aspect, the encryption key is a user plane encryption key and the integrity protection key is a user plane integrity protection key, wherein the user plane encryption key and the user plane integrity protection key are maintained at the client device. In such aspects, upon receiving the second data packet, the client device verifies the second data packet with the user plane integrity protection key and / or decrypts the second data packet with the user plane encryption key. The client device receives a paging message from the network (1816). The client device transmits a null packet with the UP encrypted client device context to the network (1818).

[0213] Fig.19 1900 is a flowchart illustrating a method for communicating with a network according to various aspects of the present disclosure. The method may be performed by an apparatus such as a client device (e.g., client device 102, 502 or apparatus 1700). It should be understood that Fig.19 Operations indicated by dashed lines in the figure represent optional operations.

[0214] The client device transmits a request to communicate with the network (1902). In one example, the request may be a request previously made regarding Figure 6The request 612 described above. In one aspect, the request may include an indication that the client device is requesting an encrypted client device context and / or an indication of a service that the client device is requesting. The client device establishes a security context for a connection with a network, wherein the security context includes at least an encryption algorithm, an encryption key, an integrity protection algorithm, and / or an integrity protection key (1904). In one aspect, the encryption key is a user plane encryption key and the integrity protection key is a user plane integrity protection key, the user plane encryption key and the user plane integrity protection key are maintained at the client device, and the first data packet is integrity protected with at least the user plane integrity protection key or encrypted with the user plane encryption key.

[0215] The client device receives one or more encrypted client device contexts from the network in response to the request (1906). In one example, the one or more encrypted client device contexts may be Figure 6, an encrypted client device context in an RRC connection reconfiguration message 626 received by the client device 602. In one aspect, the encrypted client device context may be received from the network as a result of successful authentication with the network. In such aspects, successful authentication with the network does not establish an access stratum (AS) security context. For example, the one or more encrypted client device contexts may include at least one of: a security context, a quality of service (QoS) of a bearer, and / or a tunnel endpoint identifier (TEID). In one aspect, the one or more encrypted client device contexts may include a first context to be used for data-related communications with the client device and a second context to be used for control-related communications with the client device. In one aspect, the one or more encrypted client device contexts cannot be decrypted at the client device. In such aspects, the one or more encrypted client device contexts can only be decrypted by the network device that generated the one or more encrypted client device contexts. In one aspect, after the client device receives the one or more encrypted client device contexts from the network, the context is removed at the network. The client device transmits a message (1908) to the network including at least one of the one or more encrypted client device contexts. In one aspect, the one or more encrypted client device contexts enable reconstruction of a context for communicating with the client device at the network, the context comprising network state information associated with the client device. In one aspect, the message further comprises a resource establishment request and at least one of the one or more encrypted client device contexts. For example, the message may be a resource establishment request message 1016. The client device receives a network address for the client device in response to the message (1910). The client device transmits a plurality of data packets including the network address to the network (1912). The client device transmits a resource release request message to the network, wherein the resource release request message enables the network to release one or more resources for the client device (1914).

[0216] Fig. 20 2000 is a flowchart illustrating a method for communicating with a network according to various aspects of the present disclosure. The method may be performed by an apparatus such as a client device (e.g., client device 102, 502 or apparatus 1700). It should be understood that Fig. 20 Operations indicated by dashed lines in the figure represent optional operations.

[0217] In one aspect, a method for a client device is provided. The client device transmits a request to communicate with a network (2002). The client device establishes a security context for a connection with the network, wherein the security context includes at least an encryption algorithm, an encryption key, an integrity protection algorithm, an integrity protection key, or a combination thereof (2004). The client device receives one or more encrypted client device contexts from the network in response to the request (2006).

[0218] The client device obtains a message, wherein the message is associated with a service provided by the network (2008). In one aspect, each of the one or more encrypted client device contexts is associated with one of a plurality of services provided by the network. In such aspects, the client device determines at least one of the one or more encrypted client device contexts that is associated with the service, wherein the at least one of the one or more encrypted client device contexts enables reconstruction of a portion of the client device context that supports the service (2010). For example, the plurality of services may include a mobile broadband service, an ultra-reliable low latency communication (URLLC) service, a high priority access service, a delay-tolerant access service, and / or a machine type communication (MTC) service.

[0219] The client device obtains usage information associated with the at least one encrypted client device context of the one or more encrypted client device contexts (2012). In one aspect, the usage information associated with the at least one encrypted client device context of the one or more encrypted client device contexts indicates whether the transmission of the message is a reduced data transmission or a burst data transmission. In one aspect, the usage information may include a value (e.g., an index number or other value) associated with a context (or portion of a context) to be reconstructed by the network for a type of service provided by the network.

[0220] The client device transmits a message (2014) including at least one of the one or more encrypted client device contexts to the network. In one aspect, the message includes usage information. In one aspect, the one or more encrypted client device contexts enable at least a portion of a context for communicating with the client device to be reconstructed at the network, the context including network state information associated with the client device. In one aspect, the portion of the context is maintained at the network for a time period determined based on whether the transmission of the message is a reduced data transmission or a burst data transmission. In one aspect, the one or more encrypted client device contexts include a first user-plane encrypted client device context that enables a first context about the client device to be reconstructed at a first entity in the network, and a second user-plane encrypted client device context that enables a second context about the client device to be reconstructed at a second entity in the network. In such aspects, the message includes at least a first user-plane encrypted client device context and a second user-plane encrypted client device context.

[0221] Exemplary apparatus (eg, network device) and method on the apparatus

[0222] Fig.21 21 is an illustration of an apparatus 2100 according to one or more aspects of the present disclosure (e.g., aspects related to the methods of FIGS. 22-26 described below). The apparatus 2100 includes a network communication interface (e.g., at least one transceiver) 2102, a storage medium 2104, a user interface 2106, a memory device 2108, and a processing circuit 2110. In one aspect, the apparatus 2100 may be a network device (e.g., a network device 105, 505, 705) that implements Internet of Things (IoT) functions. For example, the apparatus 2100 may implement control plane IoT functions (e.g., IoTF-C 106, 506, 606, 706, 906, 1406) and / or user plane IoT functions (e.g., IoTF-U 108, 508, 608, 708, 806, 908). It should be understood that such a network device may be implemented as a single network entity or multiple network entities.

[0223] These components can be connected via a signaling bus or other suitable components (by Fig.21The signaling bus may include any number of interconnecting buses and bridges, depending on the specific application and overall design constraints of the processing circuit 2110. The signaling bus links the various circuits together so that each of the network communication interface 2102, the storage medium 2104, the user interface 2106, and the memory device 2108 is coupled to and / or in electrical communication with the processing circuit 2110. The signaling bus may also link various other circuits (not shown), such as timing sources, peripherals, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further.

[0224] The network communication interface 2102 may be adapted to facilitate communication of the device 2100. For example, the network communication interface 2102 may include circuitry and / or code (e.g., instructions) adapted to facilitate bidirectional communication of information with respect to one or more network entities in a network. The network communication interface 2102 may be configured with one or more independent receivers and / or transmitters and one or more transceivers.

[0225] Memory device 2108 may represent one or more memory devices. As indicated, memory device 2108 may maintain network related information / along with other information used by apparatus 2100. In some implementations, memory device 2108 and storage medium 2104 are implemented as a shared memory component. Memory device 2108 may also be used to store data manipulated by processing circuit 2110 or by some other component of apparatus 2100.

[0226] Storage media 2104 may represent one or more computer-readable, machine-readable, and / or processor-readable devices for storing code, such as processor-executable code or instructions (e.g., software, firmware), electronic data, databases, or other digital information. Storage media 2104 may also be used to store data manipulated by processing circuit 2110 when executing code. Storage media 2104 may be any available media that can be accessed by a general or special purpose processor, including portable or fixed storage devices, optical storage devices, and various other media capable of storing, containing, or carrying code.

[0227] By way of example and not limitation, storage medium 2104 may include: a magnetic storage device (e.g., a hard disk, a floppy disk, a magnetic stripe), an optical disk (e.g., a compact disk (CD) or a digital versatile disk (DVD)), a smart card, a flash memory device (e.g., a memory card, a memory stick, or a key drive), a random access memory (RAM), a read-only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), a register, a removable disk, and any other suitable medium for storing code that can be accessed and read by a computer. Storage medium 2104 may be implemented in an article of manufacture (e.g., a computer program product). As an example, a computer program product may include a computer-readable medium in packaging material. In view of the foregoing, in some implementations, storage medium 2104 may be a non-transitory (e.g., tangible) storage medium.

[0228] Storage medium 2104 may be coupled to processing circuit 2110 such that processing circuit 2110 can read information from and write information to storage medium 2104. That is, storage medium 2104 may be coupled to processing circuit 2110 such that storage medium 2104 is at least accessible by processing circuit 2110, including examples in which at least one storage medium is integrated into processing circuit 2110 and / or examples in which at least one storage medium is separate from processing circuit 2110 (e.g., resident in device 2100, external to device 2100, distributed across multiple entities, etc.).

[0229] The codes and / or instructions stored by the storage medium 2104, when executed by the processing circuit 2110, cause the processing circuit 2110 to perform one or more of the various functional and / or process operations described herein. For example, the storage medium 2104 may include operations configured for the following actions: regulating operations at one or more hardware blocks of the processing circuit 2110 and using the network communication interface 2102 for network communications using its corresponding communication protocol.

[0230] The processing circuitry 2110 is generally adapted for processing, including executing such code / instructions stored on the storage medium 2104. As used herein, the term "code" or "instructions" should be interpreted broadly to include, but are not limited to, programming, instructions, instruction sets, data, code, code segments, program code, programs, subroutines, software modules, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or other terminology.

[0231] The processing circuit 2110 is arranged to obtain, process and / or send data, control data access and storage, issue commands, and control other desired operations. In at least one example, the processing circuit 2110 may include a circuit system configured to implement the desired code provided by an appropriate medium. For example, the processing circuit 2110 may be implemented as one or more processors, one or more controllers, and / or other structures configured to execute executable code. Examples of the processing circuit 2110 may include a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic components, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may include a microprocessor, as well as any conventional processor, controller, microcontroller, or state machine. The processing circuit 2110 may also be implemented as a combination of computing components, such as a combination of a DSP and a microprocessor, several microprocessors, one or more microprocessors cooperating with a DSP core, an ASIC and a microprocessor, or any other number of variations. These examples of the processing circuit 2110 are for illustration, and other suitable configurations falling within the scope of the present disclosure are also contemplated.

[0232] According to one or more aspects of the present disclosure, the processing circuit 2110 may be adapted to perform any or all of the features, processes, functions, operations, and / or routines for any or all of the devices described herein. As used herein, the term "adapted" in relation to the processing circuit 2110 may refer to the processing circuit 2110 being configured, employed, implemented, and / or programmed (one or more of the above) to perform specific processes, functions, operations, and / or routines according to the various features described herein.

[0233] According to at least one example of the apparatus 2100, the processing circuit 2110 may include one or more of a transmitting circuit / module 2120, a receiving circuit / module 2122, an authentication and verification circuit / module 2124, an encrypted client device context generation circuit / module 2126, a context reconstruction / removal circuit / module 2128, a packet processing circuit / module 2130, a storage circuit / module 2132, a network access node determination circuit / module 2134, a temporary identifier addition circuit / module 2136, a network address acquisition / release circuit / module 2137, a packet encryption and protection circuit / module 2138, and a security context establishment circuit / module 2139, which are adapted to perform any or all of the features, processes, functions, operations, and / or routines described herein (e.g., the features, processes, functions, operations, and / or routines described with respect to FIGS. 22-26 ).

[0234] The transmit circuit / module 2120 may include circuit systems and / or instructions (e.g., transmit instructions 2140 stored on the storage medium 2104) adapted to perform several functions related to, for example, the following operations: transmitting one or more encrypted client device contexts to a client device, transmitting a new encrypted client device context to a second client device, forwarding a payload portion of a control packet to an application server or a packet data network gateway (P-GW), forwarding a control packet to a client device, forwarding a first data packet to a serving network, forwarding a second data packet to the client device, and / or transmitting a network address to the client device.

[0235] The receiving circuit / module 2122 may include circuit systems and / or instructions (e.g., receiving instructions 2142 stored on the storage medium 2104) adapted to perform several functions related to, for example, the following operations: receiving a request to communicate with a network from a client device, receiving a control packet and an encrypted client device context from a client device, receiving a first data packet and an encrypted client device context from a client device, receiving a second data packet from a server or a packet data network gateway (P-GW), receiving a control packet from a second client device, receiving a context about a second client device from a second network device, receiving a message from the client device including a resource establishment request and at least one of the one or more encrypted client device contexts, receiving a message from the client device including at least one of the one or more encrypted client device contexts and usage information associated with the one or more encrypted client device contexts, and / or receiving a resource release request message from the client device.

[0236] The authentication and verification circuit / module 2124 may include circuit systems and / or instructions (e.g., authentication and verification instructions 2144 stored on the storage medium 2104) adapted to perform several functions related to, for example, the following operations: requesting authentication information from a home subscriber server (HSS) / authentication authorization accounting (AAA) server, performing mutual authentication with a client device, and verifying an encrypted client device context received from the client device.

[0237] The encrypted client device context generation circuit / module 2126 may include circuitry and / or instructions (e.g., encrypted client device context generation instructions 2146 stored on the storage medium 2104) adapted to perform several functions related to, for example, generating one or more encrypted client device contexts, wherein the one or more encrypted client device contexts enable reconstruction of at least one context for communicating with a client device at the network, determining whether the encrypted client device context has expired, generating a new encrypted client device context, determining to generate one or more encrypted client device contexts, wherein the determination is based on at least one of encrypted client device context usage information indicated in the request, a subscription of the device, or a policy, and requesting a client device context for a second client device from a second network device, the request including a control plane (CP) encrypted client device context. For example, the one or more encrypted client device contexts may include a first context to be used for data-related communications and a second context to be used for control-related communications.

[0238] Context reconstruction / removal circuitry / module 2128 may include circuitry and / or instructions (e.g., context reconstruction / removal instructions 2148 stored on storage medium 2104) adapted to perform several functions related to, for example, obtaining a key (e.g., key K) for an encrypted client device context associated with a client device; CDC-IoTF-U ), obtain a security context about the client device from the encrypted client device context based on the key, reconstruct at least one context from the encrypted client device context, reconstruct at least a portion of the context based on at least one of the one or more encrypted client device contexts and the usage information, remove at least one context, and / or maintain the at least a portion of the context for a first threshold time period when the usage information indicates reduced data transmission or maintain the at least a portion of the context for a second threshold time period when the usage information indicates burst data transmission, the second threshold time period being greater than the first threshold time period.

[0239] The packet processing circuit / module 2130 may include a circuit system and / or instructions (e.g., packet processing instructions 2150 stored on the storage medium 2104) adapted to perform several functions related to, for example, the following operations: using the at least one context to process a control packet, wherein the processing includes at least one of the following: using the context to verify or decrypt the control packet.

[0240] Storage circuit / module 2132 may include circuitry and / or instructions (eg, stored instructions 2152 stored on storage medium 2104) adapted to perform several functions related to, for example, storing a temporary identifier (ID) for downlink packets for a client device.

[0241] The network access node determination circuit / module 2134 may include circuit systems and / or instructions (e.g., network access node determination instructions 2154 stored on storage medium 2104) adapted to perform several functions related to, for example, the following operations: determining the network access node to which the second data packet is forwarded.

[0242] The temporary identifier addition circuit / module 2136 may include a circuit system and / or instructions (e.g., temporary identifier addition instructions 2156 stored on the storage medium 2104) adapted to perform several functions related to, for example, the following operations: adding a temporary identifier to the second data packet, the temporary identifier enabling the network access node to determine the client device.

[0243] The network address acquisition / release circuit / module 2137 may include a circuit system and / or instructions (e.g., network address acquisition / release instructions 2157 stored on the storage medium 2104) adapted to perform several functions related to, for example, the following operations: obtaining a network address for a client device in response to a message, transmitting a resource release request message from the client device to a gateway, wherein the resource release request message enables the gateway to release the network address for the client device, and / or transmitting a resource release request message to the gateway when a timer expires before a transmission from the client device to the network or before a transmission from the network to the client device, wherein the resource release request message enables the gateway to release one or more resources for the client device.

[0244] The packet encryption and protection circuit / module 2138 may include circuit systems and / or instructions (e.g., packet encryption and protection instructions 2158 stored on the storage medium 2104) adapted to perform several functions related to, for example, the following operations: encrypting or integrity protecting a packet using a user plane (UP) client device key, decrypting and verifying a first data packet based on a security context, and / or encrypting or integrity protecting a second data packet using a user plane encryption key or a user plane integrity protection key.

[0245] The security context establishment circuit / module 2139 may include a circuit system and / or instructions (e.g., security context establishment instructions 2159 stored on the storage medium 2104) adapted to perform several functions related to, for example, the following operations: establishing at least one context with a client device, the at least one context including network status information associated with a connection between the client device and a network, wherein the network status information includes at least an encryption algorithm, an encryption key, an integrity protection algorithm, an integrity protection key, or a combination thereof.

[0246] As mentioned above, the instructions stored by the storage medium 2104, when executed by the processing circuit 2110, cause the processing circuit 2110 to perform one or more of the various functional and / or process operations described herein. For example, the storage medium 2104 may include one or more of the following: transmission instructions 2140, reception instructions 2142, authentication and verification instructions 2144, encrypted client device context generation instructions 2146, context reconstruction / removal instructions 2148, packet processing instructions 2150, storage instructions 2152, network access node determination instructions 2154, temporary identifier addition instructions 2156, network address acquisition / release instructions 2157, packet encryption and protection instructions 2158, and security context establishment instructions 2159.

[0247] Figure 22 (including Fig.22A and 22B ) is a flowchart 2200 illustrating a method for communicating in an IoT network architecture according to various aspects of the present disclosure. The method may be implemented by an IoT function (e.g., a control plane IoTF, such as Figure 1 A device such as a network device (e.g., a control plane IoTF 106) Figure 1 The network device 105 or Fig.21 It should be understood that the operations indicated by dashed lines in FIG. 22 represent optional operations.

[0248] The apparatus receives a request from a client device to communicate with a network (2202). The apparatus requests authentication information from a Home Subscriber Server (HSS) / Authentication Authorization Accounting (AAA) server (2204). The apparatus performs mutual authentication with the client device (2206).

[0249] The apparatus establishes at least one context with the client device, the at least one context comprising network state information associated with a connection between the client device and the network (2207). In one aspect, the network state information comprises at least an encryption algorithm, an encryption key, an integrity protection algorithm, and / or an integrity protection key. The apparatus determines to generate one or more encrypted client device contexts, wherein the determination is based on at least one of the encrypted client device context usage information indicated in the request, a subscription of the client device, and / or a policy (2208).

[0250] The apparatus generates one or more encrypted client device contexts (2210). In one aspect, the one or more encrypted client device contexts enable reconstruction of a context for communicating with the client device at a network. In one aspect, the one or more encrypted client device contexts include a first context to be used for data-related communications and a second context to be used for control-related communications. The apparatus transmits the one or more encrypted client device contexts to the client device (2212).

[0251] The apparatus receives a control packet and an encrypted client device context from a client device (2214). The apparatus verifies the encrypted client device context received from the client device (2216). In one aspect, the apparatus verifies the encrypted client device context received from the client device by determining whether the encrypted client device context has expired, generating one or more new encrypted client device contexts when a previous encrypted client device context has expired, and transmitting the one or more new encrypted client device contexts to the client device when the previous encrypted client device context has expired. In one aspect, verifying the encrypted client device context includes determining a key for verifying the encrypted client device context.

[0252] The apparatus reconstructs at least one context from the encrypted client device context (2218). The apparatus processes a control packet using the at least one context, wherein the processing includes at least one of: authenticating or decrypting the control packet using the at least one context (2220). The apparatus stores a temporary identifier (ID) for a downlink packet for the client device (2222). The apparatus forwards a payload portion of the control packet to an application server or a packet data network gateway (P-GW) (2224).

[0253] Figure 23 (including Fig.23A and 23B ) is a flowchart 2300 illustrating a method for communicating in an IoT network architecture according to various aspects of the present disclosure. The method may be implemented by an IoT function (e.g., a control plane IoTF, such as Figure 1 A device such as a network device (e.g., a control plane IoTF 106) Figure 1 The network device 105 or Fig.21 It should be understood that the operations indicated by dashed lines in FIG23 represent optional operations.

[0254] The apparatus receives a request to communicate with a network from a client device (2302). The apparatus establishes at least one context with the client device, the at least one context comprising network state information associated with a connection between the client device and the network, wherein the network state information comprises at least an encryption algorithm, an encryption key, an integrity protection algorithm, and / or an integrity protection key (2304). The apparatus generates one or more encrypted client device contexts (2306). In one aspect, the one or more encrypted client device contexts enable reconstruction of at least one context for communicating with the client device at the network. The apparatus transmits the one or more encrypted client device contexts to the client device (2308). The apparatus removes the at least one context (2310). The apparatus receives a message from the client device, the message comprising at least one of the one or more encrypted client device contexts and usage information associated with the one or more encrypted client device contexts (2312). In one aspect, the usage information indicates whether the transmission of the message is a reduced data transmission or a burst data transmission. In one aspect, the network device may reconstruct at least a portion of the context based on at least one of the one or more encrypted client device contexts and the usage information. In one aspect, the message from the client device includes a resource establishment request and at least one encrypted client device context of the one or more encrypted client device contexts. For example, the message may be Fig.10 , wherein the device receives a resource establishment request message 1016 in the resource establishment request message 1016. The device obtains a network address for the client device in response to the message (2314). The device transmits the network address (2316) to the client device. In one aspect, the device maintains the at least a portion of the context for a first threshold time period when the usage information indicates a reduction in data transmission or maintains the at least a portion of the context for a second threshold time period when the usage information indicates a burst data transmission, and the second threshold time period is greater than the first threshold time period. In one aspect, the device transmits a resource release request message (2318) to the gateway when the timer expires before the transmission from the client device to the network or before the transmission from the network to the client device. In one aspect, the resource release request message enables the gateway to release one or more resources for the client device. In another aspect, the device receives a resource release request message (2320) from the client device. In such aspects, the device transmits a resource release request message from the client device to the gateway (2322). In one aspect, the resource release request message enables the gateway to release one or more resources for the client device. In some aspects, operation 2318 and operations 2320 and 2322 may be performed alternatively. For example, if operation 2318 is performed, operations 2320 and 2322 may not be performed. As another example, if operations 2320 and 2322 are performed, operation 2318 may not be performed.

[0255] Fig.24 2400 is a flowchart illustrating a method for communicating in an IoT network architecture according to various aspects of the present disclosure. The method may be implemented by an IoT function (e.g., a control plane IoTF, such as Figure 1 A device such as a network device (e.g., a control plane IoTF 106) Figure 1 The network device 105 or Fig.21 Device 2100) is executed.

[0256] The apparatus receives a control plane packet from a second client device (2402). In one aspect, the second client device is different from the client device from which the request to communicate with the network was initially received. The apparatus requests a context about the second client device from the second network device, the request including a control plane (CP) encrypted client device context (2404). The apparatus receives a context about the second client device from the second network device (2406). The apparatus generates a new encrypted client device context (2408). The apparatus transmits the new encrypted client device context to the second client device (2410).

[0257] Figure 25 (including Fig.25A and 25B ) is a flowchart 2500 illustrating a method for communicating in an IoT network architecture according to various aspects of the present disclosure. The method may be implemented by an IoT function (e.g., a user plane IoTF, such as Figure 1 A device such as a network device (e.g., a user plane IoTF 108) Figure 1 The network device 105 or Fig.21 It should be understood that the operations indicated by dashed lines in FIG25 represent optional operations.

[0258] The apparatus obtains a key (eg, a key K) for an encrypted client device context associated with the client device. CDC-IoTF-U )(2502). The apparatus receives a first data packet (e.g., a UL data packet) and an encrypted client device context from a client device (2504). The apparatus obtains a security context about the client device from the encrypted client device context using the key (2506). The apparatus decrypts and verifies the first data packet based on the security context (2508). The apparatus forwards the first data packet to a service network (2510) when the decryption and verification are successful.

[0259] In one aspect, the apparatus receives a second data packet (eg, Fig. 9The apparatus determines a network access node to which the second data packet is forwarded (2514). The apparatus adds a temporary identifier to the second data packet, the temporary identifier enabling the network access node to determine the client device (2516). The apparatus encrypts or integrity protects the second data packet using a user plane encryption key or a user plane integrity protection key (2518). The apparatus (e.g., via Fig. 9 Message 934 in the forwarding of the second data packet to the client device (2520).

[0260] Figure 26 (including Fig.26A and 26B ) is a flowchart 2600 illustrating a method for communicating in an IoT network architecture according to various aspects of the present disclosure. The method may be implemented by an IoT function (e.g., a control plane IoTF, such as Figure 1 A device such as a network device (e.g., a control plane IoTF 106) Figure 1 The network device 105 or Fig.21 It should be understood that the operations indicated by dashed lines in FIG26 represent optional operations.

[0261] The apparatus receives a request from a client device to communicate with a network (2602). The apparatus requests authentication information from a Home Subscriber Server (HSS) / Authentication Authorization Accounting (AAA) server (2604). The apparatus performs mutual authentication with the client device (2606).

[0262] The apparatus establishes at least one context with the client device, the at least one context comprising network state information associated with a connection between the client device and a network (2608). In one aspect, the network state information comprises at least an encryption algorithm, an encryption key, an integrity protection algorithm, and / or an integrity protection key. The apparatus determines to generate one or more encrypted client device contexts, wherein the determination is based on at least one of the encrypted client device context usage information indicated in the request, a subscription of the client device, and / or a policy (2610).

[0263] The device generates one or more encrypted client device contexts (2612). In one aspect, the one or more encrypted client device contexts enable a context for communicating with the client device to be reconstructed at a network. In one aspect, the one or more encrypted client device contexts include a first context to be used for data-related communications and a second context to be used for control-related communications. The device transmits the one or more encrypted client device contexts to the client device (2614). The device removes the at least one context (2616). The device receives a message from the client device, the message including at least one of the one or more encrypted client device contexts and usage information associated with the one or more encrypted client device contexts (2618). The device reconstructs at least a portion of the context based on at least one of the one or more encrypted client device contexts and the usage information (2620). The device maintains the at least a portion of the context for a first threshold time period when the usage information indicates reduced data transmission or maintains the at least a portion of the context for a second threshold time period when the usage information indicates burst data transmission, the second threshold time period being greater than the first threshold time period (2622).

[0264] Exemplary apparatus (eg, network access node) and method on the apparatus

[0265] Fig. 27 According to one or more aspects of the present disclosure (for example, with the following description Fig.28 29) is an illustration of an apparatus 2700 that includes a communication interface (e.g., at least one transceiver) 2702, a network communication interface 2703, a storage medium 2704, a user interface 2706, a memory device 2708, and a processing circuit 2710.

[0266] These components can be connected via a signaling bus or other suitable components (by Fig. 27 The signaling bus may include any number of interconnecting buses and bridges, depending on the specific application and overall design constraints of the processing circuit 2710. The signaling bus links the various circuits together so that each of the communication interface 2702, the network communication interface 2703, the storage medium 2704, the user interface 2706, and the memory device 2708 is coupled to and / or in electrical communication with the processing circuit 2710. The signaling bus may also link various other circuits (not shown), such as timing sources, peripherals, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further.

[0267] The communication interface 2702 may be adapted to facilitate wireless communication of the apparatus 2700. For example, the communication interface 2702 may include circuitry and / or code (e.g., instructions) adapted to facilitate bidirectional information communication about one or more communication devices in a network. The communication interface 2702 may be coupled to one or more antennas 2712 for wireless communication within a wireless communication system. The communication interface 2702 may be configured with one or more stand-alone receivers and / or transmitters and one or more transceivers. In the illustrated example, the communication interface 2702 includes a transmitter 2714 and a receiver 2716.

[0268] The network communication interface 2703 may be adapted to facilitate communication of the device 2700. For example, the network communication interface 2703 may include circuitry and / or code (e.g., instructions) adapted to facilitate bidirectional communication of information with respect to one or more network entities in a network. The network communication interface 2703 may be configured with one or more independent receivers and / or transmitters and one or more transceivers.

[0269] Memory device 2708 may represent one or more memory devices. As indicated, memory device 2708 may maintain network related information / along with other information used by apparatus 2700. In some implementations, memory device 2708 and storage medium 2704 are implemented as a shared memory component. Memory device 2708 may also be used to store data manipulated by processing circuit 2710 or by some other component of apparatus 2700.

[0270] Storage media 2704 may represent one or more computer-readable, machine-readable, and / or processor-readable devices for storing code, such as processor-executable code or instructions (e.g., software, firmware), electronic data, databases, or other digital information. Storage media 2704 may also be used to store data manipulated by processing circuit 2710 when executing code. Storage media 2704 may be any available media that can be accessed by a general or special purpose processor, including portable or fixed storage devices, optical storage devices, and various other media capable of storing, containing, or carrying code.

[0271] By way of example and not limitation, storage medium 2704 may include: a magnetic storage device (e.g., a hard disk, a floppy disk, a magnetic stripe), an optical disk (e.g., a compact disk (CD) or a digital versatile disk (DVD)), a smart card, a flash memory device (e.g., a memory card, a memory stick, or a key drive), a random access memory (RAM), a read-only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), a register, a removable disk, and any other suitable medium for storing code that can be accessed and read by a computer. Storage medium 2704 may be implemented in an article of manufacture (e.g., a computer program product). As an example, a computer program product may include a computer-readable medium in packaging material. In view of the foregoing, in some implementations, storage medium 2704 may be a non-transitory (e.g., tangible) storage medium.

[0272] Storage medium 2704 may be coupled to processing circuit 2710 such that processing circuit 2710 can read information from and write information to storage medium 2704. That is, storage medium 2704 may be coupled to processing circuit 2710 such that storage medium 2704 is at least accessible by processing circuit 2710, including examples in which at least one storage medium is integrated into processing circuit 2710 and / or examples in which at least one storage medium is separate from processing circuit 2710 (e.g., resident in device 2700, external to device 2700, distributed across multiple entities, etc.).

[0273] The codes and / or instructions stored by the storage medium 2704, when executed by the processing circuit 2710, cause the processing circuit 2710 to perform one or more of the various functional and / or process operations described herein. For example, the storage medium 2704 may include operations configured for the following actions: regulating operations at one or more hardware blocks of the processing circuit 2710 and utilizing the communication interface 2702 to communicate wirelessly by utilizing its corresponding communication protocol.

[0274] The processing circuitry 2710 is generally adapted for processing, including executing, such code / instructions stored on the storage medium 2704. As used herein, the term "code" or "instructions" should be interpreted broadly to include, but are not limited to, programming, instructions, instruction sets, data, code, code segments, program code, programs, subroutines, software modules, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or other terminology.

[0275] Processing circuit 2710 is arranged to obtain, process and / or send data, control data access and storage, issue commands, and control other desired operations. In at least one example, processing circuit 2710 may include a circuit system configured to implement the desired code provided by an appropriate medium. For example, processing circuit 2710 may be implemented as one or more processors, one or more controllers, and / or other structures configured to execute executable code. Examples of processing circuit 2710 may include a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field programmable gate array (FPGA) or other programmable logic component designed to perform the functions described herein, discrete gate or transistor logic, discrete hardware components, or any combination thereof. A general-purpose processor may include a microprocessor, as well as any conventional processor, controller, microcontroller, or state machine. Processing circuit 2710 may also be implemented as a combination of computing components, such as a combination of DSP and microprocessor, several microprocessors, one or more microprocessors cooperating with a DSP core, ASIC and microprocessor, or any other number of variations. These examples of processing circuit 2710 are for illustration, and other suitable configurations falling within the scope of the present disclosure are also contemplated.

[0276] According to one or more aspects of the present disclosure, the processing circuit 2710 may be adapted to perform any or all of the features, processes, functions, operations, and / or routines for any or all of the devices described herein. As used herein, the term "adapted" in relation to the processing circuit 2710 may refer to the processing circuit 2710 being configured, employed, implemented, and / or programmed (one or more of the above) to perform specific processes, functions, operations, and / or routines according to the various features described herein.

[0277] According to at least one example of the apparatus 2700, the processing circuit 2710 may include one or more of a receiving circuit / module 2722, a temporary identifier adding circuit / module 2724, a storage circuit / module 2726, a temporary identifier removing circuit / module 2728, a data packet forwarding circuit / module 2730, a packet processing circuit / module 2732, a packet encryption and protection circuit / module 2734, a context reconstruction / removal circuit / module 2738, and a network address obtaining / releasing circuit / module 2740, which are adapted to perform any or all of the features, processes, functions, operations, and / or routines described herein (e.g., with respect to Fig.28 and 29).

[0278] The receiving circuit / module 2722 may include a circuit system and / or instructions (e.g., receiving instructions 2742 stored on the storage medium 2704) adapted to perform several functions related to, for example, the following operations: receiving a first data packet with a request to communicate with a network from a client device, receiving a first data packet and an encrypted client device context from the client device, receiving a second data packet from a network function implemented at a network node, and receiving a message from the client device including a resource establishment request and at least one encrypted client device context of one or more encrypted client device contexts.

[0279] The temporary identifier adding circuit / module 2724 may include circuitry and / or instructions (eg, temporary identifier adding instructions 2744 stored on the storage medium 2704) adapted to perform several functions related to, for example, adding a temporary identifier to a first data packet.

[0280] The storage circuit / module 2726 may include circuit systems and / or instructions (e.g., stored instructions 2746 stored on the storage medium 2704) adapted to perform several functions related to, for example, the following operations: storing a temporary identifier for a client device. For example, the temporary identifier may be a cellular cell radio network temporary identifier (C-RNTI). In one aspect, the temporary identifier is stored for a predetermined period of time.

[0281] Temporary identifier removal circuit / module 2728 may include circuitry and / or instructions (eg, temporary identifier removal instructions 2748 stored on storage medium 2704) adapted to perform several functions related to, for example, removing the temporary identifier in the second data packet.

[0282] The data packet forwarding circuit / module 2730 may include a circuit system and / or instructions (e.g., data packet forwarding instructions 2750 stored on the storage medium 2704) adapted to perform several functions related to, for example, the following operations: determining a first network node to which a first data packet is intended, forwarding the first data packet to a service network when decryption and verification are successful, determining a network function to which the request is to be forwarded, wherein the determination is preconfigured at the network access node, determining a client device to which a second data packet is to be forwarded, and forwarding the second data packet to the client device.

[0283] The packet processing circuit / module 2732 may include circuit systems and / or instructions (e.g., packet processing instructions 2752 stored on storage medium 2704) adapted to perform several functions related to, for example, the following operations: decrypting and authenticating a first data packet based on a security context.

[0284] The packet encryption and protection circuit / module 2734 may include circuit systems and / or instructions (e.g., packet encryption and protection instructions 2754 stored on the storage medium 2704) adapted to perform several functions related to, for example, the following operations: encrypting or integrity protecting a packet using a user plane (UP) client device key, decrypting and verifying a first data packet based on a security context, and / or encrypting or integrity protecting a second data packet using a user plane encryption key or a user plane integrity protection key.

[0285] Context reconstruction / removal circuitry / module 2738 may include circuitry and / or instructions (e.g., context reconstruction / removal instructions 2758 stored on storage medium 2704) adapted to perform several functions related to, for example, obtaining a key (e.g., key K) for an encrypted client device context associated with a client device; CDC-IoTF-U ), using the key to obtain a security context about the client device from the encrypted client device context, reconstructing at least one context from the encrypted client device context, reconstructing at least a portion of the context based on at least one of the one or more encrypted client device contexts and the usage information, removing at least one context, and / or maintaining the at least a portion of the context for a first threshold time period when the usage information indicates reduced data transmission or maintaining the at least a portion of the context for a second threshold time period when the usage information indicates burst data transmission, the second threshold time period being greater than the first threshold time period.

[0286] The network address obtain / release circuit / module 2740 may include a circuit system and / or instructions (e.g., network address obtain / release instructions 2760 stored on the storage medium 2704) adapted to perform several functions related to, for example, the following operations: obtaining a network address for the client device in response to the message, transmitting the network address to the client device, transmitting a resource release request message from the client device to the gateway, wherein the resource release request message enables the gateway to release one or more resources for the client device, and / or transmitting a resource release request message to the gateway when a timer expires before a transmission from the client device to the network or before a transmission from the network to the client device, wherein the resource release request message enables the gateway to release one or more resources for the client device.

[0287] As mentioned above, the instructions stored by the storage medium 2704, when executed by the processing circuit 2710, cause the processing circuit 2710 to perform one or more of the various functional and / or process operations described herein. For example, the storage medium 2704 may include one or more of the following: receiving instructions 2742, temporary identifier adding instructions 2744, storing instructions 2746, temporary identifier removing instructions 2748, data packet forwarding instructions 2750, packet processing instructions 2752, packet encryption and protection instructions 2754, context reconstruction / removal instructions 2758, and network address acquisition / release instructions 2760.

[0288] Fig.28 2800 is a flowchart illustrating a method for communicating in an IoT network architecture according to various aspects of the present disclosure. The method may be performed by a device such as a network access node (e.g., Figure 1 The network access node 104 or Fig. 27 Device 2700) is executed.

[0289] The apparatus receives a first data packet with a request to communicate with a network from a client device (2802). The apparatus stores a temporary identifier for the client device (2804). For example, the temporary identifier may be a cellular cell radio network temporary identifier (C-RNTI), and the temporary identifier may be stored for a predetermined period of time. The apparatus adds the temporary identifier to the first data packet (2806).

[0290] The device determines a first network node to which the first data packet is intended (2808). The device determines a network function to which the request is to be forwarded, wherein the determination is preconfigured at the network access node (2810). The device forwards the first data packet to the network function (2812).

[0291] The apparatus receives a second data packet from a network function implemented at a network node (2814). The apparatus determines a client device to which the second data packet is to be forwarded (2816). In one aspect, the apparatus determines the client device to which the second data packet is to be forwarded by identifying the client device from a temporary identifier in the second data packet. The apparatus removes the temporary identifier in the second data packet (2818). The apparatus forwards the second data packet to the client device (2820).

[0292] Figure 29 (including Fig.29A and 29B ) is a flowchart 2900 illustrating a method for communicating in a network according to various aspects of the present disclosure. The method may be performed by a device such as a network access node (e.g., Fig.12 The network access node 1204 or Fig. 27 It should be understood that Fig. 27 Operations indicated by dashed lines in the figure represent optional operations.

[0293] The apparatus obtains a key (eg, a key K) for an encrypted client device context associated with the client device. CDC-IoTF-U )(2902). The apparatus receives a first data packet (e.g., a UL data packet) and an encrypted client device context (2904) from a client device. The apparatus obtains a security context about the client device from the encrypted client device context using the key (2906). The apparatus decrypts and / or verifies the first data packet based on the security context (2908). The apparatus forwards the first data packet to a service network (2910) when the decryption and verification are successful. The apparatus receives a second data packet (e.g., a DL data packet) from a server or a packet data network gateway (2912). The apparatus encrypts or integrity protects the second data packet using a user plane encryption key or a user plane integrity protection key (2914). The apparatus forwards the second data packet to the client device (2916). The apparatus removes at least one context (2918). The apparatus receives a message (2920) from the client device including a resource establishment request and at least one encrypted client device context from one or more encrypted client device contexts. The apparatus obtains a network address for the client device in response to the message (2922). The apparatus transmits the network address (2924) to the client device. In one aspect, the device transmits a resource release request message (2926) to the gateway when the timer expires before the transmission from the client device to the network or before the transmission from the network to the client device. In one aspect, the resource release request message enables the gateway to release one or more resources for the client device. In another aspect, the device receives a resource release request message (2928) from the client device. In such aspects, the device transmits the resource release request message from the client device to the gateway (2930). In one aspect, the resource release request message enables the gateway to release one or more resources for the client device. In some aspects, operation 2926 and operations 2928 and 2930 may be performed alternatively. For example, if operation 2926 is performed, operations 2928 and 2930 may not be performed. As another example, if operations 2928 and 2930 are performed, operation 2926 may not be performed.

[0294] One or more components, steps, features and / or functions illustrated in the accompanying drawings may be rearranged and / or combined into a single component, step, feature or function, or implemented in several components, steps or functions. Additional elements, components, steps, and / or functions may also be added without departing from the novel features disclosed herein. The devices, equipment and / or components illustrated in the accompanying drawings may be configured to perform one or more methods, features, or steps described herein. The novel algorithms described herein may also be efficiently implemented in software and / or embedded in hardware.

[0295] It should be understood that the specific order or hierarchy of the steps in the disclosed methods is an illustration of an exemplary process. Based on design preferences, it should be understood that the specific order or hierarchy of the steps in these methods can be rearranged. The attached method claims present the elements of the various steps in a sample order and are not meant to be limited to the specific order or hierarchy presented unless specifically described herein. Additional elements, components, steps, and / or functions may also be added or not utilized without departing from the present disclosure.

[0296] Although features of the present disclosure may have been discussed with respect to certain implementations and drawings, all implementations of the present disclosure may include one or more of the advantageous features discussed herein. In other words, although one or more implementations may be discussed as having certain advantageous features, one or more of such features may also be used in accordance with any of the various implementations discussed herein. In a similar manner, although exemplary implementations may be discussed herein as device, system, or method implementations, it should be understood that such exemplary implementations may be implemented in a variety of devices, systems, and methods.

[0297] In addition, it is noted that at least some implementations are described as processes depicted as flow charts, flow diagrams, structure diagrams, or block diagrams. Although the flow charts may describe each operation as a sequential process, many of these operations can be performed in parallel or concurrently. In addition, the order of these operations can be rearranged. The process terminates when its operation is completed. In some aspects, the process may correspond to a method, function, procedure, subroutine, subprogram, etc. When the process corresponds to a function, its termination corresponds to the function returning to the caller function or main function. One or more of the various methods described herein may be implemented in part or in whole by programming (e.g., instructions and / or data) that can be stored in a machine-readable, computer-readable and / or processor-readable storage medium and executed by one or more processors, machines and / or devices.

[0298] Those skilled in the art will further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in conjunction with the implementations disclosed herein may be implemented as hardware, software, firmware, middleware, microcode, or any combination thereof. To clearly illustrate this interchangeability, various illustrative components, blocks, modules, circuits, and steps have been generally described above in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system.

[0299] Within the present disclosure, the wording "exemplary" is used to mean "serving as an example, instance, or illustration". Any implementation or aspect described herein as "exemplary" is not necessarily to be construed as superior or superior to other aspects of the present disclosure. Likewise, the term "aspect" does not require that all aspects of the present disclosure include the discussed features, advantages, or modes of operation. The term "coupled" is used herein to refer to a direct or indirect coupling between two objects. For example, if object A physically contacts object B, and object B contacts object C, objects A and C may still be considered to be coupled to each other - even if they are not in direct physical contact with each other. For example, a first die may be coupled to a second die in a package, even if the first die is never in direct physical contact with the second die. The terms "circuit" and "circuitry" are used broadly and are intended to include both hardware implementations of electronic devices and conductors, which when connected and configured enable the functions described in the present disclosure to be performed without limitation on the type of electronic circuits, and software implementations of information and instructions, which when executed by a processor enable the functions described in the present disclosure to be performed.

[0300] As used herein, the term "determine" encompasses a wide variety of actions. For example, "determine" may include calculating, computing, processing, deriving, studying, searching (e.g., searching in a table, database, or other data structure), ascertaining, and similar actions. Moreover, "determine" may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), and similar actions. Similarly, "determine" may also include parsing, selecting, choosing, establishing, and similar actions. As used herein, the term "obtain" may include one or more actions, including but not limited to receiving, generating, determining, or any combination thereof.

[0301] The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. Various modifications to these aspects will be readily apparent to those skilled in the art, and the universal principles defined herein may be applied to other aspects. Therefore, the claims are not intended to be limited to the various aspects shown herein, but should be granted the full scope consistent with the language of the claims, wherein the singular reference to the element is not intended to mean "there is and only one" - unless specifically stated, but intended to mean "one or more". Unless specifically stated otherwise, the term "some" refers to "one or more". The phrase "at least one" of a list of items refers to any combination of these items, including a single member. As an example, "at least one of a, b or c" is intended to cover: a; b; c; a and b; a and c; b and c; and a, b and c. The elements of the various aspects described throughout this disclosure are all structurally and functionally equivalent schemes currently or hereafter known to those of ordinary skill in the art, and are expressly incorporated herein by reference, and are intended to be covered by the claims. In addition, nothing disclosed herein is intended to be contributed to the public, regardless of whether such disclosure is explicitly described in the claims. No element of a claim is to be construed under 35 USC §112, sixth paragraph, unless the element is expressly recited using the phrase "means for" or, in the case of a method claim, the element is recited using the phrase "step for."

[0302] Accordingly, the various features associated with the examples described herein and shown in the drawings may be implemented in different examples and implementations without departing from the scope of the present disclosure. Therefore, although certain specific configurations and arrangements have been described and shown in the drawings, such implementations are merely illustrative and do not limit the scope of the present disclosure, as various other additions and modifications to the described implementations, as well as deletions, will be apparent to one of ordinary skill in the art. Therefore, the scope of the present disclosure is determined solely by the literal language of the appended claims and their legal equivalents.

Claims

1. A method for a network device, include: receiving, via a network access node, from a client device a request to communicate with a network through the network device; establishing at least one context with the client device, the at least one context comprising network state information associated with a connection between the client device and the network, wherein the network state information comprises at least an encryption algorithm, an encryption key, an integrity protection algorithm, an integrity protection key, or a combination thereof; generating one or more encrypted client device contexts, wherein the one or more encrypted client device contexts enable reconstruction of the at least one context for communicating with the client device at one or more of the network access node, the network device, and the network; as well as The one or more encrypted client device contexts are transmitted to the client device via the network access node.

2. The method of claim 1, further comprising determining to generate the one or more encrypted client device contexts, wherein the determination is based on at least one of: encrypted client device context usage information indicated in the request, a subscription of the client device, a policy, or a combination thereof. 3 . The method of claim 1 , wherein the one or more encrypted client device contexts include a first context to be used for data-related communications and a second context to be used for control-related communications.

4. The method of claim 1, further comprising: include: receiving a control packet and an encrypted client device context from the client device; verifying the encrypted client device context received from the client device; reconstructing the at least one context from the encrypted client device context; processing the control packet using the at least one context, wherein the processing comprises at least one of: authenticating the control packet, decrypting the control packet, or a combination thereof using the at least one context; storing a temporary identifier for downlink packets for the client device; as well as The payload portion of the control packet is forwarded to an application server or a packet data network gateway.

5. The method of claim 4, wherein the encryption key comprises at least a control plane encryption key, a user plane encryption key, or a combination thereof, and the integrity protection key comprises at least a user plane integrity protection key, a control plane integrity protection key, or a combination thereof.

6. The method of claim 4, wherein verifying the encrypted client device context include: determining whether the encrypted client device context has expired; generating one or more new encrypted client device contexts when a previous encrypted client device context has expired; as well as The one or more new encrypted client device contexts are transmitted to the client device when the previous encrypted client device context has expired.

7. The method of claim 4, further comprising: include: receiving a control packet from a second client device; requesting a context about the second client device from a second network device, the request including a control plane encrypted client device context; receiving the context about the second client device from the second network device; generating a new encrypted client device context; as well as The new encrypted client device context is transmitted to the second client device.

8. The method of claim 4, wherein verifying the encrypted client device context comprises determining a key for verifying the encrypted client device context.

9. The method of claim 4, further comprising: include: removing the at least one context; receiving, from the client device, a message including a resource establishment request and at least one of the one or more encrypted client device contexts; obtaining a network address for the client device in response to the message; as well as The network address is transmitted to the client device.

10. The method of claim 9, further comprising: include: A resource release request message is transmitted to a gateway when a timer expires prior to transmission from the client device to the network or prior to transmission from the network to the client device, wherein the resource release request message enables the gateway to release one or more resources for the client device.

11. The method of claim 1, wherein the network device is an Internet of Things (IoT) network node, and wherein the request to communicate with the network is a request to communicate through the IoT network node.

12. A network device, include: a network communication interface configured to communicate with one or more network entities including a network access node; as well as a processing circuit coupled to the network communication interface, the processing circuit being configured to: receiving, via the network access node, from a client device a request to communicate with a network through the network device; establishing at least one context with the client device, the at least one context comprising network state information associated with a connection between the client device and the network, wherein the network state information comprises at least an encryption algorithm, an encryption key, an integrity protection algorithm, an integrity protection key, or a combination thereof; generating one or more encrypted client device contexts, wherein the one or more encrypted client device contexts enable reconstruction of the at least one context for communicating with the client device at one or more of the network access node, the network device, and the network; as well as The one or more encrypted client device contexts are transmitted to the client device via the network access node.

13. The network device of claim 12, wherein the network device is an Internet of Things (IoT) network node.

14. A method for a network device, include: obtaining a key for an encrypted client device context associated with the client device; receiving, via a network access node, a first data packet and the encrypted client device context from the client device for forwarding to a serving network; obtaining a security context about the client device from the encrypted client device context using the key; decrypting and authenticating the first data packet based on the security context; as well as When the decryption and verification are successful, the first data packet is forwarded to the service network.

15. The method of claim 14, wherein obtaining the security context comprises decrypting the encrypted client device context based on the key, and wherein the security context comprises at least a user plane encryption key, a user plane integrity protection key, or a combination thereof.

16. The method of claim 14, wherein the security context comprises a user plane encryption key and a user plane integrity protection key, the method further comprising: include: receiving a second data packet from a server or a packet data network gateway; determining the network access node to which the second data packet is forwarded; adding a temporary identifier to the second data packet, the temporary identifier enabling the network access node to determine the client device; Encrypting or integrity protecting the second data packet using the user plane encryption key or the user plane integrity protection key; as well as The second data packet is forwarded to the client device via the network access node.

17. A network device, include: a network communication interface configured to communicate with one or more network entities including a network access node and at least one serving network entity; as well as a processing circuit coupled to the network communication interface, the processing circuit being configured to: obtaining a key for an encrypted client device context associated with the client device; receiving, via the network access node, a first data packet and the encrypted client device context from the client device for forwarding to the at least one serving network entity; obtaining a security context about the client device from the encrypted client device context using the key; decrypting and authenticating the first data packet based on the security context; as well as The first data packet is forwarded to the at least one serving network entity when the decryption and verification are successful.

18. The network device of claim 17, wherein the processing circuit configured to obtain the security context is further configured to: The encrypted client device context is decrypted based on the key, wherein the security context includes at least a user plane encryption key or a user plane integrity protection key.

19. The network device of claim 17, wherein the security context comprises a user plane encryption key and a user plane integrity protection key, wherein the processing circuit is further configured to: receiving a second data packet from a server or a packet data network gateway; determining the network access node to which the second data packet is forwarded; adding a temporary identifier to the second data packet, the temporary identifier enabling the network access node to determine the client device; Encrypting or integrity protecting the second data packet using the user plane encryption key or the user plane integrity protection key; as well as The second data packet is forwarded to the client device via the network access node.

20. The network device of claim 17, wherein the network device is an Internet of Things (IoT) network node.

Images