Method and apparatus for communication

By using key management functions to determine the security protection scheme and level of data sessions and generate keys, the problem of data leakage caused by key corruption is solved, and flexible communication security protection is achieved.

CN121890129APending Publication Date: 2026-04-17HUAWEI TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
HUAWEI TECH CO LTD
Filing Date
2024-01-10
Publication Date
2026-04-17

AI Technical Summary

Technical Problem

During communication, if the key is compromised, it may lead to data leakage. Existing technologies are insufficient to effectively protect the security of multiple communication sessions.

Method used

The Key Management Function (KMF) determines the security protection scheme and level of data sessions, collects parameters to generate keys, and provides flexible security protection mechanisms, including end-to-end and hop-to-hop protection methods.

Benefits of technology

It improves communication security, provides flexible security protection solutions, adapts to different security requirements of different devices and services, and enhances the security of data sessions.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121890129A_ABST
    Figure CN121890129A_ABST
Patent Text Reader

Abstract

The embodiment of the invention provides a method and a device. The method comprises: determining a security protection scheme for a data session between a device and a first server and a security protection level for the data session; based on the security protection scheme for the data session and the security protection level for the data session, a plurality of parameters are collected, where the plurality of parameters are used to derive at least one key for protecting the data session. Keys for protecting data sessions may be generated based on different schemes and different levels. This may improve the security of communications. In addition, this may bring more flexibility to different security requirements from different devices and different services.
Need to check novelty before this filing date? Find Prior Art

Description

Cross-reference to related applications

[0001] This application relates to and claims priority to U.S. Provisional Patent Application No. 63 / 586,707, filed on September 29, 2023, entitled "System and Method on Security Protection on Data Session in Future Networks".

[0002] The public information disclosed in the aforementioned application is incorporated herein by reference in its entirety. Technical Field

[0003] Embodiments of the present invention relate to the field of communication technology, and more specifically, to methods and apparatus for communication. Background Technology

[0004] When a user device requests services from a service provider, security processes may be involved. However, when keys are used to secure multiple communication sessions, corruption of those keys could lead to data breaches. Summary of the Invention

[0005] The embodiments of this application provide methods and apparatus for communication, which can improve the security of communication.

[0006] According to a first aspect, embodiments of this application provide a method for communication, which can be executed by a key management function or a chip installed in the key management function (KMF). KMF is a network function responsible for key management. The method includes: determining a security protection scheme and a security protection level for a data session between a device and a first server; and collecting multiple parameters based on the security protection scheme and the security protection level for the data session, wherein the multiple parameters are used to derive at least one key for protecting the data session.

[0007] According to the above technical solution, keys used to protect data sessions can be generated based on different schemes and levels. This can improve communication security. Furthermore, it provides greater flexibility for different security requirements from different devices and services.

[0008] In conjunction with the first aspect, in some embodiments, the data session between the device and the first server includes a first communication between the first network function and the device, and a second communication between the first network function and the first server.

[0009] In conjunction with the first aspect, in some embodiments, the security protection scheme for the data session includes a first scheme, the at least one key corresponding to the first scheme and including a first key and a second key, the first key being used to protect the first communication and the second key being used to protect the second communication.

[0010] According to the above technical solution, the security protection of data sessions can be achieved by jumping to another session.

[0011] In conjunction with the first aspect, in some embodiments, the first network function includes a first gateway or user plane function (UPF).

[0012] In conjunction with the first aspect, in some embodiments, the security protection scheme for the data session includes a second scheme, the at least one key corresponding to the second scheme and including a third key, the third key being used at the device and the first server.

[0013] According to the above technical solution, the security protection of data sessions can be achieved end-to-end.

[0014] In conjunction with the first aspect, in some embodiments, the data session is associated with a service, application, or session, or with a task or device.

[0015] In one embodiment, the security protection level for the data session includes a first level, and a key associated with the first level is used to protect the service or the application.

[0016] In another embodiment, the security protection level for the data session includes a second level, and a key associated with the second level is used to protect the session.

[0017] In yet another embodiment, the security protection level for the data session includes a third level, and a key associated with the third level is used to protect the task, which includes at least one session.

[0018] In conjunction with the first aspect, in some embodiments, the security protection scheme for the data session is a first scheme, and the plurality of parameters for deriving at least one key include a first parameter for generating the first key and a second parameter for generating the second key.

[0019] The first parameter includes: the device identifier (ID), the ID of the first network function, the ID of one or more algorithms used to generate the first key, a time window, and a shared key known to the device. The second parameter includes: the ID of the first network function, the ID of the first server, a time window, and a shared key known to the device.

[0020] When the security protection level for the data session is Level 1, the first parameter and the second parameter further include a service ID or an application ID. When the security protection level for the data session is Level 2, the first parameter and the second parameter further include a session ID. When the security protection level for the data session is Level 3, the first parameter and the second parameter further include a task ID.

[0021] In conjunction with the first aspect, in some embodiments, the security protection scheme for the data session is a second scheme. The plurality of parameters used to derive at least one key include: the device ID, the first server ID, a time window, and a shared key known to the device.

[0022] When the security protection level for the data session is Level 1, the plurality of parameters further includes a service ID or an application ID. When the security protection level for the data session is Level 2, the plurality of parameters further includes a session ID. When the security protection level for the data session is Level 3, the plurality of parameters further includes a task ID.

[0023] In conjunction with the first aspect, in some embodiments, the method further includes: receiving a first message, wherein the first message includes at least one of the following: a security process capability of a first network function or a security process capability of the device. Determining a security protection scheme for a data session between the device and the first server and a security protection level for the data session includes: determining the security protection scheme for the data session and the security protection level for the data session based on the first message.

[0024] In conjunction with the first aspect, in some embodiments, the method further includes: sending a second message to the first server, wherein the second message is used to request the security process capabilities of the first server; and receiving a third message from the first server, wherein the third message includes the security process capabilities of the first server.

[0025] In conjunction with the first aspect, in some embodiments, the method further includes: sending a fourth message, wherein the fourth message includes a first security context, the first security context including at least one of the following: the security context of the device, the security context of the first server, or the security context of the first network function.

[0026] In conjunction with the first aspect, in some embodiments, the method further includes: receiving a fifth message from a second network function, wherein the fifth message is used to request a refresh of the key used to protect the data session.

[0027] In conjunction with the first aspect, in some embodiments, the method further includes: receiving a sixth message from a second network function, wherein the sixth message indicates the release of the data session; and sending a seventh message, wherein the seventh message includes the ID of at least one key to be released, and the key used to protect the data session includes the at least one key.

[0028] According to a second aspect, embodiments of this application provide a method for communication, which can be executed by a second network function or a chip installed in the second network function. The method includes: receiving a fourth message, wherein the fourth message includes a first security context, the first security context being used to configure a key for protecting a data session between a device and a first server. The key for protecting the data session is generated based on a security protection scheme and a security protection level for the data session.

[0029] In conjunction with the second aspect, in some embodiments, the method further includes: sending a first message, wherein the first message includes at least one of the following: the security processing capability of a first network function or the security processing capability of the device, and the security protection scheme and the security protection level of the data session are determined based on the first message.

[0030] In conjunction with the second aspect, in some embodiments, the first security context includes the security context of the first server. The method further includes sending an eighth message to the first server, wherein the eighth message includes the security context of the first server.

[0031] In conjunction with the second aspect, in some embodiments, the first security context includes the security context of the first network function. The method further includes sending a ninth message to the first network function, wherein the ninth message includes the security context of the first network function.

[0032] In conjunction with the second aspect, in some embodiments, the first security context includes the security context of the device. The method further includes sending a tenth message to the device, wherein the tenth message includes the security context of the device.

[0033] In conjunction with the second aspect, in some embodiments, the method further includes: sending a fifth message to the KMF, wherein the fifth message is used to request a refresh of the key used to protect the data session.

[0034] In conjunction with the second aspect, in some embodiments, the method further includes: sending a sixth message to the KMF, wherein the sixth message indicates the release of the data session; and receiving a seventh message from the KMF, wherein the seventh message includes the ID of at least one key to be released, the key used to protect the data session including the at least one key.

[0035] According to a third aspect, embodiments of this application provide a method for communication, which can be executed by a first server or a chip installed in the first server. The method includes: receiving a second message from a KMF, wherein the second message requests the first server's security process capabilities; and sending a third message to the KMF, wherein the third message includes the first server's security process capabilities, which are used to determine a security protection scheme and a security protection level for a data session between a user equipment and the first server.

[0036] In conjunction with the third aspect, in some embodiments, the method further includes: receiving a fourth message from the KMF, wherein the fourth message includes the security context of the first server; or receiving an eighth message from a second network function, wherein the fifth message includes the security context of the first server.

[0037] In conjunction with the third aspect, in some embodiments, the method further includes: receiving a seventh message from the KMF, wherein the seventh message includes the ID of at least one key that needs to be released from the key used to protect the data session; or receiving an eleventh message from a second network function, wherein the eleventh message includes the ID of at least one key that needs to be released from the key used to protect the data session.

[0038] According to a fourth aspect, embodiments of this application provide a method for communication, the method being executable by a first network function or a chip installed in the first network function. The method includes: receiving a fourth message from a KMF, the fourth message including a security context of the first network function; or receiving a ninth message from a second network function, the ninth message including the security context of the first network function.

[0039] The security context of the first network function is used to configure a key at the first network function, the key being used to protect the data session between the device and the first server.

[0040] The key used to protect the data session is generated based on the security protection scheme and the security protection level of the data session.

[0041] In conjunction with the fourth aspect, in some embodiments, the method further includes: receiving a seventh message from the KMF, the seventh message including the ID of at least one key that needs to be released from the key used to protect the data session; or receiving a twelfth message from a second network function, the twelfth message including the ID of at least one key that needs to be released from the key used to protect the data session.

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

[0043] According to a sixth 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 fourth aspects or any possible implementation thereof.

[0044] Optionally, the chip may also include at least one memory.

[0045] Optionally, the chip may also include a communication interface for inputting and / or outputting information or data.

[0046] According to a seventh 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 fourth aspects or any implementation thereof.

[0047] According to an eighth aspect, a communication system is provided. The communication system may include the communication apparatus described in the fifth or seventh aspect. For example, the communication system may include one or more of the following: a KMF, a first network function, a second network function, or a first server. The communication system may also include devices.

[0048] According to a ninth aspect, a computer storage medium is provided for storing executable computer code for executing one or more instructions of a method in any one of the first to fourth aspects or any implementation thereof.

[0049] According to a tenth aspect, a computer program product is provided, comprising one or more instructions, wherein when the computer program product is run on a computer, the computer performs a method of any one of the first to fourth aspects or any implementation thereof. Attached Figure Description

[0050] Figure 1 This is a schematic diagram of a communication system.

[0051] Figure 2 An exemplary communication system is shown.

[0052] Figure 3 Another example of an ED and a base station is shown.

[0053] Figure 4 The unit or module in the device is shown.

[0054] Figure 5 The conceptual architecture of a 6G system is shown.

[0055] Figure 6 Network scenarios provided for some embodiments of this application.

[0056] Figure 7 This application provides a secure protection architecture for data sessions in some embodiments.

[0057] Figure 8 A schematic flowchart illustrating a method for communication provided for some embodiments of this application.

[0058] Figure 9 A schematic flowchart illustrating a method for communication provided for some embodiments of this application.

[0059] Figure 10 A schematic flowchart illustrating a method for communication provided for some embodiments of this application.

[0060] Figure 11 A schematic flowchart illustrating a method for communication provided for some embodiments of this application.

[0061] Figure 12 A schematic flowchart illustrating a method for communication provided for some embodiments of this application.

[0062] Figure 13 A schematic block diagram of a communication device provided for embodiments of this application.

[0063] Figure 14 A schematic block diagram of a communication device provided for embodiments of this application. Detailed Implementation

[0064] 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.

[0065] This application includes at least the following parts.

[0066] (1) Design method for security protection of data sessions The basic concept is that a network function (called the key management function, KMF) is used to select a security protection scheme and a security protection level for a data session. Furthermore, the KMF collects parameters for key derivation based on the selected scheme and level, and generates a key based on the selected scheme / level of security protection for the data session.

[0067] (2) Design the key generation process The related embodiments provide a process for key generation. These embodiments illustrate two questions: (1) how does KMF determine which security protection scheme / level to use for a data session; and (2) what parameters are used to derive the key based on the selected scheme / level? (3) Provide key update and key release procedures.

[0068] These embodiments provide details about the key update and key release processes.

[0069] This invention generally relates to wireless communication.

[0070] Many emerging trends will trigger considerations and designs for 6G / future wireless networks: new network infrastructure capabilities (e.g., widely deployed cloud-friendly infrastructure); new or relatively mature technologies (e.g., large-scale models of artificial intelligence (AI), data privacy, blockchain, etc.), which have made significant progress and have had a major impact on society and human life; new applications and services (e.g., AI services, data or sensing services, digital world services, etc.), which are widely used in industries / businesses and by individual customers; and a more globalized / open / collaborative operating trend (i.e., more open and collaborative operating models are becoming prevalent in many sectors).

[0071] New expectations and stricter requirements for future networks have also driven a rethinking and development of next-generation wireless networks. These requirements include privacy and trustworthiness, simplified standardization, and rapid deployment.

[0072] All of these factors have driven the research on the sixth-generation (6G) network architecture.

[0073] The proposed 6G network architecture (centered on X) is based on SBA (XaaS service) and / or cloud-native. X, as a service, can be represented as XaaS.

[0074] The requirements for 6G system network architecture design include: (1) The proposed 6G network architecture needs to support new 6G services, which can be developed / deployed by third parties.

[0075] (2) The proposed 6G network architecture needs to embrace a more open ecosystem and be open to third parties with strong technical capabilities.

[0076] (3) The proposed 6G network architecture needs to achieve better trust management.

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

[0078] To facilitate understanding of the embodiments of this application, let's first take... Figures 1 to 4 The following describes in detail the communication system to which the embodiments of this application are applicable, using the communication system shown as an example.

[0079] 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 later) radio access network or a traditional (e.g., fifth-generation (5G) or fourth-generation (4G)) radio access network. One or more electronic devices (EDs) 110a to 110j (collectively referred to as 110) may be interconnected with each other or connected to one or more network nodes (170a, 170b, collectively referred to as 170) within 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. Furthermore, communication system 100 includes a public switched telephone network (PSTN) 140, the Internet 150, and other networks 160.

[0080] 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.

[0081] Terrestrial communication systems and non-terrestrial communication systems can be considered subsystems of a communication system. Figure 2In the example shown, communication system 100 includes electronic devices (EDs) 110a to 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.

[0082] 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 transmission with T-TRP 170a via terrestrial air interface 190a. In some examples, ED 110a to 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 transmission with NT-TRP 172 via non-terrestrial air interface 190c.

[0083] 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.

[0084] 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.

[0085] 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.

[0086] 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.

[0087] 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.

[0088] 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.

[0089] 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.

[0090] 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.

[0091] 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.

[0092] 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.

[0093] 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.

[0094] 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).

[0095] 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.

[0096] 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.

[0097] 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.

[0098] 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.

[0099] 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.

[0100] 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.

[0101] 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.

[0102] 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.

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

[0104] 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 an AI or machine learning (ML) module. 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.

[0105] 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.

[0106] 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.

[0107] 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.

[0108] 6G systems adopt a service-based architecture and the XaaS concept. XaaS services in 6G systems are categorized into three layers. For ease of explanation, Figure 5 The conceptual architecture of a 6G system is shown.

[0109] The infrastructure layer includes the infrastructure that supports 6G services. This includes wireless network infrastructure (such as RAN and core network (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.

[0110] Each infrastructure can have control and management functions for infrastructure management, represented as C / M functions. Each of these infrastructures is an Infrastructure as a Service.

[0111] The control and management (C / M) layer comprises the control and management services for the 6G system. These are developed and deployed using slicing technology and leveraging the resources provided by the infrastructure layer. In the conceptual architecture of a 6G system: Resource management (RM) as a service provides the ability to manage the lifecycle of various slices and allocate air resources to wireless devices.

[0112] Mission management (MM) refers to the ability of a service provider to program the configuration of XaaS services at the service layer to provide mission services. A 6G mission is defined as a service provided by a 6G system to a customer. A mission 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.

[0113] - 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.

[0114] 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.

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

[0116] Protocol as a Service (PCA) provides the ability to customize the protocol stack for the identified interface design service. The protocol stack can be predefined for selection on demand, or it can be designed on demand.

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

[0118] 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.

[0119] 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.

[0120] 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—statistical data from any type of sensor, device, network function, etc.

[0121] - The data storage and sharing service is represented as NET4Data as a Service. This service 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 regarding the control of identified data.

[0122] - Services that provide access to the digital world are 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.

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

[0124] - 6G connectivity services are represented as NET4CON as a service. Enhanced connectivity services, such as Connection-Oriented Networking (NET4CON) as a service, provide the ability to exchange messages and data between supporting new 6G services.

[0125] 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.

[0126] 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.

[0127] Any pair of XaaS services in a 6G system can also be each other's customers and providers. Some examples are: the infrastructure owner provides its resources to the XaaS services in the service layer and the C / M layer; the RM service may need the capabilities provided by NET4AI, DAM, and NET4DW to enable its resource management for vertical slices; the CONET service and the NET4Data service may need the capabilities provided by NET4BC to run.

[0128] Key concepts of 6G systems 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.

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

[0130] - 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.

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

[0132] - 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.

[0133] - 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.

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

[0135] - 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.

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

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

[0138] - 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.

[0139] - 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.

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

[0141] - 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.

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

[0143] - 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.

[0144] Currently, when a UE is able to connect to the network, a security process involving the UE and network functions is involved. For ease of illustration, the key hierarchy or key framework involved in the current security process may include: keys for protecting non-access stratum (NAS) signals using specific integrity / encryption algorithms, keys for protecting user plane (UP) traffic using specific integrity / encryption algorithms, and keys for protecting RRC signaling using specific integrity / encryption algorithms. These keys can be used to securely protect the NAS interface, data transmitted from the UE to the RAN, and the RRC interface, respectively; correspondingly, these keys may also be referred to as keys for NAS integrity / encryption, keys for UP integrity / encryption, and keys for RRC integrity / encryption, respectively. These keys are derived from long-term shared keys known to the UE and the network. The keys for UP integrity / encryption can be indirectly derived from the long-term shared keys combined with information about the UE and the service network. For example, the UE information may include the PCI or the UE's ID. After a PDU session is established, these keys for UP integrity / encryption can be used to protect data transmitted from the UE to the RAN. These keys for UP integrity / encryption can be used for secure multi-PDU sessions. However, using the same key to protect multiple communication sessions may lead to data leakage if the key is compromised.

[0145] In future networks, new applications and services will be supported, such as AI services, data services, sensing services, and digital world services. These services can be developed and deployed using resources provided by infrastructure (e.g., wireless access networks, data centers, or other infrastructure) and leveraging network function virtualization and slicing technologies. Each of these services can be called anything as a service (XaaS). Multiple network functions may exist within an XaaS module. These network functions can be categorized into two types: control / management (C / M) functions and data processing functions. Data processing functions are used to process data and can only exist in the XaaS service layer. C / M functions are used for control and management and can exist in both the XaaS service layer and the C / M layer. The service provider for XaaS can also be called an XaaS service. Network functions that can be used to process data related to XaaS services and deployed by XaaS services can be called XaaS processing service functions.

[0146] Figure 6 Network scenarios provided for some embodiments of this application. For example... Figure 6As shown, a control / management trustworthy gateway (C / M-TW-GW) is a network function that can be defined as an endpoint of a network-side C / M session. A C / M session is set up to transmit control messages for a device or XaaS service. A C / M session can be defined as a secure logical connection between a device (e.g., a UE) and its serving C / M-TW-GW. A data trustworthy gateway (Data-TW-GW) is a network function that can be defined as an endpoint of a device's data session. A data session is established to enable a device or XaaS service to participate in data processing. A data session can be defined as a secure logical connection between a device and its serving Data-TW-GW. A radio bearer (RB) handler is a network function that can be implemented as a radio access network (RAN). RB handlers can connect both other infrastructure (e.g., the core network and / or a third-party cloud) and the C / M-TW-GW. Communication between a device and an RB handler can include either a C / M RB or a data RB. A C / M plane RB can be defined as an air connection used to carry control signaling for air interface management and C / M plane messages. A data plane RB can be an air connection used to carry data plane traffic. In this scenario, there may be more network functions, such as authentication servers and authorization servers.

[0147] like Figure 6 As shown, there are several interfaces within the network scenario used to connect these NFs. For example, interface I can be defined as a set of security functions that enable devices to securely authenticate and access services and prevent attacks on the wireless interface. Similarly, interface II can be defined as a set of security functions that enable... Figure 6The system shown can securely exchange C / M sessions between the device and the C / M-TW-GW, or securely exchange data sessions between the device and the data-TW-GW. For example, interface III can be defined as a set of security functions enabling the system to securely exchange C / M sessions between the XaaS service and the C / M-TW-GW, or securely exchange data sessions between the XaaS service and the data-TW-GW. In other words, interface I can support connections between the device and the RB processor; interface II can support connections between the device and the C / M-TW-GW / data-TW-GW; and interface III can support connections between the XaaS service and the C / M-TW-GW / data-TW-GW. For example, interface IV can support connections between the RB processor and the C / M-TW-GW / data-TW-GW. For clarity, compared to the current network, the NAS interface between the UE and the AMF can be switched to interface II, the C / M session interface between the UE and the serving C / M-TW-GW.

[0148] In this scenario, when a device is able to connect to the network, a secure process between the device (e.g., UE) and network functions will be involved. For example, when a device is able to connect to the C / M-TW-GW and / or to the RAN infrastructure (e.g., Figure 6 In the RB processing procedure within the RAN infrastructure, when the RAN infrastructure connects to other infrastructures (such as CN infrastructure, third-party clouds) and both C / M-TW-GW, the security process may include a primary authentication and key negotiation process. The purpose of the primary authentication and key negotiation process is to achieve mutual authentication between the device and the service network and to provide key materials that can be used between the device and the service network. These key materials can be used for signaling security protection of Interface I and Interface II in subsequent security processes. Alternatively, when a device requests a service, the security process may include a secondary primary authentication and key negotiation process. The purpose of the secondary authentication and key negotiation process is to achieve mutual authentication between the device and the XaaS service and to provide key materials that can be used between the device and the XaaS service in subsequent security processes. These key materials can be used for data security protection of Interface I and Interface II in subsequent security processes.

[0149] Because future networks may involve new services, network functions, and interfaces, security protection for these new interfaces may become necessary. For example, a data-TW-GW may be introduced in future networks, allowing direct communication between devices and the data-TW-GW. In other words, current networks do not support connections between devices and the data-TW-GW, but this could be achieved through... Figure 6Interface II is supported as mentioned above. For example, a device's data session can be a connection between the device and its service data-TW-GW; a XaaS service's data session can be a connection between the service data-TW-GW and the XaaS service. Furthermore, end-to-end data sessions can be introduced. An end-to-end data session can connect from a device to the service data-TW-GW, or from the service data-TW-GW to the XaaS. Additionally, since future work may involve data sessions, but the current network does not support data sessions, current security protections do not cover the security protection of data sessions.

[0150] like Figure 6 As shown, a data-TW-GW is introduced in the 6G system, and a new interface II is proposed between the device and the data-TW-GW. The device's service data-TW-GW is defined as the endpoint of the device's data session. The service data-TW-GW can be deployed in the RAN domain. The service data-TW-GW can also be deployed in the CN domain. XaaS services (e.g., DAM services, AI services) can be deployed in either the RAN or CN domain. The device's data session is a secure connection between the device and its service data-TW-GW (i.e., interface II). The XaaS service's data session is a secure connection between the service data-TW-GW and the XaaS service (i.e., interface III). The end-to-end data session includes both the device's data session and the XaaS service's data session.

[0151] In 5G systems, security protection for the NAS interface, RRC interface, and data from the UE to the RAN utilizes keys for NAS encryption / integrity, keys for RRC encryption / integrity, and keys for UP encryption / integrity. These keys are derived from long-term shared keys known to the UE and the network. The keys for UP encryption / integrity can be indirectly derived from the long-term shared keys combined with UE information (e.g., PCI, UE ID) and information from the serving network (e.g., the name of the serving network). These keys for UP encryption / integrity are used for data protection from the UE to the RAN after the PDU session is established. These keys for UP encryption / integrity can be used for secure multi-PDU sessions. Multiple studies have shown that applying the same key to multiple communication sessions can lead to data leakage when the key is compromised. Furthermore, NIST recommends that keys should be applied only once per communication, or that each session should be unique.

[0152] 6G proposes allowing the UE to communicate directly with the serving data-TW-GW (without the RAN node's involvement in encrypted data). The NAS interface between the UE and AMF is switched to C / M session interface II between the UE and the serving C / M-TW-GW, and data session interface II between the UE and the serving data-TW-GW. However, what is lacking is an efficient mechanism to support the security of the data session between the UE and the serving data-TW-GW. For example: Does the communication between the UE and the serving data-TW-GW require security protection? Which function determines this? What security parameters should be included? 6G introduces an end-to-end data session that connects from the UE to the serving data-TW-GW and from the serving data-TW-GW to the XaaS service. In 5G systems, IPsec or TLS protocols can be used to implement secure communication on interfaces between the AMF and other NFs, or on interfaces between UPFs, or on interfaces from UPFs to DN-AAA. How to manage these keys for IPsec or TLS protocols is outside the scope of 3GPP. In 6G systems, DN-AAA can be deployed by the network (e.g., the XaaS service), and how to provide secure communication from the data-TW-GW to the XaaS service should be resolved by the network. Therefore, the following technical questions arise: Which function is responsible for providing keys for secure communication between the data-TW-GW and the XaaS service? What is the security protection level for the end-to-end data session? To address this issue, a system and method for securing data sessions in future networks are provided. This research provides a system for securing data sessions in which KMF selects a security protection scheme / level for the data session and generates keys that should be configured to the network and devices. These keys can be per-session, per-service, or per-device. This improves the security protection of data sessions. More importantly, this application can provide security customization to provide hop-to-hop security protection or end-to-end security protection.

[0153] A system is provided for securing data sessions, wherein KMF selects a security protection scheme / level for the data session and generates keys, which should be configured to the network and devices. These keys can be per session, per service, or per device. This can improve the security protection of data sessions. According to the concept of this application, the following technical problems exist.

[0154] (1) Key for each session If key derivation techniques are used in 5G systems, the keys will be used across multiple PDU sessions. These keys could potentially lead to data breaches. What new problems arise if keys are to be used only once per communication, or to be unique for each session? For example, are keys associated with a session? Which function provides session information for key generation? How are these keys updated if the session changes? How are these keys activated or released if the session is terminated? (2) How to determine the key for each session, each service, and each device In 5G systems, keys used for UP encryption / integrity are used across multiple secure PDU sessions, but these keys are associated with a specific device. As discussed earlier, in 6G systems, keys can be per session, per service, and per device. Keys can be used for hop-to-hop security protection (e.g., security protection for communication from a device to the service data-TW-GW, and security protection for communication from the service data-TW-GW to the XaaS service). Keys can be used for end-to-end security protection (e.g., security protection for communication from a device to the XaaS service). So, which function selects or determines which type of key will be used, and how does that function make the selection? How are these keys configured for the data-TW-GW, the device, or the XaaS service? In response to the problems identified above, this application provides a system and method for securely protecting data sessions in a network (e.g., a future network), which can improve the security protection of data sessions.

[0155] Figure 7 This application provides a data session security protection architecture for some embodiments. The purpose of these embodiments is to provide a method for securely protecting data sessions. These data sessions include communication between a device and a data-TW-GW, and communication between the data-TW-GW and XaaS services (such as...). Figure 7 (As shown).

[0156] Mission management (MM) can be a network function responsible for managing missions. A mission can be a service type provided by a single XaaS service, or it can be a service type that requires contributions from multiple XaaS services. For example, a mission may include at least one session, and a session may include at least one service or application. For clarity, MM can support services that provide mission services by configuring XaaS service providers with the ability to configure them.

[0157] KMF is the network function responsible for key generation and key configuration. Furthermore, KMF can handle key refresh and key revocation. For ease of explanation, let's look at... Figure 6In the scenario illustrated, multiple intermediate and terminal keys can be used to secure communication on Interface I and Interface II. These could include keys for protecting C / M sessions (also known as C / M session keys) and keys for protecting data sessions (also known as data session keys). These keys are generated by one or more KMFs and configured for the relevant network functions (e.g., C / M-TW-GW and Data-TW-GW). Therefore, these keys cannot be generated by the relevant network functions themselves.

[0158] KMF can also be responsible for managing the security context of a device. A security context is a state that should be established locally at the device and service network domain. For example, the security context of a data-TW-GW may include the keys configured for the data-TW-GW. The security context of a data-TW-GW may also include a set of identifiers or names corresponding to the encryption and integrity algorithms implemented in the data-TW-GW. As another example, the security context of an XaaS service may include the keys configured for the XaaS service. The security context of an XaaS service may also include a set of identifiers or names corresponding to the encryption and integrity algorithms implemented in the XaaS service. As yet another example, the security context of a device may include inputs for generating keys to be configured for the device, and algorithms used to generate these keys. The security context of a device may also include a set of identifiers or names corresponding to the encryption and integrity algorithms implemented in the device.

[0159] like Figure 7 As shown, communication between a device and an XaaS service can include communication between the device and the data TW-GW and communication between the data TW-GW and the XaaS service. In other words, a data session between a device and an XaaS service can include both the device's data session and the XaaS service's data session.

[0160] In some implementations, different security protection schemes can be used for data sessions. For example, data session security protection can include end-to-end security protection. In this scenario, the keys used to protect the data session are used in both the device and the XaaS service. These keys can also be referred to as keys for the XaaS service and the device. As another example, data session security protection can include hop-to-hop security protection. In this scenario, the keys used to protect the data session can include keys for protecting data sessions on Interface II (also known as keys for the data-TW-GW and the device) and keys for protecting data sessions on Interface III (also known as keys for the data-TW-GW and the XaaS service). The key for protecting data sessions on Interface II can be known by the device and the data-TW-GW. The key for protecting data sessions on Interface III can be known by the data-TW-GW and the XaaS service. KMF can be used to select a security protection scheme for the data session from different schemes.

[0161] In some implementations, one or more data sessions between a device and an XaaS service can be associated with at least one service / application, at least one session, at least one task, or at least one device. Different security protection levels can be applied to data sessions. For ease of illustration, the keys used to secure data sessions can have different levels, such as keys for services / applications, keys for sessions, or keys for tasks. Keys for services / applications can be used to protect the service / application associated with the data session. Keys for sessions can be used to protect the session associated with the data session. Keys for tasks can be used to protect all or more data sessions belonging to a task. In some embodiments, the keys used to secure data sessions can include keys for devices. Keys for devices can be used to protect all or more data sessions belonging to a device. In other words, data session security protection can be applied to each service / application, each session, each task, or each device. There can be multiple devices and multiple data sessions capable of communicating with the XaaS service. KMF can select the security protection level for each data session. The keys used to protect these data sessions can include: keys for services / applications, keys for each session, keys for each task, or keys for each device.

[0162] Technical terms, such as “C / M-TW-GW,” “Data-TW-GW,” and “KMF,” are not limited to the specific exemplary names presented herein. These terms or the concepts they refer to may also be called by other names. For example, a key management function may be called a key generation and configuration function. As another example, a control / management trusted gateway may be called a control / management gateway.

[0163] Figure 8 The following is a schematic flowchart of method 300 provided for some embodiments of this application. The steps involved in method 300 are described in detail below.

[0164] In S301, the second network function sends the first message to the KMF.

[0165] The first message may include at least one of the following: the security processing capability of the first network function and the security processing capability of the device.

[0166] Security capabilities can indicate the procedural capabilities that can be provided to perform security protection for data sessions. For example, a device's security procedural capabilities can indicate the encryption / integrity algorithms that the device can implement. Similarly, the security procedural capabilities of a first network function can indicate the encryption / integrity algorithms that the first network function can implement. As another example, a device's security procedural capabilities can also indicate the key derivation algorithms that the device can implement.

[0167] The first message can be used to request a security context associated with the data session between the device and the first server.

[0168] In S302, KMF sends a second message to the first server.

[0169] The second message can be used to request the security process capabilities of the first server.

[0170] In S303, the first server sends a third message to KMF.

[0171] The third message includes the security process capabilities of the first server.

[0172] In some embodiments, steps S302 and S303 may be skipped when the security process capabilities of the first server are not required.

[0173] In S304, KMF determines the security protection scheme and the security protection level for the data session between the device and the first server.

[0174] The data session between the device and the first server may include a first communication and a second communication. The first communication may be communication between the device and a first network function, and the second communication may be communication between the first network function and the first server. For ease of explanation, let's refer to... Figure 6 or Figure 7Taking the scenario shown as an example, the XaaS service can serve as an example of the first server, and the data-TW-GW can serve as an example of the first network function. Correspondingly, the device's data session (i.e., the data session on interface II) can serve as an example of the first communication, and the XaaS service's data session (i.e., the data session on interface III) can serve as an example of the second communication. In some implementations, the first network function can be a user plane function (UPF).

[0175] A security protection scheme can instruct one or more network functions that can use keys to protect data sessions between a device and a first server. For example, the security protection scheme can instruct whether to use a key to protect the data session at a first network function.

[0176] In some embodiments, the security protection scheme for data sessions includes a first scheme. At least one key corresponding to the first scheme may include a first key and a second key. The first key is used to protect a first communication, and the second key is used to protect a second communication. The first key can be configured for a device and a first network function, while the second key can be configured for the first network function and a first server. The first key can be used at the device and the first network function, and the second key can be used at the first network function and the first server. For ease of explanation, ... Figure 7 Taking the scenario shown as an example, the key used to protect the data session on interface II can be considered as an example of the first key, and the key used to protect the data session on interface III can be considered as an example of the second key. Hop-to-hop security protection for the data session can be considered as an example of the first security protection scheme.

[0177] In some embodiments, the security protection scheme for the data session includes a second scheme. At least one key corresponding to the second scheme may include a third key, wherein the third key is used at both the device and the first server. For ease of illustration, ... Figure 7 Taking the scenario shown as an example, end-to-end security protection for data sessions can serve as an example of a second security protection scheme.

[0178] In some implementations, a data session is associated with at least one service / application, at least one session, at least one task, or at least one device.

[0179] In one embodiment, the security protection level includes a first level. A key corresponding to the first level can be used to protect the data session by protecting at least one service / application. For example, services #1 through #3 are associated with data session #1. The keys used to protect the data session can include keys #1 through #3. Keys #1 through #3 can be used to protect services #1 through #3 respectively. In other words, according to the first level, security protection for the data session can be performed for each service / application.

[0180] In another embodiment, the security protection level includes a second level. A key corresponding to the second level can be used to protect a data session by protecting at least one session. In other words, according to the second level, security protection for the data session can be performed for each session.

[0181] In another embodiment, the security protection level includes a third level. A key corresponding to the third level can be used to protect all or one data sessions associated with each of the at least one task. In other words, according to the third level, security protection for the data sessions can be performed for each task.

[0182] For ease of explanation, task #1 may include data session #1, and task #2 may include data session #2 and data session #3. For example, when performing security protection for data sessions according to the second level, the keys used to protect the data sessions may include keys #4 through #6. Keys #4 through #6 can be used to protect data sessions #1 through #3, respectively. As another example, when performing security protection for data sessions according to the third level, the keys used to protect the data sessions may include keys #7 and #8. Keys #7 and #8 can be used to protect one or more data sessions associated with task #1 and task #2, respectively.

[0183] In another embodiment, the security protection level includes a fourth level. A key corresponding to the fourth level can be used to protect all data sessions associated with each of the at least one device. For example, data sessions #4 and #5 are associated with UE #1, and data session #6 is associated with UE #2. The keys used to protect the data sessions may include key #9 and key #10. Key #9 and key #10 can be used to protect one or more data sessions associated with UE #1 and UE #2, respectively. In other words, according to the fourth level, security protection for data sessions can be performed for each device.

[0184] In one embodiment, there are two security protection schemes for the data session. One is end-to-end security protection for the data session, where the data used to protect the keys is known to both the device and the XaaS service. The other is hop-to-hop security protection for the data session, where there are keys for data protection on interface II and keys for data protection on interface III. Furthermore, the keys used to secure the data session can have different levels, such as keys for each device, keys for each service (or application), and keys for each session (or task). It should be noted that a task or a session may include at least one service or application. The keys can be used for data encryption or data integrity. The KMF should determine the scheme and level of security protection used for the data session.

[0185] In S305, KMF collects multiple parameters based on the security protection scheme and the security protection level of the data session.

[0186] Multiple parameters are used to derive at least one key for protecting data sessions. These parameters may include at least one of the following: information from the device, information from a first network function, information from a first server, and information from the KMF. The second network function can be used to manage multiple tasks.

[0187] For ease of explanation, using Figure 7 In the scenario illustrated, the MM can serve as an example of a second network function. Parameters used for key derivation can include: information from the MM, information from the device, information from the data-TW-GW, information from the KMF, and information from the XaaS service. For example, information from the MM can include a service ID / application ID, or a session ID / task ID. A task or a session can include at least one service or an application. As another example, information from the device can include the device ID and the ID of the algorithm used to generate the key. As yet another example, information from the data-TW-GW can include the data-TW-GW ID. As yet another example, information from the KMF can include a shared key known to the device and the KMF, indicating a time window for key verification. The shared key can be a root key. As yet another example, information from the XaaS service can include the ID of the XaaS processing service function (PSF). The XaaS PSF is a network function deployed by the XaaS service to process data related to the XaaS service.

[0188] In some implementations, when using a first security protection scheme to protect the data session between the device and the first server, multiple parameters include a first parameter for generating a first key and a second parameter for generating a second key. The first parameter may include at least one of the following: the device ID, the ID of a first network function, the ID of one or more algorithms used to generate the first key, a time window, or a shared key known to the device and the KMF. The second parameter may include at least one of the following: the ID of the first server, the ID of the first network function, the ID of one or more algorithms used to generate the second key, a time window, or a shared key.

[0189] In some embodiments, when the first security protection level is used to protect the data session between the first server and the device, the first parameter and the second parameter further include a service ID / application ID. When the second security protection level is used to protect the data session between the first server and the device, the first parameter and the second parameter further include a session ID. When the third security protection level is used to protect the data session between the first server and the device, the first parameter and the second parameter include a task ID.

[0190] In some implementations, multiple parameters include at least one of the following: the device ID, the ID of the first server, the time window, or a shared key known to the device and KMF.

[0191] In some embodiments, when the first security protection level is used to protect the data session between the first server and the device, multiple parameters include a service ID / application ID. When the second security protection level is used to protect the data session between the first server and the device, multiple parameters include a session ID. When the third security protection level is used to protect the data session between the first server and the device, multiple parameters include a task ID.

[0192] In some implementations, KMF determines the security protection scheme and security protection level based on at least one of the following: local policies from the network operator or security requirements of the data session.

[0193] In some implementations, the security protection scheme and security protection level can be determined based on at least one of the following: the security process capabilities of the first server, the security process capabilities of the device, or the security process capabilities of the network function.

[0194] In S306, KMF generates a security context.

[0195] At least one of the following can be generated based on the collected parameters: the security context of the device, the security context of the first network function, or the security context of the first server.

[0196] In S307, KMF sends a fourth message to configure the security context.

[0197] Key configuration can be implemented by KMF or a second network function.

[0198] In some embodiments, the KMF is responsible for key configuration. A fourth message can be used to configure these security contexts. For example, in S307a, the KMF can send a message to a first network function. The message may include the security context of the first network function. As another example, in S307b, the KMF can send a message to a first server. The message may include the security context of the first server. Yet another example, in S307c, the KMF can send a message to a second network function. The message includes the security context of the device. These messages can serve as examples of the fourth message.

[0199] In some embodiments, the second network function is responsible for key configuration. For example, in S307c, the KMF can send a message to the second network function, the message including the security context of the device and the security context of the first server. When using the first security protection scheme, the message may also include the security context of the first network function. In this scenario, steps S307a and S307b can be skipped. The message in S307c can be used as an example of a fourth message.

[0200] In other words, step S307 includes step S307c. Furthermore, in some embodiments, step S307 also includes steps S307a and S307b.

[0201] In fact, the key used to protect data sessions can be refreshed or updated.

[0202] In some implementations, the second network function sends a fifth message to the KMF to request a refresh of the keys used to protect the data session. The KMF can then refresh these keys. New keys can be generated and configured for the relevant entities.

[0203] In practice, when a data session is released, one or more keys can be released. In this scenario, KMF can send a sixth message for key release. This message may include the ID of at least one key that needs to be released.

[0204] Similar to key configuration, key release can be achieved by KMF or a second network function.

[0205] In some implementations, the KMF is responsible for key release. For example, the KMF can send a message to a first network function. This message may include the IDs of one or more keys that need to be released at the first network function. As another example, the KMF can send a message to a first server. This message may include the IDs of one or more keys that need to be released at the first server. Yet another example is that the KMF can send a message to a second network function. This message may include the IDs of one or more keys that need to be released at the device. Such messages can be used as examples of a sixth message.

[0206] In some embodiments, the second network function is responsible for key configuration. For example, the KMF can send messages to the second network function. These messages may include the IDs of one or more keys that need to be released at the first server and the IDs of one or more keys that need to be released at the device. When using the first security protection scheme, the messages may also include the IDs of one or more keys that need to be released at the first network function.

[0207] In some embodiments, when the second network function is responsible for key configuration, method 300 further includes steps S308 and S309.

[0208] In S308, the second network function sends an eighth message to the first server, the eighth message including the security context of the first server.

[0209] In S309, the second network function sends a ninth message to the first network function, the ninth message including the security context of the first network function.

[0210] In S310, the second network function sends a tenth message to the device, the tenth message including the device's security context.

[0211] In some embodiments, when the second network function is responsible for key release, the second network function sends an eleventh message to the first server, the message including the IDs of one or more keys that need to be released at the first server. The second network function sends a twelfth message to the first network function, the twelfth message including the IDs of one or more keys that need to be released at the first network function. The second network function sends a thirteenth message to the device, the thirteenth message including the IDs of one or more keys that need to be released at the device.

[0212] For ease of explanation, using Figure 7 Taking the scenario shown as an example, we will combine Figure 9 Describe examples of methods for securing data sessions.

[0213] Figure 9 A schematic flowchart of method 400 provided for some embodiments of this application. Figure 9The method 400 shown may include steps S402 to S412. Each step is described in detail below.

[0214] In S402, MM defines the security protection for data sessions.

[0215] When the MM receives a service request from the device, it can determine whether security protection for the data session is required. If security protection is required, the MM can send a request for security protection to the KMF. The KMF can then receive this request.

[0216] In S404, KMF defines the security protection scheme and level for data sessions.

[0217] In S406, KMF collects the inputs used for key derivation.

[0218] KMF can collect parameters based on security protection schemes and levels, which can be used as inputs for key derivation.

[0219] In S408, KMF selects the algorithm for key derivation and the algorithm for key activation.

[0220] KMF can select the algorithm used for key derivation. The algorithm used for key derivation can be used to generate keys for protecting data sessions. For example, KMF can select an algorithm to generate keys for data-TW-GW and devices, keys for data-TW-GW and XaaS services, or keys for XaaS services and devices.

[0221] Keys used to protect data sessions may include keys for protecting data sessions using a specific encryption algorithm, and / or keys for protecting data sessions using a specific integrity algorithm. The KMF can determine the specific encryption algorithm and the specific integrity algorithm. For example, keys used for the data-TW-GW and devices may include keys for protecting data sessions on Interface II using a specific encryption algorithm, and keys for protecting data sessions on Interface II using a specific integrity algorithm. These encryption and integrity algorithms can be determined by the KMF.

[0222] In S410, KMF generates security contexts.

[0223] KMF can generate keys for data encryption and keys for data integrity. KMF can generate security contexts for devices, data-TW-GW, and XaaS services.

[0224] In S412, configure the security context.

[0225] These security contexts can be configured by KMF or MM for devices or related network functions.

[0226] in other words, Figure 9 It shows the corresponding Figure 7 The principle of data session security protection is as follows: When a service request is received from a device, the MM should determine whether it needs to protect the data session. If the MM needs to protect the data session, it should request security protection from the KMF. The KMF should select a security protection scheme and a security protection level for the data session. Then, the KMF collects parameters for key derivation based on the selected scheme and level. Next, the KMF selects the algorithm for key derivation, the algorithm for data encryption, and the algorithm for data integrity. Then, the KMF generates keys for data encryption and data integrity, as well as security contexts for the device, the data-TW-GW, and the XaaS service. Finally, these security contexts are configured for the device, the data-TW-GW, and the XaaS service.

[0227] Compared with the existing technology in 3GPP 33.501, the method for securing data sessions can have the following new features. (1) Communication between the device and the service data-GW should be protected. When communication is protected, the communication content will be encrypted and cannot be read by the RAN and other data-TW-GWs. (2) KMF has new features to determine which security protection scheme / level on the data session and the collection input for key generation.

[0228] For ease of explanation, the following will be combined with Figure 10 An example describing the call flow of the key generation process.

[0229] Figure 10 Schematic flowcharts illustrating methods for communication provided for some embodiments of this application. These embodiments provide information regarding... Figure 9 More details on key generation. Key points regarding the security of data sessions are as follows: (1) How does KMF determine the security protection scheme / level for data sessions? KMF should determine the security protection scheme / level for data sessions based on MM's service security requirements, network operator's local policies, equipment, and the security process capabilities of the service data-TW-GW and XaaS services. It should be noted that MM's security requirements should include the equipment's service security requirements and MM's network security performance. Security process capabilities should indicate what process capabilities can be provided to perform security protection for data sessions, such as algorithms for data encryption / integrity and algorithms for key derivation.

[0230] (2) What are the parameters used for key derivation depending on the selected scheme / level? Parameters used for key derivation can include information from the MM (Master Controller), the device, the data-TW-GW (Data-TW-GW), the KMF (Key Management Controller), and the XaaS service. For example, information from the MM can include a service ID / application ID or a task ID / session ID. It should be noted that a task or a session can include at least one service or application. Information from the device can include at least the device ID and the algorithm ID used to generate the key. Information from the data-TW-GW can include at least the data-TW-GW ID. Information from the KMF can include at least the root key known to the device and the KMF, and a time window indicating the key's verification period. Information from the XaaS service can include at least the ID of the XaaS PSF (Processing Service Provider) used to process the data.

[0231] For ease of explanation, Figure 7 Taking the scenario shown as an example, Table 1 illustrates the parameters used for key derivation according to some embodiments of this application.

[0232] As shown in Table 1, the keys used for the data-TW-GW and devices refer to those configured for both the data-TW-GW and the devices. The keys used for the data-TW-GW and XaaS services refer to those configured for both the data-TW-GW and the XaaS PSF used for data processing. The keys used for devices and XaaS services refer to those configured for both the devices and the XaaS PSF. In other words, the keys used for the data-TW-GW and devices can be examples of the first key, the keys used for the data-TW-GW and XaaS services can be examples of the second key, and the keys used for the XaaS services can be examples of the third key. "Bounce to hop" in Table 1 indicates that KMF selects hop-to-hop security protection for the data session, and end-to-end security protection for the data session can be represented by "end-to-end" in Table 1. "Per device," "Per task / session," and "Per service / application" in Table 1 can respectively represent the security protections performed for each device, each task / session, and each service / application for the data session. The ID of the XaaS PSF can be used as an example of the first server.

[0233] Table 1: Inputs used for key derivation

[0234] like Figure 10 As shown, XaaS service is used as an example of the first server, and Data-TW-GW is used as an example of the first network function.

[0235] In S501, the device sends message 1 to MM.

[0236] Message 1 is used to request services supported by XaaS services. Message 1 may include the device ID, the security requirements of the service, and the device's security capabilities.

[0237] In S502, the MM determines whether a service needs protection.

[0238] MM can determine whether a service needs protection based on its security requirements.

[0239] In S503, MM sends message 3 to KMF.

[0240] Message 3 is used to request security configuration. Message 3 may include the device ID, security requirements, the device's security capabilities, and the security capabilities of the Data-TW-GW.

[0241] In some embodiments, for KMF, the security requirements received from MM may include at least one of the following: security requirements from the device (e.g., security requirements of the service, security requirements of the device), and network security performance from MM.

[0242] Message 3 can be considered an example of the first message mentioned in method 300.

[0243] In some embodiments, message 3 also includes the security capabilities of the XaaS service, the ID of the XaaS PSF, and the ID of the data-TW-GW. In this scenario, message 3 can also be considered an example of the third message mentioned in method 300.

[0244] In S504, KMF sends message 4 to the XaaS service.

[0245] Message 4 is used to request security capabilities for the XaaS service. Message 4 may include an indication of a request for security process capabilities of the XaaS service.

[0246] Message 4 can be considered an example of the second message mentioned in method 300.

[0247] In S505, the XaaS service sends message 5 to KMF.

[0248] Message 5 includes the security capabilities of the XaaS service. Message 5 can be a response to message 4.

[0249] Message 5 can be considered an example of the third message mentioned in method 300.

[0250] In S506, KMF determines the security protection levels and schemes for data sessions.

[0251] For example, the security protection level and scheme for data sessions can be determined based on at least one of the following: security requirements from the MM, local policies from the network operator, the security process capabilities of the equipment, the security process capabilities of the data-TW-GW, or the security process capabilities of the XaaS service.

[0252] In S507, KMF collects the inputs used for key derivation.

[0253] In one embodiment, the KMF can send a request to the MM to collect information from the MM or from the Data-TW-GW. Accordingly, the MM can send a response based on the request. For example, the response may include a service ID / application ID, or a session ID / task ID.

[0254] In another embodiment, the KMF can send a request to the XaaS service to collect information from the service. Accordingly, the XaaS service can send a response based on the request. For example, the response may include the ID of the XaaS PSF.

[0255] The collected information can be used as input to generate a key that is used to protect data sessions.

[0256] In S508, KMF generates security contexts.

[0257] KMF can generate keys to protect data sessions based on the selected level and scheme of security protection. KMF can generate at least one of the following: the security context of the device, the security context of the data-TW-GW, or the security context of the XaaS service.

[0258] In one embodiment, the KMF is responsible for key configuration.

[0259] In another embodiment, the MM is responsible for key configuration.

[0260] In S509, KMF sends message 9 to data-TW-GW.

[0261] Message 9 may include the security context of the data-TW-GW and the ID of the key used in the data-TW-GW to protect the data session. Message 9 can be used to configure these keys.

[0262] Message 9 can be considered an example of the fourth message mentioned in method 300.

[0263] In S510, Data-TW-GW sends message 10 to KMF.

[0264] The Data-TW-GW can maintain or preserve its security context. Message 10 can indicate the successful configuration of the key used at the Data-TW-GW.

[0265] In S511, KMF sends message 11 to the XaaS service.

[0266] Message 11 may include the security context of the XaaS service and the ID of the key used by the XaaS service to protect the data session.

[0267] Message 11 can be considered an example of the fourth message mentioned in method 300.

[0268] In S512, the XaaS service sends message 12 to KMF.

[0269] The XaaS service can maintain or preserve its security context. Message 12 can indicate the successful configuration of the key used by the XaaS service.

[0270] In some embodiments, KMF can configure keys to XaaS service and data-TW-GW according to S509 to S512.

[0271] In S513, KMF sends message 13 to MM.

[0272] Message 13 may include the device's security context and the ID of a key used at the device to protect the data session. MM may also send a message to the device including the device's security context. Furthermore, a key used at the device can be generated based on the message.

[0273] Message 13 can be seen as an example of the fourth message mentioned in method 300.

[0274] In some embodiments, message 13 also includes the security context of the data-TW-GW and the security context of the XaaS service.

[0275] In S514, MM sends message 14 to the XaaS service.

[0276] Message 14 may include the security context of the XaaS service and the ID of the key used by the XaaS service to protect the data session.

[0277] Message 14 can be considered as an example of the eighth message mentioned in method 300.

[0278] In S515, the XaaS service sends message 15 to the MM.

[0279] The XaaS service can maintain or preserve its security context. Message 12 can indicate the successful configuration of the key used by the XaaS service.

[0280] MM can configure keys for XaaS services based on S514 and S515.

[0281] In S516, MM sends message 16 to data-TW-GW.

[0282] Message 16 may include the security context of the data-TW-GW and the ID of the key used in the data-TW-GW to protect the data session.

[0283] Message 16 can be considered an example of the ninth message mentioned in method 300.

[0284] In S517, Data-TW-GW sends message 17 to MM.

[0285] The Data-TW-GW can maintain or preserve its security context. Message 17 can indicate the successful configuration of the key used at the Data-TW-GW.

[0286] MM can configure keys to the data-TW-GW based on S516 and S517.

[0287] In S518, the Data-TW-GW maintains the security context of the Data-TW-GW.

[0288] In S519, the XaaS service maintains the security context of the XaaS service.

[0289] In S520, MM sends message 20 to the device.

[0290] Message 20 includes the device's security context and the ID of the key used on the device.

[0291] Message 20 can be considered an example of the tenth message mentioned in method 300.

[0292] In S521, the device generates keys and maintains the device's security context.

[0293] In one embodiment, the call flow regarding the key generation process (e.g., as...) Figure 10 (As shown), details are as follows: (1) The device sends message 1 to MM.

[0294] (2) The MM determines whether the service requires protection based on the service requirements. (3) If the service needs protection, then MM sends message 3 to KMF.

[0295] Message 3 can be considered an example of the first message mentioned in method 300.

[0296] (4) If message 3 does not include the security process capabilities of the XaaS service, then KMF may request the security process capabilities of the XaaS service. KMF sends message 4 to the XaaS service.

[0297] Message 4 can be considered an example of the second message mentioned in method 300.

[0298] (5) The XaaS service sends message 5 to KMF.

[0299] Message 5 can be considered an example of the third message mentioned in method 300.

[0300] (6) KMF determines the security protection level / scheme for data sessions.

[0301] (7) The KMF can collect inputs for key derivation. For example, the KMF can send a request to the MM to obtain information from the MM and information from the Data-TW-GW. The MM sends a response based on the request. In some embodiments, the KMF can send a request to the XaaS service to obtain information from the XaaS service. The XaaS service sends a response based on the request. In some embodiments, information from the XaaS service can be sent to the KMF via the MM. In some embodiments, information from the MM, information from the XaaS service, and information from the Data-TW-GW can be included in message 3.

[0302] (8) KMF generates keys based on the selected security protection scheme / level for the data session. KMF generates the security context for the device, the security context for the data-TW-GW, and the security context for the XaaS service. KMF sets the IDs for these keys.

[0303] (9) KMF can configure these security contexts for the Data-TW-GW and XaaS services. KMF sends message 9 to the Data-TW-GW.

[0304] Message 9 can be considered an example of the fourth message mentioned in method 300.

[0305] (10) Data-TW-GW saves the security context of Data-TW-GW and sends message 10 to KMF.

[0306] (11) KMF sends message 11 to the XaaS service.

[0307] Message 11 can be considered an example of the fourth message mentioned in method 300.

[0308] (12) The XaaS service saves the security context of the XaaS service and sends message 12 to KMF.

[0309] (13) KMF sends message 13 to MM.

[0310] Message 13 can be seen as an example of the fourth message mentioned in method 300.

[0311] (14) The MM can configure these security contexts for the data-TW-GW and XaaS services. The MM sends message 14 to the XaaS service.

[0312] Message 14 can be considered as an example of the eighth message mentioned in method 300.

[0313] (15) The XaaS service saves the security context of the XaaS service and sends message 15 to the MM.

[0314] (16) MM sends message 16 to data-TW-GW.

[0315] Message 16 can be considered an example of the ninth message mentioned in method 300.

[0316] (17) Data-TW-GW saves the security context of Data-TW-GW and sends message 17 to KMF.

[0317] (18) Data-TW-GW maintains the security context of data-TW-GW.

[0318] (19) XaaS service maintains the security context of XaaS service.

[0319] (20) MM sends message 20 to the device.

[0320] Message 20 can be considered an example of the tenth message mentioned in method 300.

[0321] (21) The device generates a key and maintains the device's security context.

[0322] This embodiment provides the factors that influence how to determine the security protection scheme / level for data sessions. In 3GPP 33.501, there is only one key generation scheme, with no scheme / level selection. However, this application can provide a variety of customized security protections for data sessions.

[0323] In 3GPP 33.501, the inputs for key derivation include the device ID, the name of the serving network, the root key, and information related to accessing the gNB (e.g., PCI). However, this application adds information from the MM (e.g., session ID, service ID) to the inputs for the aforementioned key derivation. In other words, the key used for data encryption / data integrity can be per session, per service, or per device. This can improve the security protection of data sessions.

[0324] In practical applications, it may be necessary to update the key used to protect data sessions.

[0325] In some implementations, the key update process can be triggered by the MM when the task / session changes due to changes in the Data-TW-GW and XaaS PSF. In other implementations, the key update process can be triggered by the KMF when the time window expires or the root key changes.

[0326] For ease of explanation, the following will be combined with Figure 11 An example describing the call flow for the key update process.

[0327] Figure 11 A schematic flowchart illustrating a method for communication provided for some embodiments of this application. For example... Figure 11 As shown, XaaS service is used as an example of the first server, and Data-TW-GW is used as an example of the first network function.

[0328] In S601, MM sends message 1 to KMF.

[0329] Message 1 is used to request an update to the key used to protect data sessions (e.g., the key used to protect data sessions on interface II, the key used to protect data sessions on interface III, or the key used at the device and XaaS service). Message 1 may include the device ID, the XaaS PSF ID, and the data-TW-GW ID.

[0330] Message 1 can be considered an example of the fifth message mentioned in method 300.

[0331] In S602, KMF generates a new security context.

[0332] KMF can generate new keys based on the selected security protection scheme / level for the data session. KMF can set the IDs of these keys.

[0333] KMF can generate at least one of the following: the security context of the device, the security context of the data-TW-GW, and the security context of the XaaS service.

[0334] In S603, KMF sends message 3 to data-TW-GW.

[0335] Message 3 may include the security context of the data-TW-GW and the ID of the key used in the data-TW-GW to protect the data session. Message 3 can be used to configure these keys.

[0336] Message 3 can be seen as an example of the fourth message mentioned in method 300.

[0337] In S604, Data-TW-GW sends message 4 to KMF.

[0338] The Data-TW-GW can maintain or preserve its security context. Message 4 indicates successful configuration of the key used at the Data-TW-GW.

[0339] In S605, KMF sends message 5 to the XaaS service.

[0340] Message 5 may include the security context of the XaaS service and the ID of the key used by the XaaS service to protect the data session.

[0341] Message 5 can be seen as an example of the fourth message mentioned in method 300.

[0342] In S606, the XaaS service sends message 6 to KMF.

[0343] The XaaS service can maintain or preserve its security context. Message 6 can indicate the successful configuration of the key used by the XaaS service.

[0344] In S607, KMF sends message 7 to MM.

[0345] Message 7 may include the device's security context and the ID of the key used at the device to protect the data session.

[0346] Message 7 can be considered an example of the fourth message mentioned in method 300.

[0347] In some embodiments, the MM can also send messages to the device including the device's security context. Furthermore, a key for use on the device can be generated based on the message. In this scenario, the MM can be responsible for key configuration.

[0348] In S608, MM sends message 8 to the XaaS service.

[0349] Message 8 may include the security context of the XaaS service and the ID of the key used by the XaaS service to protect the data session.

[0350] Message 8 can be considered an example of the eighth message mentioned in method 300.

[0351] In S609, the XaaS service sends message 9 to the MM.

[0352] The XaaS service can maintain or preserve its security context. Message 9 can indicate the successful configuration of the key used by the XaaS service.

[0353] In S610, MM sends message 10 to data-TW-GW.

[0354] Message 10 may include the security context of the data-TW-GW and the ID of the key used in the data-TW-GW to protect the data session.

[0355] Message 10 can be considered an example of the ninth message mentioned in method 300.

[0356] In S611, the data-TW-GW sends message 11 to the MM.

[0357] The Data-TW-GW can maintain or preserve its security context. Message 11 can indicate the successful configuration of the key used at the Data-TW-GW.

[0358] In S612, the Data-TW-GW maintains the security context of the Data-TW-GW.

[0359] In S613, the XaaS service maintains the security context of the XaaS service.

[0360] In S614, MM sends message 14 to the device.

[0361] Message 14 includes the device's security context and the ID of the key used on the device.

[0362] Message 14 can be considered an example of the tenth message mentioned in method 300.

[0363] In S615, the device generates keys and maintains the device's security context.

[0364] In S616, the device sends message 16 to MM.

[0365] Message 16 can indicate the successful configuration of the key used at the device.

[0366] In one embodiment, for the call flow regarding the key update process (such as...) Figure 11 (As shown), details are as follows: (1) MM sends message 1 to KMF.

[0367] Message 1 can be considered an example of the fifth message mentioned in method 300.

[0368] (2) KMF generates keys based on the selected security protection scheme / level for the data session. KMF generates the security context of the device, the security context of the data-TW-GW, and the security context of the XaaS service. KMF sets IDs for these keys.

[0369] (3) KMF can configure these security contexts for the data-TW-GW and XaaS services. KMF sends message 3 to the data-TW-GW.

[0370] Message 3 can be seen as an example of the fourth message mentioned in method 300.

[0371] (4) Data-TW-GW saves the security context of Data-TW-GW and sends message 4 to KMF.

[0372] (5) KMF sends message 5 to the XaaS service.

[0373] Message 5 can be seen as an example of the fourth message mentioned in method 300.

[0374] (6) The XaaS service saves the security context of the XaaS service and sends message 5 to KMF.

[0375] (7) KMF sends message 7 to MM.

[0376] Message 7 can be considered an example of the fourth message mentioned in method 300.

[0377] (8) The MM can configure these security contexts for the data-TW-GW and XaaS services. The MM sends message 8 to the XaaS service.

[0378] Message 8 can be considered an example of the eighth message mentioned in method 300.

[0379] (9) The XaaS service saves the security context of the XaaS service and sends message 9 to MM.

[0380] (10) MM sends message 10 to data-TW-GW.

[0381] Message 10 can be considered an example of the ninth message mentioned in method 300.

[0382] (11) Data-TW-GW saves the security context of Data-TW-GW and sends message 11 to KMF.

[0383] (12) Data-TW-GW maintains the security context of Data-TW-GW.

[0384] (13) The XaaS service maintains the security context of the XaaS service.

[0385] (14) MM sends message 14 to the device.

[0386] Message 14 can be considered an example of the tenth message mentioned in method 300.

[0387] (15) The device generates a key and maintains the device's security context.

[0388] (16) The device sends message 16 to MM.

[0389] In practice, it may be necessary to release the key used to protect the data session. For example, when the MM releases the session, the MM can trigger a key release process.

[0390] For ease of explanation, the following will be combined with Figure 12 An example describing the call flow for the key release process.

[0391] Figure 12 A schematic flowchart illustrating a method for communication provided for some embodiments of this application. For example... Figure 12 As shown, XaaS service is used as an example of the first server, and Data-TW-GW is used as an example of the first network function.

[0392] In S701, MM sends message 1 to KMF.

[0393] Message 1 is used to notify the release of a data session. Message 1 may include the device ID and the session or service ID.

[0394] Message 1 can be considered an example of the sixth message mentioned in method 300.

[0395] In S702, KMF determines whether the key used to protect the data session needs to be released.

[0396] For example, when security protection for data sessions is performed per service, per application, or per session, KMF can notify the relevant network functions to release the keys used to protect the data sessions.

[0397] In S703, KMF sends message 3 to data-TW-GW.

[0398] Message 3 may include the ID of at least one key that needs to be released from the key used to protect the data session at the data-TW-GW.

[0399] Message 3 can be considered an example of the seventh message mentioned in method 300.

[0400] In S704, Data-TW-GW sends message 4 to KMF.

[0401] Message 4 can indicate the successful release of at least one key that needs to be released.

[0402] In S705, KMF sends message 5 to the XaaS service.

[0403] Message 5 may include the ID of at least one key that needs to be released from the keys used to protect the data session at the XaaS service.

[0404] Message 5 can be seen as an example of the seventh message mentioned in method 300.

[0405] In S706, the XaaS service sends message 6 to KMF.

[0406] Message 6 can indicate the successful release of at least one key that needs to be released.

[0407] In S707, KMF sends message 7 to MM.

[0408] Message 7 is used to confirm the release of a data session. Message 7 may include the ID of at least one key that needs to be released from the keys used by the device service to protect the data session.

[0409] Message 7 can be considered an example of the seventh message mentioned in method 300.

[0410] In some embodiments, message 7 may further include: at least one key that needs to be released from the keys used at XaaS, and at least one key that needs to be released from the keys used at Data-TW-GW. In this scenario, the MM can be responsible for key release.

[0411] In S708, MM sends message 8 to the XaaS service.

[0412] Message 8 may include the ID of at least one key that needs to be released from the keys used to protect the data session at the XaaS service.

[0413] Message 8 can be considered an example of the eleventh message mentioned in method 300.

[0414] In S709, the XaaS service sends message 9 to the MM.

[0415] Message 9 can indicate the successful release of at least one key that needs to be released.

[0416] In S710, MM sends message 10 to data-TW-GW.

[0417] Message 10 may include the ID of at least one key that needs to be released from the key used to protect the data session at the data-TW-GW.

[0418] Message 10 can be considered an example of the twelfth message mentioned in method 300.

[0419] In S711, the data-TW-GW sends message 11 to the MM.

[0420] Message 11 can indicate the successful release of at least one key that needs to be released.

[0421] In S712, MM sends message 12 to the device.

[0422] Message 12 may include the ID of at least one key that needs to be released from the keys used at the device to protect the data session.

[0423] Message 12 can be considered an example of the thirteenth message mentioned in method 300.

[0424] In S713, the device sends message 13 to MM.

[0425] Message 11 can indicate the successful release of at least one key that needs to be released.

[0426] In one embodiment, the call flow for key deactivation (e.g.) Figure 12 (As shown), details are as follows: (1) MM sends message 1 to KMF.

[0427] Message 1 can be considered an example of the sixth message mentioned in method 300.

[0428] (2) KMF determines whether to release the keys based on message 1. If these keys are per task / session or per service / application, KMF should notify the release of these keys.

[0429] (3) KMF can release these keys. KMF sends message 3 to data-TW-GW.

[0430] Message 3 can be considered an example of the seventh message mentioned in method 300.

[0431] (4) Data-TW-GW sends message 4 to KMF.

[0432] (5) KMF sends message 5 to the XaaS service.

[0433] Message 5 can be seen as an example of the seventh message mentioned in method 300.

[0434] (6) The XaaS service sends message 5 to KMF.

[0435] (7) KMF sends message 7 to MM.

[0436] Message 7 can be considered an example of the seventh message mentioned in method 300.

[0437] (8) MM can release these keys. MM sends message 8 to the XaaS service.

[0438] Message 8 can be considered an example of the eleventh message mentioned in method 300.

[0439] (9) The XaaS service sends message 9 to MM.

[0440] (10) MM sends message 10 to data-TW-GW.

[0441] Message 10 can be considered an example of the twelfth message mentioned in method 300.

[0442] (11) Data-TW-GW sends message 1 to MM.

[0443] (12) MM sends message 12 to the device.

[0444] Message 12 can be considered an example of the thirteenth message mentioned in method 300.

[0445] (13) The device sends message 13 to MM.

[0446] This application provides security protection for data sessions, particularly in communication between the device and the service data-GW. When communication is protected, the communication content is encrypted and cannot be read by the RAN and other data-TW-GWs.

[0447] In addition, KMF has new features for determining the security protection level / method for data sessions and for collecting inputs for key generation.

[0448] We hope to declare the information exchange used to determine the security protection level / method and the information exchange used for key generation.

[0449] These technical solutions can bring some benefits.

[0450] (1) Regarding security protection In 3GPP 33.501, a key is used for multiple communication sessions. In this application, the key can be specific to each session and each service. This improves the security of communication.

[0451] (2) For customization Different security protection methods / levels are provided for data sessions. This brings greater flexibility to different security requirements from different devices and services.

[0452] 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.

[0453] Figure 13This is a schematic block diagram of a communication device 10 provided in some 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 KMF, a first network function, a second network function, or a first server, or a chip installed in any of these network functions.

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

[0455] The communication device 10 may further include a communication module 12. The communication module 12 is used to implement sending and / or receiving operations. The communication module 12 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.

[0456] For example, if communication device 10 corresponds to Figure 3 In the KMF, the communication module 12 can be used to receive the first message. The communication module 12 can also be used to send a second message to the second KMF.

[0457] For example, if communication device 10 corresponds to Figure 8 The second function of the communication module 12 is to receive the fourth message.

[0458] For example, if communication device 10 corresponds to Figure 8 If the first server is in the middle, then the communication module 12 can be used to receive the second message.

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

[0460] Figure 14 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.

[0461] 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 KMF, a first network function, a second network function, or a first server. In this implementation, the processor 21 can be a baseband device, and the communication interface 23 can be a radio frequency device.

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

[0463] 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: KMF, a first network function, a second network function, or a first server. The communication system may also include a device (e.g., a UE) or other network functions, without limitation.

[0464] 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.

[0465] 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.

[0466] 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.

[0467] 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.

[0468] 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.

[0469] 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.

[0470] 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.

[0471] 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.

[0472] 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.

[0473] 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.

[0474] 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 key management function (KMF), characterized in that, include: Determine the security protection scheme and the security protection level for the data session between the device and the first server; Based on the security protection scheme and the security protection level of the data session, multiple parameters are collected, wherein the multiple parameters are used to derive at least one key for protecting the data session.

2. The communication method according to claim 1, characterized in that, The data session between the device and the first server includes a first communication between the first network function and the device, and a second communication between the first network function and the first server.

3. The communication method according to claim 1 or 2, characterized in that, The security protection scheme for the data session includes a first scheme, and the at least one key corresponds to the first scheme and includes a first key and a second key, wherein the first key is used to protect the first communication and the second key is used to protect the second communication.

4. The communication method according to claim 2, characterized in that, The first network function includes a first gateway or user plane function.

5. The communication method according to claim 1 or 2, characterized in that, The security protection scheme for the data session includes a second scheme, the at least one key corresponding to the second scheme and including a third key, the third key being used at the device and the first server.

6. The communication method according to any one of claims 1 to 5, characterized in that, The data session is related to a service, application, or session, or a task or device is related to the data session; wherein, The security protection level for the data session includes a first level, and a key associated with the first level is used to protect the service or the application; or The security protection level for the data session includes a second level, and a key associated with the second level is used to protect the session; or The security protection level for the data session includes a third level, and a key associated with the third level is used to protect the task, which includes at least one session.

7. The communication method according to any one of claims 1 to 6, characterized in that, The security protection scheme for the data session is a first scheme, wherein the plurality of parameters used to derive at least one key include a first parameter for generating the first key and a second parameter for generating the second key; wherein, The first parameter includes: the device identifier (ID), the ID of the first network function, the ID of one or more algorithms used to generate the first key, a time window, and a shared key known to the device; The second parameter includes: the ID of the first network function, the ID of the first server, the time window, and the shared key known to the device; wherein, When the security protection level for the data session is Level 1, the first parameter and the second parameter further include a service ID or an application ID; or When the security protection level for the data session is level two, the first parameter and the second parameter further include the session ID; or When the security protection level for the data session is Level 3, the first parameter and the second parameter also include the task ID.

8. The communication method according to any one of claims 1 to 6, characterized in that, The security protection scheme for the data session is a second scheme, and the plurality of parameters used to derive at least one key include: The device ID, the first server ID, the time window, and the device's known shared key; wherein, When the security protection level for the data session is Level 1, the plurality of parameters further includes a service ID or an application ID; or When the security protection level for the data session is Level 2, the plurality of parameters also includes the session ID; or When the security protection level for the data session is Level 3, the plurality of parameters also include the task ID.

9. The communication method according to any one of claims 1 to 8, characterized in that, Also includes: Receive a first message, wherein the first message includes at least one of the following: the security process capability of a first network function or the security process capability of the device; The determination of the security protection scheme for the data session between the device and the first server and the security protection level for the data session include: Based on the first message, the security protection scheme and the security protection level for the data session are determined.

10. The communication method according to any one of claims 1 to 9, characterized in that, Also includes: Send a second message to the first server, wherein the second message is used to request the first server's security process capabilities; A third message is received from the first server, wherein the third message includes the security process capabilities of the first server.

11. The communication method according to any one of claims 1 to 10, characterized in that, Also includes: Send a fourth message, wherein the fourth message includes a first security context, the first security context including at least one of the following: the security context of the device, the security context of the first server, or the security context of the first network function.

12. The communication method according to any one of claims 1 to 11, characterized in that, Also includes: A fifth message is received from the second network function, wherein the fifth message is used to request a refresh of the key used to protect the data session.

13. The communication method according to any one of claims 1 to 12, characterized in that, Also includes: A sixth message is received from the second network function, wherein the sixth message indicates the release of the data session; Send a seventh message, wherein the seventh message includes the ID of at least one key that needs to be released, and the key used to protect the data session includes the at least one key.

14. A communication method performed by a second network function, characterized in that, include: Receive a fourth message, wherein the fourth message includes the first security context, the first security context being used to configure a key for protecting a data session between the device and the first server; The key used to protect the data session is generated based on the security protection scheme and the security protection level of the data session.

15. The communication method according to claim 14, characterized in that, Also includes: Send a first message, wherein the first message includes at least one of the following: the security processing capability of a first network function or the security processing capability of the device, and the security protection scheme and the security protection level of the data session are determined based on the first message.

16. The communication method according to claim 14 or 15, characterized in that, The first security context includes the security context of the first server, and the method further includes: Send an eighth message to the first server, wherein the eighth message includes the security context of the first server.

17. The communication method according to claim 14 or 15, characterized in that, The first security context includes the security context of the first network function, and the method further includes: A ninth message is sent to the first network function, wherein the ninth message includes the security context of the first network function.

18. The communication method according to any one of claims 14 to 17, characterized in that, The first security context includes the security context of the device, and the method further includes: Send a tenth message to the device, wherein the tenth message includes the security context of the device.

19. The communication method according to any one of claims 14 to 18, characterized in that, Also includes: A fifth message is sent to the KMF, wherein the fifth message is used to request a refresh of the key used to protect the data session.

20. The communication method according to any one of claims 14 to 19, characterized in that, Also includes: Send a sixth message to the KMF, wherein the sixth message indicates the release of the data session; A seventh message is received from the KMF, wherein the seventh message includes the ID of at least one key that needs to be released, and the key used to protect the data session includes the at least one key.

21. A communication method executed by a first server, characterized in that, include: Receive a second message from KMF, wherein the second message is used to request the security process capabilities of the first server; A third message is sent to the KMF, wherein the third message includes the security processing capability of the first server, and the security processing capability of the first server is used to determine the security protection scheme and the security protection level of the data session between the user equipment and the first server.

22. The communication method according to claim 21, characterized in that, Also includes: Receive a fourth message from the KMF, wherein the fourth message includes the security context of the first server; or An eighth message is received from the second network function, wherein the fifth message includes the security context of the first server.

23. The communication method according to claim 21 or 22, characterized in that, Also includes: Receive a seventh message from the KMF, wherein the seventh message includes the ID of at least one key that needs to be released from the key used to protect the data session; or An eleventh message is received from the second network function, wherein the eleventh message includes the ID of at least one key that needs to be released from the key used to protect the data session.

24. 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 13, or the method according to any one of claims 14 to 20, or the method according to any one of claims 21 to 23.

25. The communication device according to claim 24, characterized in that, The communication device also includes the memory.

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

27. A communication device, characterized in that, The communication device includes functions or units for implementing the method according to any one of claims 1 to 13, or the method according to any one of claims 14 to 20, or the method according to any one of claims 21 to 23.

28. 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 is used to implement the method according to any one of claims 1 to 13, or the method according to any one of claims 14 to 20, or the method according to any one of claims 21 to 23.

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

30. A communication system, characterized in that, Includes one or more of the following communication devices: A communication apparatus for performing the method according to any one of claims 1 to 13; A communication apparatus for performing the method according to any one of claims 14 to 20; A communication apparatus for performing the method according to any one of claims 21 to 23.

31. 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 implements the method according to any one of claims 1 to 13, or the method according to any one of claims 14 to 20, or the method according to any one of claims 21 to 23.

32. 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 implements the method according to any one of claims 1 to 13, or the method according to any one of claims 14 to 20, or the method according to any one of claims 21 to 23.