Method and apparatus for communication

Abstract

The embodiment of the invention provides a method and device for communication. In the application, an anchor point key is bound with a service GW, and is associated with the name and other information of the service GW. The anchor key is generated by the KMF after mutual authentication between the device and the network is successful. The KMF is a network function responsible for key management, such as anchor key derivation. Compared to the prior art, there is no security context transmission between the old serving GW and the new serving GW because the security context is generated by the KMF and provided to the new serving GW. This may reduce message exchange overhead as well as storage overhead of the GW.

Description

Cross-references to related applications

[0001] This application claims priority to U.S. Provisional Patent Application No. 63 / 586,631, filed September 29, 2023, entitled "System and methods for anchor key generation and configuration in the future network." The disclosure of the above application is incorporated herein by reference in its entirety. Technical Field

[0002] Embodiments of this application relate to the field of wireless technology, and more specifically, to methods and apparatus for communication. Background Technology

[0003] In the 3rd Generation Partnership Project (3GPP), the master authentication and key negotiation process aims to achieve mutual authentication between devices and the network, and to provide an anchor key for indirect key derivation to secure communication between devices and the network. This anchor key is called K. SEAF The security anchor function (SEAF) of the serving network is provided by the authentication server function (AUSF) of the home network. Anchor key binding is achieved by including a parameter called the "serving network name" in a key derivation chain that begins with the long-term user key. Keys for more than one security context can be derived from K. SEAF Indirect derivation without a new authentication process. All these keys are generated by network functions, such as K. AMF The terminal key, generated by the access management function (AMF) for security protection during communication between the device and the AMF, is generated by the AMF. These network functions should store or maintain the security context. Furthermore, if the long-term user key changes, these functions should update the security context associated with that long-term user key. Information exchange between security-related network functions incurs additional overhead during key refresh.

[0004] Due to N2 handover or Protocol Data Unit (PDU) session establishment, the security context of the user equipment (UE) should be transferred from the old gateway (GW) (e.g., AMF) to the new serving GW. This security context should include algorithm parameters and inputs for terminal key derivation. This security context may include new K... AMF Or a terminal key. The transmission of security context may incur message exchange overhead. Summary of the Invention

[0005] Embodiments of this application provide methods and apparatus for communication that can reduce message exchange overhead.

[0006] According to a first aspect, a communication method is provided, which can be executed by a first device or a chip installed in the first device. For example, the first device may be a key management function (KMF). The method includes: receiving a first message from an authentication server (AS), wherein the first message includes the name of a second network function, and the second network function is directly connected to a service provider that provides application services to the device, or directly connected to a network that provides network services to the device; generating an anchor key based on the name of the second network function, wherein the anchor key is used to determine whether authentication is required between the device and the network; and sending a second message to the second network function, wherein the second message includes a first security context of the second network function, wherein the first security context includes a terminal key derived from the anchor key, the terminal key being used to securely protect communication between the device and the second network function.

[0007] According to the scheme proposed in this application, a key management function (KMF) is introduced. The KMF is responsible for generating anchor keys, generating security contexts for the service GW and devices, and maintaining these security contexts. Compared to existing technologies, there is no security context transmission between the old and new service GWs during handover. The security context is generated by the KMF and configured for the new service GW. This reduces the message exchange overhead for key updates, as well as the storage overhead of the GW.

[0008] In one implementation of the first aspect, the first security context includes the ID of the anchor key.

[0009] In this implementation, when a device moves from an old service gateway to a new service gateway, a new anchor key is generated without prior security context, and the anchor key's ID is configured for the new service gateway. This avoids security context exchange during the handover.

[0010] In one implementation of the first aspect, the method further includes: generating a second security context for the device, wherein the second security context includes the ID of the anchor key, and the second security context further includes an algorithm for generating the anchor key or the terminal key.

[0011] In one implementation of the first aspect, the method further includes: sending the second security context to the device.

[0012] In this implementation, the KMF also generates a security context for the device and configures the security context for the device. This means that the serving gateway and other network functions do not maintain security contexts, which reduces the storage overhead of the serving gateway and other network functions.

[0013] In one implementation of the first aspect, the second network function includes a service gateway.

[0014] In one implementation of the first aspect, after sending the second message to the second network function, the method further includes: receiving a third message from the second network function, wherein the third message includes information related to the update of the anchor key.

[0015] The technical effects of the second or third aspect can be referenced from the technical effects of the first aspect, and will not be elaborated further below.

[0016] According to a second aspect, a communication method is provided, which can be executed by a second device or a chip installed in the second device. The method includes: obtaining a first security context of a second network function, wherein the first security context includes a terminal key derived from an anchor key used to determine whether authentication is required between the device and the network, the anchor key being generated based on the name of the second network function, and the terminal key being used to securely protect communication between the device and the second network function; and storing the first security context.

[0017] In one implementation of the second aspect, the first security context includes the ID of the anchor key.

[0018] In one implementation of the second aspect, obtaining the first security context includes: receiving a second message from a first network function, wherein the first network function is responsible for generating the anchor key or the terminal key, and the second message includes the first security context.

[0019] In one implementation of the second aspect, after receiving the second message from the first network function, the method further includes: sending a third message to the first network function, wherein the third message includes information related to the update of the anchor key.

[0020] In one implementation of the second aspect, the information related to the update of the anchor key includes one or more of the following parameters: the frequency of updating the anchor key, and one or more inputs for anchor key derivation.

[0021] In one implementation of the second aspect, before receiving the second message from the first network function, the method further includes: determining whether new authentication is required by comparing the name of the second network function with the name of an old second network function, wherein the second network function is a new second network function selected by the old second network function due to a switch; if the new authentication is not required, sending a fourth message to the first network function, wherein the fourth message includes the name of the second network function and a temporary device information.

[0022] In one implementation of the second aspect, the second network function includes a service gateway.

[0023] According to a third aspect, a communication method is provided, which can be executed by a third device or a chip installed in the third device. The method includes: after successful mutual authentication between a device and an authentication server (AS), obtaining a shared key between the device and the AS; sending a first message to a first network function, wherein the first message includes the name of a second network function, the name of the second network function being used to generate an anchor key, the anchor key being used to determine whether authentication is required between the device and the network.

[0024] According to a fourth aspect, a communication device is provided, the communication device having functions or modules for performing methods in any one of the first to third aspects or any implementation thereof.

[0025] According to a fifth aspect, a chip (or chip system) is provided. The chip includes at least one processor coupled to at least one memory. The at least one memory is used to store one or more instructions and / or executable computer code. The at least one processor is used to invoke the one or more instructions and / or executable computer code to cause a communication device on which the chip is mounted to perform a method of any one of the first to third aspects or any implementation thereof. Optionally, the chip may further include at least one memory. Optionally, the chip may further include a communication interface for inputting and / or outputting information or data.

[0026] According to a sixth aspect, a communication device is provided. The communication device includes one or more circuits and one or more communication interfaces. The one or more communication interfaces may include a first interface and a second interface, wherein the first interface is used to receive (i.e., input) information and / or data to be processed by the one or more circuits, and the second interface is used to transmit (i.e., output) the information and / or data processed by the one or more circuits. The one or more circuits are used to process the information and / or data to be processed, causing the communication device to perform a method of any one of the first to third aspects or any implementation thereof.

[0027] According to a seventh aspect, a communication system is provided. The communication system may include at least one communication device according to any one of the first to third aspects or any implementation thereof.

[0028] According to an eighth aspect, a computer storage medium is provided for storing executable computer code for executing one or more instructions of the method according to any one of the first to third aspects or any implementation thereof.

[0029] According to a ninth aspect, a computer program product is provided, comprising one or more instructions that, when the computer program product is run on a computer, the computer performs the method according to any one of the first to third aspects or any possible implementation thereof. Attached Figure Description

[0030] One or more embodiments have been described by way of example with reference to the accompanying drawings. These exemplary descriptions and drawings are not intended to limit the embodiments. Elements with the same reference numerals in the drawings are shown as similar elements, and the drawings are not limited to scale, wherein: Figure 1 A schematic diagram illustrating the application scenarios provided for embodiments of this application; Figure 2An example of a communication system is shown; Figure 3 Another example of an electronic device (ED) and a base station is shown; Figure 4 An example of a channel model for a MIMO system; Figure 5 An example of the conceptual architecture of a 6G system; Figure 6 An architecture for anchor key management provided for some embodiments of this application; Figure 7 A schematic flowchart illustrating a communication method proposed for some embodiments of this application; Figure 8 Examples of methods provided for embodiments of this application; Figure 9 This is an example of the security context transfer process during service GW reallocation in the case of a system with KMF deployed; Figure 10 This is an example of the security context transfer process during service GW reallocation in the absence of KMF deployment in the system; Figure 11 A schematic block diagram of a communication device provided for embodiments of this application; Figure 12 A schematic block diagram of a communication device provided for embodiments of this application. Detailed Implementation

[0031] To gain a detailed understanding of the features and technical content of the embodiments of this application, the implementation methods of the embodiments of this application will be described in detail below with reference to the accompanying drawings. The drawings are for reference and illustration only and are not intended to limit the embodiments of this application. In the following technical description, many details are set forth for ease of explanation, in order to provide a thorough understanding of the disclosed embodiments.

[0032] This application broadly relates to wireless communication. Many emerging trends will trigger considerations and designs for future wireless networks, such as 6th generation (6G) wireless networks. The proposed 6G wireless communication can meet the following requirements: - New network infrastructure capabilities, such as widely deployed cloud-friendly infrastructure; - New (relatively) mature technologies, such as large-scale models of artificial intelligence (AI), data privacy, blockchain, etc., have made significant progress and have had a major impact on society and human life as a whole. - New applications and services, such as AI services, data (sensing) services, digital world services, etc., which are widely used in industries / businesses and by individual customers; - A more globalized / open / collaborative operating trend, namely, more open and collaborative operating models are becoming prevalent in many fields.

[0033] New expectations and more stringent requirements for future networks have also driven a rethinking and development of next-generation wireless networks. These requirements may include: - Privacy and trustworthiness, etc.; - Simplify and standardize; - Rapid deployment; - etc.

[0034] All of the above factors have driven research into 6G network architecture. The proposed 6G network architecture (centered on X) is based on service-based architecture (SBA) (XaaS services) and cloud-native principles. Requirements for 6G system network architecture design may include: - The proposed 6G network architecture needs to support new 6G services, which can be developed / deployed by third parties; - The proposed 6G network architecture needs to embrace a more open ecosystem and be open to third parties with strong technical capabilities; The proposed 6G network architecture requires better trust management.

[0035] A solution is needed to meet the above requirements.

[0036] In 3GPP 33.501, the master authentication and key negotiation process is designed to achieve mutual authentication between the UE (i.e., the device) and the network, and to provide an anchor key that can be used to indirectly derive a key for security protection of communication between the UE and the network. SEAF The anchor key is provided to the SEAF of the serving network by the AUSF (Authorization Service Server) of the home network. Anchor key binding is achieved by including a parameter called the "serving network name" in a key derivation chain from the long-term user key to the anchor key. Keys for more than one security context can be obtained from K. SEAF Indirect derivation, without requiring a new authentication process. All these keys (e.g., K) AMF Both the terminal key and the network function (e.g., K) are generated by the network function. AMFThe terminal key for security protection of communication between the UE and the AMF is generated by the AMF; the terminal key for security protection of communication between the UE and the gNB is generated by the gNB. These network functions should store or maintain security contexts (e.g., algorithm parameters, inputs used to derive these keys). Furthermore, if the long-term user key changes, these network functions should update the security context associated with the long-term user key.

[0037] In 3GPP 33.501, the anchor key is bound to the SEAF of the serving network. This functionality of the SEAF can be supported in a single instance of the AMF (GW). Due to N2 handover or PDU session establishment, the UE's security context should be transferred from the old AMF (GW) to the new serving AMF (GW). This security context should include algorithm parameters and those used to derive K. AMF The input. These security contexts can include new K AMF Or the terminal key. The new service AMF (GW) can generate a new K. AMF Or a terminal key. This can incur message exchange overhead.

[0038] This section first introduces relevant technologies and concepts to better understand the technical solution proposed in this application.

[0039] Currently, in 3GPP 33.501, mutual authentication and key negotiation generate an anchor key associated with the serving network. The gateway (GW) key is derived from the anchor key. The GW key is used to derive terminal keys, which are used to secure communication between the device and the GW. When the serving GW changes during handover, the device's security context (e.g., the anchor key and the old GW's key) must be transferred from the old GW to the new GW, which can be very costly, especially in high-mobility scenarios. Furthermore, the AMF, gNB, or SEAF should store or maintain the security context (e.g., algorithm parameters, inputs used to derive these keys).

[0040] To address these issues, this application provides a system and method for anchor key generation and configuration in future networks. The proposed scheme can reduce message exchange overhead and improve network performance efficiency.

[0041] To reduce the overhead of security context exchange, this application proposes a novel system and method for anchor key management. The basic concepts of this application are as follows.

[0042] In version 33.501, the anchor key is associated with the name of the serving network, and the AMF key is associated with both the device name and the anchor key. If the concept of a serving network is removed, the anchor key will be directly bound to the serving GW. In this case, when a device moves from an old serving GW to a new serving GW, a new AMF key is generated directly without requiring the device's security context (e.g., K). SEAF Under this assumption, new technical issues need to be addressed. For example, how are new anchor keys generated? Who will generate the new anchor keys? What information should be exchanged between the GW and the AUSF (Authentication Server)? Who maintains the security context? How are the new anchor keys configured? How are the new anchor keys updated during a switchover? How does the service GW determine if it has a new authentication process? The basic concepts of this application consist of three parts: (1) It introduces the concept of anchor keys being bound to a service GW rather than a service network. An architecture for anchor key management and certain definitions related to anchor keys are provided. (2) It designs methods for generating anchor keys and configuring anchor keys to a service GW. (3) It provides a procedure for security context exchange during service GW reallocation.

[0043] Anchor keys are bound to the service gateway (GW), not the service network. A new method for generating anchor keys bound to the service GW is provided. This avoids the overhead of security context exchange due to handover.

[0044] Beneficial technical effects include at least the following two points: (1) Reduce storage overhead The concept of a serving network is eliminated; the anchor key will be directly bound to the serving GW. The GW does not maintain the K in 3GPP 33.501. SEAF Furthermore, the anchor key is generated by KMF. This means that the service GW and other network functions do not maintain the security context.

[0045] (2) Reduce communication overhead When a device moves from an old service gateway to a new service gateway, a new anchor key is generated directly, without requiring the previous security context. This avoids security context exchange during the handover process.

[0046] refer to Figure 1This simplified schematic diagram of a communication system is provided as an illustrative example, but not a limitation. Communication system 100 includes a radio access network 120. Radio access network 120 may be a next-generation (e.g., 6G or higher) radio access network or a traditional (e.g., 5G or 4G) radio access network. One or more electronic devices (EDs) 110a, 110b, 110c, 110d, 110e, 110f, 110g, 110h, 110i, 110j (generally referred to as 110) may be interconnected with each other or connected to one or more network nodes (170a, 170b, generally referred to as 170) in radio access network 120. Core network 130 may be part of the communication system and may depend on or be independent of the radio access technology used in communication system 100. Communication system 100 also includes a public switched telephone network (PSTN) 140, the Internet 150, and other networks 160.

[0047] Figure 2 An exemplary communication system 100 is illustrated. Typically, the communication system 100 enables multiple wireless or wired components to transmit data and other content. The purpose of the communication system 100 may be to provide content such as voice, data, video, and / or text via broadcast, multicast, unicast, etc. The communication system 100 can operate by sharing resources (e.g., carrier spectrum bandwidth) among its constituent components. The communication system 100 may include terrestrial communication systems and / or non-terrestrial communication systems. The communication system 100 can provide a wide range of communication services and applications (e.g., earth monitoring, remote sensing, passive sensing and positioning, navigation and tracking, autonomous delivery and mobility, etc.). The communication system 100 can provide high availability and robustness through the joint operation of terrestrial and non-terrestrial communication systems. For example, integrating a non-terrestrial communication system (or components thereof) into a terrestrial communication system can realize a heterogeneous network comprising multiple layers. Compared to traditional communication networks, heterogeneous networks can achieve better overall performance through efficient multi-link joint operation, more flexible function sharing, and faster physical layer link switching between terrestrial and non-terrestrial networks.

[0048] Terrestrial communication systems and non-terrestrial communication systems can be considered subsystems of a communication system. Figure 5In the example shown, communication system 100 includes electronic devices (EDs) 110a, 110b, 110c, and 110d (generally referred to as ED 110), radio access networks (RANs) 120a and 120b, a non-terrestrial communication network 120c, a core network 130, a public switched telephone network (PSTN) 140, the Internet 150, and other networks 160. RANs 120a and 120b include corresponding base stations (BSs) 170a and 170b, which may generally be referred to as terrestrial transmit and receive points (T-TRPs) 170a and 170b. The non-terrestrial communication network 120c includes access nodes 172, which may generally be referred to as non-terrestrial transmit and receive points (NT-TRPs) 172.

[0049] Alternatively, any ED 110 can be used to connect, access, or communicate with any T-TRP 170a and 170b and NT-TRP 172, Internet 150, core network 130, PSTN 140, other network 160, or any combination thereof. In some examples, ED 110a can perform uplink and / or downlink transmissions with T-TRP 170a via terrestrial air interface 190a. In some examples, ED 110a, 110b, 110c, and 110d can also communicate directly with each other via one or more sidelink air interfaces 190b. In some examples, ED 110d can perform uplink and / or downlink transmissions with NT-TRP 172 via non-terrestrial air interface 190c.

[0050] Air interfaces 190a and 190b can use similar communication technologies, such as any suitable wireless access technology. For example, communication system 100 can implement one or more channel access methods in air interfaces 190a and 190b, such as code division multiple access (CDMA), space division multiple access (SDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), or single-carrier FDMA (SC-FDMA) (also known as discrete Fourier transform spread OFDMA (DFT-s-OFDMA)). Air interfaces 190a and 190b can utilize other high-dimensional signal spaces, which may involve combinations of orthogonal and / or non-orthogonal dimensions.

[0051] The non-terrestrial air interface 190c enables communication between the ED 110d and one or more NT-TRP 172s via a wireless link, or simply a link. For some examples, the link is a dedicated connection for unicast transmission, a connection for broadcast transmission, or a connection for multicast transmission between a group of ED 110s and one or more NT-TRP 172s.

[0052] RANs 120a and 120b communicate with core network 130 to provide various services, such as voice, data, and other services, to EDs 110a, 110b, and 110c. RANs 120a and 120b and / or core network 130 may communicate directly or indirectly with one or more other RANs (not shown), which may or may not be directly served by core network 130, and may or may not use the same radio access technology as RANs 120a, RAN 120b, or both. Core network 130 may also act as a gateway access between (i) RANs 120a and 120b and / or EDs 110a, 110b, and 110c, and between (ii) other networks (e.g., PSTN 140, Internet 150, and other networks 160). Additionally, some or all of ED110a, 110b, and 110c may include the ability to communicate with different wireless networks via different wireless links using different wireless technologies and / or protocols. Instead of wireless communication (or other than wireless communication), ED 110a, 110b, and 110c may also communicate with service providers or exchanges (not shown) via wired communication channels and with the Internet 150. PSTN 140 may include a circuit-switched telephone network for providing plain old telephone service (POTS). The Internet 150 may include a network of computers and subnets (intranets) or both, incorporating protocols such as Internet Protocol (IP), Transmission Control Protocol (TCP), and User Datagram Protocol (UDP). ED 110a, 110b, and 110c may be multimode devices capable of operating according to multiple wireless access technologies and include multiple transceivers required to support these technologies.

[0053] Figure 3Another example of the ED 110 and base stations 170a, 170b, and / or 170c is shown. The ED 110 is used to connect people, objects, machines, etc. The ED 110 can be widely used in various scenarios, including, for example, cellular communication, device-to-device (D2D), vehicle-to-everything (V2X), peer-to-peer (P2P), machine-to-machine (M2M), machine-type communications (MTC), Internet of Things (IoT), virtual reality (VR), augmented reality (AR), mixed reality (MR), metaverse, digital twins, industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, smart cities, drones, robots, remote sensing, passive sensing, positioning, navigation and tracking, autonomous delivery and mobility, etc.

[0054] Each ED 110 represents any end-user equipment suitable for wireless operation and may include (or be referred to as): user equipment / device (UE), wireless transmit / receive unit (WTRU), mobile station, fixed or mobile subscriber unit, cellular phone, station (STA), machine type communication (MTC) device, personal digital assistant (PDA), smartphone, laptop, computer, tablet, wireless sensor, consumer electronics device, smartbook, vehicle, automobile, truck, bus, train, or IoT device, wearable device (e.g., watch, glasses, head-mounted device, etc.), industrial equipment, or devices comprising or including the foregoing (e.g., communication module, modem, or chip), etc. Future generations of ED 110 may be referred to using other terms. Base stations 170a and 170b are T-TRPs and will be referred to as T-TRP 170 below. Figure 3As also shown, NT-TRP will be referred to as NT-TRP 172 below. Each ED 110 connected to T-TRP 170 and / or NT-TRP 172 can be dynamically or semi-statically turned on (i.e., established, activated, or enabled), turned off (i.e., released, deactivated, or disabled), and / or configured in response to one or more of the availability and necessity of the connection.

[0055] ED 110 includes a transmitter 201 and a receiver 203 coupled to one or more antennas 204. Only one antenna 204 is shown in the figure to avoid congestion. One, some, or all of the antennas 204 may also be panels. For example, the transmitter 201 and receiver 203 may be integrated as a transceiver. The transceiver is used to modulate data or other content for transmission by at least one antenna 204 or a network interface controller (NIC). The transceiver is also used to demodulate data or other content received through at least one antenna 204. Each transceiver includes any suitable structure for generating signals for wireless or wired transmission and / or for processing signals received wirelessly or wiredly. Each antenna 204 includes any suitable structure for transmitting and / or receiving wireless or wired signals.

[0056] ED 110 includes at least one memory 208. Memory 208 stores instructions and data used, generated, or acquired by ED 110. For example, memory 208 may store software instructions or modules for implementing some or all of the functions and / or embodiments described herein and executed by one or more processing units (e.g., processor 210). Each memory 208 includes any suitable one or more volatile and / or non-volatile storage and retrieval devices. Any suitable type of memory can be used, such as random access memory (RAM), read-only memory (ROM), hard disk, optical disk, subscriber identity module (SIM) card, memory stick, secure digital (SD) memory card, on-processor cache, etc.

[0057] ED 110 may also include one or more input / output devices (not shown) or interfaces (e.g., connected to...). Figure 1 (Wired interface of Internet 150 in the network). Input / output devices or interfaces support interaction with users or other devices in the network. Each input / output device or interface includes any suitable structure for providing or receiving information from the user, and / or for communication on the network interface. For example, suitable structures include speakers, microphones, keypads, keyboards, displays, touchscreens, etc.

[0058] ED 110 includes a processor 210 for performing operations, including operations related to preparing for uplink transmissions to NT-TRP 172 and / or T-TRP 170; operations related to processing downlink transmissions received from NT-TRP 172 and / or T-TRP 170; and operations related to processing sidelink transmissions to and from another ED 110. Processing operations related to preparing for uplink transmissions may include operations such as encoding, modulation, transmit beamforming, and generating symbols for transmission. Processing operations related to processing downlink transmissions may include operations such as receive beamforming, demodulation, and decoding of received symbols. According to an embodiment, the downlink transmission may be received by receiver 203, possibly using receive beamforming, and processor 210 may extract signaling from the downlink transmission (e.g., by detecting and / or decoding signaling). Examples of signaling may be reference signals transmitted by NT-TRP 172 and / or T-TRP 170. In some embodiments, processor 210 performs transmit beamforming and / or receive beamforming based on beam direction indications (e.g., beam angle information (BAI)) received from T-TRP 170. In some embodiments, processor 210 may perform operations related to network access (e.g., initial access) and / or downlink synchronization, such as operations related to detecting synchronization sequences, decoding, and acquiring system information. In some embodiments, processor 210 may perform channel estimation using reference signals received from NT-TRP 172 and / or T-TRP 170.

[0059] Although not shown, processor 210 may form part of transmitter 201 and / or receiver 203. Although not shown, memory 208 may form part of processor 210.

[0060] The processing components of processor 210, transmitter 201, and receiver 203 may be implemented by the same or different processors, which execute instructions stored in memory (e.g., memory 208). Alternatively, some or all of the processing components of processor 210, transmitter 201, and receiver 203 may be implemented using dedicated circuitry, such as a programmable field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), or hardware accelerators such as graphics processing units (GPUs) or artificial intelligence (AI) accelerators.

[0061] The T-TRP 170 may be known by other names in some implementations, such as base station, base-transceiver station (BTS), wireless base station, network node, network device, network-side device, transmit / receive node, NodeB, evolved NodeB (eNodeB or eNB), home eNodeB, next-generation NodeB (gNB), transmission point (TP), site controller, access point (AP), wireless router, relay station, ground node, ground network device, ground base station, base band unit (BBU), remote radio unit (RRU), active antenna unit (AAU), remote radio head (RRH), central unit (CU), distributed unit (DU), positioning node, etc. The T-TRP 170 can be a macro BS, pico BS, relay node, host node, or a combination thereof. T-TRP 170 may refer to the aforementioned device or a component of the aforementioned device (e.g., a communication module, modem, or chip).

[0062] In some embodiments, the various parts of T-TRP 170 may be distributed. For example, some modules of T-TRP 170 may be located remotely from the device housing the antenna 256 of T-TRP 170 and may be coupled to the device housing the antenna 256 via a communication link (not shown) sometimes referred to as a fronthaul (e.g., a common public radio interface, CPRI). Therefore, in some embodiments, the term T-TRP 170 may also refer to modules on the network side that perform processing operations such as determining the location of ED 110, resource allocation (scheduling), message generation, and encoding / decoding; these modules are not necessarily part of the device housing the antenna 256 of T-TRP 170. These modules may also be coupled to other T-TRPs. In some embodiments, T-TRP 170 may actually be multiple T-TRPs that operate together to provide services such as coordinated multicast to ED 110.

[0063] T-TRP 170 includes at least one transmitter 252 and at least one receiver 254 coupled to one or more antennas 256. Only one antenna 256 is shown in the figure to avoid congestion. One, some, or all of the antennas 256 may also be panels. The transmitter 252 and receiver 254 may be integrated as a transceiver. T-TRP 170 also includes a processor 260 for performing operations including operations related to: preparing transmissions for downlink transmission to ED 110, processing uplink transmissions received from ED 110, preparing transmissions for backhaul transmission to NT-TRP 172, and processing transmissions received from NT-TRP 172 via backhaul. Processing operations related to preparing transmissions for downlink or backhaul transmission may include operations such as encoding, modulation, precoding (e.g., multiple-input multiple-output (MIMO) precoding), transmit beamforming, and generating symbols for transmission. Processing operations related to transmissions received in the uplink or via backhaul may include receiving beamforming, demodulating received symbols, and decoding received symbols. Processor 260 may also perform operations related to network access (e.g., initial access) and / or downlink synchronization, such as generating the contents of a synchronization signal block (SSB), generating system information, etc. In some embodiments, processor 260 also generates beam direction indications, such as BAI, that can be scheduled for transmission by scheduler 253. Processor 260 performs other network-side processing operations described herein, such as determining the location of ED 110, determining the deployment location of NT-TRP 172, etc. In some embodiments, processor 260 may generate signaling, such as for configuring one or more parameters of ED 110 and / or one or more parameters of NT-TRP 172. Any signaling generated by processor 260 is transmitted by transmitter 252. It should be noted that the term "signaling" used herein may also be referred to as control signaling. Signaling can be transmitted in physical layer control channels (e.g., physical downlink control channel (PDCCH)). In this case, the signaling can be called dynamic signaling. Signaling transmitted in the downlink physical layer control channel can be called downlink control information (DCI). Signaling transmitted in the uplink physical layer control channel can be called uplink control information (UCI). Signaling transmitted in the sidelink physical layer control channel can be called sidelink control information (SCI).Signaling can be included in higher-layer (e.g., above the physical layer) messages transmitted on physical layer data channels (e.g., physical downlink shared channel, PDSCH). In this case, the signaling can be referred to as higher-layer signaling, static signaling, or semi-static signaling. Higher-layer signaling can refer to radio resource control (RRC) protocol signaling or media access control-control element (MAC-CE) signaling.

[0064] Scheduler 253 may be coupled to processor 260. Scheduler 253 may be included within T-TRP 170 or may operate separately from T-TRP 170. Scheduler 253 may schedule uplink, downlink, lateral link, and / or backhaul transmissions, including issuing scheduling authorizations and / or configuring schedule-free (e.g., "configuration authorization") resources. T-TRP 170 also includes memory 258 for storing information and data. Memory 258 stores instructions and data used, generated, or acquired by T-TRP 170. For example, memory 258 may store software instructions or modules executed by processor 260 for implementing some or all of the functions and / or embodiments described herein.

[0065] Although not shown, processor 260 may form part of transmitter 252 and / or receiver 254. Furthermore, although not shown, processor 260 may implement scheduler 253. Although not shown, memory 258 may form part of processor 260.

[0066] The processing components of processor 260, scheduler 253, transmitter 252, and receiver 254 may be implemented by the same or different processors, which execute instructions stored in memory (e.g., memory 258). Alternatively, some or all of the processing components of processor 260, scheduler 253, transmitter 252, and receiver 254 may be implemented using dedicated circuitry, such as a programmable FPGA, hardware accelerator (e.g., GPU or AI accelerator), or ASIC.

[0067] Although the NT-TRP 172 is shown as an example of a drone only, it can be implemented in any suitable non-terrestrial form, such as satellites and high-altitude platforms, including international mobile communication base stations and unmanned aerial vehicles. Furthermore, the NT-TRP 172 may be known by other names in some implementations, such as a non-terrestrial node, a non-terrestrial network device, or a non-terrestrial base station. The NT-TRP 172 includes a transmitter 272 and a receiver 274 coupled to one or more antennas 280. Only one antenna 280 is shown in the figure to avoid congestion. One, some, or all of the antennas may also be panels. The transmitter 272 and receiver 274 may be integrated as a transceiver. The NT-TRP 172 also includes a processor 276 for performing operations including: preparing transmissions for downlink transmission to ED 110, processing uplink transmissions received from ED 110, preparing transmissions for backhaul transmission to T-TRP 170, and processing transmissions received from T-TRP 170 via backhaul. Processing operations related to preparing a transmission for downlink or backhaul transmission may include operations such as encoding, modulation, precoding (e.g., MIMO precoding), transmit beamforming, and generating symbols for transmission. Processing operations related to processing transmissions received in the uplink or via backhaul may include operations such as receive beamforming, demodulating received symbols, and decoding received symbols. In some embodiments, processor 276 performs transmit beamforming and / or receive beamforming based on beam direction information (e.g., BAI) received from T-TRP 170. In some embodiments, processor 276 may generate signaling, such as for configuring one or more parameters of ED110. In some embodiments, NT-TRP 172 implements physical layer processing but does not implement higher-level functions such as those at the medium access control (MAC) or radio link control (RLC) layers. Since this is only an example, more generally, NT-TRP 172 may implement higher-level functions in addition to physical layer processing.

[0068] The NT-TRP 172 also includes a memory 278 for storing information and data. Although not shown, a processor 276 may form part of the transmitter 272 and / or the receiver 274. Although not shown, the memory 278 may form part of the processor 276.

[0069] The processing components of processor 276, transmitter 272, and receiver 274 may be implemented by the same or different one or more processors, which execute instructions stored in memory (e.g., memory 278). Alternatively, some or all of the processing components of processor 276, transmitter 272, and receiver 274 may be implemented using dedicated circuitry, such as a programmable FPGA, hardware accelerator (e.g., GPU or AI accelerator), or ASIC. In some embodiments, NT-TRP 172 may actually be multiple NT-TRPs operating together to coordinate services such as multicast transmission ED 110.

[0070] T-TRP 170, NT-TRP 172 and / or ED 110 may include other components, but for clarity these components are omitted.

[0071] One or more steps of the methods in the embodiments provided herein can be based on Figure 4 The corresponding unit or module is executed. Figure 4 The diagram illustrates units or modules within a device, such as in ED 110, T-TRP 170, or NT-TRP 172. For example, signals may be transmitted by a transmitting unit or transmitting module. Signals may be received by a receiving unit or receiving module. Signals may be processed by a processing unit or processing module. Other steps may be performed by artificial intelligence (AI) or machine learning (ML) modules. The corresponding units or modules may be implemented using hardware, one or more components or devices executing software, or a combination thereof. For example, one or more units or modules may be circuits such as integrated circuits. Examples of integrated circuits include programmable FPGAs, GPUs, or ASICs. For example, one or more units or modules may be logic, such as a part of a circuit, an integrated circuit, or a logical function executed by software instructions executed by a processor. It should be understood that if these modules are implemented, for example, using software executed by a processor, then these modules may be retrieved by the processor, wholly or partially, individually or collectively, for processing, in one or more instances, as needed, and these modules themselves may include instructions for further deployment and instantiation.

[0072] Additional details regarding ED 110, T-TRP 170, and NT-TRP 172 are known to those skilled in the art. Therefore, these details are omitted herein.

[0073] The solutions described in this application are applicable to next-generation (e.g., 6G or higher) networks, or traditional (e.g., 5G or 4G) networks.

[0074] The proposed 6G system architecture is defined as supporting 6G XaaS services through the use of technologies such as network function virtualization and network slicing. The 6G system architecture leverages service-based interactions between 6G services.

[0075] The 6G system adopts a service-based architecture and the XaaS concept. XaaS services in the 6G system are categorized into three layers. The conceptual structure of the 6G system is as follows: Figure 5 As shown.

[0076] The infrastructure layer includes the infrastructure that supports 6G services. This includes wireless network infrastructure (such as RAN, CN), cloud / data center infrastructure, satellite networks, storage / database infrastructure, and sensing networks. This infrastructure can be provided by a single provider or by multiple providers.

[0077] Each piece of infrastructure can have its own control and management functions, represented as control and management (C / M) functions, for infrastructure management. Each of these infrastructures is an Infrastructure as a Service.

[0078] The C / M layer includes control and management services for the 6G system. These are developed and deployed using slicing technology and leveraging resources provided by the infrastructure layer. 6G services in the C / M layer may include: Resource management (RM) as a service provides the ability to manage the lifecycle of various slices and allocate over-the-air resources to wireless devices; - A 6G task is defined as a service provided by a 6G system to a customer. A task can be a service type provided by a single 6G XaaS service, or it can be a service type that requires contributions from multiple XaaS services.

[0079] - Mission management (MM) is a service that provides the ability to program XaaS services at the service layer to provide mission services.

[0080] - The Confederation Network (CONET) as a Service provides the ability for multiple partners to jointly deliver 6G services. This capability is provided through protocol negotiation involving alliance formation, mutual authentication, mutual authorization, and the recording and retrospective of selected actions performed by partners, ensuring a trusted environment for the operation of 6G systems.

[0081] Service provisioning management (SPM) refers to the ability of service providers to control and manage customer access to 6G services and configure requested services. This capability is provided through unified mutual authentication, authorization and policies, key management, quality of service (QoS) guarantees, and accounting between any pair of XaaS service providers and customers. Customers include not only end customers in the physical world but also digital representatives in the digital world.

[0082] - Connectivity management (CM) as a service leverages 5G connectivity management capabilities but extends to include the digital world.

[0083] Protocol as a Service (PCA) provides the ability to customize protocol stacks for the design services of the identified interfaces.

[0084] - Protocol stacks can be predefined for selection on demand, or designed on demand.

[0085] Cybersecurity as a Service (CASS) provides infrastructure owners with the ability to detect potential security risks to their infrastructure.

[0086] XaaS services in the C / M layer support the control and management of the 6G system itself and provide support to vertical industries upon request. For example, the RM service can provide air resource management services to the RAN, and can also provide air resource allocation services to end customers in vertical industries. XaaS in the C / M layer can be deployed using slicing technology.

[0087] The service layer includes 6G services provided to customers. In the 6G system conceptual architecture: - AI services are represented as NET4AI as a service. Artificial intelligence services provide AI capabilities to support a wide range of AI applications.

[0088] Data acquisition, data cleansing, data analysis, and data delivery services are referred to as DAM as a service. This service provides the ability to manage the lifecycle of statistical data, including acquiring, de-privatizing, analyzing, and delivering data, which is statistical data from any type of sensor, device, network function, etc.

[0089] - Data storage and sharing services are represented as NET4Data as a Service, which provides the ability to reliably store and share data under the control of the data owner and in accordance with the regulations of recognized authorities on the control of identified data.

[0090] - Providing services for the digital world is represented as NET4DW as a Service. Digital world services provide the ability to build, control, and manage the digital world. The digital world is defined as the digital realization of the physical world.

[0091] - The 6G blockchain service is represented as NET4BC as a service. The 6G connectivity service is represented as NET4Con as a service. This service provides the capability to support 6G blockchain services.

[0092] - Enhanced connectivity services, such as Connection-Oriented Networking (NET4CON) as a Service. This service provides the ability to exchange messages and data between supporting new 6G services.

[0093] All XaaS services in this layer are developed and deployed using resources provided within the infrastructure and leveraging network function virtualization and slicing technologies. The capabilities of each 6G service are provided by its control and management functions, as well as service-specific data processing capabilities.

[0094] In addition to supporting 6G XaaS services at the service layer, the 6G system also leverages the 5G system to configure vertical services. The difference between 6G XaaS services and other vertical industries is that a vertical industry is a pure customer that needs other XaaS services to enable its operation, while each XaaS service provides its capabilities to the 6G customer.

[0095] Any pair of XaaS services in a 6G system can also be customer and provider to each other. Some examples include: the infrastructure owner providing its resources to XaaS services in the service layer and the C / M layer; the RM service possibly requiring the capabilities provided by NET4AI, DAM, and NET4DW to manage its resources for vertical slices; and the CONET and NET4Data services possibly requiring the capabilities provided by NET4BC to function.

[0096] Key concepts of 6G systems may include: - Basic XaaS services are defined by decoupling comprehensive service types into basic XaaS services. Basic XaaS services provide unique capabilities to enable specific types of services, such as NET4AI services, NET4DW services, DAM services, NET4Data services, blockchain services, task management services, etc.

[0097] - Allows multiple partners to jointly operate the 6G system.

[0098] - Define the data plane of the 6G system, including the data plane processing functions of XaaS services. Programming the interconnection of these functions through task management services can support a variety of customized customer services.

[0099] - Simplify the 6G system architecture by categorizing basic control and management services and combining them into basic XaaS services in the control and management (C / M) layer.

[0100] - Define the C / M plane of the 6G system, including C / M functions in XaaS services, which may include 5GCP (e.g., AMF) depending on the implementation.

[0101] - Define the basic architecture structure (BAS), which is a unified basic structure with a minimal number of interfaces and is independent of the infrastructure type.

[0102] - Use the BAS concept to simplify the standardization, development and deployment of 6G systems, while supporting a variety of infrastructure deployment scenarios.

[0103] - Apply BAS or subsets thereof to infrastructure based on the capabilities, capacity, and requirements of the infrastructure network to adapt to a variety of deployment scenarios.

[0104] - Utilize the SBI interface concept and apply SBI interaction in both the 6G C / M plane and the 6G data plane.

[0105] - Simplify the SBI interface by introducing a trusted GW in the data plane and C / M plane of the 6G system.

[0106] - Improve trustworthiness from the perspective of 6G system operation by introducing CONET capabilities, NET4BC capabilities and anonymity service configurations provided by a trusted GW into the C / M plane and data plane of the 6G system.

[0107] - Enhance trustworthiness from the perspective of end-customer privacy protection by providing unified mutual authentication, IDM, data purification, etc. through SPM service, DAM service and 6G blockchain service.

[0108] - Simplify roaming management of wireless devices in the physical and digital worlds through unified certification that includes all participating partners and customers.

[0109] - By defining multiple architecture options, it supports multiple development paths from 5G systems to 6G systems, requiring less work due to the introduction of the BAS concept.

[0110] - By leveraging the advantages of SBA and its additional features, backward compatibility is supported. 5G users can use 6G systems to access 5G services.

[0111] - Supports future expansion by adding new XaaS services, minimizing the impact on standardization and deployment due to the introduction of anonymous service configuration concepts in the trusted GW of the 6G C / M plane and 6G data plane.

[0112] To address the aforementioned issues, this application provides a method and system for generating and configuring anchor keys in a network (e.g., a future network), which can reduce message exchange overhead and improve network performance efficiency.

[0113] First, we introduce some basic concepts related to some embodiments of this application.

[0114] (1) The initial GW is the logical connection between the device and the GW when the device first connects to the network or service. The GW is the logical connection between the device and the network, and is responsible for message forwarding, routing, etc.

[0115] (2) A service GW is a logical connection between a device and a GW connected to a network or provider. A GW is a logical connection between a device and a network, responsible for message forwarding, routing, etc.

[0116] (3) The name of the GW is composed of the service code, the service network identifier and the device of the GW, and connected by the separator “:”, for example, service code: service network identifier: ID of the device of the GW.

[0117] (4) The anchor key is a key used to derive the terminal key, which is bound to the service GW and generated by the key management function (KMF). The inputs used to generate the anchor key are associated with the name of the service GW, the name of the device, and other information, such as the shared key negotiated after successful mutual authentication between the device and the network.

[0118] (5) KMF is a network function responsible for key management, such as anchor key generation.

[0119] The details of the basic concepts are as follows: (1) An anchor key is bound to the service GW and associated with the name of the service GW and the name of the device; (2) The anchor key is generated by KMF after successful mutual authentication.

[0120] Figure 6 An architecture for anchor key management is provided for some embodiments of this application. Figure 6In this process, when a device initially connects to the network, it sends an authentication request to the initial gateway (GW). The initial GW may select a serving GW based on the device's location or other information, such as the location of the service provider or infrastructure provider. The initial GW forwards the authentication request to the authentication server (AS) for mutual authentication between the device and the network. After successful mutual authentication, the device and the AS should negotiate a shared key. The shared key is then sent to the KMF (Knowledge Management Function), which derives the anchor key. After generating the anchor key, the KMF configures the anchor key for both the serving GW and the device.

[0121] Figure 6 The main functions of the network shown are as follows: The initial GW is responsible for identifying the service GW, determining whether to run new authentication, requesting authentication for the device, and forwarding messages.

[0122] The authentication server (AS) is responsible for authenticating devices and negotiating a shared key between the device and the AS.

[0123] KMF is responsible for generating anchor keys, generating security contexts for the service GW and devices, and maintaining the security contexts.

[0124] In this application, the anchor key is bound to the serving gateway (GW) and associated with the GW's name, the device's name, and other information. The anchor key is generated by the KMF after successful mutual authentication between the device and the network. Compared to existing technologies (e.g., 3GPP 33.501), these changes offer several advantages, such as reduced communication overhead from key update message exchanges, reduced storage overhead for the GW storing security contexts, and improved scalability for adding new network functions to the network.

[0125] Figure 7 This is a schematic flowchart illustrating a communication method proposed for some embodiments of this application. The method (200) may be implemented by a first network function (e.g., KMF) or circuitry installed in the first network function. The following embodiments use the first network function as an example.

[0126] In step 210, the first network function receives a first message from the authentication server (AS).

[0127] The first message includes the name of the second network function. The second network function is the network function to which the network or service provider connects, or the network function that the device uses to access the network or service. In this document, a service provider refers to a provider that provides services (e.g., application services) to the device.

[0128] For example, the second network function is to serve the GW.

[0129] In some embodiments, the first message may further include the device's ID. In some embodiments, the first message may further include a shared key used between the device and the network. The shared key may be determined by the device and the AS after successful mutual authentication between the device and the network. In some embodiments, the device, also referred to as a user or UE, refers to a terminal device.

[0130] As part of step 220, the first network function generates an anchor key based on the name of the second network function. The anchor key is used to determine whether authentication is required between the device and the network.

[0131] The first network function generates an anchor key based on the name of the second network function.

[0132] In some embodiments, the first network function generates an anchor key based on the name of the second network function and other information. For example, the other information may include the device ID and / or a shared key. Furthermore, the inputs used to generate the anchor key may include information other than the name of the second network function, the device ID, and the shared key, and are not limited thereto. The first network function may also set the ID of the anchor key.

[0133] The first network function can also generate a terminal key and a first security context for the second network function. The terminal key can be generated based on the anchor key and is used to securely protect communication between the device and the second network function.

[0134] In one embodiment, the first security context may include one or more of the following parameters: the ID of the anchor key, the anchor key, the ID of the encryption algorithm used for encryption of communication between the device and the second network function, and the ID of the integrity algorithm used for integrity of communication between the device and the second network function.

[0135] In another embodiment, the first security context may include one or more of the following parameters: a terminal key, an ID of an encryption algorithm used for encrypting communication between the device and the second network function, and an ID of an integrity algorithm used for ensuring the integrity of communication between the device and the second network function. Compared to the previous embodiment, the first security context in this embodiment includes a terminal key instead of an anchor key.

[0136] In step 230, the first network function sends a second message to the second network function.

[0137] The second message includes the first security context.

[0138] After receiving the second message from the first network function, the second network function stores the first security context.

[0139] Optionally, the method may further include steps 240 to 260.

[0140] In step 240, the first network function generates a second security context for the device.

[0141] The second security context includes one or more of the following parameters: a first ID of the algorithm used to generate the anchor key, a second ID of the algorithm used to generate the terminal key, the ID of the anchor key, the ID of the encryption algorithm used for encryption of communication between the device and the second network function, and the ID of the integrity algorithm used for integrity of communication between the device and the second network function.

[0142] In step 250, the first network function sends a second security context to the device via the AS and the device's initial GW.

[0143] Specifically, the first network function sends a third message to the AS including a second security context, and the AS also sends a fourth message to the device including a second security context.

[0144] In step 260, the device generates an anchor key based on the second security context.

[0145] In some embodiments, the device may also generate a terminal key based on the anchor key.

[0146] In this application, there is no security context transmission between the old service GW and the new service GW. The security context is generated by KMF and configured for the new service GW. This reduces the message exchange overhead for key updates and the storage overhead of the GW. It should be noted that if the service GW changes, the replaced service GW becomes the old service GW, and the new GW used to replace it becomes the new service GW. Subsequently, the new service GW becomes the current service GW providing services to the device.

[0147] Figure 8 Examples of methods provided for embodiments of this application. In this embodiment, the serving gateway is an example of a second network function, and KMF is an example of a first network function. In other words, Figure 8 The call flow for anchor key generation and configuration is shown. The messages in the diagram below are shown in Table 1. It should be noted that the temporary ID (simplified as Tem_ID) is a temporary ID used for communication between the device and the network.

[0148] Table 1

[0149] Figure 8 The details are as follows.

[0150] In step 301, the device sends message 1 to the initial GW.

[0151] Message 1 can be an authentication request, and it includes the device's temporary ID. Message 1 can also include a service request.

[0152] In step 302, the initial GW selects a service GW.

[0153] In some embodiments, the initial GW may be selected based on the location of the device or other information, such as the location of the service provider or the location of the infrastructure provider.

[0154] In step 303, the initial GW triggers mutual authentication between the device and the network.

[0155] In step 304, after successful mutual authentication, the device negotiates a shared key with the authentication server (AS). In some embodiments of this application, the shared key is referred to as the extended master session function (EMSK).

[0156] In step 305, AS sends message 5 to KMF.

[0157] Message 5 includes the name of the service GW, the EMSK, and the device's temporary ID. Message 5 may also be an anchor key generation request.

[0158] In step 306, KMF generates the anchor key.

[0159] Specifically, KMF selects an algorithm to generate the anchor key. The inputs used to generate the anchor key include the name of the service GW. The inputs may also include at least one of the EMSK and the device's temporary ID. KMF sets the ID of the anchor key.

[0160] KMF generates a first security context for the serving GW. The first security context of the serving GW may include one or more of the following parameters: the ID of the anchor key, the anchor key itself, the ID of the encryption algorithm used for encryption of communication between the device and the serving GW, and the ID of the integrity algorithm used for integrity of communication between the device and the serving GW.

[0161] In some embodiments, the anchor key is used for deriving the terminal key. In this case, the KMF generates the anchor key, and then the KMF generates the terminal key based on the anchor key. Therefore, the security context of the serving GW may include the terminal key instead of the anchor key. The security context of the serving GW is called the first security context.

[0162] In step 307, KMF sends message 7 to the service GW.

[0163] Message 7 may be an anchor key configuration request. Message 7 includes the first security context.

[0164] In step 308, the service GW stores the first security context.

[0165] Optionally, the method may include step 309.

[0166] In step 309, the service GW sends message 9 to the KMF.

[0167] Message 9 includes information related to anchor key updates. For example, this information may include the frequency at which the anchor key is updated. It may also include one or more inputs used for anchor key derivation.

[0168] Furthermore, after step 309, the method further includes steps 310 to 313.

[0169] In step 310, KMF generates a security context for the device. This security context is referred to as the second security context in the embodiment. Steps 310 and 306 can be a single step; this is not limited to this.

[0170] The second security context may include one or more of the following parameters: a first ID of the algorithm used to generate the anchor key, a second ID of the algorithm used to generate the terminal key, the ID of the anchor key, the ID of the encryption algorithm used for encryption of communication between the device and the service GW, and the ID of the integrity algorithm used for integrity of communication between the device and the service GW.

[0171] In step 311, KMF sends message 10 to AS.

[0172] Message 10 includes a second security context. Message 10 is a response to message 5.

[0173] In step 312, AS sends message 11 to the device.

[0174] Message 11 includes a second security context. Message 11 is a response to message 1.

[0175] In step 313, the device generates an anchor key based on the received second security context.

[0176] Specifically, the device generates the anchor key using an algorithm and inputs that are included in a second security context. In other words, the algorithm and inputs used to generate the anchor key are the same as those used in the KMF, which indicates these algorithms and inputs through the security context. For example, the inputs used to generate the anchor key include the name of the service GW, the device ID, and the EMSK.

[0177] In some embodiments, the device may also generate a terminal key based on the anchor key and the received second security context.

[0178] It can be seen that the serving GW receives the anchor key or the terminal key from the KMF, and the device generates the anchor key and / or the terminal key itself based on the second security context from the KMF.

[0179] In this application, the security context is generated by the KMF and used to serve the GW. Under this architecture, the GW does not maintain certain parts of the security context present in prior art (e.g., 3GPP 33.501), such as the algorithm used to generate the anchor key, or the algorithm used to generate both the anchor key and the terminal key, or the input K for anchor key derivation or terminal key derivation. AMF This can reduce the storage overhead of the GW.

[0180] As mentioned above, the anchor key is used to determine whether a new authentication is required. The input used to generate the anchor key includes the name of the service GW. In other words, the anchor key is associated with the name of the service GW. In some cases, the device's service GW may change, such as during a handover.

[0181] When a service gateway changes due to a switchover, the old service gateway should select the new service gateway. The new service gateway determines whether new authentication is required by comparing the names of the new and old service gateways. If both are in the same service network and have the same provider, the new service gateway should not trigger new authentication. Otherwise, new authentication should be implemented.

[0182] Figure 9 This is an example of the security context transfer process during the reallocation of a new service GW when KMF is deployed in the system.

[0183] In step 401, the old service GW selects the new service GW.

[0184] In step 402, the new service GW determines whether new authentication is required. If no new authentication is required, the new service GW obtains the security context from the KMF, which will be described in steps 403 through 405.

[0185] In step 403, without new authentication, the new service GW sends message 1 to the KMF.

[0186] Message 1 includes the device's temporary ID and the name of the new service GW.

[0187] In step 404, KMF generates a new anchor key and a new security context for the new service GW.

[0188] Specifically, KMF generates a new anchor key using the device's temporary ID, the name of the new serving GW, and the EMSK input. In some embodiments, the new anchor key may be refreshed due to parameters unknown to the device and the new serving GW. These new parameters may be included in message 1. For example, these parameters may be a semaphore message uplink counter.

[0189] In addition, KMF generates new security contexts for new service GWs, and these new security contexts are called third security contexts.

[0190] The new security context (i.e., the third security context) includes either the ID of the new anchor key or the new anchor key itself.

[0191] Optionally, in some embodiments, if the new anchor key is used for the derivation of the terminal key, the new security context of the new service GW includes the new terminal key instead of the new anchor key.

[0192] In addition, new security contexts may include new algorithms, such as new encryption algorithms for data encryption and / or new integrity algorithms for data integrity protection.

[0193] In step 405, KMF sends message 2 to the new service GW.

[0194] Message 2 includes the new security context for the new service GW.

[0195] In step 406, the new service GW stores the new security context.

[0196] In addition, in some embodiments, the KMF can generate a new security context (referred to as a fourth security context) for the device, and the KMF sends the fourth security context to the device through the initial GW.

[0197] Subsequently, new contexts for the new service GW and device are configured for the new service GW and device.

[0198] In this application, the security context of the serving GW includes only the anchor key ID, or includes the anchor key and terminal key IDs instead of the anchor key, along with the algorithm for data encryption / data integrity protection. However, in prior art (e.g., 3GPP 33.501), the security context includes the AMF key ID, terminal key, anchor key, and the algorithm for generating the key, as well as the algorithm for data encryption / data integrity protection. Compared to prior art, this application can reduce the transmission overhead of some parts of the security context.

[0199] In some embodiments, the system does not have a KMF, such as in a 5G network scenario. In this case, the anchor key, or both the anchor key and the terminal key, are generated by the serving GW itself. This situation is as follows... Figure 10 As shown.

[0200] Figure 10 This is an example of the security context transfer process during service GW reallocation when KMF is not deployed in the system.

[0201] In step 501, the old service GW selects the new service GW.

[0202] In step 502, the new service GW determines whether new authentication is required. If no new authentication is required, step 503 is executed.

[0203] In step 503, the new service GW generates a new anchor key and then generates a new security context. The old service GW only forwards the EMSK used to generate the new anchor key to the new service GW.

[0204] In existing technologies, the legacy service gateway (GW) can send the current security context to the new service gateway, or send a message with a level K parameter to the new service gateway. AMF The derived instruction provides a new security context. Compared to existing technologies, this application can reduce the overhead of security context transmission. Furthermore, embodiments can reduce the communication overhead caused by message exchange during service GW reallocation.

[0205] The methods proposed in the embodiments of this application have been described in detail above. The communication device provided in this application will be described in detail below.

[0206] Figure 11 This is a schematic block diagram of a communication device 10 provided for embodiments of this application. The communication device may be a communication apparatus or a device applied to a communication apparatus, capable of implementing the corresponding function of any network function in the embodiments of this application. For example, the device may be a chip, a chip system, or a circuit, without limitation. The communication apparatus may be a first network function (e.g., KMF), a second network function (e.g., Serving GW), or an AS, or a chip installed in any of these network functions.

[0207] The communication device 10 includes a processing module 1001. The processing module 1001 may be a processor, processing circuit, processing board, processing unit, or processing device, etc. The processing module 1001 is used to perform processing and / or operations within the communication device, excluding transmission and reception actions.

[0208] The communication device 10 may further include a communication module 1002. The communication module 1002 is used to implement sending and / or receiving operations. The communication module 1002 may also be called a transceiver module, transceiver, or transceiver device, etc., and is used to implement receiving (which may be called input) and / or sending (which may be called output) operations.

[0209] For example, if communication device 10 corresponds to Figure 7 If the first network function in the system is configured, then the communication module 1002 is used to receive a first message from the AS. The communication module 1002 is also used to send a second message to the second network function. The processing module 1001 is used to implement step 220. The processing module 1001 is also used to implement step 240. If the communication device 10 corresponds to... Figure 7 If the second network function is used, then the communication module 1002 is used to receive the second message from the first network function.

[0210] For example, if communication device 10 corresponds to Figure 8 In the AS module, the communication module 1002 is used to send message 5 and further receive message 11. The processing module 1001 is used to implement step 304, etc.

[0211] In short, the operation and / or function of device 10 are for implementing the corresponding steps of the above method embodiments.

[0212] Figure 12 This is a schematic block diagram of a communication device provided for embodiments of this application. The communication device 20 includes at least one processor 21. The at least one processor 21 is coupled to at least one memory 22. The at least one memory 22 is used to store one or more instructions and / or executable computer code. The at least one processor 21 is used to invoke one or more instructions and / or executable computer code to cause the communication device 20 to implement the methods provided in the embodiments of this application. Optionally, the communication device 20 may further include at least one memory 22. Optionally, the communication device 20 may further include at least one communication interface 23, which is used for inputting and / or outputting information or data.

[0213] In one implementation, the communication device 20 can be any of the network functions in the method embodiments. For example, the communication device 20 can be a first network function (e.g., KMF), a second network function (e.g., Serving GW), or an AS. In this implementation, the processor 21 can be a baseband device, and the communication interface 23 can be a radio frequency device.

[0214] In another implementation, the communication device 20 can be a chip (or chip system) installed in a communication device such as a first network function, IDM, second network function, or third network function. In this implementation, the processor 21 can be a circuit, such as a logic circuit, integrated circuit, etc. The communication interface 13 can be a transceiver, interface circuit, input / output interface, bus, module, pin, or other type of interface.

[0215] Embodiments of this application also provide a communication system. The communication system may include any communication device according to any method embodiment. For example, the communication system may include one or more of the following network functions: a first network function (e.g., KMF), a second network function (e.g., serving GW), or AS. The communication system may also include terminal devices and other network functions, such as an initial GW, without limitation.

[0216] Embodiments of this application also provide a computer storage medium that can store one or more instructions for performing any of the methods described above.

[0217] Embodiments of this application also provide a computer program product that can store one or more instructions for performing any of the methods described above.

[0218] In the embodiments of this application, "and / or" describes the association relationship between associated objects, indicating that three relationships may exist. For example, A and / or B can represent the following three cases: only A exists, both A and B exist, and only B exists. The character " / " generally represents an "OR" relationship between associated objects. "At least one" refers to one or more. "At least one of A and B," similar to "A and / or B," describes the association relationship between associated objects, indicating that three relationships may exist. For example, at least one of A and B can represent the following three cases: only A exists, both A and B exist, and only B exists.

[0219] Furthermore, unless the context clearly indicates otherwise, the use of the singular forms of “a” and “the” in the embodiments of this application and the appended claims is also intended to include the plural forms.

[0220] Those skilled in the art will recognize that the various examples described in conjunction with the embodiments disclosed in this specification, the units and algorithm steps, can be implemented by electronic hardware or by a combination of computer software and electronic hardware. Whether the function is executed by hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such embodiments should not be considered beyond the scope of this application.

[0221] Those skilled in the art will clearly understand that, for convenience and brevity, the specific working process of the above-described systems, devices, and units can be referred to the corresponding process in the above-described method embodiments, and will not be repeated here.

[0222] In the several embodiments provided in this application, the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the described apparatus embodiments are merely exemplary. For example, the units are divided into logical functional divisions, and other division methods may be used in actual embodiments. For example, multiple units or components may be merged or integrated into another system, or some features may be ignored or not performed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be implemented using various communication interfaces. Indirect coupling or communication connection between devices or units can be implemented electronically, mechanically, or otherwise.

[0223] In addition, the functional units in the embodiments of this application can be integrated into a processing unit, each of which can exist physically separately, or two or more units can be integrated into a unit.

[0224] When these functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. The technical solution of this application can be implemented as a software product. The software product is stored in a storage medium and includes several instructions to instruct a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the embodiments of this application. The aforementioned storage medium includes any medium capable of storing program code, such as a USB flash drive, portable hard drive, ROM, RAM, magnetic disk, optical disk, etc.

[0225] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; they may be located in one place or distributed across multiple network units. Some or all of the units can be selected based on actual needs to achieve the purpose of the embodiment. Furthermore, the functional units in the embodiments of this application may be integrated into one processing unit, or each unit may exist physically independently, or two or more units may be integrated into one unit.

[0226] The above description is merely a specific implementation of this application and is not intended to limit the scope of protection of this application. Any variations or substitutions easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A communication method executed by a first network function, characterized in that, include: Receive a first message from the authentication server AS, wherein the first message includes the name of a second network function, the second network function being directly connected to a service provider that provides application services to the device, or directly connected to a network that provides network services to the device; An anchor key is generated based on the name of the second network function, wherein the anchor key is used to determine whether authentication is required between the device and the network; Send a second message to the second network function, wherein the second message includes a first security context of the second network function, wherein the first security context includes a terminal key, the terminal key being derived from the anchor key, and the terminal key being used to securely protect the communication between the device and the second network function.

2. The method according to claim 1, characterized in that, The first security context includes the identifier ID of the anchor key.

3. The method according to claim 1 or 2, characterized in that, The method further includes: A second security context is generated for the device, wherein the second security context includes the ID of the anchor key, and the second security context also includes an algorithm for generating the anchor key or the terminal key.

4. The method according to claim 3, characterized in that, The method further includes: Send the second security context to the device.

5. The method according to any one of claims 1 to 3, characterized in that, The second network function includes a service gateway.

6. The method according to any one of claims 1 to 5, characterized in that, After sending the second message to the second network function, the method further includes: A third message is received from the second network function, wherein the third message includes information related to the update of the anchor key.

7. A communication method performed by a second network function, characterized in that, include: Obtain a first security context for the second network function, wherein the first security context includes a terminal key, the terminal key is derived from an anchor key, the anchor key is used to determine whether authentication is required between the device and the network, the anchor key is generated based on the name of the second network function, and the terminal key is used to securely protect the communication between the device and the second network function. Store the first security context.

8. The method according to claim 7, characterized in that, The first security context includes the ID of the anchor key.

9. The method according to claim 7 or 8, characterized in that, Obtaining the first security context includes: A second message is received from a first network function, wherein the first network function is responsible for generating the anchor key or the terminal key, and the second message includes the first security context.

10. The method according to any one of claims 7 to 9, characterized in that, After receiving the second message from the first network function, the method further includes: A third message is sent to the first network function, wherein the third message includes information related to the update of the anchor key.

11. The method according to claim 10, characterized in that, The information related to the update of the anchor key includes one or more of the following parameters: the frequency of updating the anchor key, and one or more inputs for anchor key derivation.

12. The method according to any one of claims 9 to 11, characterized in that, Before receiving the second message from the first network function, the method further includes: By comparing the name of the second network function with the name of the old second network function, it is determined whether new authentication is required, wherein the second network function is a new second network function selected by the old second network function due to a switch. If the new authentication is not required, a fourth message is sent to the first network function, wherein the fourth message includes the name of the second network function and the temporary ID of the device.

13. The method according to claim 8 or 9, characterized in that, The second network function includes a service gateway.

14. A communication method executed by an authentication server AS, characterized in that, include: After successful mutual authentication between the device and the authentication server AS, the shared key between the device and the AS is obtained; Send a first message to a first network function, wherein the first message includes the name of a second network function, the name of the second network function being used to generate an anchor key, the anchor key being used to determine whether authentication is required between the device and the network.

15. A communication device, characterized in that, The communication device includes a processor configured to execute one or more instructions stored in a memory to cause the communication device to implement the method according to any one of claims 1 to 6, or the method according to any one of claims 7 to 13, or the method according to claim 14.

16. The communication device according to claim 15, characterized in that, The communication device also includes the memory.

17. The communication device according to claim 15 or 16, characterized in that, The communication device includes a communication interface, which is used to input and / or output information or data.

18. A communication device, characterized in that, The communication device includes functions or units for performing the method according to any one of claims 1 to 6, or the method according to any one of claims 7 to 13, or the method according to claim 14.

19. A communication device, characterized in that, The communication device includes a circuit and a communication interface, the communication interface being used to receive information and / or data to be processed by the circuit and to send the information and / or data to the circuit; the circuit being used to perform the method according to any one of claims 1 to 6, or to perform the method according to any one of claims 7 to 13, or to perform the method according to claim 14.

20. The communication device according to claim 19, characterized in that, The communication interface is also used to output information and / or data processed by the circuit.

21. A communication system, characterized in that, Includes one or more of the following communication devices: A first communication device for performing the method according to any one of claims 1 to 6; A second communication device for performing the method according to any one of claims 7 to 13; A third communication device that performs the method according to claim 14.

22. A computer-readable storage medium, characterized in that, It includes one or more instructions, wherein when the one or more instructions are executed on a computer, the computer performs the method according to any one of claims 1 to 6, or the method according to any one of claims 7 to 13, or the method according to claim 14.

23. A computer program product, characterized in that, It includes one or more instructions, wherein when the one or more instructions are executed on a computer, the computer performs the method according to any one of claims 1 to 6, or the method according to any one of claims 7 to 13, or the method according to claim 14.

Images