[go: up one dir, main page]

WO2025237131A1 - Procédé de communication et appareil de communication - Google Patents

Procédé de communication et appareil de communication

Info

Publication number
WO2025237131A1
WO2025237131A1 PCT/CN2025/093159 CN2025093159W WO2025237131A1 WO 2025237131 A1 WO2025237131 A1 WO 2025237131A1 CN 2025093159 W CN2025093159 W CN 2025093159W WO 2025237131 A1 WO2025237131 A1 WO 2025237131A1
Authority
WO
WIPO (PCT)
Prior art keywords
terminal
address
network element
user plane
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/CN2025/093159
Other languages
English (en)
Chinese (zh)
Inventor
郭燕飞
李�赫
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of WO2025237131A1 publication Critical patent/WO2025237131A1/fr
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/11—Allocation or use of connection identifiers

Definitions

  • This application relates to the field of wireless communication, and more specifically, to a communication method and a communication device.
  • the non-3GPP access path uses a non-3GPP interworking function (N3IWF) or a trusted non-3GPP gateway function (TNGF) to establish a connection with the core network.
  • N3IWF non-3GPP interworking function
  • TNGF trusted non-3GPP gateway function
  • the Simplified Access Traffic Steering, Switching, and Splitting (ATSSS-lite) scenario aims to build upon the ASSSS scenario by eliminating the use of N3IWF or TNGF for the non-3GPP access path. Instead, it directly connects to the user plane function (UPF) network elements via non-3GPP network access nodes such as Wireless Fidelity (WiFi) to establish a non-3GPP user plane. Therefore, in this ATSSS-lite scenario, how to protect the UPF from attacks is a question worth considering.
  • UPF user plane function
  • This application provides a communication method and a communication device that can reduce the occurrence of attacks on UPF.
  • a communication method is provided.
  • This method can be applied to the user plane network element side; that is, the method can be executed by the user plane network element or by its constituent components (such as chips, chip systems, circuits, or communication modules).
  • This application does not limit the scope of the method.
  • the following description mainly uses a user plane network element as an example.
  • the method may include: obtaining first information of the terminal during the process of establishing a session for the terminal on a 3GPP access network; sending the public IP address of the user plane network element to the terminal during the process; receiving data packets sent by the terminal through non-3GPP access and second information of the terminal, wherein the destination address of the data packets is the public IP address of the user plane network element; and verifying the data packets based on the first information and the second information of the terminal.
  • the terminal supports ATSSS-lite.
  • the user plane network element can obtain the terminal's first information and provide the terminal with the public IP address of the user plane network element.
  • the terminal accesses the user plane network element through a non-3GPP connection, it can send messages to the user plane network element based on the public IP address of that user plane network element, thereby enabling the terminal to establish a non-3GPP user plane connection with the user plane network element.
  • the terminal sends data packets to the user plane network element, it also carries its second information, allowing the user plane network element to verify the data packets based on both the first and second information. Verification reduces the risk of attacks after the public IP address of the user plane network element is leaked. For example, data packets are only processed after successful verification; otherwise, they are not processed.
  • the first information of the terminal includes at least one of the following: the identifier of the terminal, the identifier of the session, the IP address of the terminal on the non-3GPP access, the IP address of the terminal on the 3GPP access, and the public IP address of the user plane network element.
  • user plane network elements can verify data packets based on at least one of the above methods. For example, taking session identifiers as an example, user plane network elements can compare the session identifier in the first information with the session identifier in the second information. If the session identifier in the first information and the session identifier in the second information are consistent, the verification passes; if the session identifier in the first information and the session identifier in the second information are inconsistent, the verification fails.
  • the first information of the terminal includes the identifier of the terminal and/or the identifier of the session
  • obtaining the first information of the terminal includes: receiving the identifier of the terminal and/or the identifier of the session.
  • receiving the identifier of the terminal and/or the identifier of the session includes: receiving the identifier of the terminal and/or the identifier of the session from a session management network element.
  • the method further includes: during the process, sending to the terminal the IP address of the terminal on the non-3GPP access and/or the IP address of the terminal on the 3GPP access.
  • the terminal can access the user plane network element based on its IP address on non-3GPP access and/or its IP address on 3GPP access, and then transmit data with the user plane network element.
  • the terminal can also carry its IP address on non-3GPP access and/or its IP address on 3GPP access in the second information, so that the user plane network element can compare the IP address on non-3GPP access and/or its IP address on 3GPP access in the first information with the IP address on non-3GPP access and/or its IP address on 3GPP access in the second information to determine whether they match.
  • the method further includes: storing the first information of the terminal.
  • the user plane network element can store the terminal's first information. In this way, when verifying the terminal's data packets later, the verification can be performed directly based on the stored first information, reducing processing latency and improving user experience.
  • storing the first information of the terminal includes: storing the first information of the terminal based on indication information, wherein the indication information indicates that the session is a session under the simplified access traffic redirection, switching, and splitting ATSSS-lite scenario.
  • the instruction information can trigger the first information of the user plane network element storage terminal.
  • the first information is a token.
  • the method further includes: sending the token to the terminal during the process.
  • the user plane network element can send the token to the terminal. This allows the terminal to carry the token when sending data packets via non-3GPP access, enabling the user plane network element to verify whether the token was provided to the terminal. This reduces the risk of attacks after the public IP address of the user plane network element is leaked.
  • the token includes a digital signature, which is the digital signature of the user plane network element or the digital signature of a core network element other than the user plane network element; or, the token includes a message authentication code, which is a message authentication code generated by the user plane network element or the message authentication code generated by a core network element other than the user plane network element.
  • the token when the first information is a token, the token can also include a digital signature or a message authentication code to improve the security of the token.
  • the method further includes: receiving a token issued by the core network element and/or relevant information required to verify the token.
  • obtaining the first information of the terminal includes: generating or receiving the token for the terminal.
  • the token is a random number; or, the token is determined based on at least one of the following: the identifier of the terminal, the identifier of the session, the IP address of the terminal on the non-3GPP access, the IP address of the terminal on the 3GPP access, and the public IP address of the user plane network element.
  • the token when the first information is a token, the token may also include a digital signature or a message authentication code, and the digital signature or message authentication code can be determined according to at least one of the above, so that different tokens can be assigned based on different sessions or different terminals.
  • the first information is information that can be used to verify the message authentication code generated by the terminal.
  • the first information may be a key or authentication information used to verify the message authentication code generated by the terminal.
  • the message authentication code is determined based on a key and at least one of the following: the identifier of the terminal, the identifier of the session, the IP address of the terminal on the non-3GPP access, the IP address of the terminal on the 3GPP access, and the public IP address of the user plane network element.
  • the method further includes receiving the key.
  • the method further includes: sending request information, the request information being used to request the key.
  • the method further includes: sending request information based on indication information, wherein the indication information indicates that the session is a session under the ATSSS-lite scenario, and the request information is used to request the key.
  • the user plane network element sends a request message so that the terminal (or the message sent by the terminal) can be verified when the terminal sends a message through non-3GPP access.
  • the indication message can trigger the user plane network element to send the request message.
  • sending the public IP address of the user plane network element includes: sending the public IP address of the user plane network element based on indication information, wherein the indication information indicates that the session is a session under the ATSSS-lite scenario.
  • the instruction information can trigger the user plane network element to send the public IP address of the user plane network element.
  • the method further includes: receiving the instruction information during the process.
  • the user plane network element can receive the indication information, and then know that the session is a session under the ATSSS-lite scenario based on the indication information, and then obtain the first information of the terminal, and/or provide the terminal with the public IP address of the user plane network element.
  • verifying the data packet based on the first information and the second information of the terminal includes: verifying the data packet based on the first information and the second information of the terminal within the valid time period corresponding to the first information of the terminal.
  • a communication method is provided. This method can be applied to the terminal side; that is, it can be executed by the terminal itself or by components of the terminal (such as a chip, chip system, circuit, or communication module). This application does not limit the scope of the method.
  • the following description mainly uses a terminal as an example.
  • the method may include: during the process of establishing a session for a terminal on a 3GPP access network, receiving the public IP address of a user plane network element; and sending a data packet and second information of the terminal through a non-3GPP access network, wherein the destination address of the data packet is the public IP address of the user plane network element, and the second information of the terminal is used to verify the data packet.
  • the second information of the terminal includes at least one of the following: the identifier of the terminal, the identifier of the session, the IP address of the terminal on the non-3GPP access, the IP address of the terminal on the 3GPP access, and the public IP address of the user plane network element.
  • the second information of the terminal is a token
  • the method further includes: receiving the token during the process.
  • the token includes a digital signature, which is the digital signature of the user plane network element or the digital signature of a core network element other than the user plane network element; or, the token includes a message authentication code, which is a message authentication code generated by the user plane network element or the message authentication code generated by a core network element other than the user plane network element.
  • the token is a random number; or, the token is determined based on at least one of the following: the identifier of the terminal, the identifier of the session, the IP address of the terminal on the non-3GPP access, the IP address of the terminal on the 3GPP access, and the public IP address of the user plane network element.
  • the second information of the terminal is a message authentication code generated by the terminal, and the method further includes: determining the message authentication code based on a key and at least one of the following: the identifier of the terminal, the identifier of the session, the IP address of the terminal on the non-3GPP access, the IP address of the terminal on the 3GPP access, and the public IP address of the user plane network element.
  • determining the message authentication code includes: determining the message authentication code based on the public IP address of the user plane network element; or, determining the message authentication code based on indication information, wherein the indication information indicates that the session is a session under the simplified access traffic redirection, switching, and splitting ATSSS-lite scenario.
  • the method further includes: during the process, receiving the IP address of the terminal on the non-3GPP access and/or the IP address of the terminal on the 3GPP access.
  • the method before receiving the public IP address of the user plane network element, the method further includes: sending indication information, the indication information indicating that the session is a session under the ATSSS-lite scenario.
  • a communication method is provided. This method can be applied to the session management network element side; that is, the method can be executed by the session management network element or by its components (such as chips, chip systems, circuits, or communication modules). This application does not limit this.
  • the following description mainly uses the session management network element as an example.
  • the method may include: during the process of establishing a session for a terminal on a 3GPP access network, receiving a session establishment message from the terminal; and based on the session establishment message, sending at least one of the following to the user plane network element: indication information, the identifier of the terminal, and the identifier of the session, wherein the indication information indicates that the session is a session under the simplified access traffic redirection, switching, and splitting ATSSS-lite scenario.
  • the identifier of the terminal is any one of the following: a general public user identifier, a network access identifier, a user-hidden identifier, or a globally unique temporary identifier.
  • sending at least one of the following to the user plane network element: indication information, the identifier of the terminal, and the identifier of the session includes: sending at least one of the following to the user plane network element based on the indication information: indication information, the identifier of the terminal, and the identifier of the session.
  • the method further includes: sending a key, the key being used to sign first information of the terminal, the first information of the terminal being used to verify data packets of the terminal.
  • the method before sending the key, the method further includes either: determining or receiving the key.
  • the method before sending the key, the method further includes: sending or receiving request information, the request information being used to request the key.
  • a communication method is provided. This method can be applied to the network element side; that is, the method can be executed by the network element or by its constituent components (such as chips, chip systems, circuits, or communication modules). This application does not limit the scope of the method.
  • the method may include: receiving a data packet sent by a terminal on a non-3GPP access network, wherein the destination address of the data packet is the IP address of a user plane network element; verifying the access point on the non-3GPP access network; and, if the access point on the non-3GPP access network is verified, sending the data packet to the user plane network element based on the IP address of the user plane network element.
  • the IP address of the user plane network element includes at least one of the following: the internal network IP address of the user plane network element, the public network IP address of the user plane network element, and the fully qualified domain name of the user plane network element.
  • a communication method is provided. This method can be applied to the access node side; that is, the method can be executed by the access node or by its components (such as chips, chip systems, circuits, or communication modules). This application does not limit the scope of the method.
  • the method may include: determining the address information of an intermediate gateway; receiving data packets and the IP address of a user plane network element sent by a terminal through a non-3GPP access network; and, if the destination address of the data packet is the public IP address of the user plane network element, sending the data packet and the IP address of the user plane network element to the intermediate gateway based on the address information of the intermediate gateway.
  • the IP address of the user plane network element includes at least one of the following: the internal network IP address of the user plane network element, the public network IP address of the user plane network element, and the fully qualified domain name of the user plane network element.
  • a communication method is provided. This method can be applied to the system side.
  • the system includes user plane network elements or components of user plane network elements (e.g., chips, chip systems, circuits, or communication modules), and session management network elements or components of session management network elements (e.g., chips, chip systems, circuits, or communication modules).
  • the method may include: during the process of establishing a session for a terminal on a 3GPP (3rd Generation Partnership Project) access network, receiving a session establishment message from the terminal; based on the session establishment message, sending at least one of the following to a user plane network element: indication information, the identifier of the terminal, and the identifier of the session, wherein the indication information indicates that the session is a session under the simplified access traffic redirection, handover, and splitting ATSSS-lite scenario; obtaining first information of the terminal during the process of establishing a session for the terminal; sending the public IP address of the user plane network element to the terminal during the process; receiving a data packet sent by the terminal through non-3GPP access and second information of the terminal, wherein the destination address of the data packet is the public IP address of the user plane network element; and verifying the data packet based on the first information and the second information of the terminal.
  • 3GPP 3rd Generation Partnership Project
  • the user plane network element is used to execute the methods in the first aspect and any of its possible implementations.
  • the session management network element is used to execute the methods in the third aspect and any of its possible implementations.
  • the system may also include a terminal or a component of a terminal (e.g., a chip, a chip system, a circuit, or a communication module).
  • a terminal or a component of a terminal e.g., a chip, a chip system, a circuit, or a communication module.
  • the terminal may be used to execute the methods of the second aspect and any of its possible implementations.
  • a seventh aspect provides a communication apparatus for performing the methods of any one of the first to sixth aspects and any possible implementation thereof.
  • the apparatus may include units and/or modules for performing the methods of any one of the first to sixth aspects and any possible implementation thereof, such as processing units and/or communication units.
  • the device is a communication device (such as a terminal device, a user plane network element, or a session management network element).
  • the communication unit can be a transceiver or an input/output interface;
  • the processing unit can be at least one processor.
  • the transceiver can be a transceiver circuit.
  • the input/output interface can be an input/output circuit.
  • the device is a chip, chip system, circuit, or communication module for communication equipment (such as terminal equipment, user plane network element, or session management network element).
  • the communication unit can be an input/output interface, interface circuit, output circuit, input circuit, pin, or related circuit on the chip, chip system, or circuit;
  • the processing unit can be at least one processor, processing circuit, or logic circuit.
  • a communication device comprising: at least one processor configured to cause the device to perform any of the first to sixth aspects and any possible implementation thereof.
  • the at least one processor is configured to execute computer programs or instructions to perform the methods of any one of the first to sixth aspects and any possible implementation thereof.
  • the device further includes a memory for storing the computer program or instructions.
  • the at least one processor is coupled to a memory for storing the computer program or instructions.
  • the memory may be located externally to the device.
  • the device also includes a communication interface through which the processor reads instructions from memory.
  • a communication interface through which the processor reads instructions from memory.
  • the communication interface being coupled to the processor and used to input computer programs or instructions to the processor, or to output information from the processor.
  • the device is a communication device (such as a terminal device, a user plane network element, or a session management network element).
  • a communication device such as a terminal device, a user plane network element, or a session management network element.
  • the device is a chip, chip system, circuit, or communication module for communication equipment (such as terminal equipment, user plane network elements, or session management network elements).
  • the chip is a modem chip, also known as a baseband chip, or a system-on-chip (SoC) chip containing a modem core, or a system-in-package (SIP) chip.
  • SoC system-on-chip
  • SIP system-in-package
  • a ninth aspect provides a computer-readable storage medium storing a computer program (e.g., program code) or instructions that, when executed on a communication device, cause the communication device to perform the methods of any one of the first to sixth aspects and any possible implementation thereof.
  • a computer program e.g., program code
  • a computer program product containing instructions which, when run on a computer, causes the computer to perform the methods of any one of the first to sixth aspects and any possible implementation thereof.
  • a communication system including a user plane network element and a session management network element.
  • the user plane network element is used to execute the method provided in any implementation of the first aspect
  • the session management network element is used to execute the method provided in any implementation of the third aspect.
  • the communication system also includes a terminal for performing the method provided by any of the implementations in the second aspect.
  • Figure 1 is a schematic diagram of the ATSSS network architecture.
  • Figure 2 is a schematic diagram of a network architecture applicable to an embodiment of this application.
  • FIGS 3 and 4 are schematic diagrams of another network architecture applicable to embodiments of this application.
  • Figure 5 is a schematic diagram applicable to a 3GPP access and a NIN3A MA PDU session according to an embodiment of this application.
  • Figure 6 is a schematic diagram of a communication method 600 provided in an embodiment of this application.
  • FIG. 7 is a schematic diagram of the steering function applicable to embodiments of this application.
  • Figure 8 is a schematic diagram of a communication method 800 provided in an embodiment of this application.
  • Figure 9 is a schematic diagram of a communication method 900 provided in an embodiment of this application.
  • Figure 10 is a schematic diagram of a communication method 1000 provided in an embodiment of this application.
  • Figure 11 is a schematic diagram of a communication method 1100 provided in an embodiment of this application.
  • Figure 12 is a schematic diagram of a communication method 1200 provided in an embodiment of this application.
  • Figure 13 is a schematic diagram of a communication device 1300 provided in an embodiment of this application.
  • Figure 14 is a schematic diagram of another communication device 1400 provided in an embodiment of this application.
  • Figure 15 is a schematic diagram of a chip system 1500 provided in an embodiment of this application.
  • instruction can include direct instruction, indirect instruction, explicit instruction, implicit instruction, etc.
  • instruction information carries A, carries the identifier of A, carries B which is associated with A, carries the identifier of B which is associated with A, etc.
  • the receiving side of an instruction information can determine A based on the instruction information, it can be described as the instruction information indicating A, and the specific method of determination is not limited.
  • instruction information can be replaced with "includes”. In this case, a statement such as "send/receive instruction information, the instruction information indicates A" can be replaced with "send/receive A”.
  • the information indicated by the instruction information is called the information to be instructed.
  • the information to be instructed there are many ways to indicate the information to be instructed, such as, but not limited to, directly indicating the information to be instructed, such as the information to be instructed itself or its index. It can also indirectly indicate the information to be instructed by indicating other information, where there is a relationship between the other information and the information to be instructed. It can also indicate only a part of the information to be instructed, while the other parts are known or pre-agreed upon.
  • the instruction of specific information can be achieved by using a pre-agreed (e.g., protocol-defined) arrangement of various pieces of information, thereby reducing instruction overhead to some extent.
  • the information to be instructed can be sent as a whole or divided into multiple sub-information pieces, and the sending period and/or timing of these sub-information pieces can be the same or different.
  • the expression “/” is used to indicate that the objects before and after are in an "or” relationship; for example, A/B can mean: A or B.
  • the expression “and/or” is used to indicate that the objects before and after are in a relationship of either "and” or "or”; for example, A and/or B can mean the following: A exists alone, B exists alone, A and B exist simultaneously, where A and B can be single or multiple.
  • At least one of the following or similar expressions are used to indicate any combination of the listed items; for example, at least one of A, B and/or C can mean the following: A exists alone, B exists alone, C exists alone, A and B exist simultaneously, B and C exist simultaneously, A and C exist simultaneously, A, B and C exist simultaneously, where A, B, and C can be single or multiple.
  • send and “receive” indicate the direction of signal transmission.
  • send information to XX can be understood as the destination of the information being XX, which may include direct transmission via the air interface or indirect transmission by other units or modules via the air interface.
  • Receiveive information from YY can be understood as the source of the information being YY, which may include direct reception from YY via the air interface or indirect reception from YY by other units or modules via the air interface.
  • Send can also be understood as the "output” of the chip interface, and “receive” can also be understood as the "input” of the chip interface. In other words, sending and receiving can occur between devices, such as between network devices and terminal devices, or within a device, such as between components, modules, chips, software modules, or hardware modules within the device via a bus, wiring, or interface.
  • predefined may mean a standard protocol predefined, or it may mean a pre-agreed or pre-negotiated agreement between devices.
  • protocol may refer to standard protocols in the field of communications, such as fourth -generation (4G) network protocols, fifth -generation (5G) network protocols, new radio (NR) protocols, 5.5G network protocols, sixth -generation (6G) network protocols, and related protocols applied to future communication systems. This application does not limit this.
  • the technical solutions provided in this application can be applied to various communication systems, such as 5th generation (5G) or new radio (NR) systems, long-term evolution (LTE) systems, LTE frequency division duplex (FDD) systems, and LTE time division duplex (TDD) systems.
  • the technical solutions provided in this application can also be applied to future communication systems, such as 6th generation (6G) mobile communication systems.
  • 6G 6th generation
  • the technical solutions provided in this application can also be applied to device-to-device (D2D) communication, vehicle-to-everything (V2X) communication, machine-to-machine (M2M) communication, machine-type communication (MTC), and Internet of Things (IoT) communication systems.
  • D2D device-to-device
  • V2X vehicle-to-everything
  • M2M machine-to-machine
  • MTC machine-type communication
  • IoT Internet of Things
  • the technical solutions provided in this application can also be applied to non-terrestrial network (NTN) systems such as
  • a satellite communication system includes a satellite base station and terminal equipment.
  • the satellite base station provides communication services to the terminal equipment.
  • Satellite base stations can also communicate with each other.
  • a satellite can act as a base station or as a terminal device.
  • “satellite” can refer to drones, hot air balloons, low-Earth orbit satellites, medium-Earth orbit satellites, high-Earth orbit satellites, etc.
  • “Satellite” can also refer to non-terrestrial base stations or non-terrestrial equipment.
  • V2X communication can include: vehicle-to-vehicle (V2V) communication, vehicle-to-infrastructure (V2I) communication, vehicle-to-pedestrian (V2P) communication, and vehicle-to-network (V2N) communication.
  • V2V vehicle-to-vehicle
  • V2I vehicle-to-infrastructure
  • V2P vehicle-to-pedestrian
  • V2N vehicle-to-network
  • a PLMN is a network established and operated by the government or its approved operators for the purpose of providing terrestrial mobile communication services to the public. It is primarily a public network where mobile network operators (MNOs) provide mobile broadband access services to users.
  • MNOs mobile network operators
  • the PLMN described in this application embodiment can specifically be a network that conforms to the 3rd Generation Partnership Project (3GPP) standard requirements, or simply a 3GPP network.
  • 3GPP networks typically include, but are not limited to, 5G networks, 4th-generation (4G) networks, and other future communication systems such as 6G networks.
  • a device can send signals to or receive signals from another device. These signals can include information, signaling, or data.
  • the device can also be replaced by an entity, network entity, communication equipment, communication module, node, communication node, etc. This application uses a device as an example for description.
  • Protocol Data Unit (PDU) Session An association between the UE and the DN, used to provide a PDU connection service, or in other words, to provide the UE with a user plane connection to the DN.
  • the network (such as a 5G network) provides data exchange services between the UE and the DN, which may be referred to as the PDU connection service.
  • the UE obtains the PDU connection service by initiating a PDU session establishment request to the network.
  • the network side provides the PDU connection service by maintaining the PDU session for the UE.
  • a PDU session can be identified by a PDU session identifier (PDU session ID). Since the PDU session is at the UE level, each PDU session identifier can also correspond to a terminal device.
  • PDU session ID PDU session identifier
  • Access technology refers to the access technology used by the terminal device to connect to the communication device, or the access technology used by the terminal device to establish a communication connection with the communication device.
  • access technologies may include NR, Evolved Universal Mobile Telecommunication System (UMTS) Terrestrial Radio Access Network (E-UTRAN), Multefire, 3GPP access technologies, non-3GPP access technologies, 4G cellular access technologies, 5G cellular access technologies, 6G cellular access technologies, trusted or untrusted WiFi access technologies, fixed or wired access technologies, etc. No limitation is imposed on this.
  • the access network that uses non-3GPP access technology may include, but is not limited to: WiFi network, WLAN, MulteFire network, wired network (e.g., wireless and wireline convergence (WWC) network), or home base station network.
  • WiFi network Wireless Fidelity
  • WLAN Wireless Fidelity
  • MulteFire network Wireless Fidelity network
  • wired network e.g., wireless and wireline convergence (WWC) network
  • WWC wireless and wireline convergence
  • the access network that adopts 3GPP access technology may include, but is not limited to: LTE network, NR network, 5G network, or subsequent evolved mobile communication networks (such as 6G network).
  • the network architecture is described below.
  • FIG. 1 is a schematic diagram of the access traffic steering, switching, splitting (ATSSS) architecture.
  • ATSSS also known as Access Traffic Direction, Transformation, and Splitting
  • 5G networks can be supported by UEs and 5GC networks.
  • the ATSSS feature enables multi-access PDU connectivity services, which can simultaneously utilize one 3GPP access network and one non-3GPP access network, and two independent N3/N9 tunnels between the PDU session anchor (PSA) and the RAN/AN to exchange PDUs between the UE and the data network.
  • Multi-access PDU connectivity services can be achieved by establishing multi-access PDU (MA PDU) sessions, i.e., PDU sessions with user plane resources on two access networks. This assumes that the single network slice selection assistance information (S-NSSAI) of the PDU session simultaneously allows both 3GPP and non-3GPP access.
  • MA PDU multi-access PDU
  • S-NSSAI single network slice selection assistance information
  • An MA PDU session is a PDU session that provides PDU connection services. It can use one access (such as a 3GPP access or a non-3GPP access) at a time, or it can use one 3GPP access and one non-3GPP access simultaneously.
  • the UE After an MA PDU session is established, when user plane resources are available on both access networks, the UE applies the network-provided policy (i.e., ATSSS rules) and considers local conditions (such as network interface availability, signal loss conditions, user preferences, etc.) to determine how to allocate uplink traffic on the two access networks.
  • the UPF anchor point of the MA PDU session applies the network-provided policy (i.e., N4 rules) and feedback information received from the UE via the user plane (such as access network unavailability or availability) to determine how to allocate downlink traffic on the two N3/N9 tunnels and the two access networks.
  • the UE applies the ATSSS rules and considers local conditions that would trigger the establishment or activation of user plane resources on the other access network.
  • MA PDU sessions can be of one of the following types: IPv4, IPv6, IPv4v6, and Ethernet. Unstructured types are not supported.
  • the UE supports one or more sterring functions, namely: Multi-path Transmission Control Protocol (TCP) (MPTCP), Multi-path Quick User Datagram Protocol (UDP) Internet Connection Protocol (QUIC) (MPQUIC), and ATSSS-LL.
  • TCP Multi-path Transmission Control Protocol
  • MPTCP Multi-path Transmission Control Protocol
  • UDP Multi-path Quick User Datagram Protocol
  • QUIC Internet Connection Protocol
  • ATSSS-LL ATSSS-LL.
  • Each sterring function in the UE according to the ATSSS rules provided by the network, allows for the sterring, handover, and offloading of service traffic across 3GPP access and non-3GPP access.
  • the UPF can support the MPTCP proxy function, which communicates with the MPTCP function in the UE using the MPTCP protocol.
  • the UPF can support the MPQUIC proxy function, which communicates with the MPQUIC function in the UE using the QUIC protocol and its multipath extensions.
  • the UPF can support the ATSSS-LL function, which is similar to the ATSSS-LL function defined for the UE. No user plane protocol needs to be defined between the ATSSS-LL function in the UE and the ATSSS-LL function in the UPF. Furthermore, the UPF supports a performance measurement function (PMF), which allows the UE to measure the performance of the corresponding access on the user plane of 3GPP access and/or on the user plane of non-3GPP access.
  • PMF performance measurement function
  • the network architecture is based on a 5G system (5GS).
  • this network architecture includes three parts: a terminal device part, a data network (DN) part, and an operator network PLMN part.
  • the operator network PLMN part may include, but is not limited to, a radio access network (RAN) and a core network (CN) part.
  • RAN radio access network
  • CN core network
  • Terminal equipment including user equipment (UE).
  • UE also known as a terminal or terminal device, it can be a device or module that accesses the aforementioned communication system and has corresponding communication functions.
  • UE can include various devices with wireless communication capabilities, which can be used to connect people, objects, machines, etc.
  • Terminal devices can be widely used in various scenarios, such as: cellular communication, D2D, V2X, peer-to-peer (P2P), M2M, MTC, IoT, virtual reality (VR), augmented reality (AR), industrial control, autonomous driving, telemedicine, smart grid, smart furniture, smart office, smart wearables, smart transportation, smart city drones, robots, remote sensing, passive sensing, positioning, navigation and tracking, autonomous delivery, etc.
  • Terminal devices can be terminals in any of the above scenarios, such as MTC terminals, IoT terminals, etc.
  • Terminal devices can be UEs, terminals, fixed devices, mobile stations or mobile devices, subscriber units, handheld devices, vehicle-mounted devices, wearable devices, cellular phones, smartphones, session initiation protocol (SIP) phones, wireless data cards, personal digital assistants (PDAs), computers, and tablets, all conforming to the 3rd Generation Partnership Project (3GPP) standard.
  • 3GPP 3rd Generation Partnership Project
  • GPS global positioning system
  • a UE can also be used as a base station.
  • a UE can act as a scheduling entity, providing sidelink signaling between UEs in scenarios such as V2X, D2D, or P2P.
  • the device for implementing the functions of a terminal device can be the terminal device itself, or it can be any device capable of supporting the terminal device in implementing the functions, such as a chip system, chip, circuit, or communication module (i.e., a communication module that performs communication functions).
  • This device can be installed in the terminal device.
  • the chip system can be composed of chips, or it can include chips and other discrete devices.
  • the device can also be configured with program instructions for performing corresponding communication functions.
  • the data network portion can include a Data Network (DN), which provides the network for transmitting data.
  • DN Data Network
  • Examples include carrier service networks (such as IP Multimedia Subsystem (IMS)), the Internet, and third-party service networks.
  • IMS IP Multimedia Subsystem
  • a DN can also be called a Packet Data Network (PDN), and is typically a network located outside the carrier network, such as a third-party network.
  • PDN Packet Data Network
  • the (R)AN portion may include one or more access network elements or access network devices.
  • the access network provides network access functionality to authorized users in a specific area and includes radio access network (RAN) devices and AN devices.
  • RAN devices are primarily radio network devices within the 3GPP network, while AN devices may be access network devices not defined by 3GPP.
  • Access networks can be those employing different access technologies.
  • 3GPP access technologies such as those used in 3G, 4G, or 5G systems
  • non-3GPP access technologies such as those used in 3G, 4G, or 5G systems
  • 3GPP access technology refers to access technology that conforms to 3GPP standards and specifications.
  • the access network equipment in a 5G system is called a next-generation NodeB (gNB) or RAN.
  • gNB next-generation NodeB
  • RAN next-generation NodeB
  • Non-3GPP access technologies refer to access technologies that do not conform to 3GPP standards and specifications. Examples include air interface technologies such as access points (APs) in Wireless Fidelity (WiFi), Worldwide Interoperability for Microwave Access (WiMAX), and Code Division Multiple Access (CDMA) networks. Access network equipment (AN equipment) allows terminal equipment and the 3GPP core network to interconnect using non-3GPP technologies.
  • air interface technologies such as access points (APs) in Wireless Fidelity (WiFi), Worldwide Interoperability for Microwave Access (WiMAX), and Code Division Multiple Access (CDMA) networks.
  • APs access points
  • WiFi Wireless Fidelity
  • WiMAX Worldwide Interoperability for Microwave Access
  • CDMA Code Division Multiple Access
  • AN equipment allows terminal equipment and the 3GPP core network to interconnect using non-3GPP technologies.
  • the access network device in this application embodiment can be a device or module with corresponding communication functions.
  • the access network device can be a device used to communicate with terminal devices; it can also be called a network device or a wireless access network device, such as a base station.
  • the access network device can refer to a RAN node (or device) that connects terminal devices to a wireless network.
  • a base station can broadly encompass, or be replaced by, various names including: NodeB, evolved NodeB (eNB), gNB, relay station, access point, transmitting and receiving point (TRP), transmitter point, master station, auxiliary station, motor slide retainer (MSR) node, home base station, network controller, access node, wireless node, access point (AP), transmission node, transceiver node, baseband unit (BBU), remote radio unit (RRU), active antenna unit (AAU), remote radio head (RRH), central unit (CU), distributed unit (DU), positioning node, etc.
  • a base station can be a macro base station, micro base station, relay node, donor node, or similar entities, or combinations thereof.
  • a base station can also refer to a communication module, modem, or chip installed within the aforementioned equipment or apparatus.
  • a base station can also be a mobile switching center, a device that performs base station functions in D2D, V2X, and M2M communications, a network-side device in a 6G network, or a device that performs base station functions in future communication systems.
  • a base station can support networks using the same or different access technologies. The embodiments of this application do not limit the specific technologies or device forms used in the network equipment.
  • Base stations can be fixed or mobile.
  • a helicopter or drone can be configured to act as a mobile base station, and one or more cells can move depending on the location of the mobile base station.
  • a helicopter or drone can be configured as a device to communicate with another base station.
  • the access network equipment mentioned in the embodiments of this application may be an equipment including CU, or DU, or an equipment including CU and DU, or a control plane CU node (central unit-control plane (CU-CP)) and a user plane CU node (central unit-user plane (CU-UP)) and a DU node.
  • CU-CP central unit-control plane
  • CU-UP central unit-user plane
  • RAN nodes collaborate to assist terminal devices in achieving wireless access, with different RAN nodes implementing some of the base station's functions.
  • RAN nodes can be CUs, DUs, CU-CPs, CU-UPs, or radio units (RUs).
  • CUs and DUs can be configured separately or included in the same network element, such as a BBU.
  • RUs can be included in radio equipment or radio units, such as RRUs, AAUs, or RRHs.
  • a radio access network can also be an open radio access network (O-RAN) architecture.
  • CU can also be called an open CU (open CU, O-CU)
  • DU can also be called an open DU (open DU, O-DU)
  • CU-CP can also be called an open CU-CP (open CU-CP, O-CU-CP)
  • CU-UP can also be called an open CU-UP (open CU-UP, O-CU-UP)
  • RU can also be called an open RU (open RU, O-RU).
  • Any of the units among CU (or CU-CP, CU-UP), DU, and RU in this application can be implemented through software modules, hardware modules, or a combination of software modules and hardware modules.
  • the device for implementing the functions of the access network device can be the access network device itself, or it can be any device capable of supporting the access network device in implementing these functions, such as a chip system, chip, circuit, or communication module (i.e., a communication module that performs communication functions).
  • This device can be installed within the access network device.
  • the chip system can be composed of chips, or it can include chips and other discrete devices.
  • the device can be configured with program instructions for performing corresponding communication functions. This embodiment only uses the access network device as an example to illustrate the device for implementing the functions of the access network device, and does not limit the solution of this embodiment.
  • Access network equipment and terminal equipment can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; they can also be deployed on water; and they can also be deployed in the air on airplanes, balloons, and satellites. This application embodiment does not limit the scenario in which the access network equipment and terminal equipment are located.
  • the CN component may include, but is not limited to, the following network functions (NFs): network slice selection function (NSSF), network slice specific authentication and authorization function (NSSAAF), authentication server function (AUSF), unified data management (UDM), network exposure function (NEF), network repository function (NRF), policy control function (PCF), application function (AF), access and mobility management function (AMF), session management function (SMF), user plane function (UPF), and signaling control point (SCP).
  • NFs network slice selection function
  • NSSAAF network slice specific authentication and authorization function
  • AUSF authentication server function
  • UDM unified data management
  • NEF network exposure function
  • NRF network repository function
  • PCF policy control function
  • AF application function
  • AMF access and mobility management function
  • SMF user plane function
  • SCP signaling control point
  • UPF network element Used for packet routing and forwarding, as well as Quality of Service (QoS) processing of user plane data.
  • User data can access the DN through this network element.
  • QoS Quality of Service
  • User data can access the DN through this network element.
  • it can be used to implement the functions of a user plane network element.
  • AMF network element mainly used for mobility management and access management, and can be used to implement other functions in the mobility management entity (MME) besides session management, such as access authorization/authentication.
  • MME mobility management entity
  • SMF network elements mainly used for session management, Internet Protocol (IP) address allocation and management for terminal devices, selection and management of user plane functions, policy control and billing function interface endpoints, and downlink data notification, etc.
  • IP Internet Protocol
  • PCF network element A unified policy framework used to guide network behavior, providing policy rule information to network elements (such as AMF, SMF, etc.) or terminal devices.
  • NRF network element Used to store network function entities and their description information, as well as support functions such as service discovery and network element entity discovery.
  • NEF network element used to enable third parties to use the services provided by the network, support the network to open its capabilities, events and data analysis, provide security configuration information to the PLMN from external applications, and convert information exchanged between the PLMN and external networks.
  • UDM network element used for unified data management, 5G user data management, processing user identification, access authentication, registration, or mobility management, etc.
  • UDR network element Used to provide UDM with the function of saving and retrieving subscription data, PCF with the function of saving and retrieving policy data, saving and retrieving user NF group ID information, etc.
  • AF element Used to provide corresponding services by interacting with other NFs in the PLMN, such as providing network selection information for roaming UE visits, routing data flows, and accessing NEFs.
  • AUSF network element used for Level 1 authentication, i.e. authentication between UE (subscribed user) and operator network.
  • Nnssf, Nnef, Nnrf, Npcf, Nudm, Nudr, Naf, Nausf, Namf, Nsmf, Neasdf, Nnssaaf, Nnsacf, N1, N2, N3, N4, and N6 are interface sequence numbers.
  • the meaning of the above interface sequence numbers can be found in the definitions in the 3GPP standard protocol; this application does not limit the meaning of the above interface sequence numbers.
  • the interface names between the various network functions in Figure 2 are merely examples. In specific implementations, the interface names of this system architecture may be other names, which this application does not limit.
  • the names of the messages (or signaling) transmitted between the above network elements are also merely examples and do not constitute any limitation on the function of the messages themselves.
  • the interface between (R)AN and CN can also be called the NG interface (not shown in the figure).
  • (R)AN and CN are connected through the NG interface.
  • the NG interface can include the NG-C interface and the NG-U interface.
  • the NG-C interface is the control plane interface, connecting (R)AN and AMF, and is used to transmit control plane data.
  • the NG-U interface is the user plane interface, connecting (R)AN and UPF, and is used to transmit user plane data.
  • the network elements shown in Figure 2 can be understood as network elements in the core network used to implement different functions, for example, they can be combined into network slices as needed. These core network elements can be independent devices or integrated into the same device to implement different functions. This application does not limit the specific form of the above network elements.
  • the above network elements or functions can be physical entities in hardware devices, software instances running on dedicated hardware, or virtualized functions instantiated on a shared platform (e.g., a cloud platform). Simply put, an NF can be implemented by hardware or by software.
  • ATSSS-lite ATSSS-lite
  • the architecture shown in Figure 3 is suitable for non-roaming scenarios, while the architecture shown in Figure 4 is suitable for roaming scenarios.
  • the ATSSS-lite scenario aims to eliminate the need for N3IWF or TNGF to establish a connection with the core network on the non-3GPP access path, instead directly establishing a non-3GPP user plane connection with user plane network elements (such as UPF) via WiFi or IP access.
  • ATSSS-lite can also be called by other names, such as ATSSS-lite, ATSSS-Ph4, gatewayless ATSSS, or lightweight ATSSS.
  • ATSSS ATSSS
  • This application does not limit the specific name, and its name does not limit the scope of protection of the embodiments of this application. For ease of description, the embodiments of this application are described using ATSSS-lite.
  • the ATSSS-lite architecture is similar to the ATSSS architecture.
  • the UE accesses the network through both 3GPP and non-3GPP access paths, switching, redirecting, and offloading traffic between the two paths. It still uses MA PDU sessions (Multi-Access PDU sessions) to carry service data on both paths and still uses ATSSS rules for traffic switching, redirection, and offloading.
  • MA PDU sessions Multi-Access PDU sessions
  • ATSSS-lite architecture proposes a gatewayless architecture, such as TNGF (for trusted non-3GPP access) or N3IWF (for untrusted non-3GPP access), connecting to the core network through non-3GPP access.
  • the UE connects to the UPF through the public IP network (internet) via an interface (e.g., denoted as Nx).
  • Nx an interface
  • the session name when the UE accesses the network through 3GPP and non-3GPP access paths can be called an MA PDU session, or other names; there is no limitation on this.
  • the PCF in the home public land mobile network is denoted as the home PCF (hPCF or H-PCF)
  • the SMF in the HPLMN is denoted as the home SMF (home SMF, hSMF or H-SMF)
  • the SMF in the visited public land mobile network is denoted as the visited SMF (visited SMF, vSMF or V-SMF)
  • the UPF in the HPLMN is denoted as the home UPF (home UPF, hUPF or H-UPF)
  • the UPF in the visited public land mobile network is denoted as the visited UPF (visited UPF, vUPF or V-UPF).
  • the visited UPF visitor UPF, vUPF or V-UPF
  • FIG. 5 is a schematic diagram of an MA PDU session applicable to an embodiment of this application, involving a 3GPP access and a non-integrated non-3GPP access (NIN3A).
  • the ATSSS-Lite architecture introduces the concept of non-integrated non-3GPP access (NIN3A), which represents a non-3GPP access that does not use boundary nodes (such as TNGF or N3IWF).
  • NIN3A can represent a type of non-3GPP access network that provides a direct IP connection between the UE and the UPF without requiring intermediate network functions (NFs) (such as N3IWF and TNGF).
  • NFs intermediate network functions
  • the UE connects to the UPF via the public IP network through interface Nx.
  • Traffic processing is similar to that in the ATSSS architecture, except that the non-3GPP access branch of the MA PDU session is replaced by a secure connection on NIN3A. It is assumed that the UPF, acting as the anchor point for the ATSSS-Lite connection, supports the Nx interface. The UPF can process traffic according to the traffic processing rules provided by the SMF.
  • the UE needs to pass through a border node to establish a connection with the core network via non-3GPP access.
  • the connection can be established through the TNGF; for untrusted non-3GPP access, the connection can be established through the N3IWF.
  • IPsec Internet Protocol Security
  • a hop-by-hop security mechanism from the UE to the border node and from the border node to the core network is used to establish a secure channel for the user plane or control plane of the entire system.
  • the non-3GPP network access node needs to establish a connection with the user plane functional network elements.
  • the N3IWF and TNGF are no longer used on non-3GPP access.
  • the public IP address of the UPF can be provided to the UE to facilitate the UE's establishment of the non-3GPP user plane.
  • this method may lead to the leakage of the UPF's public IP address, resulting in a large number of packets being sent to that UPF IP address, causing a denial-of-service (DoS) attack.
  • DoS denial-of-service
  • the UPF can filter by source or destination address based on the UE's IP address, thereby associating it with the corresponding session.
  • a data packet comes from a source address that the UPF does not recognize, the UPF can simply ignore the packet, thus mitigating the possibility of indiscriminate packet sending to the UPF IP address and causing a DoS attack to some extent.
  • the source address of a data packet can be forged and spoofed, if an attacker knows the UE's IP address and sends packets to the UPF IP address, the risk of a DoS attack still exists.
  • this application proposes that the UPF can be protected from attacks by enabling access control through the UPF or by network elements other than the UPF.
  • the relevant access control scheme for the UPF is introduced with reference to Figures 6 to 10.
  • This scheme is applicable to the following scenarios: ATSSS-lite scenario, where a UE uses both a 3GPP access network and a non-3GPP access network simultaneously; boundary nodes (such as TNGF or N3IWF) are no longer used on the non-3GPP access network; the user plane on the non-3GPP access network can be established through the control plane of the 3GPP access network.
  • the 3GPP connection sends the public IP address of the UPF to the UE so that the UE and the UPF can communicate on the Nx interface subsequently.
  • the UPF After receiving a message (such as data) from the UE, the UPF first verifies the message. If the verification passes, the message is processed; if the verification fails, the message is ignored or discarded.
  • a message such as data
  • Figure 6 is a schematic diagram of a communication method 600 provided in an embodiment of this application, the method 600 shown in Figure 6 may include the following steps.
  • the user plane network element obtains the terminal's first information (or the terminal's first information, or the first information corresponding to the terminal).
  • the terminal's first information represents information related to or used by the terminal (or the session).
  • the terminal's first information will be simply referred to as "first information.”
  • the first information will be explained in detail later in conjunction with schemes #1 and #2.
  • method 600 further includes: a user plane network element receiving indication information, which indicates an ATSSS-lite scenario.
  • the terminal sends the indication information to the user plane network element.
  • the session management network element sends the indication information to the user plane network element.
  • the terminal sends information #1 to the session management network element, and the session management network element sends the indication information to the user plane network element based on information #1.
  • information #1 may indicate that the terminal supports ATSSS-lite.
  • this instruction information Based on this instruction information, the user plane network element obtains the first information.
  • this instruction information can also be used to indirectly instruct (or trigger) the user plane network element to obtain the first information.
  • the indication information indicates that the terminal supports ATSSS-lite; for another example, the indication information indicates that the terminal's session is an ATSSS-lite session; for yet another example, the indication information indicates that the terminal does not use a border node (such as TNGF or N3IWF) to establish a connection with the core network (such as UPF) on non-3GPP access; for yet another example, the indication information indicates that the UE uses NIN3A for non-3GPP access.
  • a border node such as TNGF or N3IWF
  • the indication information indicates that the UE uses NIN3A for non-3GPP access.
  • the indication information can directly indicate that the terminal's session is an ATSSS-lite session, or it can indicate it indirectly.
  • One possible implementation is to use at least one bit to indicate whether the terminal's session is an ATSSS-lite session. For example, suppose one bit is used to indicate whether the terminal's session is an ATSSS-lite session. If this bit is set to "0", it indicates that the terminal's session is an ATSSS-lite session; if this bit is set to "1", it indicates that the terminal's session is not an ATSSS-lite session. It should be understood that the above is merely an illustrative example and is not intended to be limiting.
  • Another possible implementation is to use a specific field to indicate the information. For example, if the user plane network element receives this specific field, it indicates that the terminal's session is an ATSSS-lite session; if the user plane network element does not receive this field, it indicates that the terminal's session is not an ATSSS-lite session. It should be understood that the above is merely an illustrative example and is not intended to be limiting.
  • Another possible implementation is to indicate the information indirectly through other information. For example, if the session management network element sends a key to the user plane network element (the key can be referred to in the description of Scheme 2 below), or if the session management network element sends the terminal identifier and/or session identifier to the user plane network element, it indicates that the terminal's session is a session under the ATSSS-lite scenario.
  • This indication information can also be referred to as the ATSSS-lite indicator.
  • the ATSSS-lite indicator will be used as an example below.
  • the user plane network element sends the public IP address of the user plane network element to the terminal.
  • step 620 can be executed first, followed by step 610; or step 610 can be executed first, followed by step 620; or steps 620 and 610 can be executed simultaneously. There is no limitation on this.
  • a session is, for example, a PDU session or an MA PDU session.
  • a user plane network element might be a UPF (User Plane Function).
  • UPF User Plane Function
  • the user plane network element sends its public IP address to the terminal. This can be done either by the user plane network element sending its public IP address directly to the terminal, or by the user plane network element sending its public IP address to the terminal through other network elements (such as session management network elements, mobility management network elements, network access devices, etc.).
  • network elements such as session management network elements, mobility management network elements, network access devices, etc.
  • the public IP address of the user plane network element sent to the terminal can be either the complete information of the user plane network element's public IP address or a prefix thereof; there is no limitation in this regard.
  • the following description will use the public IP address of the user plane network element. It can be understood that the public IP address of the user plane network element can be replaced with the prefix of the user plane network element's public IP address.
  • the user plane network element sends its public IP address to the terminal.
  • this instruction information can also be used to indirectly instruct (or trigger) the user plane network element to send its public IP address to the terminal.
  • the terminal sends a data packet and its second information to the user plane network element on a non-3GPP access.
  • the user plane network element receives the data packet and the terminal's second information.
  • the second information of the terminal represents information related to the terminal or used for the terminal (or the session).
  • the second information of the terminal is simply referred to as the second information.
  • the second information can be carried in the data packet or outside the data packet; there is no limitation on this. The second information will be explained in detail later in conjunction with schemes #1 and #2.
  • the destination address of this data packet is the public IP address of the user plane network element.
  • the terminal sends the data packet to the user plane network element on a non-3GPP access route based on the public IP address of the user plane network element received in step 610.
  • the destination address of the data packet is an IP address constructed based on the public IP address prefix of the UPF.
  • the user plane network element verifies the data packet based on the first information and the second information. In other words, the user plane network element performs access control or access authorization on the data packet based on the first information and the second information, or, in other words, the user plane network element determines whether to process the data packet based on the first information and the second information.
  • the user plane network element verifies the data packet successfully. In this case, the user plane network element processes the data packet. Specifically, if, after verification, the user plane network element determines that the data packet is a normal or legitimate data packet, then the user plane network element processes the data packet. Processing the data packet can mean either sending the data packet based on its destination address, or responding according to the content of the data packet and a predetermined procedure.
  • the user plane network element fails to verify the data packet. In this case, the user plane network element does not process the data packet. Specifically, if the user plane network element determines that the data packet is an abnormal or invalid data packet after verification, then the user plane network element does not process the data packet. Not processing the data packet can mean either ignoring the data packet or discarding the data packet.
  • user plane network element authentication packets include at least the following two schemes:
  • Solution #1 The user plane network element verifies the data packet based on the terminal's characteristic information
  • the user plane network element verifies the data packet based on the terminal's authorization information.
  • Option #1 UPF verifies data packets based on the terminal's characteristic information.
  • the characteristic information of this terminal is referred to as the terminal's first characteristic information.
  • the terminal's first characteristic information is simply referred to as first characteristic information.
  • the first information can also be called first characteristic information.
  • the first characteristic information will be used as an example to introduce scheme #1 below.
  • the first feature information represents terminal-related information that can be used to verify information subsequently sent by the terminal on non-3GPP access. Specifically, the UPF verifies data packets sent by the terminal on non-3GPP access based on this first feature information.
  • the first feature information can also be called access control information or access control list; however, the name of the first feature information is not limited in this embodiment.
  • the UPF stores the first feature information. This allows the UPF to directly verify the data packet based on the stored first feature information after the terminal sends it to the UPF on a non-3GPP network.
  • other network elements may store the first feature information.
  • the UPF can first obtain (e.g., receive) the first feature information from these other network elements and then verify the data packet based on it.
  • the UPF stores the first feature information based on an ATSSS-lite instruction; in other words, the ATSSS-lite instruction can be used to trigger the UPF to store the first feature information.
  • the first feature information includes at least one of the following: the terminal identifier, the session identifier, the terminal's IP address, and the public IP address of the UPF.
  • the terminal identifier the terminal identifier
  • the session identifier the terminal's IP address
  • the public IP address of the UPF the public IP address
  • the public IP address of the UPF represents the IP address associated with the UPF.
  • the UPF can provide the terminal with the public IP address of the UPF. Subsequently, when the terminal sends information (such as data packets) to the UPF on a non-3GPP access, it can send information to the UPF based on the public IP address of the UPF.
  • This application does not limit the network element that allocates the public IP address of the UPF.
  • the UPF, SMF, or other core network elements may allocate the public IP address of the UPF.
  • the allocation of the public IP address of the UPF to the UPF is used as an example for illustration.
  • the public IP address of a UPF can include the following scenarios.
  • the public IP address of the UPF is per session.
  • the UPF assigns a UPF IP address to each terminal's session. Based on this, the UPF IP address can uniquely identify the traffic of a specific session corresponding to a terminal on non-3GPP access.
  • the UPF IP address in the first feature information can be the public IP address of the UPF of the per session.
  • the second possible scenario is that the public IP address of the UPF is reused.
  • the UPF assigns a single public IP address to multiple terminal sessions.
  • multiple sessions or multiple terminals share (i.e., reuse) a single public IP address of the UPF.
  • sessions can be further identified through the terminal's IP address.
  • the terminal's IP address includes: the terminal's IP address on non-3GPP access and/or the terminal's IP address on 3GPP access.
  • Figure 7 is a schematic diagram of the steering function applicable to embodiments of this application.
  • an IP address for the terminal on a non-3GPP access and an IP address for the terminal on a 3GPP access can be assigned, so that a unique session can be identified by the IP address of the terminal on the non-3GPP access.
  • the redirection function is MPTCP.
  • a terminal or a terminal session it can assign the terminal's IP address IP@1 on a non-3GPP access network and the terminal's IP address IP@2 on a 3GPP access network.
  • a unique session can be identified by either the terminal's IP address IP@1 on a non-3GPP access network or the terminal's IP address IP@2 on a 3GPP access network.
  • the redirection function is MPQUIC.
  • a terminal or a terminal session it can assign the terminal's IP address IP@4 on non-3GPP access and the terminal's IP address IP@5 on 3GPP access.
  • a unique session can be identified by either the terminal's IP address IP@4 on non-3GPP access or the terminal's IP address IP@5 on 3GPP access.
  • IP address can be assigned to a terminal or a terminal session, and the terminal uses the same IP address on both non-3GPP and 3GPP access, thereby identifying a unique session through the IP address.
  • the redirection function is ATSSS-LL.
  • an IP address IP@3 can be assigned.
  • the terminal uses IP@3 on both non-3GPP access and 3GPP access.
  • the unique session can be identified through IP@3.
  • the network elements that allocate IP addresses for terminals on non-3GPP access and those that allocate IP addresses for terminals on 3GPP access are not limited.
  • the UPF allocates IP addresses for terminals on both non-3GPP and 3GPP access.
  • other core network elements besides the UPF allocate IP addresses for terminals on both non-3GPP and 3GPP access.
  • the network element that allocates the IP address for the terminal on non-3GPP access and the network element that allocates the IP address for the terminal on 3GPP access can be the same or different, and this is not limited.
  • the terminal's IP address refers to the IP address associated with the terminal.
  • the source address of that data is the terminal's IP address.
  • the terminal's IP address can be the complete information of the terminal's IP address, or it can be the terminal's IP address prefix; there is no limitation in this regard.
  • the following description will use the terminal's IP address; it can be understood that the terminal's IP address can be replaced with the terminal's IP address prefix.
  • the terminal's IP address includes: the terminal's IP address on non-3GPP access and/or the terminal's IP address on 3GPP access. Please refer to the preceding descriptions for information on the terminal's IP address; it will not be repeated here. Unless otherwise specified, the terminal's IP address mentioned below will include: the terminal's IP address on non-3GPP access and/or the terminal's IP address on 3GPP access.
  • the session identifier is used to identify the session.
  • the session identifier could be the identifier (identify, ID) of the terminal's PDU session.
  • the terminal's identifier can be used to identify the terminal.
  • the terminal's identifier includes any of the following: generic public subscription identifier (GPSI), network access identifier (NAI), subscription concealed identifier (SUCI), or globally unique temporary identifier (GUTI).
  • GPSI generic public subscription identifier
  • NAI network access identifier
  • SUCI subscription concealed identifier
  • GUITI globally unique temporary identifier
  • step 610 can also be described as follows: During the process of establishing a session for the terminal on 3GPP access, the UPF obtains the first feature information. Three implementation methods are introduced below.
  • UPF assigns the first feature information to the terminal.
  • the first feature information includes the terminal's IP address and/or the public IP address of the UPF, which assigns the terminal's IP address and/or the UPF's public IP address.
  • the first feature information includes the terminal identifier and/or the session identifier.
  • the UPF assigns the terminal identifier and/or the session identifier to the terminal. This can also be understood as the UPF determining the terminal identifier and/or the session identifier for the terminal, or the UPF determining the terminal identifier and/or the session identifier and using the determined terminal identifier and/or session identifier as the first feature information.
  • the second possible implementation is that the UPF receives the first feature information.
  • the first characteristic information includes the terminal identifier and/or session identifier.
  • the UPF receiving the terminal identifier and/or session identifier may include: the UPF receiving the terminal identifier and/or session identifier from other core network elements (such as session management elements (such as SMF)); correspondingly, the other core network elements sending the terminal identifier and/or session identifier to the UPF.
  • the other core network elements may send the terminal identifier and/or session identifier to the UPF based on an ATSSS-lite instruction; in other words, the ATSSS-lite instruction can be used to trigger other core network elements to send the terminal identifier and/or session identifier to the UPF.
  • the third possible implementation is that the UPF allocates and receives the first feature information for the terminal.
  • the first feature information includes a first part of information and a second part of information.
  • the UPF can allocate the first part of information to the terminal and receive the second part of information.
  • the first feature information includes the terminal identifier, the session identifier, the terminal's IP address, and the UPF's public IP address.
  • UPF can assign a terminal's IP address and UPF's public IP address to the terminal, and receive the terminal's identifier and session identifier.
  • the UPF can assign a public IP address to the terminal and receive the terminal's identifier, session identifier, and IP address.
  • the UPF can receive these identifiers from different network elements. For instance, the UPF might receive the terminal's identifier and session identifier from the session management network element, and the terminal's IP address from a non-3GPP access node.
  • the UPF can assign a public IP address to the terminal and an IP address for the terminal on 3GPP access, and receive the terminal's identifier, session identifier, and IP address on non-3GPP access.
  • the UPF can receive the terminal's identifier, session identifier, and IP address on non-3GPP access from different network elements. For instance, the UPF receives the terminal's identifier and session identifier from the session management network element, and receives the terminal's IP address on non-3GPP access from the non-3GPP access node.
  • the terminal sends feature information (i.e., an example of the second information) to the UPF on a non-3GPP access.
  • the terminal may also send feature information to the UPF based on the ATSSS-lite instruction; or, the terminal may also send feature information to the UPF based on the received public IP address of the UPF.
  • this feature information may be carried in the data packet or it may be outside the data packet; there is no limitation on this.
  • the characteristic information carried by the terminal when sending information is called the terminal's second characteristic information.
  • the terminal's second characteristic information will be simply referred to as second characteristic information.
  • the second information can also be called second characteristic information.
  • second characteristic information For ease of understanding and distinction, the following explanation will use second characteristic information as an example.
  • the second feature information includes at least one of the following: the terminal identifier, the session identifier, the terminal's IP address, and the public IP address of the UPF. Please refer to the preceding descriptions for details regarding these information.
  • the second feature information is similar to the first feature information, except that the first feature information is the feature information stored at the UPF, or in other words, the feature information used by the UPF to verify the data packets of the terminal; the second feature information is the feature information carried by the terminal when sending information (such as data packets), used by the UPF to verify the second feature information.
  • the session identifier is identifier #1
  • the session identifier included in the second feature information sent by the terminal is identifier #2.
  • Identifier #1 and identifier #2 may be the same or different. The specific verification process is explained in detail below.
  • step 640 UPF verifies the data packet based on the first feature information and the second feature information.
  • UPF verifies data packets based on first and second feature information, which can also be understood as UPF verifying the second feature information based on the first feature information. If UPF verifies the second feature information based on the first feature information and the data packet passes verification, it can be determined that the data packet has passed verification or that the data packet is a valid data packet, and therefore the data packet is processed; if UPF fails to verify the second feature information based on the first feature information and the data packet fails verification, it can be determined that the data packet has failed verification or that the data packet is not a valid data packet, and therefore the data packet is not processed.
  • the following is an example, combining the information included in the first feature information and the second feature information.
  • the first feature information includes the terminal's IP address (e.g., denoted as IP#1)
  • the second feature information includes the terminal's IP address (e.g., denoted as IP#2).
  • the source address of the data packet is IP#2.
  • the terminal sends a data packet to the UPF; since the source address of this data packet is IP#2, it can be understood that the data packet carries the second characteristic information (i.e., IP#2).
  • IP#1 is the IP address of the terminal on a non-3GPP access network. UPF determines (or verifies) whether the source address of the data packet is IP#1. In other words, UPF determines whether IP#1 and IP#2 match (i.e., are consistent).
  • the source address of the data packet matches (i.e., is consistent) the IP address of the terminal on non-3GPP access in the first feature information, that is, IP#1 matches (i.e. is consistent) the IP#2, then the verification is successful, that is, the UPF processes the data packet.
  • the source address of the data packet does not match (i.e., they are inconsistent) with the IP address of the terminal on a non-3GPP access in the first feature information, that is, IP#1 and IP#2 match (i.e., they are inconsistent)
  • the verification fails, and the UPF will not process the data packet.
  • IP#1 is the terminal's IP address on the 3GPP access network.
  • the UPF determines (or verifies) whether the source address of the data packet is IP#1. In other words, the UPF determines whether IP#1 and IP#2 match (i.e., are consistent). This method is applicable to scenarios where the terminal's IP address on the 3GPP access network can identify a unique session, such as IP@3 in Figure 7, or IP@2 or IP@5 in Figure 7.
  • the source address of the data packet matches (i.e., is consistent) the IP address of the terminal on the 3GPP access in the first feature information, that is, IP#1 matches (i.e. is consistent) the IP#2, then the verification is successful, that is, the UPF processes the data packet.
  • the verification fails, and the UPF will not process the data packet.
  • the first feature information includes the public IP address of the UPF (e.g., IP#3), and the second feature information includes the public IP address of the UPF (e.g., IP#4).
  • the destination address of the data packet is IP#4.
  • the terminal sends a data packet to the UPF; since the destination address of this data packet is IP#4, it can be understood that the data packet carries the second characteristic information (i.e., IP#4).
  • IP#3 is the public IP address of the UPF.
  • the UPF determines (or verifies) whether the destination address of the data packet is IP#3. In other words, the UPF determines whether IP#3 and IP#4 match (i.e., are consistent).
  • the destination address of the data packet matches (i.e., is consistent with) the public IP address of the UPF in the first feature information, that is, IP#3 matches (i.e. is consistent with) IP#4, then the verification is successful, and the UPF processes the data packet.
  • the verification fails, and the UPF will not process the data packet.
  • the first feature information includes the terminal's IP address (e.g., IP#1) and the UPF's public IP address (e.g., IP#3)
  • the second feature information includes the terminal's IP address (e.g., IP#2) and the UPF's public IP address (e.g., IP#4).
  • IP#1 is the IP address of the terminal on a non-3GPP access.
  • the source address of the data packet matches (i.e., is consistent) with the IP address of the terminal on a non-3GPP access network in the first feature information (i.e., IP#1 matches IP#2)
  • the destination address of the data packet matches (i.e., is consistent) with the public IP address of the UPF in the first feature information (i.e., IP#3 matches IP#4)
  • the verification passes, and the UPF processes the data packet.
  • the source address of the data packet does not match (i.e., is inconsistent) with the IP address of the terminal on a non-3GPP access network in the first feature information (i.e., IP#1 does not match IP#2), and/or, the destination address of the data packet does not match (i.e., is inconsistent) with the public IP address of the UPF in the first feature information (i.e., IP#3 does not match IP#4), then the verification fails, and the UPF does not process the data packet.
  • the terminal's IP address and the UPF's public IP address match.
  • UPF can determine whether the source address and destination address of a data packet match. For example, if the source address and destination address match, the verification passes, and the UPF processes the data packet; conversely, if the source address and destination address do not match, the verification fails, and the UPF does not process the data packet.
  • IP#1 is the terminal's IP address on the 3GPP access network. This method is applicable to scenarios where the terminal's IP address on the 3GPP access network can identify a unique session, such as IP@3 in Figure 7, or IP@2 or IP@5 in Figure 7.
  • the source address of the data packet matches (i.e., is consistent) with the IP address of the terminal on 3GPP access in the first feature information, that is, IP#1 matches IP#2 (i.e., is consistent), and the destination address of the data packet matches (i.e., is consistent) with the public IP address of the UPF in the first feature information, that is, IP#3 matches IP#4 (i.e., is consistent), then the verification is successful, that is, the UPF processes the data packet.
  • the IP address of the terminal on the 3GPP access included in the data packet matches (i.e., is consistent) with the IP address of the terminal on the 3GPP access in the first feature information, that is, IP#1 matches IP#2 (i.e., is consistent), and the destination address of the data packet matches (i.e., is consistent) with the public IP address of the UPF in the first feature information, that is, IP#3 matches IP#4 (i.e., is consistent), then the verification is successful, and the UPF processes the data packet.
  • the source address of the data packet does not match (i.e., is inconsistent) with the IP address of the terminal on the 3GPP access in the first feature information, that is, IP#1 and IP#2 do not match (i.e., are inconsistent); and/or, the destination address of the data packet does not match (i.e., is inconsistent) with the public IP address of the UPF in the first feature information, that is, IP#3 and IP#4 do not match (i.e., are inconsistent), then the verification fails, that is, the UPF does not process the data packet.
  • the verification fails, that is, the UPF does not process the data packet.
  • the first feature information includes the terminal's identifier (e.g., denoted as ID#1)
  • the second feature information includes the terminal's identifier (e.g., denoted as ID#2).
  • the UPF processes the data packet.
  • the verification will fail, meaning the UPF will not process the data packet.
  • the first feature information includes the session identifier (e.g., denoted as ID#3)
  • the second feature information includes the session identifier (e.g., denoted as ID#4).
  • the UPF processes the data packet.
  • the verification will fail, meaning the UPF will not process the data packet.
  • the first feature information includes the terminal identifier (e.g., denoted as ID#1) and the session identifier (e.g., denoted as ID#3)
  • the second feature information includes the terminal identifier (e.g., denoted as ID#2) and the session identifier (e.g., denoted as ID#4).
  • the verification is successful, and the UPF processes the data packet.
  • the verification fails, meaning that the UPF does not process the data packet.
  • the first feature information includes the public IP address of the UPF (e.g., IP#3), the identifier of the terminal (e.g., ID#1), and the identifier of the session (e.g., ID#3)
  • the second feature information includes the public IP address of the UPF (e.g., IP#4) and the identifier of the terminal (e.g., ID#2).
  • the verification is successful, that is, the UPF processes the data packet.
  • the verification fails, that is, the UPF does not process the data packet.
  • the UPF can first determine whether the destination address of the data packet matches the public IP address of the UPF in the first feature information. If they match, it can then verify whether the ID#1 provided by the terminal matches the ID#2 in the first feature information.
  • step 640 during the valid time corresponding to the first feature information, the UPF verifies the data packet based on the first feature information and the second feature information.
  • the effective time corresponding to the first feature information is represented by a timer.
  • the timer corresponding to the first feature information is called timer#1.
  • timer#1 if timer#1 has not expired, the first feature information is used to verify the data packet; if timer#1 has expired, the first feature information is no longer used to verify the data packet.
  • timer#1 can be represented as a time period; or timer#1 can be implemented using a timer. For instance, if the timer is running, the first characteristic information is used to verify the data packet; if the timer stops (or expires), the first characteristic information is no longer used to verify the data packet.
  • timer#1 is predefined, or determined by the UPF itself; or determined by other network elements and notified to the UPF.
  • Option #2 UPF verifies data packets based on the terminal's authorization information.
  • the authorization information of this terminal will be referred to as the terminal's first authorization information.
  • the terminal's first authorization information will be simply referred to as first authorization information.
  • the first information can also be called first authorization information.
  • Scheme #2 will be introduced using first authorization information as an example below.
  • the first authorization information can be used to verify information subsequently sent by the terminal on non-3GPP access. Specifically, the UPF verifies data packets sent by the terminal on non-3GPP access based on the first authorization information.
  • the first authorization information can also be called verification information, and the name of the first authorization information is not limited in this embodiment.
  • the first authorization information includes a token (or verification information associated with the token), and/or a message authentication code (MAC) (or verification information associated with the MAC).
  • the verification information associated with the token represents information used to verify the token, such as a public key or certificate used to verify the token's digital signature.
  • the verification information associated with the MAC represents information used to verify the MAC generated by the terminal, such as a key used to verify the MAC generated by the terminal.
  • the verification information associated with the MAC can be used to verify the MAC generated by the terminal, it can also be referred to as information that can be used to verify the MAC generated by the terminal.
  • step 610 can also be described as follows: During the process of establishing a session for the terminal on 3GPP access, the UPF obtains the first authorization information. Further optionally, the UPF can obtain the first authorization information for the terminal based on the ATSSS-lite indication. Three implementation methods are described below.
  • the first possible implementation is that the UPF assigns the first authorization information to the terminal.
  • the first authorization information is a token
  • UPF assigns this token to the terminal.
  • the second possible implementation is that the UPF receives the first authorization information.
  • the first authorization information is a token or MAC address.
  • the UPF receives the relevant information of the token or MAC address and can then determine the token or MAC address based on that information.
  • the third possible implementation is that the UPF allocates and receives the first authorization information for the terminal.
  • the first authorization information is a token and a MAC address.
  • the UPF can assign the token to the terminal and receive the relevant information about the MAC address, and then determine the MAC address based on the relevant information.
  • the terminal also sends authorization information to the UPF on non-3GPP access. Further optionally, the terminal may send authorization information to the UPF based on the ATSSS-lite instruction; or, the terminal may send authorization information to the UPF based on the received public IP address of the UPF.
  • the authorization information may be carried in the data packet or it may be outside the data packet; there is no limitation on this.
  • the authorization information carried by the terminal when sending information is called the terminal's second authorization information.
  • the terminal's second authorization information will be simply referred to as second authorization information.
  • the second information can also be called second authorization information.
  • second authorization information For ease of understanding and distinction, the following explanation will use second authorization information as an example.
  • the second authorization information includes a token and/or a MAC address.
  • step 640 UPF verifies the data packet based on the first authorization information and the second authorization information.
  • UPF verifies data packets based on the first and second authorization information, which can also be understood as UPF verifying the second authorization information based on the first authorization information. If UPF verifies the second authorization information successfully based on the first authorization information, it can be determined that the data packet has passed verification or that the data packet is a valid data packet, and therefore the data packet is processed; if UPF fails to verify the second authorization information successfully based on the first authorization information, it can be determined that the data packet has failed verification or that the data packet is not a valid data packet, and therefore the data packet is not processed.
  • the first authorization information is a token (e.g., token#1) and/or verification information related to token#1, and the second authorization information is a token (e.g., token#2).
  • the UPF can verify the data packet based on token #1 or verification information associated with token #1 and token #2.
  • token#1 and token#2 match (i.e., are identical), the verification is successful, and the UPF processes the data packet; or, if token#2 is verified based on the verification information associated with token#1, the verification is successful, and the UPF processes the data packet.
  • token#1 and token#2 do not match (i.e., are inconsistent)
  • the verification fails, meaning the UPF will not process the data packet; or, if the verification of token#2 fails based on the verification information associated with token#1, the verification fails, meaning the UPF will not process the data packet.
  • the content of the token (such as token#1, or token#2) can be implemented in the following two ways.
  • the first possible implementation is that the token is a random number.
  • a token is associated with a session (or terminal).
  • a session can be associated with one or more tokens.
  • the UPF can generate a random number and associate (or bind) the random number with the session. Subsequently, after the UPF receives a data packet and a token (such as token#2) from the terminal, it can determine the random number associated with the session of the terminal corresponding to the data packet (i.e., token#1) based on at least one of the following contained in the data packet: the terminal's IP address, the UPF's public IP address, the terminal's identifier, the session's identifier, and the association relationship. Then, it can perform verification based on the random number and token#2.
  • a token such as token#2
  • the second possible implementation involves a token determined based on at least one of the following: the terminal identifier, the session identifier, the terminal's IP address, and the public IP address of the UPF.
  • the token content is generated based on at least one of the following: the terminal identifier, the session identifier, the terminal's IP address, and the public IP address of the UPF.
  • tokens (such as token#1, or token#2) can be issued using either MAC constructs or digital signatures. These two methods are described below.
  • the first possible implementation involves token issuance via MAC construction.
  • the token is transmitted and/or stored in MAC form, or the token includes the MAC.
  • the MAC is determined based on at least one of the following: the terminal identifier, the session identifier, the terminal's IP address, or the public IP address of the UPF.
  • the UPF can use its own key to issue the token; in other words, the UPF does not use a key deduced from the UE's security context.
  • the UPF can pre-configure (or pre-store) one or more keys for token issuance.
  • the second possible implementation involves issuing a digital signature for the token; in other words, the token carries a digital signature when it is transmitted and/or stored.
  • the digital signature is determined based on at least one of the following: the terminal's identifier, the session's identifier, the terminal's IP address, or the public IP address of the UPF.
  • UPF can obtain a token in the following two ways.
  • the UPF determines the token itself. For example, the UPF generates its own random number. Another example is that the UPF determines the token based on at least one of the following: the terminal identifier, the session identifier, the terminal's IP address, or the UPF's public IP address. For instance, the UPF determines the digital signature or MAC address of the random number based on at least one of these.
  • the second possible implementation involves the UPF receiving token information from other network elements.
  • This token information can include the token itself, or it can include information required to verify the token (i.e., token-related verification information).
  • This token verification information could include, for example, certificates or public keys.
  • the other network element is any of the following: session management network element (such as SMF), storage network element (such as NRF), mobility management network element (such as AMF), etc.
  • SMF session management network element
  • NRF storage network element
  • AMF mobility management network element
  • the UPF requests token information from other network elements, and those other network elements send the token information back to the UPF based on the UPF's request.
  • Another example is that other network elements proactively send token information to the UPF.
  • the first authorization information is a MAC (e.g., MAC#1) and/or verification information related to MAC#1, and the second authorization information is a MAC (e.g., MAC#2).
  • the UPF can verify the data packet based on MAC#1 and MAC#2.
  • the verification passes, and the UPF processes the data packet; or, if MAC#2 passes verification based on the verification information associated with MAC#1, the verification passes, and the UPF processes the data packet.
  • the verification fails, meaning the UPF will not process the data packet; or, if the verification of MAC#2 fails based on the verification information related to MAC#1, the verification fails, meaning the UPF will not process the data packet.
  • the UPF can determine MAC#1 based on the key, or verify MAC#2.
  • the UPF receives the key.
  • the UPF receives the key in several ways, including the following implementations.
  • the session management network element (such as the SMF) sends a key to the UPF.
  • the UPF then receives this key.
  • the session management network element can proactively send a key to the UPF; or, the UPF can request a key from the session management network element, and in response to the UPF's request, the session management network element can send a key to the UPF; or, the session management network element can send a key to the UPF based on the ATSSS-lite instruction.
  • the session management network element can deduce the key itself, or it can receive the key deduced by other core network elements (such as the mobility management network element), or it can request and receive the key deduced by other core network elements (such as the mobility management network element), without any limitation on this.
  • the second possible implementation involves the mobility management element (such as the AMF) sending a key to the UPF.
  • the mobility management element such as the AMF
  • the mobility management network element can proactively send a key to the UPF; or, the UPF can request a key from the mobility management network element, and in response to the UPF's request, the mobility management network element can send a key to the UPF; or, the mobility management network element can send a key to the UPF based on the ATSSS-lite instruction.
  • the input parameters for key K’ derivation include at least one of the following: terminal identifier, session identifier, terminal IP address, UPF public IP address, terminal access type, and intermediate key.
  • the terminal access type may, for example, include 3GPP access or non-3GPP access.
  • the derivation process of key K’ is as follows:
  • K’ KDF(K, UE ID, PDU session ID, Access type); or,
  • K’ KDF(KAMF, UE ID, PDU session ID); or,
  • K’ KDF(K, UE IP address, Access type); or,
  • K’ KDF(K, UPF IP address); etc.
  • K can be KAMF, KAUSF, KSEAF, or KSMF.
  • KAMF represents the intermediate key provided by AMF, KAUSF by ASF, KSEAF by SEAF, and KSMF by SMF.
  • UE ID represents the terminal identifier.
  • PDU session ID represents the session identifier.
  • Access type represents the terminal's access type.
  • UE IP address represents the terminal's IP address on 3GPP or non-3GPP access.
  • UPF IP address represents the UPF's public IP address (corresponding to the UPF address at the session granularity).
  • KDF represents a key derivation method, such as converting a short key into a long key.
  • the second authorization information (i.e., the second information) sent by the terminal on non-3GPP access is MAC#2.
  • the terminal can calculate MAC#2 based on a key and at least one of the following: the terminal's identifier, the session identifier, the terminal's IP address, and the public IP address of the UPF.
  • the terminal calculates MAC#2 based on the public IP address of the UPF. Specifically, after receiving the public IP address of the UPF in step 620, the terminal can assume that the session is under the ATSSS-lite scenario, and therefore the terminal calculates MAC#2.
  • the terminal calculates MAC#2 based on the ATSSS-lite instruction.
  • the ATSSS-lite instruction can be determined by the terminal itself or received by the terminal; there is no limitation on this.
  • step 640 during the valid time corresponding to the second authorization information, the UPF verifies the data packet based on the first authorization information and the second authorization information.
  • the second authorization information corresponds to a timer (denoted as timer#2 for distinction).
  • timer#2 By setting the duration of timer#2, replay attacks can be prevented to some extent.
  • timer#2 indicates the validity period of the second authorization information. Specifically, if timer#2 has not expired, the first authorization information is used to verify the second authorization information; if timer#2 has expired, the second authorization information will no longer be verified.
  • timer#2 can be represented as a time period; or timer#2 can be implemented using a timer. For instance, if the timer runs, the second authorization information is verified using the first authorization information; if the timer stops (or expires), the second authorization information is no longer verified.
  • Scheme #1 and Scheme #2 have been described above. It is understood that Scheme #1 and Scheme #2 are illustrative examples, and the embodiments of this application are not limited thereto. Any variation of Scheme #1 or Scheme #2 is applicable to the embodiments of this application.
  • Scheme 600 is mainly described using user plane network elements for verification, but this is not limited.
  • other network elements or gateways can also use the above methods (such as Scheme #1 or Scheme #2) for verification.
  • network element #B as an example; for details, please refer to the preceding descriptions.
  • network element #B receives data packets from the terminal on non-3GPP access and the terminal's second information; network element #B verifies the data packets based on the first and second information.
  • network element #B receives data packets from the terminal on non-3GPP access and the terminal's second feature information; network element #B verifies the data packets based on the first and second feature information.
  • network element #B can be used to authenticate terminals accessing the network via non-3GPP networks.
  • network element #B represents the network element that authenticates terminals accessing the network via non-3GPP networks.
  • network element #B can be a firewall, such as a firewall in front of the user plane network element.
  • Authentication of terminals accessing the network via non-3GPP networks can also be described as authentication of data packets from terminals accessing the network via non-3GPP networks, or authentication of sessions from terminals accessing the network via non-3GPP networks; there is no limitation on this.
  • the name of network element #B is also not limited.
  • network element #B can also be called a gateway, authentication gateway (or authentication network element), data packet authentication gateway (or data packet network element), or firewall, etc. Any name that can achieve the above functions is applicable to the embodiments of this application.
  • network element #B verifies terminals accessed through non-3GPP networks, please refer to the previous section on user plane network element verification methods; these details will not be repeated here.
  • network element #B can be a standalone device or integrated into the same device to implement different functions. This application does not limit the specific form of the aforementioned network element #B.
  • network element #B can be a physical entity in a hardware device, a software instance running on dedicated hardware, or a virtualized function instantiated on a shared platform (e.g., a cloud platform).
  • network element #B can be deployed (or integrated) within a user plane network element; alternatively, network element #B can also be deployed outside of the user plane network element, such as between a user plane network element and a non-3GPP access point.
  • deploying network element #B between a user plane network element and a non-3GPP access point means that when the terminal sends data packets through the non-3GPP access point, the data packets first pass through network element #B, and then through the user plane network element.
  • the method by which network element #B obtains the first feature information is not limited.
  • the user plane network element sends the first characteristic information to network element #B.
  • a user plane network element actively sends first characteristic information to network element #B. For instance, in step 610, the user plane network element receives the first characteristic information and then sends it to network element #B.
  • a user plane network element sends first characteristic information to network element #B based on a request from network element #B. For instance, after network element #B receives a data packet and second characteristic information from a terminal on a non-3GPP access network, it requests the terminal's first characteristic information from the user plane network element; the user plane network element then sends the terminal's first characteristic information to network element #B based on the request.
  • a second possible implementation involves a network element outside the user plane (such as a network management function (e.g., operation administration and maintenance, OAM) or a session management element) sending the first characteristic information to network element #B.
  • a network management function e.g., operation administration and maintenance, OAM
  • a session management element or a user plane element sends the first characteristic information to a network element outside the user plane element; this network element outside the user plane element then sends the first characteristic information to network element #B.
  • Two examples are given using network management functions as an example.
  • a user plane network element proactively sends the first characteristic information to a network management function/session management network element, such as in step 610 where the user plane network element obtains the first characteristic information and then sends it to the network management function/session management network element; or the network management function/session management network element proactively sends the first characteristic information to network element #B, or the network management function/session management network element sends the first characteristic information to network element #B based on a request from network element #B.
  • the session management network element/user plane network element sends the first characteristic information to the network management function, such as the session management network element sending the first characteristic information to the network management function based on the ATSSS-lite instruction; the network management function actively sends the first characteristic information to network element #B, or the network management function sends the first characteristic information to network element #B based on the request of network element #B.
  • the network management function such as the session management network element sending the first characteristic information to the network management function based on the ATSSS-lite instruction
  • the network management function actively sends the first characteristic information to network element #B, or the network management function sends the first characteristic information to network element #B based on the request of network element #B.
  • the scheme for network elements other than user plane network elements to send the first characteristic information to network element #B is the same as the first possible implementation, and will not be elaborated here.
  • the mobility management network element is AMF
  • the terminal is UE
  • the session management network element is SMF
  • the user plane network element is UPF. It should be understood that the processes described below are merely illustrative examples, and the embodiments of this application are not limited thereto. Content not described in detail below can be referred to the description in method 600, and will not be repeated hereafter.
  • Figure 8 is a schematic diagram of a communication method 800 provided in an embodiment of this application.
  • Method 800 can be used to implement scheme #1 in method 600.
  • the method 800 shown in Figure 8 may include the following steps.
  • the UE and the network side perform the 3GPP registration process.
  • step 801 the UE completes the registration for 3GPP access.
  • the UE sends a non-access stratum (NAS) message to the AMF, which carries a session establishment request.
  • NAS non-access stratum
  • the UE can send a NAS message to the AMF via the RAN, which carries a PDU session establishment request (or MA PDU session establishment request).
  • a PDU session establishment request or MA PDU session establishment request.
  • the UE may also send an ATSSS-lite indicator to the AMF, which indicates that the UE supports ATSSS-lite.
  • the ATSSS-lite indicator may be carried within the NAS message, or it may be sent to the AMF via separate signaling; there is no limitation on this.
  • step 802 a NAS message is used as an example for illustration, but the embodiments of this application are not limited to this.
  • AMF sends a Session Context Establishment Request message to SMF.
  • the AMF also sends an ATSSS-lite indication to the SMF.
  • the UE sends an ATSSS-lite indication to the AMF, therefore, in step 803, the AMF also sends an ATSSS-lite indication to the SMF.
  • the ATSSS-lite indication can be carried in the session context establishment request message, or it can be sent to the SMF via separate signaling; there is no limitation on this.
  • SMF queries UDM for subscription data, selects PCF, and obtains policy information.
  • the SMF and UDM can interact to obtain session management-related subscription data from the UDM, and the SMF can register UE's current session-related information with the UDM.
  • SMF sends an N4 session establishment request message to UPF and establishes an N4 session.
  • the SMF sends at least one of the following to the UPF: an ATSSS-lite indication, the UE's identifier, and the session identifier (such as the PDU session ID).
  • the UE's identifier can be, for example, GPSI and/or NAI.
  • UPF determines and stores the first feature information.
  • the UPF after receiving the N4 session establishment request message from the SMF, the UPF establishes 3GPP and non-3GPP user plane resources for the UE, enabling subsequent user plane data transmission on the established user plane. Alternatively, after receiving the N4 session establishment request message from the SMF, the UPF determines whether to establish 3GPP and non-3GPP user plane resources for the UE based on the ATSSS-lite instruction in the N4 session establishment request message.
  • the UPF determines the first characteristic information, including: if the UE supports ATSSS-lite, the UPF determines the first characteristic information. For instance, if the N4 session establishment request message in step 805 includes an ATSSS-lite indication, then the UPF determines the first characteristic information.
  • the first feature information includes at least one of the following: the UE identifier, the session identifier (such as the PDU session ID), the UE's IP address, and the UPF's public IP address.
  • the UE identifier and the session identifier are received from the SMF side in step 805.
  • the UPF's public IP address can be determined by the UPF itself. The above information can be referred to the relevant description in method 600, and will not be repeated here.
  • UPF sends its public IP address to SMF.
  • the public IP address of the UPF sent by the UPF to the SMF can be either the public IP address of the UPF or an IP address prefix.
  • the public IP address of the UPF will be used as an example here.
  • the public IP address of the UPF can be included in the N4 session establishment response message.
  • the public IP address of the UPF can also be carried in other signaling messages, without limitation.
  • the UPF IP address can also be carried in messages such as the N4 session modification with PFCP or the Nupf_event exposure subscribe request.
  • the UPF may also send at least one of the following to the SMF: the UE's IP address or IP address prefix on non-3GPP access, or the UE's IP address or IP address prefix on 3GPP access.
  • the N4 session establishment response message may also include at least one of the following: the UE's IP address or IP address prefix on non-3GPP access, or the UE's IP address or IP address prefix on 3GPP access.
  • SMF sends the public IP address of UPF to UE.
  • step 807 the UPF sends the UPF's public IP address prefix to the SMF
  • step 808 the SMF sends the UPF's public IP address prefix to the UE.
  • the UPF's public IP address will be used as an example here.
  • the SMF can send the public IP address of the UPF to the UE through the AMF and RAN.
  • the SMF may also send at least one of the following to the UE: the UE's IP address or IP address prefix on non-3GPP access, or the UE's IP address or IP address prefix on 3GPP access.
  • the UE establishes a connection with a non-3GPP access network, such as an L2 connection. This allows the UE to send messages on the non-3GPP access network.
  • a non-3GPP access network such as an L2 connection.
  • non-3GPP access networks assign IP addresses or IP address prefixes to UEs on non-3GPP access networks.
  • the UE sends a request message to the UPF on a non-3GPP access, the request message including second feature information.
  • the source address of the request message is the UE's IP address on non-3GPP access or an IP address constructed based on the UE's IP address prefix on non-3GPP access, such as the UE's IP address or IP address prefix allocated in step 809, or the UE's IP address or IP address prefix determined by the UPF in step 806.
  • the destination address of the request message is the public IP address of the UPF or an IP address constructed based on the public IP address prefix of the UPF, that is, the public IP address or IP address prefix of the UPF determined by the UPF in step 806.
  • the request message can be any of the following: an IPSec request message, a transport layer security (TLS) request message, a QUIC request message, or an MPQUIC request message.
  • the request message can also be a data packet. There is no limitation on this.
  • the second feature information may include at least one of the following: the UE's identifier, the session identifier (such as the PDU session ID), the UE's IP address, and the UPF's public IP address.
  • the identifier information may be carried in the request message in any of the following ways: IPSec, where the IP address uses the UE's IP address or an IP address prefix on 3GPP/non-3GPP access, and the IDi information carries information related to the UE's identifier and the session identifier; TLS, where the pre_shared_key carries information related to the UE's identifier and the session identifier (as the KID), or the certificate subject name is constructed based on the UE's identifier and the session identifier.
  • UPF performs verification based on the first feature information and the second feature information.
  • the UPF receives a request message from the UE and verifies it by combining the first feature information determined in step 806 and the second feature information received in step 810. If the verification passes, as an example, an establishment response message can be sent to the UE, i.e., step 812; if the verification fails, the request message can be directly rejected.
  • the first feature information includes the UE's IP address on a non-3GPP access network.
  • the UPF determines whether the source address of the request message is the UE's IP address on a non-3GPP access network. If the source address of the request message is the UE's IP address on a non-3GPP access network as shown in the first feature information, the verification passes; otherwise, the verification fails.
  • the second feature information is the source address of the request message.
  • the first feature information including the public IP address of the UPF.
  • the UPF determines whether the destination address of the request message is its public IP address. If the destination address of the request message is the public IP address of the UPF in the first feature information, the verification passes; otherwise, the verification fails. In this case, the second feature information is the destination address of the request message.
  • the UPF determines whether the destination address of the request message is the public IP address of the UPF and whether the UE identifier in the request message matches (i.e., is consistent) the UE identifier in the first feature information. If the destination address of the request message is the public IP address of the UPF in the first feature information, and the UE identifier in the request message matches (i.e., is consistent) the UE identifier in the first feature information, then the verification passes; otherwise, the verification fails.
  • UPF sends a response message to UE.
  • the response message can be any of the following: an IPSec response message, a TLS response message, a QUIC response message, or an MPQUIC response message.
  • the request message in step 810 is an IPSec request message
  • the response message in step 812 is an IPSec response message.
  • the request message in step 810 is a TLS request message
  • the response message in step 812 is a TLS response message.
  • the request message in step 810 is a QUIC request message
  • the response message in step 812 is a QUIC response message.
  • the response message in step 812 is an MPQUIC response message.
  • the UPF can determine and store the first feature information.
  • the UE sends a message on a non-3GPP access, it can carry the second feature information.
  • the UPF can perform verification based on the first and second feature information, thereby reducing the risk of the UPF being attacked after its public IP address is leaked.
  • Figure 9 is a schematic diagram of a communication method 900 provided in an embodiment of this application.
  • Method 900 can be used to implement scheme #2 in method 600, and in a scenario where the authorization information is a token.
  • the method 900 shown in Figure 9 may include the following steps.
  • the UE and the network side perform the 3GPP registration process.
  • the UE sends a NAS message to the AMF, which carries a session establishment request.
  • AMF sends a Session Context Establishment Request message to SMF.
  • SMF queries UDM for subscription data, selects PCF, and obtains policy information.
  • SMF sends an N4 session establishment request message to UPF and establishes an N4 session.
  • Steps 901-905 are similar to steps 801-805, and can be found in the description above. They will not be repeated here.
  • UPF confirms or receives token #1.
  • the UPF after receiving the N4 session establishment request message from the SMF, the UPF establishes 3GPP and non-3GPP user plane resources for the UE, enabling subsequent user plane data transmission on the established user plane. Alternatively, after receiving the N4 session establishment request message from the SMF, the UPF determines whether to establish 3GPP and non-3GPP user plane resources for the UE based on the ATSSS-lite instruction in the N4 session establishment request message.
  • the first possible implementation is that UPF determines token #1.
  • the UPF determines token #1 by: determining token #1 based on the ATSSS-lite indication. For instance, if the N4 session establishment request message in step 805 includes the ATSSS-lite indication, then the UPF determines token #1.
  • the UPF generates a random number and binds it locally with the UE's PDU session ID or the IP address assigned to the UE, using the random number as token #1.
  • the UPF issues a token#1 to the UE, which is determined based on at least one of the following: the terminal identifier, the session identifier, the terminal's IP address, and the UPF's public IP address.
  • token#1 can be issued using a MAC construct or a digital signature.
  • the UPF may pre-configure a key for token issuance and use that key to issue token#1.
  • the UPF may pre-configure a digital certificate and a corresponding private key, or a public-private key pair, and use that private key to issue token#1.
  • the second possible implementation is that UPF receives token #1.
  • the UPF receives token#1 and/or related information about token#1 from the SMF or NRF.
  • the related information about token#1 represents information related to verifying token#1, or verification information for token#1, such as certificates or public keys.
  • the UPF can request token #1 from the SMF or NRF; another example is that the SMF or NRF proactively sends token #1 to the UPF; yet another example is that the SMF or NRF sends token #1 to the UPF based on the ATSSS-lite instruction.
  • the SMF or NRF determines token #1, please refer to the method by which the UPF determines token #1.
  • UPF sends its public IP address and token #1 to SMF.
  • the public IP address of the UPF sent by the UPF to the SMF can be either the public IP address of the UPF or an IP address prefix.
  • the public IP address of the UPF will be used as an example here.
  • the public IP address of the UPF and token #1 can be included in the N4 session establishment response message.
  • the public IP address and token #1 of UPF can also be carried in other signaling messages without limitation.
  • the UPF IP address and token #1 can also be carried in messages such as N4 session modification with PFCP or Nupf_event exposure subscribe request.
  • step 907 the UPF may not need to send token #1 to the SMF.
  • step 908 when the SMF sends the public IP address of the UPF to the UE, it can directly send token #1 back to the UE.
  • SMF sends the UPF's public IP address and token #1 to UE.
  • the UE sends a request message to the UPF on a non-3GPP access, the request message including token#2.
  • Step 910 is similar to step 810, except that in step 810 the request message carries the second feature information, while in step 910 the request message carries token#2.
  • the UPF verifies the token #2 received in step 910 based on token #1 or related information from token #1 in step 906. If the verification passes, a response message can be sent to the UE as an example, i.e., step 912; if the verification fails, the UE's request can be directly rejected.
  • the UPF receives a request message from the UE, extracts token#2 from the request message, and verifies whether the random number in token#2 is bound to the UE's session. In other words, it verifies whether token#2 matches (i.e., is consistent with) token#1 in step 906. If token#2 in the request message is bound to the UE's session, that is, if token#2 in the request message matches (i.e., is consistent with) token#1 in step 906, then the verification passes; otherwise, the verification fails.
  • the request message in step 910 may also carry second feature information, and the UPF may also verify the second feature information, as detailed in the relevant description in step 811.
  • the UPF may also directly verify whether the source address and/or destination address of the request message are valid, as detailed in the relevant description in step 811.
  • UPF sends a response message to UE.
  • Step 912 is similar to step 812, and will not be described in detail here.
  • the token when the token is a random number, if the random number is not encrypted, it can be used once.
  • the UE can carry a new random number each time it sends data (or a request).
  • the UPF can send multiple tokens to the UE for multiple transmissions.
  • the UPF can send multiple tokens to the UE through a single signaling, for the UE to use during multiple transmissions; or, the UPF can send multiple tokens to the UE separately in multiple transmissions, and the UE can carry the latest received random number each time it sends data (or a request).
  • the UPF can send two tokens to the UE.
  • the first token is used once, and the second can be reused repeatedly.
  • the UE can subsequently construct its own MAC value, and each MAC construction can use different content.
  • the token can be sent encrypted; or multiple tokens can be sent, similar to the case of random numbers.
  • a timer can be set for the token (such as timer#2 mentioned above).
  • the UPF can determine and provide the UE with an authorization token for subsequent access to the UPF on non-3GPP access.
  • the UE sends a message on non-3GPP access, it can carry this token.
  • the UPF can verify the token provided by the UE based on the local token and/or related information of the token, thereby reducing the risk of the UPF being attacked after its public IP address is leaked.
  • Figure 10 is a schematic diagram of a communication method 1000 provided in an embodiment of this application.
  • Method 1000 can be used to implement scheme #2 in method 600, and in a scenario where the authorization information is MAC.
  • the method 1000 shown in Figure 10 may include the following steps.
  • the UE and the network side perform the 3GPP registration process.
  • the UE sends a NAS message to the AMF, which carries a session establishment request.
  • AMF sends a session context establishment request message to SMF.
  • SMF queries UDM for subscription data, performs PCF selection, and obtains policy information.
  • the UPF also stores the key.
  • the SMF sends the key to the UPF.
  • the key can be carried in the N4 session establishment request message in step 1005.
  • the AMF actively derives the key for the UPF and sends the key to the SMF, which then sends the key to the UPF; or the SMF requests and receives the key from the AMF, which then sends the key to the UPF; or the SMF actively derives the key for the UPF and sends the key to the UPF.
  • the AMF sends the key to the UPF. For example, during session establishment, the AMF proactively derives a key for the UPF and sends that key to the UPF. Alternatively, the UPF requests a key from the AMF, and in response, the AMF derives the key for the UPF and sends that key to the UPF.
  • UPF sends its public IP address to SMF.
  • Step 1007 can be referred to step 807, and will not be repeated here.
  • SMF sends the public IP address of UPF to UE.
  • the SMF can send the public IP address of the UPF to the UE through the AMF and RAN.
  • UE deduces the key and uses the key to calculate the MAC (e.g., MAC#2).
  • the MAC e.g., MAC#2
  • the UE calculates MAC#2 based on the public IP address of the UPF. Specifically, after the UE receives the public IP address of the UPF in step 1008, it can assume that the session is under the ATSSS-lite scenario, so the UE calculates MAC#2.
  • the UE may use a key and at least one of the following to calculate MAC#2: the UE's identifier, the session identifier (such as the PDU session ID), the UE's IP address, and the UPF's public IP address.
  • the example given is that the UE derives the key itself; however, this embodiment is not limited to this.
  • the UE may also request the key from other network elements/devices.
  • UE accesses a non-3GPP network.
  • the UE sends a request message to the UPF on a non-3GPP access, the request message including MAC#2.
  • Step 1011 is similar to step 810, except that in step 810 the request message carries the second feature information, while in step 1011 the request message carries MAC#2.
  • the UPF when the UPF receives a request message from the UE, it extracts MAC#2 and verifies it. If the verification passes, as an example, a response message can be sent to the UE, i.e., step 1013; if the verification fails, the UE's request can be directly rejected.
  • the UPF calculates MAC#1 based on the key stored in step 1006 for at least one of the following: the UE's identifier, the session identifier (such as the PDU session ID), the UE's IP address, and the UPF's public IP address. If the MAC#1 calculated by the UPF matches (i.e., is consistent) with the MAC#2 in the request message, the verification passes; otherwise, the verification fails. It can be understood that the rules for the UPF to calculate MAC#1 are the same as the rules for the UE to calculate MAC#2 in step 1009.
  • UPF sends a response message to UE.
  • Step 1013 is similar to step 812, and will not be described in detail here.
  • the UPF can determine the key used to verify the MAC provided by the UE.
  • the UE sends a message on a non-3GPP access, it can carry the MAC.
  • the UPF can verify the MAC provided by the UE based on the key, thereby reducing the risk of the UPF being attacked after its public IP address is leaked.
  • This scheme is applicable to the following scenarios: ATSSS-lite scenarios, where a UE simultaneously uses a 3GPP access network and a non-3GPP access network; boundary nodes (such as TNGF or N3IWF) are no longer used on the non-3GPP access network; the user plane on the non-3GPP access network can be established through the control plane of the 3GPP access network.
  • boundary nodes such as TNGF or N3IWF
  • the 3GPP connection sends the UPF's IP address (such as the UPF's internal or public IP address) to the UE so that the UE and UPF can communicate on the Nx interface subsequently.
  • network element #A After receiving a message (such as data) from the UE, network element #A first verifies the UE's message. If the verification passes, the UE's message is sent to the UPF; if the verification fails, the UE's message is ignored or discarded.
  • the specific implementation is explained in detail in Figures 11 and 12 below.
  • Figure 11 is a schematic diagram of a communication method 1100 provided in an embodiment of this application.
  • the method 1100 shown in Figure 11 may include the following steps.
  • Network element #A receives data packets sent by the terminal on a non-3GPP access, and the destination address of the data packets is the IP address of the user plane network element.
  • network element #A receives data packets sent by the terminal through a non-3GPP access point.
  • network element #A can be used to verify non-3GPP access points.
  • network element #A represents the network element used to verify non-3GPP access points.
  • network element #A is a security network element preceding the user plane network element. If network element #A successfully verifies a non-3GPP access point, it can also determine that the terminal accessing through that non-3GPP access point is legitimate (or of low risk). If network element #A fails to verify a non-3GPP access point, it can also determine that the terminal accessing through that non-3GPP access point is not legitimate (or of high risk). Therefore, network element #A's verification of non-3GPP access points can also be understood as: network element #A verifies the terminal accessing through that non-3GPP access point. The specific method by which network element #A verifies non-3GPP access points will be explained in detail later in conjunction with step 1120.
  • network element #A can also be called a gateway, an intermediate gateway (or intermediate network element), a security network element (or security gateway), or an ATSSS-lite gateway (or ATSSS-lite network element), etc. Any name that can achieve the above functions is applicable to the embodiments of this application.
  • the specific form of network element #A is not limited.
  • network element #A can be a NEF or an ATSSS-lite gateway, etc.
  • network element #A can be a standalone device or integrated into the same device to implement different functions. This application does not limit the specific form of the aforementioned network element #A.
  • network element #A can be a physical entity in a hardware device, a software instance running on dedicated hardware, or a virtualized function instantiated on a shared platform (e.g., a cloud platform).
  • network element #A can be deployed between the UE and user plane network elements; or, network element #A can be deployed between user plane network elements and non-3GPP access points. Taking the deployment of network element #A between the UE and user plane network elements as an example, this means that when the terminal sends data packets through a non-3GPP access point, the data packets first pass through network element #A and then through user plane network elements. Whether there are other network elements between network element #A and user plane network elements, or between the non-3GPP access point and the terminal, is not limited.
  • the IP address of the user plane network element includes at least one of the following: the internal IP address of the user plane network element, the public IP address of the user plane network element, and the fully qualified domain name (FQDN) of the user plane network element.
  • FQDN fully qualified domain name
  • the IP address of the UPF can be either the IP address of the UPF or an IP address prefix.
  • the IP address of the UPF will be used as an example here.
  • method 1100 further includes: during the process of establishing a session for the terminal on 3GPP access, the user plane network element sends the IP address of the user plane network element to the terminal, the IP address of the user plane network element being the same as the IP address of the user plane network element in step 1110.
  • Network element #A verifies non-3GPP access point.
  • step 1110 the terminal sends a data packet through a non-3GPP access point, and correspondingly, network element #A receives the data packet; before processing the data packet, network element #A first verifies the non-3GPP access point.
  • network element #A determines that the non-3GPP access point is a legitimate access point (such as a legitimate WLAN node), and the verification passes; otherwise, the verification fails.
  • network element #A stores a whitelist. If a non-3GPP access point belongs to a node in the whitelist, then network element #A determines that the non-3GPP access point is a legitimate access point (such as a legitimate WLAN node), and the verification passes; otherwise, the verification fails.
  • a legitimate access point such as a legitimate WLAN node
  • network element #A stores a blacklist. If a non-3GPP access point is not a node in the blacklist, then network element #A determines that the non-3GPP access point is a legitimate access point (such as a legitimate WLAN node), and the verification passes; otherwise, the verification fails.
  • a legitimate access point such as a legitimate WLAN node
  • data packets are sent to the user plane network element based on the IP address of the user plane network element.
  • method 1100 further includes: storing (or pre-configuring) the address of network element #A in a non-3GPP access point.
  • Figure 12 is a schematic diagram of a communication method 1200 provided in an embodiment of this application. Method 1200 can be used to implement method 1100. The method 1200 shown in Figure 12 may include the following steps.
  • IP address of network element #A is pre-configured (or stored) on a non-3GPP access point.
  • network element #A is a NEF or ATSSS-lite gateway.
  • the UE and the network side perform the 3GPP registration process.
  • the UE sends a NAS message to the AMF, which carries a session establishment request.
  • AMF sends a Session Context Establishment Request message to SMF.
  • SMF queries UDM for subscription data, selects PCF, and obtains policy information.
  • SMF sends an N4 session establishment request message to UPF and establishes an N4 session.
  • UPF sends its IP address to SMF.
  • the UPF IP address is either the UPF's internal IP address or its FQDN.
  • the UPF's internal IP address can be the complete information of the UPF's internal IP address, or it can be a prefix of the UPF's internal IP address; there is no limitation in this regard.
  • the following description uses the UPF's internal IP address; it can be understood that the UPF's internal IP address can be replaced with any prefix of the UPF's internal IP address.
  • the UPF IP address can be included in the N4 session establishment response message.
  • the UPF IP address can also be carried in other signaling messages, without limitation.
  • the UPF IP address can also be carried in messages such as N4 session modification with PFCP or Nupf_event exposure subscribe request.
  • the UE registers on the 3GPP access and performs the PDU session establishment process corresponding to ATSSS-lite.
  • the UPF can provide the UPF's internal IP address or FQDN to reduce the risk of the UPF IP address being leaked.
  • SMF sends UPF IP address to UE.
  • the UPF IP address can be, for example, the UPF's internal IP address or FQDN.
  • the SMF can send the public IP address of the UPF to the UE through the AMF and RAN.
  • UE accesses a non-3GPP network.
  • the UE sends a request message to network element #A on a non-3GPP access, and the request message includes the UPF IP address.
  • the request message includes the UPF IP address, which can be the UPF's internal IP address or FQDN.
  • the request message can be any of the following: an IPSec request message, a TLS request message, a QUIC request message, or an MPQUIC request message.
  • Network element #A verifies non-3GPP access point.
  • network element #A After receiving a request message from the UE through a non-3GPP access point, network element #A verifies the non-3GPP access point. If the verification is successful, the UPF can be determined based on the UPF IP address carried in the request message, and then a request message can be sent to that UPF, i.e., step 1212; if the verification fails, the UE's request can be directly rejected.
  • network element #A determines that the non-3GPP access point is a legitimate access point (such as a legitimate WLAN node), and the verification passes; otherwise, the verification fails.
  • network element #A stores a whitelist. If a non-3GPP access point belongs to a node in the whitelist, then network element #A determines that the non-3GPP access point is a legitimate access point (such as a legitimate WLAN node), and the verification passes; otherwise, the verification fails.
  • a legitimate access point such as a legitimate WLAN node
  • network element #A stores a blacklist. If a non-3GPP access point is not a node in the blacklist, then network element #A determines that the non-3GPP access point is a legitimate access point (such as a legitimate WLAN node), and the verification passes; otherwise, the verification fails.
  • a legitimate access point such as a legitimate WLAN node
  • Network element #A sends a request message to UPF.
  • UPF sends a response message to UE.
  • the UPF can send a response message to the UE via the NEF or network element #A.
  • the UPF sends its public IP address to the UE.
  • the response message in step 1213 includes the UPF's public IP address.
  • method 1200 further includes: the UE sending indication information to a non-3GPP access point, the indication information indicating that communication between the UE and the UPF will no longer be forwarded to network element #A for processing.
  • FIG. 13 is a schematic diagram of a communication device 1300 provided in an embodiment of this application.
  • the communication device 1300 includes a transceiver unit 1310 and a processing unit 1320.
  • the transceiver unit 1310 can be used to implement corresponding communication functions.
  • the transceiver unit 1310 can also be referred to as a communication interface or a communication unit.
  • the processing unit 1320 can be used to perform processing, such as verifying data packets.
  • the device 1300 may further include a storage unit for storing instructions and/or data, and the processing unit 1320 may read the instructions and/or data from the storage unit to enable the device to implement the aforementioned method embodiments.
  • the device 1300 can be a user plane network element as described in the preceding embodiments.
  • This device 1300 can implement the steps or processes performed by the user plane network element corresponding to those described in the above method embodiments.
  • the transceiver unit 1310 can be used to perform transceiver-related operations (such as sending and/or receiving data or messages) of the user plane network element in the above method embodiments
  • the processing unit 1320 can be used to perform processing-related operations of the user plane network element in the above method embodiments, or operations other than transceiver operations (such as operations other than sending and/or receiving data or messages).
  • processing unit 1320 is used to obtain the terminal's first information during the process of establishing a session for the terminal on 3GPP access; transceiver unit 1310 is used to send the public IP address of the user plane network element to the terminal during the process; transceiver unit 1310 is also used to receive data packets sent by the terminal through non-3GPP access and the terminal's second information, wherein the destination address of the data packets is the public IP address of the user plane network element; processing unit 1320 is also used to verify the data packets based on the terminal's first information and the terminal's second information.
  • the terminal's first information includes at least one of the following: the terminal's identifier, the session identifier, the terminal's IP address on non-3GPP access, the terminal's IP address on 3GPP access, and the public IP address of the user plane network element.
  • the first information of the terminal includes the terminal's identifier and/or the session's identifier, and the transceiver unit 1310 is also used to receive the terminal's identifier and/or the session's identifier.
  • the transceiver unit 1310 is also used to send the terminal's IP address on a non-3GPP access and/or the terminal's IP address on a 3GPP access to the terminal.
  • the processing unit 1320 is used to store the first information of the terminal.
  • the processing unit 1320 is specifically used to store the terminal's first information based on the indication information, wherein the indication information indicates that the session is a simplified access traffic redirection, switching, and splitting session in the ATSSS-lite scenario.
  • the first piece of information is a token.
  • the transceiver unit 1310 is also used to send a token to the terminal during the process.
  • the token includes a digital signature, which may be a digital signature of a user plane network element or a digital signature of a core network element other than a user plane network element; or, the token includes a message authentication code, which may be a message authentication code generated by a user plane network element or a message authentication code generated by a core network element other than a user plane network element.
  • the transceiver unit 1310 is also used to receive the token issued by the core network element and/or the relevant information required for verifying the token.
  • the processing unit 1320 is specifically used to generate a token for the terminal or to receive a token.
  • the token is a random number; or, the token is determined based on at least one of the following: the identifier of the terminal, the identifier of the session, the IP address of the terminal on a non-3GPP access, the IP address of the terminal on a 3GPP access, or the public IP address of the user plane network element.
  • the first information is information that can be used to verify the message authentication code generated by the terminal.
  • the message authentication code is determined based on a key and at least one of the following: the terminal identifier, the session identifier, the terminal's IP address on a non-3GPP access, the terminal's IP address on a 3GPP access, and the public IP address of the user plane network element.
  • the transceiver unit 1310 is also configured to send request information based on indication information, wherein the indication information indicates that the session is a session under the ATSSS-lite scenario, and the request information is used to request a key.
  • the transceiver unit 1310 is specifically used to send the public IP address of the user plane network element based on the indication information, wherein the indication information indicates that the session is a session under the ATSSS-lite scenario.
  • the transceiver unit 1310 is also used to receive instruction information during the process.
  • the processing unit 1320 is specifically used to verify the data packet based on the first information and the second information of the terminal within the valid time corresponding to the first information of the terminal.
  • the device 1300 can be the terminal described in the foregoing embodiments.
  • the device 1300 can implement the steps or processes executed by the terminal corresponding to those described in the above method embodiments.
  • the transceiver unit 1310 can be used to perform transceiver-related operations (such as sending and/or receiving data or messages) of the terminal in the above method embodiments
  • the processing unit 1320 can be used to perform processing-related operations of the terminal in the above method embodiments, or operations other than transceiver operations (such as operations other than sending and/or receiving data or messages).
  • the transceiver unit 1310 is used to receive the public IP address of the user plane network element during the process of establishing a session for the terminal on the 3GPP access; the transceiver unit 1310 is also used to send data packets and the terminal's second information through non-3GPP access, the destination address of the data packets being the public IP address of the user plane network element, and the terminal's second information being used to verify the data packets.
  • the second information of the terminal includes at least one of the following: the terminal's identifier, the session identifier, the terminal's IP address on non-3GPP access, the terminal's IP address on 3GPP access, and the public IP address of the user plane network element.
  • the second information of the terminal is a token
  • the transceiver unit 1310 is also used to receive the token during the process.
  • the token includes a digital signature, which may be a digital signature of a user plane network element or a digital signature of a core network element other than a user plane network element; or, the token includes a message authentication code, which may be a message authentication code generated by a user plane network element or a message authentication code generated by a core network element other than a user plane network element.
  • the token is a random number; or, the token is determined based on at least one of the following: the identifier of the terminal, the identifier of the session, the IP address of the terminal on a non-3GPP access, the IP address of the terminal on a 3GPP access, or the public IP address of the user plane network element.
  • the second information of the terminal is a message authentication code generated by the terminal.
  • the processing unit 1320 is used to determine the message authentication code based on the key and at least one of the following: the terminal identifier, the session identifier, the terminal's IP address on non-3GPP access, the terminal's IP address on 3GPP access, and the public IP address of the user plane network element.
  • the processing unit 1320 is specifically used to determine the message authentication code based on the public IP address of the user plane network element; or, based on the indication information, determine the message authentication code, wherein the indication information indicates that the session is a simplified access traffic redirection, switching, and splitting session in the ATSSS-lite scenario.
  • the transceiver unit 1310 is also configured to receive, during the process, the IP address of the terminal on a non-3GPP access and/or the IP address of the terminal on a 3GPP access.
  • the transceiver unit 1310 is further configured to, before receiving the public IP address of the user plane network element, further include: sending indication information, the indication information indicating that the session is a session under the ATSSS-lite scenario.
  • the device 1300 can be the session management network element in the aforementioned embodiments.
  • This device 1300 can implement the steps or processes corresponding to those executed by the session management network element in the above method embodiments.
  • the transceiver unit 1310 can be used to perform transceiver-related operations (such as sending and/or receiving data or messages) of the session management network element in the above method embodiments
  • the processing unit 1320 can be used to perform processing-related operations of the session management network element in the above method embodiments, or operations other than transceiver operations (such as operations other than sending and/or receiving data or messages).
  • the transceiver unit 1310 is used to receive a session establishment message from the terminal during the process of establishing a session for the terminal on the 3GPP access.
  • the transceiver unit 1310 is also used to send at least one of the following to the user plane network element based on the session establishment message: indication information, terminal identifier, and session identifier, wherein the indication information indicates that the session is a session under the simplified access traffic redirection, switching, and splitting ATSSS-lite scenario.
  • the terminal identifier may be any of the following: a general public user identifier, a network access identifier, a user-hidden identifier, or a globally unique temporary identifier.
  • the transceiver unit 1310 is specifically used to send at least one of the following to the user plane network element based on the indication information: indication information, terminal identifier, and session identifier.
  • the device 1300 here is embodied in the form of a functional unit.
  • the term "unit” here can refer to an application-specific integrated circuit (ASIC), electronic circuitry, a processor (e.g., a shared processor, a proprietary processor, or a group processor, etc.) and memory for executing one or more software or firmware programs, integrated logic circuitry, and/or other suitable components supporting the described functions.
  • ASIC application-specific integrated circuit
  • the device 1300 can be specifically the communication device in the above embodiments, and can be used to execute the various processes and/or steps corresponding to the communication device in the above method embodiments; to avoid repetition, these will not be described again here.
  • the apparatus 1300 of each of the above-described schemes has the function of implementing the corresponding steps performed by the communication device (such as a terminal or a network device) in the above-described methods.
  • the function can be implemented in hardware or by hardware executing corresponding software.
  • the hardware or software includes one or more modules corresponding to the above functions; for example, the transceiver unit can be replaced by a transceiver (e.g., the transmitting unit in the transceiver unit can be replaced by a transmitter, and the receiving unit in the transceiver unit can be replaced by a receiver), and other units, such as processing units, can be replaced by a processor, respectively executing the transceiver operations and related processing operations in each method embodiment.
  • the transceiver unit 1310 may also be a transceiver circuit (for example, it may include a receiving circuit and a transmitting circuit), and the processing unit may be a processing circuit.
  • the device in Figure 13 can be the communication device (such as a terminal or a network-side device) in the aforementioned embodiments, or it can be a chip or a chip system, such as a system-on-chip (SoC).
  • the transceiver unit can be an input/output circuit or a communication interface; the processing unit is a processor, microprocessor, or integrated circuit integrated on the chip. No limitations are imposed here.
  • Figure 14 is a schematic diagram of another communication device 1400 provided in an embodiment of this application.
  • the device 1400 includes a processor 1410, which is coupled to a memory 1420.
  • the memory 1420 is used to store computer programs or instructions and/or data.
  • the processor 1410 is used to execute the computer programs or instructions stored in the memory 1420, or to read the data stored in the memory 1420, to perform the methods in the above method embodiments.
  • processors 1410 there may be one or more processors 1410.
  • the memory 1420 may be one or more.
  • the memory 1420 can be integrated with the processor 1410, or it can be set separately.
  • the device 1400 further includes a transceiver 1430 for receiving and/or transmitting signals.
  • a processor 1410 is used to control the transceiver 1430 to receive and/or transmit signals.
  • processor 1410 may have the functions of processing unit 1320 shown in FIG13
  • memory 1420 may have the functions of storage unit
  • transceiver 1430 may have the functions of transceiver unit 1310 shown in FIG13.
  • the device 1400 is used to implement the operations performed by the communication device (such as a terminal or a network-side device) in the various method embodiments described above.
  • the communication device such as a terminal or a network-side device
  • processor 1410 is used to execute computer programs or instructions stored in memory 1420 to implement the relevant operations of the communication device in the various method embodiments described above.
  • processors mentioned in the embodiments of this application can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc.
  • DSPs digital signal processors
  • ASICs application-specific integrated circuits
  • FPGAs field-programmable gate arrays
  • a general-purpose processor can be a microprocessor or any conventional processor.
  • Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory.
  • Volatile memory can be random access memory (RAM).
  • RAM can be used as an external cache.
  • RAM includes the following forms: static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (SLDRAM), and direct rambus RAM (DR RAM).
  • SRAM static random access memory
  • DRAM dynamic random access memory
  • SDRAM synchronous dynamic random access memory
  • DDR SDRAM double data rate synchronous dynamic random access memory
  • ESDRAM enhanced synchronous dynamic random access memory
  • SLDRAM synchronous linked dynamic random access memory
  • DR RAM direct rambus RAM
  • the processor is a general-purpose processor, DSP, ASIC, FPGA, or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component
  • the memory storage module
  • memory described herein is intended to include, but is not limited to, these and any other suitable types of memory.
  • Figure 15 is a schematic diagram of a chip system 1500 provided in an embodiment of this application.
  • the chip system 1500 (or may also be referred to as a processing system) includes logic circuitry 1510 and an input/output interface 1520.
  • the logic circuit 1510 can be a processing circuit in the chip system 1500.
  • the logic circuit 1510 can be coupled to a memory unit, calling instructions from the memory unit, enabling the chip system 1500 to implement the methods and functions of the embodiments of this application.
  • the input/output interface 1520 can be an input/output circuit in the chip system 1500, outputting processed information from the chip system 1500, or inputting data or signaling information to be processed into the chip system 1500 for processing.
  • the chip system 1500 is used to implement the operations performed by the communication device (such as a terminal device, a user plane network element, or a session management network element) in the various method embodiments described above.
  • the communication device such as a terminal device, a user plane network element, or a session management network element
  • logic circuit 1510 is used to implement processing-related operations performed by communication devices (such as terminal devices, user plane network elements, or session management network elements) in the above method embodiments;
  • input/output interface 1520 is used to implement sending and/or receiving-related operations performed by communication devices (such as terminal devices, user plane network elements, or session management network elements) in the above method embodiments.
  • This application also provides a computer-readable storage medium storing a computer program or instructions for implementing the methods executed by a communication device (such as a terminal device, a user plane network element, or a session management network element) in the above-described method embodiments.
  • a communication device such as a terminal device, a user plane network element, or a session management network element
  • a computer program or instruction when run on a communication device, it causes the communication device (such as a terminal device, a user plane network element, or a session management network element) to perform the above-mentioned methods (such as method 600, method 800-method 1200).
  • the communication device such as a terminal device, a user plane network element, or a session management network element
  • This application also provides a computer program product comprising instructions which, when executed by a computer, implement the methods described above as being executed by a communication device (such as a terminal device, a user plane network element, or a session management network element).
  • a communication device such as a terminal device, a user plane network element, or a session management network element.
  • a computer program or instruction when run on a communication device, it causes the communication device (such as a terminal device, a user plane network element, or a session management network element) to execute the above methods (such as method 600, method 800-method 1200).
  • the communication device such as a terminal device, a user plane network element, or a session management network element
  • This application also provides a communication system that includes user plane network elements and session management network elements from the embodiments described above.
  • the system includes the user plane network elements and session management network elements from the embodiment of FIG6.
  • Another example is the UPF and SMF shown in FIG8-10.
  • the communication system may also include other devices or network elements, such as terminal devices or other core network elements.
  • This application also provides a communication system that includes network element #A and user plane network elements as described in the above embodiments.
  • the system includes network element #A and user plane network elements as described in the embodiment of FIG11.
  • Another example is the UPF and network element #A in FIG12.
  • the communication system may also include other devices or network elements, such as terminal devices or other core network elements.
  • the disclosed apparatus and methods can be implemented in other ways.
  • the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods.
  • multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.
  • the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, and the indirect coupling or communication connection of apparatus or units may be electrical, mechanical, or other forms.
  • implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof.
  • software When implemented using software, it can be implemented entirely or partially in the form of a computer program product.
  • the computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated.
  • the computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device.
  • the computer can be a personal computer, a server, or a network device, etc.
  • the computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another.
  • the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means.
  • the computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media.
  • the available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).
  • the aforementioned available media include, but are not limited to, USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks, and other media capable of storing program code.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La présente demande concerne un procédé de communication et un appareil de communication. Le procédé comprend les étapes suivantes : sur un accès 3GPP, acquisition de premières informations d'un terminal pendant le processus d'établissement d'une session pour le terminal ; pendant le processus, envoi d'une adresse IP publique d'un élément de réseau de plan d'utilisateur au terminal ; réception d'un paquet de données envoyé par le terminal au moyen d'un accès non-3GPP et de secondes informations du terminal, l'adresse de destination du paquet de données étant l'adresse IP publique de l'élément de réseau de plan d'utilisateur ; et vérification du paquet de données sur la base des premières informations du terminal et des secondes informations du terminal. De cette manière, lors de l'accès à l'élément de réseau de plan d'utilisateur au moyen d'un accès non-3GPP, le terminal peut envoyer un message à l'élément de réseau de plan d'utilisateur sur la base de l'adresse IP publique de l'élément de réseau de plan d'utilisateur, de sorte qu'un plan d'utilisateur non-3GPP soit établi entre le terminal et l'élément de réseau de plan d'utilisateur. De plus, lorsque le terminal envoie un paquet de données à l'élément de réseau de plan d'utilisateur, les secondes informations du terminal sont portées dans le paquet de données, de sorte que l'élément de réseau de plan d'utilisateur puisse vérifier le paquet de données sur la base des premières informations et des secondes informations, ce qui permet de réduire le risque d'attaques suite à l'exposition de l'adresse IP publique de l'élément de réseau de plan d'utilisateur.
PCT/CN2025/093159 2024-05-11 2025-05-07 Procédé de communication et appareil de communication Pending WO2025237131A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202410600739.X 2024-05-11
CN202410600739.XA CN120935572A (zh) 2024-05-11 2024-05-11 通信方法和通信装置

Publications (1)

Publication Number Publication Date
WO2025237131A1 true WO2025237131A1 (fr) 2025-11-20

Family

ID=97591706

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2025/093159 Pending WO2025237131A1 (fr) 2024-05-11 2025-05-07 Procédé de communication et appareil de communication

Country Status (2)

Country Link
CN (1) CN120935572A (fr)
WO (1) WO2025237131A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109996346A (zh) * 2017-12-29 2019-07-09 华为技术有限公司 会话建立方法、设备及系统
WO2021134601A1 (fr) * 2019-12-31 2021-07-08 华为技术有限公司 Procédé et appareil permettant d'établir une session
CN113709904A (zh) * 2020-05-22 2021-11-26 华为技术有限公司 连接建立的方法、装置和系统
CN114726829A (zh) * 2022-04-02 2022-07-08 中国电信股份有限公司 通信方法、用户面网关及通信系统
CN117278534A (zh) * 2023-10-30 2023-12-22 中国电信股份有限公司技术创新中心 实现ims会话的方法、层三中继终端、通信系统和存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109996346A (zh) * 2017-12-29 2019-07-09 华为技术有限公司 会话建立方法、设备及系统
WO2021134601A1 (fr) * 2019-12-31 2021-07-08 华为技术有限公司 Procédé et appareil permettant d'établir une session
CN113709904A (zh) * 2020-05-22 2021-11-26 华为技术有限公司 连接建立的方法、装置和系统
CN114726829A (zh) * 2022-04-02 2022-07-08 中国电信股份有限公司 通信方法、用户面网关及通信系统
CN117278534A (zh) * 2023-10-30 2023-12-22 中国电信股份有限公司技术创新中心 实现ims会话的方法、层三中继终端、通信系统和存储介质

Also Published As

Publication number Publication date
CN120935572A (zh) 2025-11-11

Similar Documents

Publication Publication Date Title
US20240373385A1 (en) Apparatus, system, method, and computer-readable medium for performing service delivery for multi-user mobile terminals
KR102320063B1 (ko) 서비스 슬라이스 선택 및 분리를 위한 방법
JP7535067B2 (ja) マルチユーザモバイル端末のためのサービス配信を実行するための装置、システム、方法、およびコンピュータ可読媒体
US11848909B2 (en) Restricting onboard traffic
EP4406335A1 (fr) Utilisation d'un canal d'accès aléatoire physique (prach) pour identifier de multiples caractéristiques et combinaisons de caractéristiques
CN114339688A (zh) 用于ue与边缘数据网络的认证的装置和方法
JP2022544374A (ja) 複数のｕｓｉｍを有するｗｔｒｕの登録及びセキュリティ強化
WO2023018778A1 (fr) Support de service informatique de réseau d'accès radio à unités distribuées
US20250071190A1 (en) Microservice communication and computing offloading via service mesh
WO2020217224A1 (fr) Comportement amf et scp dans la découverte déléguée de pcf
US20230232468A1 (en) Session establishment method and apparatus
CN113766502A (zh) 用在ue、smf实体、以及预配置服务器中的装置
EP4201004A1 (fr) Identification d'un ue à l'aide de son adresse ip source
JP2025507445A (ja) ポリシー制御機能（ｐｃｆ）の方法及びｐｃｆ
US20240236183A1 (en) Remote direct memory access (rdma) support in cellular networks
US20230017260A1 (en) Access control method and communications device
KR20240163129A (ko) Acr 선택 및 조정
WO2025237131A1 (fr) Procédé de communication et appareil de communication
CN118525541A (zh) 用户设备（ue）和第六代（6g）网络之间基于6g相互传输层安全性（mtls）的安全性体系结构
US20240205813A1 (en) Method and apparatus to access core networks via gateway functions
CN118972078A (zh) 一种通信方法和通信装置
WO2024069616A1 (fr) Support d'accès à un équipement utilisateur (ue) pour un réseau non public autonome (snpn)
WO2023192832A1 (fr) Chaînage de fonctions de service dans un système cellulaire sans fil avec exposition de service à des tiers
WO2024105650A1 (fr) Fourniture d'informations concernant la fourniture de serveurs à un équipement utilisateur (ue) pendant des procédures d'intégration
WO2025076079A1 (fr) Mécanisme d'identification de trafic de dispositifs derrière une passerelle résidentielle (rg)