System and method for accessing network services in wireless communication network

Abstract

The present disclosure provides systems and methods for accessing network services in a wireless communication network. According to one aspect, a method performed by an access manager, AM, is provided. The method includes receiving, from a device, a request for a network service (NS). The request includes information that identifies the NS and an NS context identifier (identity, ID). The method further includes processing the request according to a network service access protocol (NSAP) context on the AM, and processing the request according to a network service access protocol (NSAP) context on the AM. The method further comprises the step of selecting a network service function (SNF), and the method further comprises the step of selecting a network service function (SNF). The method also includes sending a service request notification to the NSF, the service request notification including the information identifying the NS and the NS context ID. The method also includes receiving a service response from the NSF. The method also includes sending a response message including the NS context ID and the service response to the device.

Description

Technical Field

[0001] The present disclosure relates to the field of communication networks, and more particularly to a system and method for accessing network services in a wireless communication network. Background Art

[0002] In a wireless communication network (e.g., a 5G wireless network), a user equipment (UE) has a single non-access stratum (NAS) interface in the core network (CN). The NAS interface terminates at a network function in the CN, such as an access and mobility management function (AMF). The UE communicates with one or more CN functions through a NAS termination point (e.g., AMF), and the communication can be protected using NAS security mechanisms. Therefore, the UE's communication with one or more CN functions relies on a NAS termination point, i.e., a CN function, which acts as a relay between the UE and the CN function. This dependency will unnecessarily limit the UE's ability to communicate with the one or more CN functions.

[0003] Although consideration has been given to UE communicating with multiple CN functions without relying on a CN relay function, such efforts are insufficient, especially in terms of efficient mechanisms to support NAS security, such as whether different NAS security parameters should be used for different CN functions, and how NAS security parameters should be distributed and updated.

[0004] In addition to the challenges involved in improving UE communications with multiple CN functions, the potential availability of network services provided by the radio access network (RAN) also brings additional challenges. For example, how can the UE communicate with network functions in both the CN and the RAN. In addition, whether such UE communications should be protected, and if so, how to protect such UE communications, these are challenges that need attention.

[0005] Therefore, there is a need for a system and method for accessing network services in a wireless communication network that eliminates or reduces one or more limitations of the prior art.

[0006] The purpose of providing this background information is to disclose information believed by the applicant to be potentially relevant to the present invention. It is not necessary nor should it be construed that any of the above information constitutes prior art to the present invention. Summary of the invention

[0007] The present disclosure provides a system and method for accessing network services in a wireless communication network. According to one aspect, a method is provided. The method includes: an access manager (AM) receives a first request for a network service (NS) from a radio access network (RAN) node, the first request including information identifying the NS and an NS context identifier (ID) identifying the NS context; the method also includes: the AM selects a network service function (SNF) according to the first request. The method also includes: the AM sends a service request notification to the NSF, the service request notification including the information in the first request. The method also includes: the AM receives a service response from the NSF, the service response corresponds to the service request notification and indicates whether the information in the first request to the NS has been accepted. The method also includes: the AM sends a response message to the RAN node, the response message includes the NS context ID and an encrypted service response, wherein the encrypted service response is obtained by encrypting the service response.

[0008] In some embodiments, the first request to the NS may include one or more of: a service name or ID, a device ID, a slice ID, an application ID, a data network ID, one or more NS operations to be performed for the NS context identified by the NS context ID, and an ID of each of the one or more NS operations.

[0009] In some embodiments, the first request to the NS is obtained by: the RAN node re-encrypts the second request according to the NSAP processing rules of the network service access protocol (NSAP) context on the RAN node using a public key associated with the AM. The method may also include: before selecting the NSF, the AM decrypts the first request using a private key included in the NSAP context on the AM.

[0010] In some embodiments, the second request is sent by the device to the RAN node, the second request is encrypted using a public key of the device according to an NSAP processing rule of an NSAP context on the device, and the NSAP context on the device is associated with the NS context ID.

[0011] In some embodiments, the AM selecting the NSF according to the first request includes: the AM sending a third request to a network binding function (NBF) to identify the NSF, the third request including the NS context ID; and the AM receiving a response indicating the NSF from the NBF.

[0012] In some embodiments, the AM selects the NSF according to the request, including: the AM sends a third request to a network registry function (NRF) to identify the NSF, the third request including the location of the device and NS information; the AM receives a response from the NRF indicating the NSF and the location of the NSF.

[0013] In some embodiments, the AM selects the NSF according to the first request, including: the AM sends a third request to the network function, the third request including any one of the device's location, NS information, and NS context ID; and the AM receives a response from the network function indicating the NSF and the location of the NSF.

[0014] In some embodiments, the AM selects the NSF based on the first request, including: selecting the NSF based on one or more of the following: network services provided by the NSF and identified in the NS information; a service area of ​​the location of the coverage device of the NSF; the location of the NSF; the NSF belongs to a network slice identified in the NS information; the NSF is used to provide services for applications, subsystems or dedicated network services identified in the NS information.

[0015] In some embodiments, the service response includes one or more of the following: an NS context ID, an NS session ID, a first indication indicating that the NS session identified by the NS session ID is a newly created NS session, a second indication indicating that the NS session requires one or more NSAP security parameters, and routing information used by the NS session to reach the NSF.

[0016] In some embodiments, the encrypted service response is obtained in the following manner: the AM encrypts the service response according to the NSAP context on the AM using the AM's key.

[0017] In some embodiments, the response message includes a command indicating whether to apply NSAP security to the NS context identified by the NS-context ID.

[0018] In some embodiments, the method further includes: the AM applies the NSAP security parameters to the NS context based on the location determination of the NSF; and the AM allocates the NSAP security parameters to support secure communication between the device and the NSF, the communication being related to the NS context.

[0019] In some embodiments, the NSF is located in one of: a core network (CN) of the wireless communication network; a RAN of the wireless communication network, and is outside the area covered by the RAN node of the device.

[0020] In some embodiments, the NSAP security parameters include a device public key and a device private key, and the method further includes: the AM sends a device key message to the RAN node, the device key message including at least one of the device public key and the device private key.

[0021] In some embodiments, the method further comprises: the AM receiving an acknowledgement of receipt of the device key message from the RAN node.

[0022] In some embodiments, the device key message is encrypted with a key, and the method further includes: the AM negotiates the key with the device.

[0023] In some embodiments, the NSAP security parameters include an uplink (UL) re-encryption key associated with the NS session and a downlink (DL) re-encryption key associated with the device.

[0024] In some embodiments, the method also includes: the AM sends a RAN configuration request to the RAN node, the RAN configuration request including one or more of the following: NS context ID, NS session ID, NSF ID or address, routing information for reaching the NSF, a command indicating whether to apply NSAP security to the NS context, a UL re-encryption key, and a DL re-encryption key.

[0025] In some embodiments, the method further comprises: the AM receiving a RAN response from the RAN node, the RAN response indicating receipt of the RAN configuration request.

[0026] In some embodiments, the NSAP security parameters include an NSF public key and an NSF private key.

[0027] In some embodiments, the method further includes: the AM sends an NSF configuration request to the NSF, the NSF configuration request including one or more of the following: an ID of the RAN node, a command indicating whether to apply NSAP security to the NS context, an NSF public key, and an NSF private key.

[0028] In some embodiments, the method further includes: the AM receiving an NSF response from the NSF, the NSF response indicating that the NSF configuration request is received.

[0029] According to another aspect, a method is provided. The method includes: a device sends a second request for a network service (NS) to a radio access network (RAN) node, the second request including information identifying the NS and an NS context identifier (ID) identifying an NS context. The method includes: the device receives a network message, the network message including the NS context ID and a re-encrypted service response, the re-encrypted service response indicating whether the information in the second request has been accepted.

[0030] In some embodiments, the network message also includes a command indicating whether to apply network service access protocol (NSAP) security to the NS context.

[0031] In some embodiments, the method further includes: the device updates the NSAP context on the device according to the network message; the device performs secure communication with a network service function (NSF) according to the NSAP context on the device, wherein the secure communication is related to the NS context.

[0032] In some embodiments, the network message further includes one or more keys for supporting secure communication, the one or more keys including: a device public key and a device private key. In some embodiments, the method further includes: the device encrypting an uplink (UL) NSAP message using the device public key; and the device sending the encrypted UL NSAP message to the RAN node.

[0033] In some embodiments, the method further includes: the device receiving a re-encrypted downlink (DL) NSAP message from the RAN node; and the device decrypting the re-encrypted DL NSAP message using a device private key.

[0034] According to another aspect, a method is provided. The method includes: a radio access network (RAN) node receives a second request for a network service (NS) from a device, the second request including information identifying the NS and an NS context identifier (ID) identifying the NS context. The method also includes: the RAN node obtains the first request by encrypting the second request; the RAN node sends the first request for the NS to the AM. The method also includes: the RAN node receives a response message from the AM, the response message including the NS context ID and an encrypted service response, wherein the encrypted service response corresponds to the first request for the NS and indicates whether the first request for the NS has been accepted. The method also includes: the RAN node sends a network message to the device, the network message including the NS context ID and a re-encrypted service response, the re-encrypted service response being obtained by re-encrypting the encrypted service response.

[0035] In some embodiments, the first request is obtained by encrypting the second request according to the NSAP processing rules of the NASP context on the RAN node using a public key associated with the AM.

[0036] In some embodiments, the method also includes: the RAN node receives a RAN configuration request from the AM, the RAN configuration request including one or more of the following: NS context ID, NS session ID, NSF ID or address, routing information for reaching the NSF, a command indicating whether to apply NSAP security to the NS context, a UL re-encryption key, and a DL re-encryption key.

[0037] In some embodiments, the method further includes: the RAN node receives a device key message from the AM, the device key message includes at least one of the following: a device public key and a device private key. The method further includes: the RAN node sends a network message to the device, the network message includes one or more of the following: an NS context ID, a command indicating whether to apply a network service access protocol (NSAP) security to a network service (NS) context identified by the NS context ID, a device public key, and a device private key.

[0038] In some embodiments, the method further comprises: the RAN node sending an acknowledgement of receipt of the device key message to the AM.

[0039] In some embodiments, the method further includes: the RAN node receives an encrypted UL NSAP message from the device. The method further includes: the RAN node re-encrypts the encrypted UL NSAP message using a UL re-encryption key; and the RAN node sends the re-encrypted UL NSAP message to the NSF.

[0040] In some embodiments, the method further includes: the RAN node receives the encrypted DL NSAP message from the NSF. The method further includes: the RAN node re-encrypts the encrypted DL NSAP message using a DL re-encryption key; and the RAN node sends the re-encrypted DL NSAP message to the device.

[0041] According to another aspect, a method is provided. The method includes: a network service function (NSF) receives a service request notification from an access manager (AM), the service request notification including information identifying a network service (NS) and an NS context identifier (ID) identifying an NS context. The method also includes: sending a service response, the service response corresponding to the service request notification and indicating whether the service request notification has been accepted.

[0042] In some embodiments, the method further includes: the NSF updates the NSAP context on the NSF according to the service request notification; the NSF performs secure communication with the device according to the NSAP context on the NSF, wherein the secure communication is related to the NS context.

[0043] In some embodiments, the service request notification also includes one or more of the following: a command indicating whether to apply network service access protocol (NSAP) security to the NS context identified by the NS context ID, an NSF public key for supporting secure communications, an NSF private key for supporting secure communications, and an ID of a radio access network (RAN) node serving the device.

[0044] In some embodiments, the NSF performing secure communication with the device includes: the NSF encrypting a downlink (DL) NSAP message using an NSF public key; and the NSF sending the encrypted DL NSAP message to the RAN node.

[0045] In some embodiments, the NSF performing secure communication with the device includes: the NSF receiving a re-encrypted uplink (UL) NSAP message from the RAN node; and the NSF decrypting the re-encrypted UL NSAP message using the NSF private key.

[0046] In some embodiments, the method further includes: the NSF receives a service request notification from the AM, the service request notification including one or more of the following: NS information and NS operation instructions.

[0047] According to another aspect, a method is provided. The method includes: a device sends a second request for a network service (NS) to a radio access network (RAN) node, the second request including information identifying the NS and an NS context identifier (ID) identifying the NS context. The method also includes: the RAN node obtains the first request by encrypting the second request; the RAN node sends the first request for the NS to an access manager (AM). The method also includes: the AM selects a network service function (NSF) according to the first request; the AM sends a service request notification to the NSF, the service request notification including the information in the first request. The method also includes: the AM receives a service response from the NSF, the service response corresponds to the service request notification and indicates whether the information in the first request for the NS has been accepted; the AM sends a response message to the RAN node, the response message including the NS context ID and the encrypted service response, wherein the encrypted service response is obtained by encrypting the service response. The method also includes: the RAN node sends a network message to the device, the network message including the NS context ID and the re-encrypted service response, the re-encrypted service response is obtained by re-encrypting the encrypted service response.

[0048] According to another aspect, a method is provided. The method includes: a radio access network (RAN) node receives a request message for a network service (NS) from a device, the NS being associated with an NS context, the request message including information identifying the NS and an NS context identifier (ID) identifying the NS context. The method also includes: the RAN node determines an NS session associated with the NS context ID based on a network service access protocol (NSAP) context on the RAN node. The method also includes: the RAN node sends the request message to a network service function (NSF) using the NS session. The method also includes: the RAN node receives a response message from the NSF, the response message including the NS context and indicating that the request for the NS has been accepted. The method also includes: the RAN node sends the response message to the device.

[0049] In some embodiments, the request message also includes one or more of the following: a service name or ID, a device ID, a slice ID, an application ID, a data network ID, one or more NS operations to be performed for the NS context identified by the NS context ID, and an ID of each of the one or more NS operations.

[0050] In some embodiments, the request message is encrypted using a public key of the device, and the method further includes: the RAN node re-encrypts the encrypted request message using an uplink (UL) re-encryption key based on an NSAP context on the RAN node, wherein the NSAP context on the RAN node indicates that NSAP security is applied to the request message.

[0051] In some embodiments, the method further comprises: the RAN node receiving a first indication from the device, the first indication indicating that the request message is encrypted.

[0052] In some embodiments, the response message is encrypted by a public key of the NSF, and the method further includes: the RAN node re-encrypts the encrypted response message using a downlink (DL) re-encryption key based on an NSAP context on the RAN node, wherein the NSAP context on the RAN node indicates that NSAP security is applied to the response message.

[0053] In some embodiments, the method further comprises: the RAN node receiving a second indication from the device, the second indication indicating that the response message is encrypted.

[0054] According to another aspect, a method is provided. The method includes: an access manager (AM) receives the following instructions: relocating a serving network service function (NSF) of a network service (NS) context from an old NSF to a new NSF; the AM reselects or selects a new NSF to serve the NS context. The method also includes: the AM sends a first relocation notification to the new NSF, the first relocation notification includes an NS context identifier (ID) identifying the NS context and information identifying the old NSF; the AM receives a first relocation response from the new NSF. The method also includes: the AM sends a first network message to a device associated with the NS context, the first network message includes a first command, and the first command indicates to suspend communications associated with the NS context ID.

[0055] In some embodiments, AM reselects or selects a new NSF to serve the NS context, including: AM sends a request to the network registry function (NRF) to identify the new NSF, the request including the location of the device and NS information; AM receives a response from the NRF indicating the new NSF and the location of the new NSF.

[0056] In some embodiments, the AM receives a first relocation response from the new NSF, including: the AM receives one or more of the following from the new NSF: an NS session ID associated with the NS context ID, a first indication indicating whether the NS session identified by the NS session ID is a newly created NS session, a second indication indicating that the NS session requires one or more NSAP security parameters, and routing information for the NS session.

[0057] In some embodiments, the location of the new NSF is different from the location of the old NSF, and the method further includes: the AM determines to apply NSAP security parameters to the NS context; the AM allocates NSAP security parameters to support secure communication between the device and the new NSF, wherein the communication is related to the NS context.

[0058] In some embodiments, the AM assigning NSAP security parameters includes: the AM assigning an uplink (UL) re-encryption key associated with the NS session and a downlink (DL) re-encryption key associated with the device. The method also includes: the AM sending a RAN configuration request to the RAN node, the RAN configuration request including one or more of the following: NS context ID, NS session ID, new NSF ID or address, a first NSAP command indicating whether to apply NSAP security to the NS context, routing information for reaching the new NSF, UL re-encryption key, and DL re-encryption key; the AM receives a RAN response from the RAN node, the RAN response indicating receipt of the RAN configuration request.

[0059] In some embodiments, the AM assigning NSAP security parameters includes: the AM assigning an NSF public key and an NSF private key. The method also includes: the AM sending an NSF configuration request to the new NSF, the NSF configuration request including one or more of the following: an ID of the RAN node, a second NSAP command indicating whether to apply NSAP security to the NS context, an NSF public key, and an NSF private key; the AN receiving an NSF response from the new NSF, the NSF response indicating receipt of the NSF configuration request.

[0060] In some embodiments, the method further includes: the AM sends a second relocation notification to the old SMF, the second relocation notification includes the NS context ID and information about the new NSF; the AM receives a second relocation response from the old SMF, the second relocation response indicates that the NS context has been transferred to the new NSF. The method further includes: the AM sends a second network message to the device, the second network message includes a second command, and the second command indicates to resume communication associated with the NS context ID.

[0061] According to another aspect, a system is provided. The system includes a device, an access manager (AM), and a radio access network (RAN) node. The device is used to: send a second request for a network service (NS) to the RAN node, the second request including information identifying the NS and an NS context identifier (ID) identifying the NS context. The RAN node is used to: obtain a first request by encrypting the second request; and send the first request for the NS to the AM. The AM is used to: select a network service function (NSF) according to the first request; and send a service request notification to the NSF, the service request notification including the information in the first request. The AM is also used to: receive a service response from the NSF, the service response corresponds to the service request notification and indicates whether the information in the first request for the NS has been accepted; and send a response message to the RAN node, the response message including the NS context ID and the encrypted service response, wherein the encrypted service response is obtained by encrypting the service response. The RAN node is also used to: send a network message to the device, the network message including the NS context ID and the re-encrypted service response, the re-encrypted service response is obtained by re-encrypting the encrypted service response.

[0062] According to another aspect, an apparatus is provided. The apparatus includes at least one processor and at least one machine-readable medium storing executable instructions. When the executable instructions are executed by the at least one processor, the executable instructions configure the apparatus to perform one or more of the methods described herein.

[0063] According to another aspect, a computer device is provided. The computer device includes a non-transitory computer-readable medium having instructions stored therein. When the instructions are executed by a computer processor, the instructions cause the computer device to perform one or more of the methods described herein.

[0064] According to one aspect, a chip is provided, wherein the chip includes a processor and a data interface, and the processor reads instructions stored in a memory by using the data interface to execute one or more of the methods described herein.

[0065] Other aspects of the present disclosure provide apparatus and systems for implementing the method according to the first aspect disclosed herein. For example, a wireless station and an access point may be configured with a machine-readable memory including instructions, which, when executed by a processor of these devices, configure the device to perform one or more of the methods and systems described herein.

[0066] Embodiments have been described above in conjunction with aspects of the present invention, and these embodiments may be implemented based on these aspects. It will be appreciated by those skilled in the art that embodiments may be implemented in conjunction with the aspects in which they are described, but may also be implemented together with other embodiments of this aspect. When the embodiments are mutually exclusive or contradictory, this will be apparent to those skilled in the art. Some embodiments may be described in conjunction with an aspect, but may also be applicable to other aspects, which will be apparent to those skilled in the art. BRIEF DESCRIPTION OF THE DRAWINGS

[0067] Further features and advantages of the present invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings, in which:

[0068] Figure 1 A wireless communication network according to one aspect is shown.

[0069] Figure 2 A network service access protocol (NSAP) layer is shown according to one aspect.

[0070] Figure 3 A network service access protocol (NSAP) message is shown according to one aspect.

[0071] Figure 4 An example of processing NSAP messages according to one aspect is shown.

[0072] Figure 5 A process for requesting a network service according to one aspect is shown.

[0073] Figure 6 Another process for requesting a network service according to one aspect is shown.

[0074] Figure 7 A process for NSF relocation according to one aspect is shown.

[0075] Figure 8 Devices are shown that can perform any or all of the operations of the above methods and features described herein, either explicitly or implicitly, according to various aspects of the present disclosure.

[0076] It should be noted that throughout the drawings, like features are identified by like reference numerals. DETAILED DESCRIPTION

[0077] In a wireless communication network (e.g., a 5G wireless network), a user equipment (UE) has a single non-access stratum (NAS) interface that terminates at a network function (e.g., access and mobility management function (AMF)) in a core network (CN). The NAS interface is supported by a radio access network (RAN), where the RAN forwards messages transmitted over the NAS interface. The UE can communicate with other CN functions (e.g., session management function (SMF), policy control function (PCF)), but the communication passes through or passes through a NAS termination point (e.g., AMF). Messages transmitted over the NAS interface can be protected using a NAS security mechanism, which is an end-to-end mechanism (between the UE and the NSA termination point). As can be appreciated by those skilled in the art, the RAN does not participate in the NSA security mechanism.

[0078] Direct communication between the UE and multiple CN functions has not been fully explored. "Direct" here may refer to communication that does not rely on a CN function to relay messages (e.g. relay by the AMF). Further research in determining efficient mechanisms to support NAS security may also be relevant. For example, whether different CN functions should use different NAS security parameters, and how NAS security parameters should be distributed and updated.

[0079] In addition to the challenges involved in improving UE communications with multiple CN functions, the potential availability of network services provided by the radio access network (RAN) also poses additional challenges. For example, the network may simultaneously provide RAN-provided network services (provided by RAN functions) and CN-provided network services (provided by CN functions). How the UE may communicate with these network functions is unclear. For example, whether such UE communications should be protected, and if so, how to protect such UE communications.

[0080] Figure 1A wireless communication network according to one aspect is shown. A wireless communication network 100 (communication network) may include a RAN 102 and a CN 104. The communication network may provide one or more network services to a device 106 (e.g., a user equipment (UE)) through one or more network service functions (NSF) in the communication network. The network services may include one or more of mobility management, session management, policy management, and other services. The NSF may include one or more of an AMF, an SMF, a PCF, and other service functions. In some aspects, the one or more NSFs may be functions in a control plane of the communication network 100.

[0081] In one aspect, each of the one or more NSFs may provide access to one or more of the one or more network services. The NSFs located in the CN 104 may be correspondingly referred to as CN NSFs. The CN 104 may include one or more CN NSFs, such as CN NSF1 108, CN NSF5 110, and CN NSF6 112.

[0082] The NSF located in the RAN 102 may be correspondingly referred to as a RAN NSF. The RAN 102 may include one or more RAN nodes, such as RAN node 1 114 and RAN node 2 116. The RAN nodes (e.g., RAN node 1 114 and RAN node 2 116) may include one or more RAN NSFs. Figure 1 , RAN Node 1 includes RAN NSF2 118, and RAN Node 2 116 includes RAN NSF3 120 and RAN NSF4 122, as shown.

[0083] At least one of the one or more NSFs may provide access management services, including managing device access to the network and selecting an NSF for the device to access network services. The at least one of the one or more NSFs may be referred to as an access manager (AM). As an NSF, the AM may be located in the CN or the RAN, as described herein.

[0084] The device 106 may connect to or access the communication network by connecting to a RAN node in the RAN 102, such as RAN node 2 116. The RAN node 116 is considered to be serving the device 106 and may be referred to as a serving RAN node for the device.

[0085] In some aspects, from the perspective of the device, the device 106 can use a single logical interface (as shown by the dashed line) to access the one or more network services. The single logical interface can be connected to one or more NSFs through a forking effect at a RAN node (e.g., RAN node 2 116), and the one or more NSFs provide access to the one or more network services. In the illustrated figure, the one or more NSFs include CN NSF1 108, CN NSF5 110, CN NSF6 112, RAN NSF2 118, RAN NSF3 120, and RAN NSF4 122.

[0086] According to some aspects, dynamic activation and deactivation of security processing on the logical interface can be performed based on the NSF location. In some aspects, when the communication on the logical interface is protected, the communication content is encrypted and cannot be read by the RAN or service RAN node. For example, the communication between the device 106 and any one of the one or more CN NSFs through the logical interface can be protected as needed, so that the content transmitted between the device and the one or more CN NSFs cannot be read by the RAN or service RAN node. Similarly, in some aspects, the communication between the device and the RAN NSF (e.g., RAN NSF2 118) that is not located in the service RAN node (RAN node 2 116) of the device can be protected, so that the content transmitted between the device and the RAN NSF cannot be read by the service RAN node. However, in some aspects, the communication between the device and the RAN NSF (e.g., RAN NSF3 120 or RAN NSF4 122) located in the service RAN node (e.g., RAN node 2 116) may not be protected, wherein the transmitted content can be read by the service RAN node.

[0087] On the one hand, it can provide protocol layers across devices, RAN nodes and NSF, such as Figure 2 shown. Figure 21. A network service access protocol (NSAP) layer according to one aspect is shown. The terms NSAP and NSAP layer may be used interchangeably herein. In some aspects, RAN node 202 may be similar to RAN node 1 114 or RAN node 2 116. In some aspects, RAN NSF 204 may be similar to RAN NSF2 118 (when RAN node 202 is similar to RAN node 1 114). In some aspects, when RAN node 202 is similar to RAN node 2 116, RAN NSF 204 may be similar to RAN NSF3 120 or RAN NSF4 122. In some aspects, CN NSF 206 may be similar to any one of CN NSF1 108, CN NFS5 110, or CN NSF6 112.

[0088] As shown, each of the device 106, the RAN node 202, the RAN NSF 204, and the CN NSF 206 may include a NSAP layer. The device 106 may have a NSAP layer 212, and the CN NSF 206 may have a NSAP layer 232. In some aspects, when the NSF (e.g., the RAN NSF 204) is located in a RAN node (e.g., the RAN node 202), the NSF (e.g., the RAN NSF 204) and the RAN node (e.g., the RAN node 202) may share the same NSAP layer 222. In some aspects, even though the RAN NSF 204 may be located in the RAN node 202, the RAN node 202 may have a different NSAP layer than the RAN NSF 204.

[0089] The NSAP layer runs protocols to enable communication between the device 106 and the NSF (e.g., CN NSF 206), which is related to the NS context. In some aspects, depending on where the NSF is located (e.g., in the RAN 103 or in the CN 104), the NSAP layer can be adapted between the access stratum (AS) and the non-access stratum (NAS).

[0090] The NSAP layer 222 may be viewed as an enhanced protocol layer in the RAN node 202. In some aspects, the NSAP layer in the device 106 and the CNNSF may be viewed as a replacement for the NAS layer.

[0091] As will be appreciated by those skilled in the art, in some aspects, the NSAP layer 212 may form part of a protocol stack at the device 106. The protocol stack of the device 106 may also include a radio resource control (RRC) layer 214, a packet data convergence protocol (PDCP) layer 215, a radio link control (RLC) layer 216, a medium access control (MAC) layer 217, and a physical (PHY) layer 218.

[0092] In some aspects, the NSAP layer 222 may form part of a protocol stack at the RAN node 202. The protocol stack at the RAN node 202 may also include an RRC layer 224, a PDCP layer 225, an RLC layer 226, a MAC layer 227, and a PHY layer 228.

[0093] In some aspects, the NSF may include a processing module for processing information received at the NSAP layer. For example, the RANNSF 204 may include a processing module 229 for processing information received at the NSAP layer 222. Similarly, the CN NSF 206 may include a processing module 233 for processing information received at the NSAP layer 232.

[0094] In some aspects, the device 106 can access network services on an NS context by communicating with an NSF that provides access to the network services. The NS context can be device-related and can be associated with a network service. The NSF can maintain the NS context and can be considered to serve the NS context.

[0095] When communicating with the NSF, NSAP messages are exchanged between the device and the NSF. Figure 3 NSAP message 300 may include one or more fields indicating one or more of: NS context ID 302, command 304, format 306, and NS message 308. In some aspects, the one or more fields indicating command 304, format 306, and 308 may be optional.

[0096] In some aspects, the field indicating the command 304 may be used to dynamically update NSAP layer behavior. For example, the NSF may send an NSAP message including a command indication to the device so that the device may perform one or more operations according to the command to modify the NSAP context locally at the device.

[0097] In some aspects, the NS message 308 may also include an NS context ID. The NS context ID may identify the NS context. The NS context may include information identifying the corresponding network service. In some aspects, the NS context may also include information identifying one or more of the following: related devices, related network slices, related system modules or service modules, related applications, related data sources, related data networks, etc. In some aspects, the format indication 306 may indicate whether the NS message 308 is in ciphertext or in plaintext.

[0098] In some aspects, when device 106 communicates with the NSF, NSAP messages are exchanged between the device and the NSF. In some aspects, NSAP messages originating from device 106 may be referred to as uplink (UL) messages, while NSAP messages originating from the NSF may be referred to as downlink (DL) messages.

[0099] In some aspects, the NSAP message may be transmitted between the device and the NSF via the device's serving RAN node. Thus, both UL messages (NSAP messages from the device to the NSF) and DL messages (NSAP messages from the NSF to the device) may be transmitted via the device's serving RAN node.

[0100] In some aspects, the NSAP message may be transmitted using a radio bearer and a NS session. In some aspects, the radio bearer may be a signaling radio bearer (SRB) or a data radio bearer (DRB). The radio bearer may be between the device and the serving RAN node, and the NS session may be between the serving RAN node and the NSF. In some aspects, one or both of the radio bearer or the NS session may or may not be dedicated to the device.

[0101] An NSF serving an NS context may be referred to as a serving NSF, wherein the NSF receives and processes a service request associated with the NS context.

[0102] In some aspects, the serving NSF may be located outside the serving RAN node, wherein the NS session may correspond to a communication tunnel (e.g., an Ethernet tunnel, an IP tunnel, an IP / UDP tunnel, an IP / TCP tunnel, an IP / SCTP tunnel) between the serving RAN node and the serving NSF. When the serving NSF is a CN NSF or a RAN NSF located outside the serving RAN node, the serving NSF may be considered to be located outside the serving RAN. In some aspects, the transport network layer may support the communication tunnel between the serving RAN node and the serving NSF.

[0103] In some aspects, the serving NSF may be located inside the serving RAN node, wherein the NS session may correspond to an internal transport mechanism of the RAN node. When the serving NSF is located at or within the serving RAN node (e.g., RAN node 202), the serving NSF (e.g., RAN NSF 204) may be considered to be located inside the serving RAN node. The internal transport mechanism of the RAN node may be used to send the NSAP message (or the NS message embedded in the NSAP message) from the NSAP layer down to a module or component (a part of the serving NSF) of the RAN node for processing, such as processing module 229.

[0104] In some aspects, the internal transmission mechanism may be related to transmitting messages through optical fiber, copper cable or bus. In some aspects, the internal transmission mechanism may be related to transmitting messages between processes or threads. In some aspects, the internal transmission mechanism may be related to transmitting messages through interrupts or function calls.

[0105] The NSAP layer (or NSAP) on devices, RAN nodes, and NSFs may maintain a protocol context which may be referred to as an NSAP context.

[0106] In some aspects, the NSAP context on the device may include information related to the security context. The information related to the security context may refer to the NSAP security context, which may also be referred to as NSAP security parameters. In some aspects, the NSAP security context may include one or more of the following: a public key, a private key, or a reference (e.g., an ID or index) pointing to or identifying a public key and a private key. The public key may be referred to as the public key of the device. Similarly, the private key may also be referred to as the private key of the device.

[0107] In some aspects, a public key may not necessarily be public (or known to the public). For example, a public key may be a secret key. In this case, the term "public" is used to distinguish the secret key from other keys (i.e., private keys). In some aspects, the public key and the private key may be the same.

[0108] In some aspects, the public key may be used to encrypt NS messages in UL NSAP messages originating from the device. In some aspects, the private key may be used to decrypt NS messages in DL NSAP messages received by the device.

[0109] In some aspects, the NSAP context on the device may also include information indicating one or more NS context IDs and one or more NSAP processing rules associated with each of the one or more NS context IDs. The one or more NSAP processing rules associated with the NS context ID may indicate how to process an NSAP message associated with the NS context ID. As described herein, the NS context ID identifies an NS context that may be associated with an NSAP message. In some aspects, the one or more NSAP processing rules may include a security indication indicating whether NSAP security is applied to the NSAP message associated with the NS context ID.

[0110] In some aspects, one or more NSAP processing rules of one NS context may be different from one or more NSAP processing rules of another NS context. For example, a first NS context may be associated with a first NSF and a second NS context may be associated with a second NSF. The first NS context may require that NSAP security should be applied to NSAP messages transmitted between the first NSF, while the second NS context may not have a similar requirement.

[0111] In some aspects, the NSAP context on the RAN node (e.g., RAN node 1 114, RAN node 2 116, or RAN node 202) may include information related to the security context. The information related to the security context may refer to the NSAP security context, which may also be referred to as NSAP security parameters. In some aspects, the information related to the security context may be based on each device (identified by a device ID). In some aspects, the security context information of each device may include a DL re-encryption key or a reference (e.g., an ID or index) pointing to or identifying a DL re-encryption key. The DL re-encryption key may be referred to as a DL re-encryption key of the device. In some aspects, the DL re-encryption key may be used to re-encrypt the NS message in the DL NSAP message, which originates from the NSF and whose destination is the device.

[0112] In some aspects, information related to the security context may be based on each NS session (identified by an NS session ID). In some aspects, the security context information for each NS session may include a UL re-encryption key or a reference (e.g., an ID or index) pointing to or identifying a UL re-encryption key. The UL re-encryption key may be referred to as a UL re-encryption key for the NS session. In some aspects, the UL re-encryption key may be used to re-encrypt NS messages in a UL NSAP message associated with the NS session, where the NSAP message originates from the device.

[0113] In some aspects, the NSAP context on the RAN node may also include information indicating one or more NS context IDs and one or more NSAP processing rules associated with each of the one or more NS context IDs. The one or more NSAP processing rules associated with the NS context ID may indicate how to process the NSAP message associated with the NS context ID. As described herein, the NS context ID identifies the NS context that can be associated with the NSAP message. In some aspects, the one or more NSAP processing rules may include a security indication that indicates whether NSAP security is applied to the NSAP message. In some aspects, when the NSAP message is a UL NSAP message or if the NSAP message is a UL NSAP message, the one or more NSAP processing rules may indicate which NS session (identified by the NS session ID) can be used to transmit the NSAP message. In some aspects, when the NSAP message is a DL NSAP message or if the NSAP message is a DL NSAP message, the one or more NSAP processing rules may indicate which device (identified by the device ID) the NSAP message can be transmitted to.

[0114] In some aspects, the NSAP context on the NSF (e.g., CN NSF, RAN NSF) may include information related to the security context. The information related to the security context may refer to the NSAP security context, which may also be referred to as NSAP security parameters. In some aspects, the information related to the security context may be based on each NS session (identified by the NS session ID). In some aspects, the security context information for each NS session may include one or more of the following: a public key and a private key or a reference (e.g., an ID or index) pointing to or identifying the public key and the private key. In some aspects, the public key may be referred to as the public key of the NS session. In some aspects, the private key may be referred to as the private key of the NS session.

[0115] In some aspects, a public key is not necessarily public (or known to the public). In some aspects, a public key may be a secret key. The term "public" is used in this context to distinguish the secret key from other keys (i.e., private keys). In some aspects, a public key and a private key may be the same.

[0116] In some aspects, the public key may be used to encrypt NS messages in DL NSAP messages originating from the NSF. In some aspects, the private key may be used to decrypt NS messages in UL NSAP messages received by the NSF.

[0117] In some aspects, the NSAP context on the NSF may also include information indicating one or more NS context IDs and one or more NSAP processing rules associated with each of the one or more NS context IDs. The one or more NSAP processing rules associated with the NS context ID may indicate how to process the NSAP message associated with the NS context ID. In some aspects, the one or more NSAP processing rules may include a security indication indicating whether NSAP security is applied to the NSAP message associated with the NS context ID. In some aspects, when the NSAP message is a DL NSAP message or if the NSAP message is a DL NSAP message, the one or more processing rules may indicate which NS session (identified by the NS session ID) can be used to transmit the NSAP message.

[0118] In some aspects, the device 106 can access network services related to the NS context through the RAN node and the NSF. The RAN node can be considered to be serving the device. The NSF can be considered to be serving the NS context. The device and the NSF can perform NSAP communications (i.e., exchange NSAP messages) through the serving RAN node. The NSAP layer at each of the device 106, the serving RAN node, and the NSF can process the NSAP message according to the NSAP context, as further described herein.

[0119] In some aspects, during NSAP communication, the device (i.e., the NSAP layer 212 on the device 106) can process a NSAP message. The NSAP message can include an NS context ID and an NS message. In some aspects, the NSAP message can be a UL NSAP message to be sent from the device to the NSF. The UL NSAP message can be sent through a RAN node using a radio bearer. In some aspects, the NSAP message can be a DL NSAP message received by the device from the NSF. The DL NSAP message can be received through a RAN node using a radio bearer.

[0120] In some aspects, when processing an NSAP message, the device (i.e., the NSAP layer 212 on the device 106) may process the NSAP message according to one or more NSAP message processing rules associated with the NS context ID. As described herein, the one or more NSAP message processing rules may be part of the NSAP context on the device. For example, referring to Figure 5 and Figure 6 , before sending device messages 510 and 610, respectively (each of which is a UL NSAP message), device 106 may process device message 610 according to its local NSAP context, as described in one or more aspects herein. Figure 5 and Figure 6 After receiving network messages 538 and 620 , respectively (each of which is a DL NSAP message), device 106 may process the network messages according to its local NSAP context as described in one or more aspects herein.

[0121] When the NSAP message is a UL NSAP message (e.g., Figure 5 Device message 510 and Figure 6 In some aspects of the device message 610 of the present invention, the one or more NSAP message processing rules may indicate that NSAP security should be applied. For example, the one or more NSAP message processing rules may include a security indication indicating that NSAP security should be applied. According to the one or more NSAP message processing rules, the device may cipher / encrypt the NS message in the NSAP message using the public key of the device through its NSAP layer 212. In some aspects, the public key of the device used for encryption may be identified or included in the NSAP context. According to the one or more NSAP message processing rules including the security indication, the device may also include a format indication in the NSAP message through its NSAP layer 212, wherein the security indication indicates that NSAP security should be applied. The format indication may indicate that the NS message in the NSAP message is ciphertext (or in other words, in ciphertext form).

[0122] When the NSAP message is a UL NSAP message (e.g., Figure 5 Device message 510 and Figure 6 In some aspects of the device message 610 of the present invention, the one or more NSAP message processing rules may indicate that NSAP security should not be applied. For example, the one or more NSAP message processing rules may include a security indication indicating that NSAP security should not be applied. According to the one or more NSAP message processing rules, the device may not cipher / encrypt the NS message in the NSAP message. According to the one or more NSAP message processing rules, the device may include a format indication in the NSAP message through its NSAP layer 212, indicating that the NS message in the NSAP message is plain text (or in other words, in plain text form).

[0123] When the NSAP message is a DL NSAP message (e.g., Figure 5 Network message 538 and Figure 6In some aspects of a network message 620 of the present invention, the one or more NSAP message processing rules may indicate that NSAP security should be applied. According to the one or more NSAP message processing rules, unless the NSAP message includes a format indication indicating that the NS message in the NSAP is plain text (or in other words, in plain text form), the device may decipher / decrypt the NS message in the NSAP message using the device's private key (the device's private key may be identified or included in the NSAP context) through its NSAP layer 212. For example, the one or more NSAP message processing rules may include a security indication indicating that NSAP security should be applied, and the NSAP message includes a format indication. In this case, because the NS message is plain text as indicated by the format indication, the device may not decipher / decrypt the NS message in the NSAP message.

[0124] When the NSAP message is a DL NSAP message (e.g., Figure 5 Network message 538 and Figure 6 In some aspects of the NSAP message 620, the NSAP message may include a format indication indicating that the NS message in the NSAP message is ciphertext (or in ciphertext form). In these aspects, regardless of whether the one or more NSAP message processing rules indicate whether NSAP security is applied, the device may decipher / decrypt the NS message in the NSAP message using the device's private key through its NSAP layer 212. The device's private key may be identified or included in the NSAP context.

[0125] In some aspects, the public and private keys used by the device when performing secure NSAP communications in accordance with its one or more NSAP message processing rules may be distributed by the AM (e.g., in Figure 5 ), and is provided to device 106 (e.g., at block 528 of Figure 5 ), as described herein.

[0126] In some aspects, during NSAP communication, the NSF (i.e., the NSAP layer on the NSF) can process NSAP messages. For example, referring to Figure 5 , upon receiving the device message 514 (UL NSAP message), the AM 502 (which may be an NSF in some aspects) may process the device message 514 according to its local NSAP context, as described in one or more aspects herein. Figure 6 , upon receiving the device message 614 (UL NSAP message), the NSF 602 may process the device message according to its local NSAP context, as described in one or more aspects herein.

[0127] Similarly, refer to Figure 5 , before sending the network message 536 (DL NSAP message), the AM 502 may process the network message according to its local NSAP context, as described in one or more aspects herein. Figure 6 Before sending the network message 618 (DL NSAP message), the NSF 602 may process the network message according to its local NSAP context, as described in one or more aspects herein.

[0128] The NSAP message may include the NS context ID and the NS message. In some aspects, the NSAP message may be a UL NSAP message received by the NSF from the device (e.g., Figure 5 Device message 514 or Figure 6 Device message 614). The NSF may receive a UL NSAP message using a NS session through a RAN node. In some aspects, the NSAP message may be a DL NSAP message to be sent by the NSF to the device through a RAN node using a NS session. In either case (e.g., a UL NSAP message or a DL NSAP message), the NS session is associated with an NS context ID that identifies the NS context.

[0129] When processing the NSAP message, the NSF may process the NSAP message according to one or more NSAP message processing rules associated with the NS context ID. In some aspects, the one or more NSAP message processing rules may be part of the NSAP context on the NSF.

[0130] When the NSAP message is a DL NSAP message (e.g., Figure 5 Network message 536 or Figure 6 In some aspects of the network message 618 of the present invention, the one or more NSAP message processing rules may indicate that NSAP security should be applied. For example, the one or more NSAP message processing rules may include a security indication indicating that NSAP security should be applied. According to the one or more NSAP message processing rules, the NSF may cipher / encrypt the NS message in the NSAP message using the public key of the NS session through its NSAP layer. The public key of the NS session may be identified or included in the NSAP context. In some aspects, the NSF may include a format indication in the NSAP message through its NSAP layer according to the one or more message processing rules to indicate that the NS message in the NSAP message is ciphertext (or in other words, in ciphertext form).

[0131] When the NSAP message is a DL NSAP message (e.g., Figure 5 Network message 536 or Figure 6 In some aspects of the network message 618 of the present invention, the one or more NSAP message processing rules may indicate that NSAP security should not be applied. For example, the one or more NSAP message processing rules may include a security indication indicating that NSAP security should not be applied. According to the one or more NSAP message processing rules, the NSF may include a format indication in the NSAP message through its NSAP layer, indicating that the NS message in the NSAP message is plain text (or in other words, in plain text form).

[0132] When the NSAP message is a UL NSAP message (e.g., Figure 5 Device message 514 or Figure 6 In some aspects of the device message 614 of the present invention, the one or more NSAP message processing rules may indicate that NSAP security should be applied. According to the one or more NSAP message processing rules, unless the NSAP message includes a format indication indicating that the NS message in the NSAP is plain text (or in other words, in plain text form), the NSF may decipher / decrypt the NS message in the NSAP message using the private key of the NS session (the private key of the NS session may be identified or included in the NSAP context) through its NSAP layer. For example, the one or more NSAP message processing rules may include a security indication indicating that NSAP security should be applied, and the NSAP message includes a format indication. In this case, because the NS message is plain text as indicated by the format indication, the NSF does not decipher (decipher / decrypt) the NS message in the NSAP message.

[0133] When the NSAP message is a UL NSAP message (e.g., Figure 5 Device message 514 or Figure 6 In some aspects of the device message 614 of the NSAP message, the NSAP message may include a format indication indicating that the NS message in the NSAP message is ciphertext (or in other words, in ciphertext form). In these aspects, regardless of whether the one or more NSAP message processing rules indicate whether NSAP security is applied, the NSF may decipher / decrypt the NS message in the NSAP message using the private key of the NS session through its NSAP layer. The private key of the NS session may be identified or included in the NSAP context.

[0134] In some aspects, the public and private keys used by the NSF in performing secure NSAP communications in accordance with its one or more NSAP message processing rules may be allocated by the AM and provided to the NSF, as described herein with reference to Figure 5Boxes 526 and 534 of, and reference Figure 7 Frames 724, 726 and 734.

[0135] During NSAP communication, the RAN node (i.e., the NSAP layer 222 on the RAN node) may receive a NSAP message. The NSAP message may include an NS context ID and an NS message. The RAN node may process the NSAP message. For example, referring to Figure 5 and Figure 6 , before sending device messages 514 and 614, respectively (each of which is a UL NSAP message), the RAN node 202 may process the device messages according to its local NSAP context, as described in one or more aspects herein. Figure 5 , before sending network message 538, or at Figure 6 , before sending network messages 620 (each of which is a DL NSAP message), RAN node 202 may process the network messages according to its local NSAP context, as described in one or more aspects herein.

[0136] In some aspects, the NSAP message may be a UL NSAP message received from device 106 (eg, Figure 5 Device message 510 or Figure 6 In some aspects, the NSAP message may be a DL NSAP message received from the NSF. The RAN node may transmit the NSAP message based on the NSAP context on the RAN node.

[0137] In some aspects, the NSAP message may be a UL NSAP message (e.g., Figure 5 Device message 510 or Figure 6 The RAN node may also transmit the NSAP message using the NS session. Since the NS session is between the RAN node and the NSF, the NSAP message may be transmitted to the NSF.

[0138] In some aspects, the NSAP message may be a DL NSAP message (eg, Figure 5 Network message 538 or Figure 6The NSAP context may be a network message 620 of the RAN node, and the NSAP message may be associated with the NS session between the RAN node and the NSF (e.g., the NSAP message is received via a tunnel between the RAN node and the NSF, the tunnel corresponding to the NS session). In some aspects, the NSAP context may indicate that the NS session is mapped to a radio bearer, which is associated with the device. Therefore, the RAN node may transmit the NSAP message using the radio bearer indicated in the NSAP context. Transmitting the NSAP message using the indicated radio bearer may cause the NSAP message to be sent to the device.

[0139] In some aspects, the NSAP context may indicate that the device corresponds to the NS context ID. The RAN node may transmit the NSAP message to the device indicated in the NSAP context using a radio bearer associated with the device.

[0140] In some aspects, before the RAN node transmits the NSAP message, the RAN node may identify one or more NSAP message processing rules associated with the NS context ID in the NSAP context on the RAN node. The RAN node may process the NSAP message according to the one or more NSAP message processing rules.

[0141] In some aspects, a UL NSAP message may be transmitted using a NS session. Figure 5 Device message 514 or for example Figure 6 In some aspects of a device message 614 of the present invention, the one or more NSAP message processing rules may indicate that NSAP security should be applied to NSAP messages associated with the NS context ID. According to the one or more NSAP message processing rules, unless the NSAP message includes a format indication indicating that the NS message in the NSAP is plain text (or in other words, in plain text form), the RAN node may perform proxy re-encryption (i.e., re-encrypt the NS message) on the NS message in the NSAP message through its NSAP layer 222 using a UL re-encryption key (the UL re-encryption key may be associated with the NS session; the UL re-encryption key may be identified or included in the NSAP context). For example, the one or more NSAP message processing rules may include a security indication indicating that NSAP security is applied, and the NSAP message includes a format indication. In this case, because the NS message is plain text, the device does not perform proxy re-encryption on the NS message in the NSAP message.

[0142] When the NSAP message is a UL NSAP message (e.g., Figure 5 Device message 514 or Figure 6In some aspects of the present invention, the NSAP message may include a format indication indicating that the NS message in the NSAP message is ciphertext (or in other words, in ciphertext form). In these aspects, regardless of whether the one or more NSAP message processing rules indicate whether NSAP security applies, the RAN node may (through its NSAP layer 222) perform proxy re-encryption on the NS message in the NSAP message (i.e., re-encrypt the NS message) using the UL re-encryption key. The UL re-encryption key may be identified or included in the NSAP context. The UL re-encryption key may be associated with the NS session.

[0143] In some aspects, the UL re-encryption key used by the RAN node when performing secure NSAP communications in accordance with the one or more NSAP message handling rules may be allocated by the AM (e.g., in Figure 5 At block 526 of Figure 7 ), and is provided to a RAN node (e.g., at block 726 of Figure 5 at block 532 of Figure 7 ), as described herein.

[0144] In some aspects, a DL NSAP message may be transmitted to a device using a radio bearer. In the case where the NSAP message is a DL NSAP message (e.g., Figure 5 Network message 538 or Figure 6 In some aspects of a network message 620 of the present invention, the one or more NSAP message processing rules may indicate that NSAP security should be applied. According to the one or more NSAP message processing rules, unless the NSAP message includes a format indication indicating that the NS message in the NSAP is plain text (or in other words, in plain text form), the RAN node may perform proxy re-encryption (i.e., re-encrypt the NS message) on the NS message in the NSAP message through its NSAP layer 222 using the device's DL re-encryption key (the DL re-encryption key may be identified or included in the NSAP context). For example, the one or more NSAP message processing rules may include a security indication indicating that NSAP security should be applied, and the NSAP message includes a format indication. In this case, because the NS message is plain text, the device does not perform proxy re-encryption on the NS message in the NSAP message.

[0145] When the NSAP message is a DL NSAP message (e.g., Figure 5 Network message 538 or Figure 6In some aspects of the NSAP message 620 of the present invention, the NSAP message may include a format indication indicating that the NS message in the NSAP message is ciphertext (or in other words, is in ciphertext form). In these aspects, regardless of whether the one or more NSAP message processing rules indicate whether NSAP security applies, the RAN node (through its NSAP layer 222) may perform proxy re-encryption on the NS message in the NSAP message (i.e., re-encrypt the NS message) using the DL re-encryption key of the device as identified or included in the NSAP context.

[0146] In some aspects, the DL re-encryption key used by the RAN node when performing secure NSAP communications in accordance with the one or more NSAP message processing rules may be allocated by the AM (e.g., in Figure 5 ), and is provided to a RAN node (e.g., at block 528 of Figure 5 ), as described herein.

[0147] In some aspects, proxy re-encryption performed by a RAN node may be performed such that a device or NSF (as the case may be) receiving an NSAP message may decrypt it using their respective private keys without negotiating a symmetric key. In some aspects, a serving NSF may be changed, and when communicating with the new NSF, the device and the new NSF may decrypt the NSAP message using their own private keys without negotiating a symmetric key. Thus, one aspect of the present disclosure may not require the negotiation of one or more symmetric keys for encryption or decryption purposes.

[0148] In some aspects, the device 106 can be served by an access management (AM). In some aspects, the AM can be selected by the device's serving RAN node. In some aspects, the AM can be the default NSAP handling point and is responsible for NSF selection and NSAP context management.

[0149] When the AM serves a device, the AM can manage the device's registration (or access or connection) to the communication network. The AM can also manage the device's access to network services on the control plane of the communication network.

[0150] Devices can access network services through NSFs, which provide access to network services. In some aspects, NSFs can be selected by AMs (e.g., Figure 5 Box 516 in, or Figure 7 When the device accesses network services, the device and the NSF may transmit and exchange NSAP messages.

[0151] In some aspects, when the AM manages the registration of a device to a communication network, the AM can authenticate and authorize the device to access or connect to the communication network. The AM can assign a temporary device ID to the device. The temporary device ID can identify the device in the communication network.

[0152] In some aspects, the AM can distribute public and private keys to devices. For example, refer to Figure 5 At block 528, AM 502 may assign NSAP security parameters to device 106, including assigning a public key and a private key to device 106. AM may provide a temporary device ID, a public key, and a private key to the device. Figure 5 At block 530, AM 502 may configure the NSAP context at device 106 by providing the assigned public key and private key to device 106. In some aspects, the device may use the temporary device ID to access network services. The device may store the public key and private key in its local NSAP context as part of the NSAP security context. As described above, the device may use the public key and private key to perform secure NSAP communications to access network services.

[0153] In some aspects, the AM may also assign DL re-encryption keys to the device and provide the DL re-encryption keys to the serving RAN node (directly or through the device). Figure 5 At block 528, the AM 502 may allocate a DL re-encryption key, and at block 532, the AM may provide the DL re-encryption key to the RAN node 202, as further described herein. The RAN node 202 may store the DL re-encryption key as part of its NSAP security context.

[0154] In some aspects, the DL re-encryption key may be generated based on or using a public key of the device. The serving RAN node may associate the DL re-encryption key with the device. The serving RAN node may identify the device using an internal ID, which may be maintained only by the RAN node or within the RAN. The RAN node may store the DL re-encryption key and association (e.g., a mapping between a key or a reference to a key and an internal ID) in its local NSAP context as part of the NSAP security context. As described above, the RAN node may use the DL re-encryption key to support secure DL NSAP communications from the NSF to the device.

[0155] In some aspects, the AM may not provide the DL re-encryption key to the serving RAN node. Instead, the AM may provide the public key of the device to the serving RAN node, and the serving RAN node may generate the DL re-encryption key using the public key of the device.

[0156] In some aspects, the DL re-encryption key may not be provided from the AM to the serving RAN node. Instead, the device may generate a DL re-encryption key using the device's public key and provide the DL re-encryption key to the serving RAN node.

[0157] In some aspects, the AM may trigger the creation of an NS session between the NSF and the serving RAN node of the device. The NS session may be used to support NSAP communications between the device and the NSF, as described herein. The NS session may be identified by an NS session ID, which may be generated by the serving RAN node, the NSF, or the AM. For example, referring to Figure 5 , when processing ( 520 ) the service request, the selected NSF 504 may establish an NS context, including generating an NS context ID based on information received in the service request 518 , as described herein.

[0158] In some aspects, the AM may configure the relevant NS session context (e.g., NS session ID, routing information, the routing information including information that can be used to reach the other end of the tunnel associated with the NS session, such as tunnel type, protocol type, address, port number, tunnel ID, tunnel endpoint ID) at one or more of the following: the serving RAN node and the NSF. Some examples of configuring the serving RAN node include: Figure 5 In box 532 and in Figure 7 One or more operations performed at block 732 in . Some examples of configuring NSF include Figure 5 In box 534 and Figure 7 One or more operations performed at box 734 in .

[0159] In one aspect, the AM may configure NSAP contexts at the serving RAN node and NSF so that the device and NSF may perform NSAP communications with each other. The NSAP contexts at the serving RAN node and at the NSF may be referred to as RAN NSAP contexts and NSF NSAP contexts, respectively.

[0160] In some aspects, the AM may allocate public and private keys and associate these keys with the NS session. The AM may provide the public and private keys to the NSF. The AM may also notify the NSF of the association of the provided keys with the NS session. In some aspects, the association may be in the form of a mapping between the keys (or references to the keys) and the NS session ID. The NSF may store the keys and associations in the NSF NSAP context as part of the NSAP security context. The NSF may use the keys to perform secure NSAP communications with the device over the NS session, as described elsewhere in this application. For example, reference Figure 5 , at block 526 and at 534, and with reference to Figure 7At block 726 and at block 734, AM 502 may send a request to NSF (or Figure 7 A new NSF in the NSAP may provide a key pair (eg, a public key and a private key), and the NSF may store the pair of keys as part of its NSAP security context.

[0161] In some aspects, the AM may allocate a UL re-encryption key and associate the key with the NS session. Figure 5 at block 526 of Figure 7 At block 726 of , AM 502 may allocate NSAP security parameters for the NS session, including allocating UL re-encryption keys. The AM may provide the UL re-encryption keys to the serving RAN node (directly or through the NSF). For example, Figure 5 526 and 532 of , or in Figure 7 At blocks 726 and 732 of FIG. 5 , after AM 502 distributes the UL re-encryption key, it may send Figure 5 The RAN node 202 and Figure 7 The UL re-encryption key is provided at 702. The corresponding RAN node may then store the UL re-encryption key as part of its NSAP security context.

[0162] The AM may also notify the serving RAN node of the association of the provided key with the NS session. In some aspects, the association may be in the form of a mapping between the key (or a reference to the key) and the NS session ID. The serving RAN node may store the key and the association in the RAN NSAP context as part of the NSAP security context. The RAN node may then use the key to perform secure UL NSAP communications from the device to the NSF, as described elsewhere in this application.

[0163] In some aspects, the AM may not provide the UL re-encryption key to the serving RAN node. Instead, the AM may provide the public key of the NS session to the serving RAN node, and the serving RAN node may generate the UL re-encryption key using the received public key of the NS session.

[0164] In some aspects, the AM may not provide the UL re-encryption key to the serving RAN node. Instead, the NSF may generate the UL re-encryption key using the public key of the NS session and provide the generated UL re-encryption key to the serving RAN node.

[0165] In some aspects, when an AM provides a key (e.g., a re-encryption key, a public key, a private key) or a key pair (e.g., a public key and a private key) to a network entity (e.g., a device, a RAN node, an NSF), the AM may provide the key or key pair by value (i.e., providing the key or key pair itself) or by reference (i.e., providing a reference or index to the key or key pair). In some aspects, when the key or key pair is pre-configured in the network entity, the AM may provide the key or key pair by reference. The network entity may then use the reference to identify the key or key pair in its configuration.

[0166] In some aspects, the AM can be the default NSAP processing point for a device to access network services before an NSF is selected for the device. For example, Figure 5 AM 502.

[0167] In some aspects, when the AM processes the NSAP message of the device related to the device accessing the network service, the AM can select the NSF for the device. In some aspects, the AM and the NSF can be the same (e.g., when the AM itself provides the network service), so the interaction between the AM and the NSF can be an internal process of the AM.

[0168] For example, the AM may be the NSF that provides the network service (e.g., registration service) that the device is accessing. Thus, in some aspects, the AM may select itself based on the network service that the device is accessing. Therefore, the NSAP communication between the AM and the device may also need to be protected.

[0169] Thus, the AM may also perform the operations described herein for establishing or supporting secure communications between the device and itself (where the NSF is the AM itself), wherein any interactions between the AM and the NSF are internal processes of the AM. In some aspects, operations for establishing secure NSAP communications between the device and the AM (also the NSF) may be performed before NSAP communications between the device and the AM begin. For example, in some aspects, secure NSAP communications between the device and the AM may occur when the AM processes a request by the device to access a communications network. Thus, communications between the device and the AM regarding the device's access to network services (in the form of NSAP message exchanges) may be protected.

[0170] In some aspects, when the serving RAN node of the device receives the NSAP message from the device, the serving RAN node may identify the NS session corresponding to the NS context ID in the NSAP message. In some aspects, if the NS session is identified, the serving RAN node may send the NSAP message using the NS session. When the NS session is used to send the NSAP message, the serving RAN node may send the NSAP message using a tunnel associated with the NS session. In some aspects, if the NS session is between the serving RAN node and the NSF, the NSAP message may be transmitted to the NSF.

[0171] In some aspects, the serving RAN node may not be able to identify the NS session corresponding to the NS context ID in the NSAP message. In these aspects, the serving RAN node may send the NSAP message to the AM using the NS session between the serving RAN node and the AM, wherein the NS session is used to support NSAP communications between the device and the AM.

[0172] After receiving the NSAP message, the AM may perform one or more operations according to one or more aspects described herein. For example, the AM may perform one or more of the following: select an NSF (e.g., Figure 5 ), triggering the creation of an NS session between the serving RAN node and the NSF, and configuring an NSAP context at the serving RAN node and at the NSF, as described above.

[0173] For example, receiving a request for a service (e.g., Figure 5 The AM of the device message 514) may select (516) NSF to provide network services.

[0174] In some aspects, triggering the creation of a NS session between the serving RAN node and the NSF (or a selected NSF) may include the AM 502 sending a service request notification 518 to the selected NSF, including the RAN node ID in the notification. The NSF may process (520) the service request by updating its local NSAP context.

[0175] The NSF may authorize the service request and, if an NS context is not already established in the NSF, the NSF may (while processing (520) the service request) establish an NS context based on information in the service request notification 518. In some aspects, establishing the NS context may include the NSF generating an NS context ID.

[0176] In some aspects, the NSF, while processing (520) the service request, may perform one or more NS operations on the NS context, the NS operations identified in the NS operation instructions included in the service request 518. The NSF may also associate the NS context with the NS session and update its local NSAP context by storing a mapping between the NS context ID and the NS session ID, as further described herein.

[0177] For example, when the AM configures the NSAP context at the NSF, the AM may simultaneously send an NSAP message to the NSF. Subsequent NSAP messages from the device may be transmitted to the NSF.

[0178] Figure 4 An example of processing NSAP messages according to one aspect is shown. Each row 420, 422, 424 and 426 may indicate a different NS context. For example, row 420 may refer to a first NS context identified by NS context ID C1a 410 associated with NS session S1a 430. Similarly, row 422 may refer to a second NS context identified by NS context ID C1b412 (different from first NS context ID C1a) associated with NS session S1b 432. As shown, in some aspects, each of NS session S1a430 and NS session S1b 432 may refer to a session between the serving RAN node 202 of device 106 and the same NSF (e.g., CNNSF 206). In other aspects, each of NS session S1a 430 and NS session S1b 432 may be associated with a different NSF, wherein each NSF may be located in RAN 102 or CN 104.

[0179] In one aspect, row 424 may refer to a third NS context identified by NS context ID C2 414 associated with NS session S2 434. NS session S2 434 may refer to a session between the serving RAN node 202 and a RAN NSF 402 located external to the serving RAN node 202. Row 426 may refer to a fourth NS context identified by NS context ID C3 416 associated with NS session S3 436. NS session S3 436 may refer to a session between the serving RAN node 202 and a RAN NSF 204 located at or within the serving RAN node 202.

[0180] NSAP messages transmitted between the device 106 and the serving RAN node 202 may be transmitted using a radio bearer 406 between the device 106 and the RAN node 202, as shown. The RAN node 202 may then send a NS message to the appropriate NSF using the NS session associated with the NS context ID.

[0181] In one aspect, when the device 106 wants to access network services, the device 106 may send a NSAP message to its serving RAN node 202. The NSAP message may include a NS context ID (eg, C1a 410 or C3 416) and a NS message.

[0182] In one aspect, if the NSAP message handling rules associated with the NS context ID indicate that NSAP security is applied, the device 106 may encrypt the NS message using the public key in the NSAP context. For example, the NS context associated with NS context ID C1a 410 may indicate that NSAP security should be applied. On the other hand, the NS context associated with NS context ID C3 416 may indicate that NSAP security should not be applied, in which case the NS message may not be encrypted.

[0183] In some aspects, the device 106 may include a format indication in the NSAP message to indicate whether the NS message is in ciphertext form. Thus, in the case of an NS context associated with the NS context ID C1a 410, the format indication may indicate that the NS message is in ciphertext form. However, in the case of an NS context associated with the NS context ID C3 416, the format indication may indicate that the NS message is in plaintext form (or the format indication field may be empty, indicating that the NS message is in plaintext).

[0184] Based on the NS context ID in the NSAP message, the RAN node may (through its NSAP layer 222) identify the NS session (e.g., S1a or S3) corresponding to the NS context ID. The RAN node may then transmit the NSAP message to the corresponding NSF using the identified NS session. For example, for the NS session associated with the NS context ID C1a 410, the RAN node 202 may use the NS session S1a 430, and for the NS session associated with the NS context identified by the NS context ID C3 416, the RAN node 202 may use the NS session S3 436. In some aspects, the RAN node 202 may send only the NS message in the NSAP message, rather than the NSAP message, to the appropriate NSF.

[0185] In one aspect, if the NSAP handling rule associated with the NS context ID indicates that SAP security is applied, the RAN node 202 may re-encrypt the NS message to be sent to the NSF using the UL re-encryption key associated with the NS session. For example, in the case of the NS context identified by the NS context ID C1a 410, the NSAP message handling rule may indicate that NSAP security should be applied. Therefore, the RAN node 202 may re-encrypt the NS message using the UL re-encryption key associated with the NS session S1a 430.

[0186] In some aspects, the NSAP message received by the RAN node 202 may indicate that the NS message is in ciphertext form (or not in plaintext form) via a format indication. Based on the format indication, the RAN node 202 may re-encrypt the NS message using a UL re-encryption key associated with the NS session.

[0187] In some aspects, use of NS sessions may enable NSAP messages (or NS messages) to be transmitted to the appropriate NSF, which provides access to the NS and maintains the NS context.

[0188] In one aspect, if the NSAP processing rules associated with the NS context ID indicate that SAP security applies (e.g., NS session S1a 430) or if the NSAP message indicates through a format indication that the NS message is in ciphertext form (or not in plaintext form), the serving NSF can use the private key associated with the NS session to decrypt the NS message.

[0189] In some aspects, the format indication in the NSAP message may take precedence or override the NSAP message processing rules. For example, the NSAP message processing rules may indicate that NSAP security does not need to be applied, but the format indication in the NSAP message indicates that the NSAP message is in ciphertext form. Based on the format indication, the entity receiving the NSAP message may apply appropriate NSAP security (e.g., encryption, re-encryption, or decryption (as appropriate)).

[0190] The NSF may perform necessary NS operations for the NS context indicated in the NS message.

[0191] Similarly, for DL, when the NSF wants to send a NS message related to the NS context to the device, the NSF can send a NSAP message to the RAN node 202 using the NS session corresponding to the NS context ID. In some aspects, the NSAP message can include the NS context ID (e.g., C1a 410 or C3 416) and the NS message. As can be appreciated by those skilled in the art, the processing of the DL NSAP message can be symmetrical with the processing of the UL NSAP message described herein.

[0192] In one aspect, the device 106 may request or access a network service by sending a service request to the RAN node 202. For example, the network service may be a mobility management service, a session management service, a task management service, a policy management service, etc. The network service may be associated with a service context (or scope). In some aspects, the request for a network service may be a request for multiple network services.

[0193] In some aspects, the device 106 may specify one or more service operations related to the network service (eg, location update for mobility management service, session establishment for session management service, context synchronization for task management service, policy acquisition for policy management service, etc.).

[0194] In some aspects, if the service context has not already been created, then during the service request process, the service context will be created. One or more service operations can be performed on the service context.

[0195] Figure 5 A process for requesting a network service according to one aspect is shown. Process 500 may refer to a network service request process in which a RAN node cannot identify an NS session corresponding to an NS context. In one aspect, process 500 may include device 106 requesting access to a network service (NS) for an NS context by sending an NSAP message (the NSAP message may be referred to as a second request for the NS) to RAN node 202. The NSAP message may also be referred to as a device message 510. RAN node 202 receives device message 510. In one aspect, device message 510 may include an NS context ID and an NS message. The NS message includes information identifying the NS.

[0196] In some aspects, the NS context ID is used to identify the NS context. In some aspects, the NS context ID may be optional, for example, when the NS context does not exist in the communication network. In some aspects, the NS context ID may be generated by the device 106. In some aspects, the NS context ID may be generated by the communication network (e.g., an NSF selected to serve the NS context may generate the NS context ID) and received by the device 106 from the communication network in a previous process.

[0197] In some aspects, the NS message may be referred to as a service request. The service request may include NS information and NS operation instructions.

[0198] In some aspects, the NS information may describe or indicate at least a portion of the NS context. In some aspects, the NS information may include an NS context ID. The NS context ID may be optional in the NS information when the NS context does not exist in the communication network and when the NS context ID will be generated by the communication network (e.g., an NSF selected to serve the NS context).

[0199] In some aspects, the NS information may also include information identifying the network service, such as a service ID or name. In some aspects, the NS information may also include information identifying the device (e.g., a device ID). In some aspects, the NS information may also include information identifying the network slice (or slice instance) associated with the network service. In some aspects, the NS information may also include information identifying the application, mission, or task associated with the network service (i.e., one or both of the application / mission / task name or the application / mission / task ID). In some aspects, the NS information may also include information identifying the data network (e.g., DNN) associated with the network service. In some aspects, the NS information may also include information identifying the subsystem or service module associated with the network service (e.g., a subsystem or service module ID). In some aspects, the NS information may also include information identifying the dedicated network service associated with the network service (e.g., a dedicated service name or ID).

[0200] In some aspects, the NS operation instruction may indicate one or more NS operations to be performed for the NS context. The NS operation instruction may include information identifying the one or more NS operations, and relevant operation parameters for each identified NS operation. Each of the one or more NS operations may be identified by an NS operation name or ID. In some aspects, the NS operation instruction may be optional in the service request. In the absence of an NS operation instruction in the service request, the service request may indicate creating or updating an NS context in the communication network using the NS information in the service request.

[0201] In some aspects, before sending the device message 510 to the RAN node 202, the device may process the device message according to its local NSAP context (NSAP context on the device), as described elsewhere herein. For example, the device message 510 may be a UL NSAP message, wherein the device may process the device message according to its local NSAP context based on the UL NSAP message described herein. The NSAP context on the device includes one or more NSAP processing rules associated with the NS context ID. If the security indication included in the one or more rules indicates that NSAP security is applied, the device will encrypt the device message 510 using the public key of the device identified or included in the NSAP context, and will also include a format indication in the NSAP message to indicate that the NS message in the UL NSAP message is ciphertext (or in other words, in ciphertext form). Therefore, the device message 510 may be referred to as a second request encrypted with the public key of the device. Specifically, the device encrypts the NS message in the device message 510 using the public key of the device.

[0202] In some aspects, process 500 may also include RAN node 202 selecting (512) an AM 502. In some aspects, if device 106 is being served by an AM, the RAN node may select an AM to serve the device. In some aspects, if device 106 is not being served by an AM, an AM is selected to serve the device and is from among those AMs associated with RAN node 202.

[0203] In some aspects, the process 500 may also include the RAN node 202 sending a device message 514 to the selected AM 202 (the device message 514 may be referred to as a first request, or the device message may be carried on the first request). In some aspects, before sending the device message 514, the RAN node 202 may process the device message 510 received from the device according to its local NSAP context, as described elsewhere herein. For example, the device message 514 may be a UL NSAP message, wherein the RAN node 202 may process the device message according to its local NSAP context (NSAP context on the RAN node 202) based on the UL NSAP message described herein. The NSAP context on the RAN node may include one or more NSAP processing rules associated with the NS context ID, and if the one or more rules indicate that NSAP security is applied to the NSAP message associated with the NS context ID (e.g., by including a security indication indicating to do so), unless the device message 510 includes a format indication indicating that the NS message in the device message 510 is plain text (or in other words, in plain text form), the device message 510 is re-encrypted using the UL re-encryption key of the NS session (i.e., the NS message in the device message 510 is re-encrypted). The UL re-encryption key of the NS session is identified or included in the NSAP context. The UL re-encryption key of the NS session may be referred to as a public key associated with the AM. It will be understood that the device message 510 may include the NS context ID and the encrypted NS message, and the device message 514 may include the NS context ID and the re-encrypted NS message. The device message 514 is obtained by re-encrypting the device message 510 using the public key associated with the AM.

[0204] In some aspects, after receiving the device message 514 from the RAN node 202, the AM 502 can process the device message 514 according to its local NSAP context (NSAP context on the AM), as described herein. For example, the device message 514 can be a UL NSAP message, wherein the AM 502 can process the device message according to its local NSAP context based on the UL NSAP message described herein. For example, the AM decrypts the device message 514 using a private key included in the NSAP context on the AM.

[0205] In one aspect, process 500 may also include AM 502 selecting 516 an NSF based on information in device message 514. In some aspects, AM 502 may select the NSF using one or both of: a network binding function (NBF) and a network registry function (NRF).

[0206] In some aspects, both the NBF and the NRF are in the communication network. The NBF may maintain binding information. In some aspects, by including a mapping between an NSF ID and an NS context ID, the binding information may indicate which NSF is serving which NS context (and therefore bound to which NS context). The NRF may maintain profile information about the NSF, which includes information about each NSF. In some aspects, the profile information of each NSF may include information about one or more network services supported or provided by the NSF, such as one or more lists of service names and service IDs. In some aspects, the profile information of each NSF may also include information about the service area of ​​the NSF, such as a list of RAN node IDs or geographic area IDs. In some aspects, the profile information of each NSF may also include information related to one or more network slices associated with the NSF, such as a list of network slice IDs. In some aspects, the profile information of each NSF may also include one or more applications, responsibilities or tasks that the NSF can serve, such as a list of application / responsibilities / task names or IDs.

[0207] In some aspects, if the device message 514 sent from the RAN node includes an NS context ID, the AM may use the NBF to identify and select the NSF. In one aspect, the AM 502 may send the NS context ID to the NBF. In an optional implementation, the AM 502 sends a third request to the NBF, and the third request includes the NS context ID. If the NBF is able to identify the NSF based on the binding information, the NBF may respond to the AM 502 with information about the serving NSF (i.e., the NSF ID), for example, the NBF sends a response to the AM, and the AM receives the response, wherein the response indicates the NSF. Thereafter, the NSF selected by the AM may be the serving NSF. In some aspects, the NBF may not identify the NSF based on the NS context ID. Therefore, the NBF may indicate to the AM 502 that the serving NSF cannot be identified.

[0208] In some aspects, the AM may select the NSF using the NRF. In one aspect, when the NSF is selected using the NRF, the AM 502 may send the NS information and the location of the device in the service request to the NRF. The location of the device may be represented using the ID of the RAN node. In an optional implementation, the AM 502 sends a third request to the NRF, the third request including the location of the device and the NS information. The NRF may select the NSF based on one or more of the following: the profile information of the NSF, the NS information, and the location of the device.

[0209] The NRF may select the NSF based on any of the following reasons: In some aspects, the NRF may select the NSF based on the NSF that provides or supports the network service identified in the NS information. In some aspects, the NRF may select the NSF based on the service area of ​​the NSF's coverage device location. In some aspects, the NRF may select the NSF based on the location of the NSF. In some aspects, the NRF may select the NSF based on the NSF belonging to the network slice identified in the NS information. In some aspects, the NRF may select the NSF based on the NSF used to serve the application, or responsibility or task, or data network, or subsystem, or service module, or dedicated network service identified in the NS information.

[0210] In some aspects, the NRF may respond to the AM 502 with information about the NSF. The information about the NSF may include information identifying the NSF (e.g., NSF ID or address) and the location of the NSF (whether the NSF is located in the CN or in the RAN, and if located in the RAN, the ID of the RAN node). For example, the NRF sends a response to the AM, and the AM receives the response, the response indicating the NSF and the location of the NSF.

[0211] In some aspects, any two of the network functions (i.e., AM 502, NBF, and NRF) may be the same network entity, for example, NBF and NRF are the same network entity, or, AM and NBF are the same network entity, or, AM and NRF are the same network entity. In aspects where two of the network functions (i.e., AM 502, NBF, and NRF) are the same entity, the interaction between the two network functions may therefore be understood as an internal process within the entity.

[0212] In some aspects, all network functions (ie, AM 502, NBF, and NRF) may be the same network entity.

[0213] In some aspects, AM 502 selects NSF through other network functions that are not NBF or NRF. The other network functions can be selected by AM 502 according to the information in the service request. AM 502 sends a third request to the other network functions, and the third request includes any one of the NS information, NS context ID, and device location sent to another network function. According to the third request, the other network function selects NSF and sends a response to AM 502, and the response indicates NSF. The response sent from the other network function to AM 502 can also indicate the location of NSF. The response can include information about NSF. The information about NSF can include information (e.g., NSF ID or address) identifying NSF and the location of NSF (NSF is located in CN or RAN, if located in RAN, it is the ID of RAN node), as described above. In some aspects, the other network function uses NBF or NRF to select NSF, wherein the other network function sends the information received from AM 502 to NBF or NRF, and receives information about NSF from NBF or NRF. It can be seen that the other network functions interact with the NBF or NRF (using the NBF or NRF) on behalf of the AM 502 to select the NSF.

[0214] In some aspects, process 500 may also include AM 502 sending a service request notification 518 to the NSF. Service request notification 518 may include a service request. In some aspects, service request notification 518 may also include information about RAN node 202 (eg, RAN node ID).

[0215] In some aspects, process 500 may also include NSF 504 processing 520 the service request. In some aspects, processing the service request may include NSF 504 updating its local NSAP context, as described elsewhere herein.

[0216] In some aspects, when processing the service request, NSF 504 can authorize the service request. In one aspect, if the NS context has not been established in the NSF, NSF 504 can establish the NS context based on the NS information in the service request, as described elsewhere herein.

[0217] In some aspects, when establishing the NS context, the NSF 504 can store the NS information as part of the NS context. In some aspects, when the communication network is to generate an NS context ID for the NS context, the NSF 504 can further generate the NS context ID, as described elsewhere herein.

[0218] In some aspects, if the service request includes NS operation instructions, when the NSF 504 processes the service request, one or more NS operations identified in the NS operation instructions may be performed for the NS context using corresponding parameters included in the NS operation instructions, as described elsewhere herein.

[0219] In some aspects, the NSF 504 may associate the NS context with the NS session. Accordingly, the NSF 504 may further update its local NSAP context, for example, by storing a mapping between the NS context ID and the NS session ID in the NSAP context, as described elsewhere herein. The NS session ID may identify the NS session. The NS session may be between a RAN node and the NSF and is device-specific. In some aspects, the NS session may be an existing NS session (if an existing NS session exists) or a newly created NS session (if an existing NS session does not exist). In some aspects, the NS session ID may be generated by the NSF when the NSF creates the NS session.

[0220] In some aspects, process 500 may also include NSF 504 responding to the service notification by sending a service response or notification response 522 to AM 502. Notification response 522 may include a service response. The service response may correspond to the service request and indicate that the service request has been accepted.

[0221] In some aspects, the NSF 504 may notify the AM 502 about the association between the NS context and the NS session by including the NS context ID and the NS session ID in the service response or notification response 522. In some aspects, the notification response 522 may also include an indication indicating whether the NS session is a newly created NS session or whether the NS session requires NSAP security parameters. In some aspects, the indication indicating whether the NS session is a newly created NS session may be equivalent to an indication indicating whether the NS session requires NSAP security parameters. The AM 502 may determine whether to perform the operation at box 524 (i.e., whether to allocate NSAP security parameters for one or more of the following: NS session and device) based on the indication, as further described herein.

[0222] In some aspects, the NSF 504 may assign routing information for the NS session and include the routing information in the service response or notification response 522. The routing information may specify how the NS session communicates to reach the NSF.

[0223] In some aspects, process 500 may also include one or more operations at block 524, involving AM 502 assigning NSAP security parameters. In some aspects, AM 502 may determine whether to apply NSAP security to the NS context based on the location of the NSF. In some aspects, if the NSF is located in the CN (e.g., a CN NSF), AM 502 may determine to apply NSAP security to the NS context. In some aspects, if the NSF is located in the RAN (i.e., if the NSF is a RAN NSF), AM 502 may determine not to apply NSAP security. In some aspects, if the NSF is located in the RAN, but not inside the serving RAN node, AM 502 may determine to apply NSAP security. In some aspects, AM 502 may decide based on local configuration, for example, as indicated in the local configuration to determine.

[0224] If AM 502 determines to apply NSAP security to the NS context, AM 502 may allocate NSAP security parameters to support secure NSAP communications associated with the NS context between the device and the NSF, as described with reference to blocks 526 and 528. If AM 502 determines not to apply NSAP security to the NS context, AM 502 may skip the operations performed with reference to blocks 526 and 528.

[0225] In some aspects, one or more operations at block 526 may include the AM 502 assigning NSAP security parameters to the NS session. In some aspects, the NSAP security parameters for the NS session may include a first key pair (e.g., an NSF public key and an NSF private key) and a UL re-encryption key. The UL re-encryption key may be associated with a public key in the first key pair, for example, derived or generated based on the public key in the first key pair. In some aspects, the AM 502 may provide the first key pair to the NSF via an NSF configuration request, and the NSF may store the received first key pair as part of its NSAP security context, as described elsewhere herein, and further described with reference to block 534. The first key pair may be used by the NSF to perform secure NSAP communications with the device, as described elsewhere herein. The NSF configuration request also includes one or more of the following: an ID of the RAN node, a command indicating whether to apply NSAP security to the NS context. If the NSF receives the NSF configuration request, the NSF sends an NSF response to the AM indicating that the NSF configuration request has been received.

[0226] In some aspects, the AM 502 may provide the UL re-encryption key to the RAN node 202, and the RAN node 202 may store the UL re-encryption key as part of its NSAP security context, as described elsewhere herein and further described with reference to block 532. The UL re-encryption key may be used by the RAN node to support secure NSAP communications in the UL direction from the device to the NSF, as described herein. For example, the AM provides the UL re-encryption key via a RAN configuration request, which may also include one or more of the following: an NS context ID, an NS session ID, an NSF ID or address, routing information for reaching the NSF, and a command indicating whether to apply NSAP security to the NS context. If the RAN node receives the RAN configuration request, the RAN node sends a RAN response to the AM, indicating receipt of the RAN configuration request.

[0227] In some aspects, the AM 502 may perform one or more operations at block 526 based on an indication in the received notification response 522. If the indication indicates that the NS session is a newly created NS session, or that the NS session requires NSAP security parameters, the AM 502 may perform the operations at block 526. Otherwise, the AM 502 may skip the operations at block 526.

[0228] In some aspects, the AM 502 may perform one or more operations at block 528 involving assigning NSAP security parameters to the device. The NSAP security parameters of the device may include a second key pair (e.g., a device public key and a device private key) and a DL re-encryption key. The DL re-encryption key may be associated with a public key in the second key pair, for example, derived or generated based on a public key in the second key pair. In some aspects, the AM 502 may provide the second key pair to the device through the RAN node, and the device may store the second key pair as part of its NSAP security context, as described herein and further described with reference to block 530. In some aspects, the AM sends a device key message to the RAN node, the device key message including at least one of the device public key and the device private key, and the RAN node then provides the device with the device public key and / or the device private key. If the RAN node receives the device key message, the RAN node sends a confirmation of receiving the device key message. In some aspects, as described herein, the device may use the second key pair to perform secure NSAP communications with the NSF. In some aspects, the AM 502 may provide the DL re-encryption key to the RAN node, and the RAN node may store the DL re-encryption key as part of its NSAP security context, as described herein and further described with reference to block 530. In some aspects, the RAN node 202 may use the DL re-encryption key to support secure NSAP communications in the DL direction from the NSF to the device, as described herein. For example, the AM provides the DL re-encryption key via a RAN configuration request.

[0229] In some aspects, the NSAP context on the AM may indicate whether the NSAP security context has been established in the device. In some aspects, the AM 502 may perform operations at block 528 only if the NSAP context on the AM indicates that the NSAP security context has not been established in the device.

[0230] In some aspects, process 500 may also include one or more operations performed at block 530. Block 530 may be related to the configuration of the NSAP context at the device. In one aspect, AM 502 may provide the second key pair to the device via RAN node 202. In some aspects, the second key pair may be in the form of a value or a reference. In some aspects, AM 502 and device 106 may negotiate a key, for example, via NSAP communication. When the second key pair is provided to the device in the form of a value, AM 502 may use the key to securely send the second key pair to the device (e.g., as part of an NSAP message sent to the device). In some aspects, after receiving the second key pair, device 106 may send a confirmation to AM (e.g., as part of an NSAP message sent to AM) to confirm the recipient. Based on the confirmation, AM 502 may identify that the NSAP security context has been established in the device. Then, AM 502 may update its local NSAP context accordingly.

[0231] In some aspects, one or more operations performed at 530 may be integrated with operations performed in sending network message 536 and operations performed in sending network message 538, as further described herein.

[0232] In some aspects, such as when the AM 502 does not perform the operations at block 528 , the operations performed at block 530 may be optional.

[0233] In some aspects, the process 500 may also include one or more operations performed at block 532. Block 532 may involve configuration of a NSAP context at a RAN node. In one aspect, the AM 502 may configure the RAN node 202 by sending a configuration request to the RAN node 202. In some aspects, the configuration request sent to the RAN node may be referred to as a RAN configuration request. In one aspect, the AM 502 may notify the RAN node 202 of the association between the NS context and the NS session by including the NS context ID and the NS session ID in the configuration request. In some aspects, the AM 502 may include information about the NSF (e.g., NSF ID or address) in the configuration request. In some aspects, if the AM 502 receives routing information for the NS session in the notification response 522 (from the NSF), the AM 502 may include the routing information in the configuration request.

[0234] In some aspects, the AM 502 may inform the RAN node 202 whether to apply NSAP security to the NS context identified by the NS context ID. The AM 502 may do so by including an NSAP command in the configuration request, wherein the NSAP command indicates whether to apply NSAP security to the NS context identified by the NS context ID.

[0235] In some aspects, one or more operations at block 532 may also include the AM 502 providing a UL re-encryption key to the RAN node 202. The UL re-encryption key may be distributed by the operations performed at block 526.

[0236] In some aspects, if the AM 502 performs one or more operations at block 528 (eg, assigning NSAP security parameters to the device) and assigns a DL re-encryption key, the AM 502 may also provide the DL re-encryption key to the RAN node when performing operations at block 532.

[0237] In some aspects, the AM 502 may provide the UL re-encryption key and the DL re-encryption key to the RAN node in the form of a value or a reference by including the key or a reference to the key in a configuration request.

[0238] In some aspects, upon receiving the configuration request, the RAN node 202 may store information about the NSF and routing information (if routing information was included in the configuration request) as part of an NS session context associated with the NS session identified by the NS session ID.

[0239] As described elsewhere herein, an NSF serving an NS context receives and processes a service request associated with the NS context. The NS context may include information identifying the corresponding network service. In some aspects, the NS context may also include information identifying one or more of the following: related devices, related network slices, related system modules or service modules, related applications, related data sources, and related data networks.

[0240] In addition, as also discussed elsewhere herein, NS sessions are used to transmit messages. The NS session context of an NS session essentially describes how messages are transmitted. For example, the NS session context may include one or more of an NS session ID, routing information, and the routing information includes information that can be used to reach the other end of a tunnel associated with the NS session, such as a tunnel type, a protocol type, an address, a port number, a tunnel ID, and a tunnel endpoint ID.

[0241] The RAN node 202 may update its local NSAP context according to the configuration request as follows.

[0242] In some aspects, the RAN node 202 may store an association between the NS context ID and the NS session ID in the NSAP context. The RAN node 202 may associate the UL re-encryption key with the NS session ID and store the association and the UL re-encryption key (or a reference to the UL re-encryption key) in the NSAP context.

[0243] In some aspects, if the configuration request includes a DL re-encryption key, the RAN node 202 may associate the DL re-encryption key with the device and store the association and the key in the NSAP context.

[0244] In some aspects, the RAN node may also update its local NSAP context based on the NSAP command in the configuration request. The RAN node may record or store in its local NSAP context whether NSAP security is applied to the NS context, as indicated in the NSAP command. In some aspects, the RAN node may record or store this information (indicating whether NSAP security is applied to the NS context) in the form of a security indication in the NSAP handling rules associated with the NS context ID.

[0245] In some aspects, the RAN node 202 may optionally acknowledge the configuration request by sending a RAN response or configuration response indicating receipt of the RAN configuration request to the AM 502. The AM 502 may receive the RAN response or configuration response in response.

[0246] In some aspects, process 500 may include one or more operations performed at block 534. In one aspect, at block 534, AM 502 may configure the NSF by sending a configuration request to the NSF. In some aspects, the configuration request sent to the NSF node may be referred to as an NSF configuration request. If information about the RAN node (e.g., RAN node ID) is not provided to the NSF in the service request notification 518, the AM 502 may include the information in the configuration request.

[0247] In some aspects, AM 502 may inform the NSF whether to apply NSAP security to the NS context identified by the NS context ID. AM 502 may do this by including the NS context ID and the NSAP command in the configuration request, wherein the NSAP command indicates whether to apply NSAP security to the NS context identified by the NS context ID.

[0248] In some aspects, the AM 502 may provide the first key pair to the NSF as a value or reference, for example, by including the first key pair or a reference to the first key pair in a configuration request.

[0249] In some aspects, the NSF 504 may process the configuration request. When processing the configuration request, the NSF 504 may store information about the RAN node (if the information was included in the configuration request) as part of an NS session context associated with the NS session identified by the NS session ID. In some aspects, the NSF 504 may also associate the first key pair with the NS session ID and store the association and the key (or a reference to the key) in its local NSAP context.

[0250] In some aspects, the NSF may also update its local NSAP context according to the NSAP command in the configuration request. The NSF may record or store in its local NSAP context whether NSAP security is applied to the NS context, as indicated in the NSAP command. In some aspects, the NSF may record or store this information (indicating whether NSAP security is applied to the NS context) in the form of a security indication in the NSAP processing rules associated with the NS context ID.

[0251] In some aspects, the NSF may optionally acknowledge the configuration request by sending an NSF response or a configuration response indicating receipt of the NSF configuration request to the AM. The AM may receive the NSF response (or configuration response) in response.

[0252] In some aspects, one or more operations performed at block 534 may be integrated with operations performed in steps of sending service request notification 518, processing (520) the service request, and sending notification response 522. For example, in one aspect, a configuration request may be integrated with service request notification 518, and a configuration response may be integrated with notification response 522. Similarly, NSF processing of the configuration request may be integrated with NSF processing of the service request (520) (see operations at block 520). In these aspects, operations at block 524 may be performed before step 518 and after step 514, and before or after step 516.

[0253] In some aspects, the process 500 may also include the AM 502 sending a NSAP message to the RAN node. In some aspects, the NSAP message may be a response message to the request or device message 514. The NSAP message may include the NS context ID and the service response. The service response may be included in the NSAP message as a NSAP message or as part of a NS message. In some aspects, the NSAP message may be referred to as a network message 536.

[0254] In some aspects, the AM 502 may inform the RAN node 202 whether to apply NSAP security to the NS context identified by the NS context ID. The AM 502 may do so by including an NSAP command in a network message, wherein the NSAP command indicates whether to apply NSAP security to the NS context identified by the NS context ID.

[0255] In some aspects, before sending the network message 536 to the RAN node 202, the AM 502 may process the network message according to its local NSAP context, as described elsewhere herein.

[0256] In some aspects, one or more operations performed in sending the network message 536 may be integrated with operations performed at block 532, such as, for example, with a configuration request sent from the AM to the RAN node.

[0257] In some aspects, process 500 may also include RAN node 202 sending network message 538 to device 106. In some aspects, prior to sending device message 538, RAN node 202 may process the network message in accordance with its local NSAP context, as described herein. After receiving network message 538 from RAN node 202, device 106 may process network message 538 in accordance with its local NSAP context, as described herein. Device 106 may retrieve a service response from network message 538.

[0258] In some aspects, the device 106 may update its local NSAP context based on the network message 538. The device may record or store in its local NSAP context whether NSAP security is applied to the NS context, as indicated in the network message (in some embodiments, as indicated in the NSAP command in the network message). In some aspects, the device may record or store this information (indicating whether NSAP security is applied to the NS context) in the form of a security indication in the NSAP handling rules associated with the NS context ID.

[0259] According to some aspects, for example, in process 500, NSAP contexts can be established at a device, a RAN node, and an NSF such that direct communication between the device and the NSF can occur with NSAP security activated as needed.

[0260] In some aspects, the device 106 can access the network service about the NS context by sending a service request to the NSF serving the NS context. The service request can be sent via an NSAP message (referred to as a device message). The device message can include the NS context ID and the service request. The device can send the device message to the RAN node. The RAN node can process the device message and send it to the NSF using the NS session corresponding to the NS context. The NSF can process the service request and send the service response back to the device. The service response can also be transmitted to the device via an NSAP message (referred to as a network message). NSAP security can be applied to device messages and network messages, as described elsewhere herein.

[0261] Figure 6 Another process for requesting a network service according to one aspect is shown. Process 600 may refer to a network service request process in which a RAN node identifies a NS session corresponding to an NS context.

[0262] In one aspect, process 600 may include device 106 requesting access to a NS for a NS context by sending a NSAP message to RAN node 202. The NSAP message may be referred to as a device message 610. In one aspect, device message 610 may include a NS context ID and a NS message. The NS message may be referred to as a service request. The NS may include NS information and NS operation instructions.

[0263] In some aspects, one or more operations performed in process 600 when device 106 sends device message 610 may be similar to one or more operations performed in process 500 when device 106 sends device message 510 .

[0264] In some aspects, process 600 may also include one or more operations at block 612. In one aspect, RAN node 202 may identify, select, or determine a NS session associated with the NS context ID, as indicated in its local NSAP context.

[0265] In some aspects, process 600 may also include RAN node 202 transmitting device message 614 using the NS session. In some aspects, RAN node 202 may process the device message according to its local NSAP context, as described elsewhere herein, prior to transmitting device message 614. RAN node 202 may then transmit device message 614 to NSF 602 associated with the NS session.

[0266] In some aspects, process 600 may also include one or more operations at block 616. In some aspects, at block 616, NSF 602 may process the device message according to its local NSAP context, as described elsewhere herein. NSF 602 may retrieve a service request from the device message.

[0267] In some aspects, NSF 602 can process the service request. When processing the service request, NSF 602 can authorize the service request. NSF 602 can also update the NS context according to the NS information described in the service request. In some aspects, if the service request includes an NS operation instruction, when NSF 602 processes the service request, it can use the corresponding parameters included in the NS operation instruction to perform one or more NS operations identified in the NS operation instruction for the NS context.

[0268] In some aspects, process 600 may also include NSF 602 responding to the service request by sending an NSAP message using an NS session, wherein the NSF receives the device message on the NS session. The NSAP message may include the NS context ID and the service response. The service response may indicate that the service request has been accepted. The NSAP message may be referred to as a network message 618.

[0269] In some aspects, prior to sending network message 618, NSF 602 may process the network message according to its local NSAP context, as described elsewhere herein.

[0270] In some aspects, process 600 may also include RAN node 202 sending network message 620 to device 106. In some aspects, prior to sending the network message, RAN node 202 may process the network message according to its local NSAP context, as described elsewhere herein.

[0271] In some aspects, after receiving the network message from the RAN node 202, the device 106 can process the network message 620 according to its local NSAP context, as described elsewhere herein. In some aspects, the device 106 can retrieve a service response from the network message 620.

[0272] According to some aspects, for example, in process 600, the device may communicate directly with the NSF (through the RAN node, but without involving other network entities in the communication network). Therefore, the communication between the device and the NSF may have less latency and overhead than in the prior art.

[0273] In some aspects, when the NSF is serving the NS context, the role played by the NSF is the service NSF of the NS context (i.e., the service NSF role), and receives and processes service requests associated with the NS context. The NSF playing the service NSF role of the NSF context can be referred to as the service NSF of the NS context. The service NSF role of the NS context can be relocated from one NSF to another NSF, which can be referred to as NSF relocation.

[0274] In some aspects, NSF relocation of NS context may occur, for example, when a device associated with the NS context moves and is handed over to a new RAN node. In some aspects, NSF relocation of NS context may occur when the serving NSF of the NS context is overloaded (e.g., serving multiple NS contexts, and the number exceeds a threshold or is not less than a threshold). In some aspects, NSF relocation of NS context may occur when network conditions change (e.g., delay, rate, throughput, delay jitter), where network conditions refer to conditions between the device associated with the NS context and the NSF.

[0275] In some aspects, during NSF relocation, a new NSF may be selected to serve the NS context, and the NS context may be transferred from the old NSF (playing the role of the serving NSF before the NSF relocation) to the new NSF. After the NSF relocation, the new NSF may start serving the NS context and become the serving NSF, and the service request associated with the NS context is transmitted to the new NSF.

[0276] Figure 7 A process for NSF relocation according to one aspect is shown. Process 700 involves relocating an NSF based on a trigger. In one aspect, process 700 may include AM 502 receiving a trigger for relocating a serving NSF for an NS context. In some aspects, the trigger may be associated with a handover (e.g., a handover notification 710 received from a RAN node 706), which in some embodiments may be a target RAN node for the handover, and in some embodiments may be a source RAN node for the handover.

[0277] In some aspects, the trigger may come from the old NSF 702 (i.e., the NSF currently serving the NS context). For example, the trigger may be a relocation request 712 received from the old NSF 702 indicating that NSF relocation or reselection is required. The relocation request may indicate the NS context ID. The old NSF 702 may be Figure 5 NSF 504 or Figure 6 NSF 602.

[0278] In some aspects, the trigger may be related to an internal decision 714 of the AM 502. For example, the AM 502 may decide to perform NSF reselection for one or more reasons (eg, to balance workloads on the NSFs, to reduce network congestion, etc.).

[0279] In some aspects, process 700 may include AM 502 reselecting 716 a NSF to serve the NS context. The reselected or selected NSF may be denoted as new NSF 704.

[0280] In some aspects, the AM 502 may use the NRF to reselect the NSF, i.e., the new NSF 704. In some aspects, one or more operations involved in reselecting the NSF using the NRF in process 700 may be similar to one or more operations involved in selecting (516) the NSF using the NRF in process 500. In some aspects, the NBF may not be used for the reselection (716) of the new NSF 704 in process 700 because there is no binding between the new NSF 704 and the NS context. Therefore, in some aspects, the reselection (716) of the new NSF may be done by the NRF to create a binding so that the serving NSF role can be relocated from the old NSF 702 to the new NSF 704.

[0281] In some aspects, process 700 may also include AM 502 notifying new NSF 704 that the new NSF is reselected to serve the NS context by sending a relocation notification 718 to the new NSF 704. In some aspects, the relocation notification may include the NS context ID. In some aspects, the relocation notification may also include information about the old NSF, such as an ID or address of the old NSF.

[0282] In some aspects, according to the relocation notification 718, the new NSF 704 can associate the NS context with the NS session and update its local NSAP context accordingly. For example, the new NSF 704 can store the mapping relationship between the NS context ID and the NS session ID in the NSAP context. The NS session ID can identify the NS session. The NS session can be between the RAN node and the NSF 704 and is for the device 106. In some aspects, the NS session is an existing NS session (if there is an existing NS session). In some aspects, the NS session is a newly created NS session (if there is no existing NS session). In some aspects, when the NSF creates the NS session, the NS session ID can be generated by the NSF.

[0283] In some aspects, process 700 may also include new NSF 704 responding to the relocation notification by sending a notification response 720 to AM 502 .

[0284] When sending the notification response 720, the new NSF 704 may notify the AM of the association between the NS context and the NS session by including the NS context ID and the NS session ID in the notification response. In some aspects, the notification response 720 may also include an indication indicating whether the NS session is a newly created NS session or whether the NS session requires NSAP security parameters. In some aspects, the AM will determine whether to perform one or more operations at block 724 (i.e., whether to allocate NSAP security parameters for the NS session) based on the indication, as further described herein.

[0285] In some aspects, the new NSF 704 may allocate routing information for the NS session and include the routing information in the notification response 720. The routing information may specify how the NS session communicates to reach the NSF 704.

[0286] In some aspects, process 700 may also include AM 502 sending a NSAP message to the device (eg, network message 722). The NSAP message may include the NS context ID and NSAP command 1. NSAP command 1 may indicate to suspend (or pause or stop) NSAP communications associated with the NS context ID.

[0287] In some aspects, based on the NSAP message (particularly the NSAP command 1 in the NSAP message), the device 106 may terminate (or suspend or stop) NSAP communications associated with the NS context ID, for example, stop processing UL NSAP messages including the NS context ID, and cache (not send or transmit) UL NSAP messages including the NS context ID.

[0288] In some aspects, process 700 may also include one or more operations at block 724 involving allocation of NSAP security parameters. In some aspects, the one or more operations at block 724 may be similar to the one or more operations at block 524 of process 500. For example, the one or more operations at block 724 may involve allocation of NSAP security parameters for NS sessions at block 726, which may be similar to the one or more operations at block 526 of process 500 (involving allocation of NSAP security parameters for NS sessions).

[0289] In some aspects, one or more operations at block 724 may include AM 502 determining whether to apply NSAP security to the NS context based on the location of the NSF. In some aspects, if the NSF is located in the CN (e.g., a CN NSF), AM 502 may determine to apply NSAP security to the NS context. In some aspects, if the NSF is located in the RAN (i.e., if the NSF is a RAN NSF), AM 502 may determine not to apply NSAP security. In some aspects, if the NSF is located in the RAN, but not inside the RAN node 706 (in some aspects the RAN node 706 may be a serving RAN node of the device 106), AM 502 may determine to apply NSAP security. In some aspects, AM 502 may decide based on a local configuration, e.g., as indicated in the local configuration.

[0290] If AM 502 determines to apply NSAP security to the NS context, AM 502 may allocate NSAP security parameters to support secure NSAP communications associated with the NS context between the device and the NSF, as described with reference to block 726. If AM 502 determines not to apply NSAP security to the NS context, AM 502 may skip the operations performed with reference to block 726.

[0291] In some aspects, one or more operations at block 724 may be related to one or more operations at block 726 (involving assigning NSAP security parameters for the NS session). In some aspects, one or more operations at block 726 may be similar to one or more operations performed in process 500 with reference to block 526, involving assigning NSAP security parameters for the NS session.

[0292] In some aspects, one or more operations at block 726 may include the AM 502 assigning NSAP security parameters to the NS session. In some aspects, the NSAP security parameters for the NS session may include a first key pair (e.g., a public key and a private key) and a UL re-encryption key. The UL re-encryption key may be associated with a public key in the first key pair, for example, generated or derived based on the public key in the first key pair. In some aspects, the AM 502 may provide the first key pair to the NSF 704, and the NSF 704 may store the received first key pair as part of its NSAP security context, as described elsewhere herein, and further described with reference to block 734. The first key pair may be used by the NSF to perform secure NSAP communications with the device, as described elsewhere herein. In some aspects, the AM 502 may provide the UL re-encryption key to the RAN node 706, and the RAN node may store the UL re-encryption as part of its NSAP security context, as described herein and further described with reference to block 732. The UL re-encryption key may be used by the RAN node to support secure NSAP communications in the UL direction from the device to the NSF, as described herein.

[0293] In some aspects, the AM 502 may perform one or more operations at block 726 based on an indication in the received notification response 720. If the indication indicates that the NS session is a newly created NS session, or that the NS session requires NSAP security parameters, the AM 502 may perform one or more operations at block 726. Otherwise, the AM 502 may skip the operations at block 726.

[0294] In some aspects, process 700 may also include performing one or more operations at block 732 involving configuration of an NSAP context at a RAN node. In one aspect, AM 502 may configure RAN node 702 by sending a configuration request to RAN node 702. In one aspect, AM 502 may notify RAN node 702 of the association between the NS context and the NS session by including the NS context ID and the NS session ID in the configuration request. In some aspects, AM 502 may include information about the NSF (e.g., the NSF ID or address) in the configuration request. In some aspects, if AM 502 receives routing information for the NS session in the notification response 720 (from the NSF), then AM 502 may include the routing information in the configuration request.

[0295] In some aspects, the AM 502 may inform the RAN node 702 whether to apply NSAP security to the NS context identified by the NS context ID. The AM 502 may do so by including an NSAP command in the configuration request, wherein the NSAP command indicates whether to apply NSAP security to the NS context identified by the NS context ID.

[0296] In some aspects, one or more operations at block 732 may also include the AM 502 providing a UL re-encryption key to the RAN node 702. The UL re-encryption key may be distributed by the operations performed at block 726.

[0297] In some aspects, the AM 502 may provide the UL re-encryption key to the RAN node in the form of a value or reference by including the key or a reference to the key in a configuration request.

[0298] In some aspects, upon receiving the configuration request, the RAN node 702 may store information about the NSF and routing information (if routing information is included in the configuration request) as part of the NS session context associated with the NS session identified by the NS session ID. The RAN node 702 may update its local NSAP context according to the configuration request as follows.

[0299] In some aspects, the RAN node 702 may store an association between the NS context ID and the NS session ID in the NSAP context. The RAN node 702 may associate the UL re-encryption key with the NS session ID and store the association and the UL re-encryption key (or a reference to the UL re-encryption key) in the NSAP context.

[0300] In some aspects, the RAN node may also update its local NSAP context based on the NSAP command in the configuration request. The RAN node may record or store in its local NSAP context whether NSAP security is applied to the NS context, as indicated in the NSAP command. In some aspects, the RAN node may record or store this information (indicating whether NSAP security is applied to the NS context) in the form of a security indication in the NSAP handling rules associated with the NS context ID.

[0301] In some aspects, the RAN node 702 may optionally acknowledge the configuration request by sending a configuration response to the AM 502 .

[0302] In some aspects, process 700 may include performing one or more operations at block 734 involving configuration of an NSAP context at the NSF. In one aspect, one or more operations at block 734 may include the AM 502 configuring the NSF by sending a configuration request to the NSF 704. If information about the RAN node 706 (e.g., an address or ID of the RAN node) is not provided to the NSF in the relocation notification 718, the AM 502 may include the information in the configuration request. In some embodiments, information about the RAN node may be provided to the NSF in the relocation notification 718, and the AM 502 may not include the information about the RAN node in the configuration request.

[0303] In some aspects, AM 502 may inform NSF 704 whether to apply NSAP security to the NS context identified by the NS context ID. AM 502 may do so by including the NS context ID and the NSAP command in a configuration request sent to the NSF, wherein the NSAP command indicates whether to apply NSAP security to the NS context identified by the NS context ID.

[0304] In some aspects, AM 502 may provide the first key pair to NSF 704 as a value or reference, for example, by including the first key pair or a reference to the first key pair in a configuration request.

[0305] In some aspects, the NSF 704 may process the configuration request. When processing the configuration request, the NSF 704 may store information about the RAN node (if such information was included in the configuration request) as part of the NS session context associated with the NS session identified by the NS session ID. In some aspects, the NSF 704 may also associate the first key pair (provided from the AM 502 in the configuration request) with the NS session ID and store the association and the key (or a reference to the key) in its local NSAP context.

[0306] In some aspects, the NSF may also update its local NSAP context according to the NSAP command in the configuration request. The NSF may record or store in its local NSAP context whether NSAP security is applied to the NS context, as indicated in the NSAP command. In some aspects, the NSF may record or store this information (indicating whether NSAP security is applied to the NS context) in the form of a security indication in the NSAP processing rules associated with the NS context ID.

[0307] In some aspects, the NSF 704 may optionally acknowledge the configuration request by sending a configuration response to the AM 502 .

[0308] In some aspects, process 700 may also include AM 502 notifying old NSF 702 to perform relocation by sending relocation notification 736 to old NSF 702. Relocation notification 736 may include NS context ID. In some aspects, relocation notification may also include information about new NSF, such as ID or address of new NSF.

[0309] In some aspects, if the AM receives a relocation request 712 from the old NSF 702 , the relocation notification 736 may be used as a response to the relocation request 712 .

[0310] In some aspects, process 700 may also include a transfer of NS context 738. Based on the relocation notification 736 received from AM 502, old NSF 702 may perform a NS context transfer 738 with new NSF 704. In some aspects, the transfer of NS context may involve old NSF 702 sending the NS context to new NSF 704 directly or through AM 502.

[0311] In some aspects, process 700 may also include old NSF 702 responding to the relocation notification by sending a notification response 740 to AM 502. Notification response 740 may indicate that the NS context has been transferred to the new NSF.

[0312] In some aspect, process 700 may also include AM 502 sending a NSAP message to the device (network message 742). In some aspects, the NSAP message may include the NS context ID and NSAP command 2. NSAP command 2 may indicate that the device may resume (or restart) NSAP communications associated with the NS context ID.

[0313] According to the NSAP message (particularly the NSAP command 2 in the NSAP message), the device 106 may resume (or restart) the NSAP communication associated with the NS context ID. For example, the device 106 may perform one or more of the following: stop caching the UL NSAP message including the NS context ID, send the cached UL NSAP message including the NS context (if any), and restart or resume processing the UL NSAP message including the NS context.

[0314] According to one aspect, the process for NSF relocation, for example process 700, can improve communication efficiency and network performance.NSF relocation can make the service NSF be relocated according to one or more of the following: equipment mobility, NSF load and network conditions.In some respects, communication efficiency can be improved by allowing shorter communication path, because the service NSF role can be relocated to the NSF closer to equipment.In some respects, network performance can be improved by reducing the delay of processing the service request from equipment.In some respects, for example, when the position of new NSF is different from the position of old NSF (for example, NSF position changes to RAN from CN, and vice versa), NSF relocation can realize dynamic activation or deactivation of NSAP security.

[0315] Figure 8 A device 800 is shown that can perform any or all operations of the above methods and features described herein explicitly or implicitly according to different aspects of the present disclosure. For example, a computer equipped with network functions can be configured as a device 800. In some aspects, the device 800 can be an AM 502, a device 106, a RAN node, an NSF (e.g., a RAN NSF or a CN NSF), or any other entity described herein. In some aspects, the device 800 can be a device connected to a network infrastructure via a wireless interface, such as a mobile phone, a smart phone, or other such devices that can be classified as user equipment (UE). In some aspects, the device 800 can be a machine type communication (MTC) device (also referred to as a machine-to-machine (m2m) device), or other such devices that can be classified as UEs, although direct services are not provided to users. In some aspects, the device 800 can be used to implement one or more aspects described herein. For example, the device 800 can be used to perform operations performed by one or more entities and functions described herein.

[0316] As shown, the device 800 may include a processor 810 (e.g., a central processing unit (CPU) or a special processor, such as a graphics processing unit (GPU), or other such processor unit), a memory 820, a non-transitory mass storage 830, an input / output interface 840, a network interface 850, and a transceiver 860, all of which are communicatively coupled via a bidirectional bus 870. According to certain aspects, any or all of the elements shown may be used, or only a subset of the elements shown may be used. In addition, the device 800 may include multiple instances of certain elements, such as multiple processors, multiple memories, or multiple transceivers. In addition, elements of the hardware device may be directly coupled to other elements without a bidirectional bus. In addition to or in place of processors and memories, other electronic components such as integrated circuits may be used to perform the desired logical operations.

[0317] The memory 820 may include any type of non-transitory memory, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), read-only memory (ROM), or any combination thereof. The mass storage 830 may include any type of non-transitory storage device, such as a solid-state drive, a hard disk drive, a disk drive, an optical drive, a USB drive, or any computer program product for storing data and machine executable program code. According to certain aspects, the memory 820 or the mass storage 830 may record therein statements and instructions executable by the processor 810 for performing any of the above-described method operations.

[0318] Aspects of the present disclosure may be implemented using electronic hardware, software, or a combination thereof. In some aspects, this may be implemented by one or more computer processors executing program instructions stored in a memory. In some aspects, the present invention may be implemented in part or in whole in hardware, for example, using one or more field programmable gate arrays (FPGA) or application specific integrated circuits (ASIC) to quickly perform processing operations.

[0319] It should be understood that although specific aspects of the technology are described herein for illustrative purposes, various modifications may be made without departing from the scope of the technology. Accordingly, the specification and drawings are to be viewed simply as an illustration of the invention as defined by the appended claims, and are contemplated to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the invention. In particular, providing a computer program product, a program element, or a program storage device such as a magnetic or optical wire, tape or optical disk for storing machine-readable signals for controlling the operation of a computer according to the method of the present technology, and / or for constructing some or all of its components according to the system of the present technology is within the scope of the present technology.

[0320] The actions associated with the methods described herein may be implemented as coded instructions in a computer program product. In other words, a computer program product is a computer-readable medium on which software codes are recorded to perform the methods when the computer program product is loaded into a memory and executed on a microprocessor of a wireless communication device.

[0321] In addition, each operation of the method can be performed on any computing device (e.g., personal computer, server, PDA, etc.), and can be performed according to one or more program elements, modules or objects or a part of one or more program elements, modules or objects generated from any programming language (e.g., C++, Java, etc.). In addition, each operation or a file or object that implements each operation, etc. can be performed by dedicated hardware or a circuit module designed for this purpose.

[0322] Through the description of the above aspects, the present invention can be implemented only by hardware, or by software and necessary general hardware platforms. Based on this understanding, the technical solution of the present invention can be embodied in the form of a software product. The software product can be stored in a non-volatile or non-transient storage medium, which can be a compact disc read-only memory (CD-ROM), a USB flash drive, or a removable hard disk. The software product includes many instructions that enable a computer device (a personal computer, a server, or a network device) to perform the methods provided in various aspects of the present invention. For example, this execution can correspond to the simulation of the logical operations described herein. According to various aspects of the present invention, the software product may additionally or alternatively include a plurality of instructions that enable a computer device to perform operations to configure or program a digital logic device.

[0323] Although the present invention has been described with reference to certain features and aspects thereof, it is apparent that various modifications and combinations are possible without departing from the scope of the invention. Accordingly, the specification and drawings are to be regarded simply as illustrations of the invention as defined by the appended claims, and are contemplated to cover any and all modifications, variations, combinations or equivalents that fall within the scope of the invention.

Claims

1. A method comprising: An access manager (AM) receives a first request for a network service (NS) from a radio access network (RAN) node, the first request including information identifying the NS and an NS context identifier (ID) identifying a NS context; The AM selects a network service function (NSF) according to the first request; The AM sends a service request notification to the NSF, where the service request notification includes information in the first request; The AM receives a service response from the NSF, the service response corresponding to the service request notification and indicating whether the information in the first request to the NS has been accepted; The AM sends a response message to the RAN node, where the response message includes the NS context ID and an encrypted service response, wherein the encrypted service response is obtained by encrypting the service response.

2. The method according to claim 1, wherein: The first request for the NS includes one or more of the following: a service name or ID, a device ID, a slice ID, an application ID, a data network ID, one or more NS operations to be performed for the NS context identified by the NS context ID, and an ID of each of the one or more NS operations.

3. The method according to claim 1 or 2, wherein: The first request to the NS is obtained by: the RAN node re-encrypting the second request according to a Network Service Access Protocol (NSAP) processing rule of the NSAP context on the RAN node using a public key associated with the AM; the method further comprising: Before selecting the NSF, the AM decrypts the first request using a private key in the NSAP context on the AM.

4. The method according to claim 3, wherein: The second request is sent by the device to the RAN node, and the second request is encrypted using the public key of the device according to the NSAP processing rule of the NSAP context on the device, and the NSAP context on the device is associated with the NS context ID.

5. The method according to any one of claims 1 to 4, wherein: The AM selecting the NSF according to the first request includes: The AM sends a third request for identifying the NSF to a network binding function (NBF), wherein the third request includes the NS context ID; The AM receives a response indicating the NSF from the NBF.

6. The method according to any one of claims 1 to 4, wherein: The AM selecting the NSF according to the request includes: The AM sends a third request to a network registration function (NRF) for identifying the NSF, wherein the third request includes the location and NS information of the device; The AM receives a response from the NRF indicating the NSF and the location of the NSF.

7. The method according to any one of claims 1 to 4, wherein: The AM selecting the NSF according to the first request includes: The AM sends a third request to the network function, wherein the third request includes any one of the location of the device, the NS information, and the NS context ID; The AM receives a response from the network function indicating the NSF and the location of the NSF.

8. The method according to claim 6, wherein: The AM selecting the NSF according to the first request includes selecting the NSF based on one or more of the following: the network service provided by the NSF and identified in the NS information; a service area of ​​the NSF covering the location of the device; The location of the NSF; The NSF belongs to the network slice identified in the NS information; The NSF is used to provide services for the application, subsystem or dedicated network service identified in the NS information.

9. The method according to any one of claims 1 to 8, wherein: The service response includes one or more of the following: The NS context ID, NS session ID; A first indication, indicating that the NS session identified by the NS session ID is a newly created NS session; a second indication, indicating that the NS session requires one or more NSAP security parameters; The NS session is used for routing information to reach the NSF.

10. The method according to any one of claims 1 to 9, wherein: The encrypted service response is obtained in the following manner: the AM encrypts the service response according to the NSAP context on the AM using the key of the AM.

11. The method according to any one of claims 1 to 10, wherein: The response message includes a command indicating whether to apply NSAP security to the NS context identified by the NS context ID.

12. The method according to any one of claims 1 to 11, further comprising: The AM determines to apply the NSAP security parameters to the NS context based on the location of the NSF; The AM allocates the NSAP security parameters to support secure communication between a device and the NSF, the communication being associated with the NS context.

13. The method according to claim 12, wherein: The location of the NSF is one of the following: Core Network (CN) of wireless communication network; The wireless communication network is located outside the area covered by the RAN node of the device.

14. The method according to claim 12 or 13, wherein: The NSAP security parameters include a device public key and a device private key, and the method further includes: The AM sends a device key message to the RAN node, where the device key message includes at least one of the device public key and the device private key.

15. The method according to claim 14, further comprising: The AM receives an acknowledgement of receipt of the Device Key message from the RAN node.

16. The method according to claim 14 or 15, wherein: The device key message is encrypted using a key, and the method further comprises: The AM negotiates a key with the device.

17. The method according to any one of claims 12 to 16, wherein: The NSAP security parameters include an uplink (UL) re-encryption key associated with the NS session and a downlink (DL) re-encryption key associated with the device.

18. The method according to claim 17, further comprising: The AM sends a RAN configuration request to the RAN node, and the RAN configuration request includes one or more of the following: the NS context ID, the NS session ID, the NSF ID or address, the routing information for reaching the NSF, a command indicating whether to apply NSAP security to the NS context, the UL re-encryption key, and the DL re-encryption key.

19. The method according to claim 18, further comprising: The AM receives a RAN response from the RAN node, the RAN response indicating receipt of the RAN configuration request.

20. The method according to any one of claims 12 to 19, wherein: The NSAP security parameters include an NSF public key and an NSF private key.

21. The method according to claim 20, further comprising: The AM sends an NSF configuration request to the NSF, where the NSF configuration request includes one or more of the following: an ID of the RAN node, a command indicating whether to apply NSAP security to the NS context, the NSF public key, and the NSF private key.

22. The method according to claim 21, further comprising: The AM receives an NSF response from the NSF, the NSF response indicating receipt of the NSF configuration request.

23. A method comprising: The device sends a second request for a network service (NS) to a radio access network (RAN) node, the second request including information identifying the NS and an NS context identifier (ID) identifying the NS context; The device receives a network message including the NS context ID and a re-encrypted service response, wherein the re-encrypted service response indicates whether the information in the second request has been accepted.

24. The method according to claim 23, wherein: The network message also includes a command indicating whether to apply Network Service Access Protocol (NSAP) security to the NS context.

25. The method according to claim 23 or 24, further comprising: The device updates the NSAP context on the device according to the network message; The device performs secure communication with a network service function (NSF) according to the NSAP context on the device, the secure communication being associated with the NS context.

26. The method according to any one of claims 23 to 25, wherein: The network message also includes one or more keys for supporting the secure communication, the one or more keys including: a device public key and a device private key.

27. The method according to claim 26, further comprising: The device encrypts an uplink (UL) NSAP message using the device public key; The device sends the encrypted UL NSAP message to the RAN node.

28. The method of claim 26, further comprising: The device receives a re-encrypted downlink (DL) NSAP message from the RAN node; The device decrypts the re-encrypted DL NSAP message using the device private key.

29. A method comprising: A radio access network (RAN) node receives a second request for a network service (NS) from a device, the second request including information identifying the NS and an NS context identifier (ID) identifying the NS context; The RAN obtains the first request by encrypting the second request; The RAN node sends the first request for the NS to the AM. The RAN node receives a response message from the AM, the response message including the NS context ID and an encrypted service response, wherein the encrypted service response corresponds to the first request to the NS and indicates whether the first request to the NS has been accepted; The RAN node sends a network message to the device, where the network message includes the NS context ID and a re-encrypted service response, where the re-encrypted service response is obtained by re-encrypting the encrypted service response.

30. The method of claim 29, wherein: The first request is obtained by encrypting the second request according to the NSAP processing rule of the NASP context on the RAN node using a public key associated with the AM.

31. The method according to claim 29 or 30, further comprising: The RAN node receives a RAN configuration request from the AM, the RAN configuration request including one or more of the following: the NS context ID, the NS session ID, the NSF ID or address, routing information for reaching the NSF, a command indicating whether to apply NSAP security to the NS context, a UL re-encryption key, and a DL re-encryption key.

32. The method according to any one of claims 29 to 31, further comprising: The RAN node receives a device key message from the AM, the device key message including at least one of the following: a device public key and a device private key; The RAN node sends a network message to the device, the network message including one or more of the following: the NS context ID, a command indicating whether to apply network service access protocol (NSAP) security to the NS context identified by the NS context ID, the device public key, and the device private key.

33. The method of claim 32, further comprising: The RAN node sends an acknowledgement of receipt of the Device Key message to the AM.

34. The method of claim 31 , further comprising: The RAN node receives an encrypted UL NSAP message from the device; The RAN node re-encrypts the encrypted UL NSAP message using the UL re-encryption key; The RAN node sends the heavily encrypted UL NSAP message to the NSF.

35. The method of claim 31 , further comprising: The RAN node receives the encrypted DL NSAP message from the NSF; The RAN node re-encrypts the encrypted DL NSAP message using the DL re-encryption key; The RAN node sends the re-encrypted DL NSAP message to the device.

36. A method comprising: A network service function (NSF) receives a service request notification from an access manager (AM), the service request notification including information identifying a network service (NS) and an NS context identifier (ID) identifying an NS context; A service response is sent, the service response corresponding to the service request notification and indicating whether the service request notification has been accepted.

37. The method of claim 36, further comprising: The NSF updates the NSAP context on the NSF according to the service request notification; The NSF performs secure communication with a device according to the NSAP context on the NSF, the secure communication being associated with the NS context.

38. The method according to claim 36 or 37, wherein: The service request notification also includes one or more of the following: a command indicating whether to apply network service access protocol (NSAP) security to the NS context identified by the NS context ID, an NSF public key for supporting the secure communication, an NSF private key for supporting the secure communication, and an ID of a radio access network (RAN) node serving the device.

39. The method of claim 38, wherein: The NSF performs secure communication with the device including: The NSF encrypts a downlink (DL) NSAP message using the NSF public key; The NSF sends the encrypted DL NSAP message to the RAN node.

40. The method of claim 38, wherein: The NSF performs secure communication with the device including: The NSF receives a re-encrypted uplink (UL) NSAP message from the RAN node; The NSF decrypts the re-encrypted UL NSAP message using the NSF private key.

41. The method according to any one of claims 36 to 40, further comprising: The NSF receives a service request notification from the AM, where the service request notification includes one or more of the following: NS information and NS operation instructions.

42. A method comprising: The device sends a second request for a network service (NS) to a radio access network (RAN) node, the second request including information identifying the NS and an NS context identifier (ID) identifying the NS context; The RAN node obtains the first request by encrypting the second request; The RAN node sends the first request for the NS to an access manager (AM); The AM selects a network service function (NSF) according to the first request; The AM sends a service request notification to the NSF, where the service request notification includes information in the first request; The AM receives a service response from the NSF, the service response corresponding to the service request notification and indicating whether the information in the first request to the NS has been accepted; The AM sends a response message to the RAN node, where the response message includes the NS context ID and an encrypted service response, wherein the encrypted service response is obtained by encrypting the service response; The RAN node sends a network message to the device, where the network message includes the NS context ID and a re-encrypted service response, where the re-encrypted service response is obtained by re-encrypting the encrypted service response.

43. A method comprising: A radio access network (RAN) node receives a request message for a network service (NS) from a device, the NS being associated with an NS context, the request message including information identifying the NS and an NS context identifier (ID) identifying the NS context; The RAN node determines, based on a Network Service Access Protocol (NSAP) context on the RAN node, a NS session associated with the NS context ID; The RAN node sends the request message to a Network Service Function (NSF) using the NS session; The RAN node receives a response message from the NSF, the response message including the NS context and indicating that the request for the NS has been accepted; The RAN node sends the response message to the device.

44. The method of claim 43, wherein: The request message also includes one or more of the following: a service name or ID, a device ID, a slice ID, an application ID, a data network ID, one or more NS operations to be performed for the NS context identified by the NS context ID, and an ID of each of the one or more NS operations.

45. The method of claim 43 or 44, wherein: Encrypting the request message using a public key of the device; The method further comprises: The RAN node re-encrypts the encrypted request message using an uplink (UL) re-encryption key based on the NSAP context on the RAN node, wherein the NSAP context on the RAN node indicates that NSAP security is applied to the request message.

46. ​​The method of claim 43, further comprising: The RAN node receives a first indication from the device, the first indication indicating that the request message is encrypted.

47. A method according to any one of claims 43 to 46, wherein: The response message is encrypted by the public key of the NSF; The method further comprises: The RAN node re-encrypts the encrypted response message using a downlink (DL) re-encryption key based on the NSAP context on the RAN node, wherein the NSAP context on the RAN node indicates that NSAP security is applied to the response message.

48. The method of claim 43, further comprising: The RAN node receives a second indication from the device, the second indication indicating that the response message is encrypted.

49. A method comprising: An access manager (AM) receives an indication to: relocate a serving network service function (NSF) of a network service (NS) context from an old NSF to a new NSF; The AM reselects or chooses the new NSF to serve the NS context; The AM sends a first relocation notification to the new NSF, where the first relocation notification includes an NS context identifier (ID) identifying the NS context and information identifying the old NSF; The AM receives a first relocation response from the new NSF; The AM sends a first network message to a device associated with the NS context, where the first network message includes a first command, where the first command indicates to suspend communication associated with the NS context ID.

50. The method of claim 49, wherein: The AM reselects or selects the new NSF to serve the NS context including: The AM sends a request to a network registration function (NRF) to identify the new NSF, the request including the location and NS information of the device; The AM receives a response from the NRF indicating the new NSF and the location of the new NSF.

51. The method of claim 49 or 50, wherein: The AM receiving the first relocation response from the new NSF includes: The AM receives one or more of the following from the new NSF: an NS session ID associated with the NS context ID, a first indication indicating whether the NS session identified by the NS session ID is a newly created NS session, a second indication indicating that the NS session requires one or more NSAP security parameters, and routing information for the NS session.

52. The method according to any one of claims 49 to 51, wherein: The location of the new NSF is different from the location of the old NSF, and the method further includes: The AM determines to apply the NSAP security parameter to the NS context; The AM allocates NSAP security parameters to support secure communication between the device and the new NSF, the communication being associated with the NS context.

53. The method of claim 52, wherein: The AM allocating the NSAP security parameter includes: the AM allocating an uplink (UL) re-encryption key associated with the NS session and a downlink (DL) re-encryption key associated with the device, and the method further includes: The AM sends a RAN configuration request to the RAN node, the RAN configuration request including one or more of the following: the NS context ID, the NS session ID, the new NSF ID or address, a first NSAP command indicating whether to apply the NSAP security to the NS context, the routing information for reaching the new NSF, the UL re-encryption key, and the DL re-encryption key; The AM receives a RAN response from the RAN node, the RAN response indicating receipt of the RAN configuration request.

54. The method of claim 52 or 53, wherein: The AM allocating the NSAP security parameters includes: the AM allocating an NSF public key and an NSF private key, and the method further includes: The AM sends an NSF configuration request to the new NSF, where the NSF configuration request includes one or more of the following: an ID of the RAN node, a second NSAP command indicating whether to apply the NSAP security to the NS context, the NSF public key, and the NSF private key; The AN receives an NSF response from the new NSF, the NSF response indicating receipt of the NSF configuration request.

55. The method according to any one of claims 50 to 55, further comprising: The AM sends a second relocation notification to the old SMF, where the second relocation notification includes the NS context ID and information about the new NSF; The AM receives a second relocation response from the old SMF, the second relocation response indicating that the NS context has been transferred to the new NSF; The AM sends a second network message to the device, where the second network message includes a second command, where the second command indicates to resume communication associated with the NS context ID.

56. A system comprising: A device, a radio access network (RAN) node, an access manager (AM), wherein The device is used for: sending a second request for a network service (NS) to the RAN node, the second request comprising information identifying the NS and an NS context identifier (ID) identifying the NS context; The RAN node is used for: Obtaining the first request by encrypting the second request; Sending the first request for the NS to the AM; The AM is used to: selecting a network service function (NSF) according to the first request; Sending a service request notification to the NSF, wherein the service request notification includes information in the first request; receiving a service response from the NSF, the service response corresponding to the service request notification and indicating whether the information in the first request to the NS has been accepted; sending a response message to the RAN node, the response message including the NS context ID and the encrypted service response, wherein the encrypted service response is obtained by encrypting the service response; The RAN node is further configured to: A network message is sent to the device, where the network message includes the NS context ID and a re-encrypted service response, where the re-encrypted service response is obtained by re-encrypting the encrypted service response.

57. An apparatus comprising: at least one processor; At least one machine-readable medium storing executable instructions which, when executed by the at least one processor, configure the apparatus to perform the method according to any one of claims 1 to 55.

58. A computer device comprising a non-transitory computer readable medium having stored therein instructions which, when executed by a computer processor, cause the computer device to perform the method of any one of claims 1 to 55.

Images