Communication method and related device

Abstract

A communication method and a related device. The method comprises: a first SEPP sends a protected first HTTP message to IPX, the protected first HTTP message being determined after a first HTTP message has been protected on the basis of first N32-f context; and the first SEPP executes a corresponding error response operation on the basis of a transmission error indicated by first indication information sent by the IPX, wherein the error response operation, for example, comprises: the first SEPP and a second SEPP exchange parameters again to obtain second N32-f context, and after the first HTTP message has been protected on the basis of the second N32-f context, the first SEEP sends a re-protected first HTTP message to the IPX, or, the first SEPP modifies the first HTTP message to obtain a second HTTP message, and after the second HTTP message has been protected on the basis of the first N32-f context, the first SEPP sends the protected second HTTP message to the IPX. By using the present application, normal communication can be maintained.

Description

Communication method and related device

[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on September 4, 2023, with application number 202311138963.3 and application name “Communication Methods and Related Devices”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of communication technology, and in particular to a communication method and related devices. Background Art

[0003] Currently, in a roaming architecture, a consumer SEPP (cSEPP) in a visited public land mobile network (vPLMN) can send a roaming message to a consumer IPX (cIPX). The cIPX then sends the roaming message to a producer IPX (pIPX). Finally, the pIPX sends the roaming message to a producer SEPP (pSEPP) in a home PLMN (hPLMN), thereby enabling roaming message delivery between different PLMNs.

[0004] Currently, SEPPs can detect errors during roaming message delivery and generate error messages to the peer SEPP. With the expansion of IPX functionality, IPX may also detect errors and generate error messages. However, the relevant standards do not currently define a response mechanism for IPX error messages, resulting in communication problems between SEPPs in different PLMNs.

[0005] Summary of the Invention

[0006] The present application provides a communication method and related devices, which are conducive to maintaining normal communication.

[0007] In a first aspect, the present application provides a communication method performed by a first SEPP, which may be the first SEPP itself or a unit or module (e.g., a chip) within the first SEPP with corresponding functions. In this method, the first SEPP uses a first N32-f context between the first SEPP and a second SEPP to securely protect a first Hypertext Transfer Protocol (HTTP) message, obtaining a protected first HTTP message, wherein the first HTTP message is used to implement a roaming service between the first SEPP and the second SEPP; the first SEPP sends the protected first HTTP message to an Internet Protocol exchange (IPX), wherein the IPX is used to route messages sent from the first SEPP to the second SEPP; the first SEPP receives first indication information from the IPX, indicating a transmission error in the first HTTP message; and the first SEPP performs an error response operation corresponding to the transmission error.

[0008] In one possible design, the error response operation includes any one of the following:

[0009] The first SEPP and the second SEPP re-exchange parameters to obtain a second N32-f context between the first SEPP and the second SEPP; the first SEPP uses the second N32-f context to securely protect the first HTTP message to obtain a re-protected first HTTP message; the first SEPP sends the re-protected first HTTP message to the IPX; or

[0010] The first SEPP modifies the first HTTP message according to the first indication information to obtain a second HTTP message; the first SEPP uses the first N32-f context to perform security protection on the second HTTP message to obtain a protected second HTTP message; and the first SEPP sends the protected second HTTP message to the IPX.

[0011] In this application, IPX can be cIPX or pIPX, without limitation. It should be understood that this application defines how a SEPP responds after receiving a first indication message from an IPX indicating a transmission error, which is beneficial for maintaining normal communication between SEPPs in different PLMNs.

[0012] In one possible design, the first indication information indicating a transmission error occurring in the first HTTP message includes:

[0013] The first indication information indicates that the IPX requires that the unencrypted first information element IE be encrypted in the first HTTP message; or,

[0014] The first indication information indicates that the second IE requiring encryption by the IPX is not encrypted in the first HTTP message.

[0015] This implementation proposes two new error types: ① IPX determines whether the first IE in the protected first HTTP message is encrypted. If the first IE is encrypted (i.e., IPX determines that the IE that should have been transmitted in plaintext is encrypted), IPX sends a first indication message to the first SEPP, indicating that IPX requires the unencrypted first IE to be encrypted in the protected first HTTP message. ② IPX determines whether the second IE in the protected first HTTP message is encrypted. If the second IE is not encrypted (i.e., IPX determines that the IE that should have been transmitted in plaintext is transmitted), IPX sends a first indication message to the first SEPP, indicating that IPX requires the encrypted second IE to be unencrypted in the protected first HTTP message. For error type ①, the first SEPP can transmit the first IE in the first HTTP message in plaintext to resolve the transmission error caused by this error type. For error type ②, the first SEPP can transmit the second IE in the first HTTP message in encrypted form to resolve the transmission error caused by this error type.

[0016] In one possible design, the encryption policy for the first IE in the first N32-f context is to encrypt the first IE, and the encryption policy for the first IE in the second N32-f context is not to encrypt the first IE; or,

[0017] The encryption policy for the second IE in the first N32-f context is not to encrypt the second IE, and the encryption policy for the second IE in the second N32-f context is to encrypt the second IE.

[0018] In one possible design, the first SEPP and the second SEPP re-exchanging parameters to obtain a second N32-f context between the first SEPP and the second SEPP includes:

[0019] The first SEPP sends a parameter exchange request to the second SEPP, where the encryption policy for the first IE included in the parameter exchange request is not to encrypt the first IE;

[0020] The first SEPP receives a parameter exchange response from the second SEPP, where the encryption policy for the first IE included in the parameter exchange response is not to encrypt the first IE; or

[0021] The first SEPP sends a parameter exchange request to the second SEPP, where the encryption policy for the second IE included in the parameter exchange request is to encrypt the second IE;

[0022] The first SEPP receives a parameter exchange response from the second SEPP, where the encryption policy for the second IE included in the parameter exchange response is to encrypt the second IE.

[0023] In one possible design, the first indication information indicating a transmission error occurring in the first HTTP message includes:

[0024] When the protected first HTTP message includes a plain text identifier of a first network function NF, the first indication information indicates that a network topology of a public land mobile network PLMN where the first SEPP is located is not hidden, and the first NF is a network element requesting the roaming service.

[0025] This implementation addresses a new error type: the network topology of the PLMN where the first SEPP resides is not hidden. To address this error type, the first SEPP can convert the plaintext identifier of the first NF in the first HTTP message into its anonymous identifier. The plaintext identifier of the first NF in the first HTTP message is then replaced with the anonymous identifier, resulting in a second HTTP message. The inclusion of the anonymous identifier in the second HTTP message conceals the network topology of the PLMN where the first SEPP resides, thus meeting the IPX transmission requirements and enabling the IPX to correctly route the second HTTP message.

[0026] In one possible design, the first SEPP modifies the first HTTP message according to the first indication information to obtain a second HTTP message, including:

[0027] Anonymizing the plaintext identifier of the first NF in the first HTTP message to obtain an anonymous identifier of the first NF;

[0028] The plain text identifier of the first NF in the first HTTP message is replaced with the anonymous identifier of the first NF to obtain the second HTTP message.

[0029] In one possible design, the first indication information indicating a transmission error occurring in the first HTTP message includes:

[0030] The first indication information indicates that the message format of the first HTTP message is not a first format.

[0031] This implementation addresses a new error type: the first HTTP message format is not in the first format. Here, the first format can be a preset format, such as JSON. For this error type, the first SEPP can convert the first HTTP message format to the first format to generate a second HTTP message. This satisfies the IPX requirement for transmitting messages in the first format, allowing the IPX to subsequently correctly route the second HTTP message.

[0032] In one possible design, the first SEPP modifies the first HTTP message according to the first indication information to obtain a second HTTP message, including:

[0033] The first SEPP converts the message format of the first HTTP message into the first format to obtain the second HTTP message.

[0034] In one possible design, the first SEPP receives the first indication information from the IPX, including:

[0035] The first SEPP receives a first message from the IPX, where the first message includes problem details ProblemDetails, and the ProblemDetails includes the first indication information.

[0036] In this implementation, ProblemDetails can be reused to carry the first indication information, which has strong operability.

[0037] In one possible design, the ProblemDetails also includes a first signature corresponding to the first indication information, or the first message also includes a first signature corresponding to the first indication information; the first signature is used to protect the integrity of the first indication information;

[0038] Before the first SEPP performs the error response operation corresponding to the transmission error, the method further includes:

[0039] Verifying, by the first SEPP, the integrity of the first indication information according to the first signature, and obtaining a verification result;

[0040] The first SEPP performs an error response operation corresponding to the transmission error, including:

[0041] If the verification result is passed, the first SEPP performs an error response operation corresponding to the transmission error.

[0042] In this implementation, when ProblemDetails is reused, integrity protection can also be performed on IEs in ProblemDetails that require integrity protection, such as the first indication information, which is beneficial to improving the reliability and security of communications.

[0043] In one possible design, the first SEPP receives the first indication information from the IPX, including:

[0044] The first SEPP receives a second message from the IPX, where the second message includes the first indication information and first reformatted data reformattedData;

[0045] The first indication information is obtained by parsing the first reformattedData.

[0046] In this implementation, the first reformattedData can be used to indicate that the first indication information exists in the second message, which is beneficial to improving the efficiency of parsing the second message.

[0047] In one possible design, the first reformattedData includes one or more of the following information: an N32-f context identifier n32fContextID, a message identifier messageId, or an authorized IPX identifier authorizedIpxId, wherein the n32fContextID is the identifier of the first N32-f context, the messageId is the identifier of the first HTTP message, and the authorizedIpxId is the identifier of the IPX;

[0048] The obtaining the first indication information by parsing the first reformattedData includes:

[0049] In a case where n32fContextID in the first reformattedData is the same as n32fContextID in the first HTTP message, the first SEPP parses to obtain the first indication information in the second message; or

[0050] In the case where the messageId in the first reformattedData is the same as the messageId in the first HTTP message, the first SEPP parses to obtain the first indication information in the second message; or,

[0051] When the authorizedIpxId in the first reformattedData is the same as the authorizedIpxId in the first HTTP message, the first SEPP parses to obtain the first indication information in the second message.

[0052] In one possible design, the first reformattedData does not include one or more of the following information: ciphertext, or Json payload JsonPayload, wherein the ciphertext includes information obtained by encrypting the IE that needs to be encrypted in the first HTTP message based on the encryption policy in the first N32-f context, and the JsonPayload includes the IE that needs to be integrity protected in the first HTTP message; the IE that needs to be integrity protected in the first HTTP message is determined based on the integrity protection policy in the first N32-f context;

[0053] The obtaining the first indication information by parsing the first reformattedData includes:

[0054] In the case that the first reformattedData does not include ciphertext, the first SEPP parses to obtain the first indication information in the second message; or

[0055] When the first reformattedData does not include JsonPayload, the first SEPP parses to obtain the first indication information in the second message.

[0056] In a second aspect, the present application provides a communication method performed by an IPX, which may be the IPX itself or a unit or module (e.g., a chip) within the IPX with corresponding functionality. In this method, the IPX receives a protected first Hypertext Transfer Protocol (HTTP) message from a first SEPP, where the protected first HTTP message is obtained by performing security protection on the first HTTP message based on a first N32-f context between the first SEPP and a second SEPP. The IPX sends first indication information to the first SEPP, where the first indication information indicates a transmission error in the first HTTP message. The transmission error includes one or more of the following:

[0057] The IPX requires that the unencrypted first information element IE be encrypted in the first HTTP message; or,

[0058] The second IE that the IPX requires to be encrypted is not encrypted in the first HTTP message; or

[0059] The network topology of the public land mobile network PLMN where the first SEPP is located is not hidden; or,

[0060] The message format of the first HTTP message is not the first format.

[0061] In one possible design, the IPX sends first indication information to the first SEPP, including:

[0062] The IPX determines whether the first IE in the protected first HTTP message is encrypted. If the first IE is encrypted, the IPX sends first indication information to the first SEPP, where the first indication information indicates that the IPX requires the unencrypted first IE to be encrypted in the protected first HTTP message; or

[0063] The IPX determines whether the second IE in the protected first HTTP message is encrypted. If the second IE is not encrypted, the IPX sends first indication information to the first SEPP, where the first indication information indicates that the IPX requires that the encrypted second IE is not encrypted in the protected first HTTP message; or

[0064] When the IPX determines that the protected first HTTP message includes a plain text identifier of a first network function NF, the IPX sends first indication information to the first SEPP, where the first indication information indicates that a network topology of a PLMN where the first SEPP is located is not hidden, and the first NF is a network element requesting the roaming service; or

[0065] The IPX determines whether a name of a message format in a message header of the protected first HTTP message is a first format. If the name of the message format in the message header of the protected first HTTP message is not the first format, the IPX sends first indication information to the first SEPP, where the first indication information indicates that the message format of the protected first HTTP message is not the first format.

[0066] In one possible design, the method further includes:

[0067] The IPX receives a re-protected first HTTP message from the first SEPP, where the re-protected first HTTP message is obtained by performing security protection on the first HTTP message based on a second N32-f context between the first SEPP and the second SEPP, where the second N32-f context is obtained by re-exchanging parameters between the first SEPP and the second SEPP;

[0068] The IPX sends the re-protected first HTTP message to the second SEPP.

[0069] In one possible design, the method further includes:

[0070] The IPX receives a protected second HTTP message from the first SEPP, where the protected second HTTP message is obtained by performing security protection on the second HTTP message based on the first N32-f context, and the second HTTP message is obtained by modifying the first HTTP message based on the first indication information;

[0071] The IPX sends the protected second HTTP message to the second SEPP.

[0072] In a third aspect, the present application provides a communication device, which may be the first SEPP itself, or a unit or module (e.g., a chip) in the first SEPP with corresponding functions. The communication device includes:

[0073] a processing unit, configured to securely protect a first Hypertext Transfer Protocol (HTTP) message using a first N32-f context between the first SEPP and the second SEPP, to obtain a protected first HTTP message, wherein the first HTTP message is used to implement a roaming service between the first SEPP and the second SEPP;

[0074] a transceiver unit, configured to send the protected first HTTP message to an Internet Protocol exchange service IPX, wherein the IPX is configured to route the message sent from the first SEPP to the second SEPP;

[0075] The transceiver unit is configured to receive first indication information from the IPX, where the first indication information indicates a transmission error that occurs in the first HTTP message;

[0076] The processing unit is configured to execute an error response operation corresponding to the transmission error.

[0077] In one possible design, the error response operation includes any one of the following:

[0078] The first SEPP and the second SEPP re-exchange parameters to obtain a second N32-f context between the first SEPP and the second SEPP; the first SEPP uses the second N32-f context to securely protect the first HTTP message to obtain a re-protected first HTTP message; the first SEPP sends the re-protected first HTTP message to the IPX; or

[0079] The first SEPP modifies the first HTTP message according to the first indication information to obtain a second HTTP message; the first SEPP uses the first N32-f context to perform security protection on the second HTTP message to obtain a protected second HTTP message; and the first SEPP sends the protected second HTTP message to the IPX.

[0080] In one possible design, the first indication information indicating a transmission error occurring in the first HTTP message includes:

[0081] The first indication information indicates that the IPX requires that the unencrypted first information element IE be encrypted in the first HTTP message; or,

[0082] The first indication information indicates that the second IE requiring encryption by the IPX is not encrypted in the first HTTP message.

[0083] In one possible design, the encryption policy for the first IE in the first N32-f context is to encrypt the first IE, and the encryption policy for the first IE in the second N32-f context is not to encrypt the first IE; or,

[0084] The encryption policy for the second IE in the first N32-f context is not to encrypt the second IE, and the encryption policy for the second IE in the second N32-f context is to encrypt the second IE.

[0085] In one possible design, the transceiver unit is configured to:

[0086] Sending a parameter exchange request to the second SEPP, where the encryption policy for the first IE included in the parameter exchange request is not to encrypt the first IE;

[0087] receiving a parameter exchange response from the second SEPP, wherein the encryption policy for the first IE included in the parameter exchange response is not to encrypt the first IE; or

[0088] Sending a parameter exchange request to the second SEPP, where the encryption policy for the second IE included in the parameter exchange request is to encrypt the second IE;

[0089] A parameter exchange response is received from the second SEPP, where the encryption policy for the second IE included in the parameter exchange response is to encrypt the second IE.

[0090] In one possible design, the first indication information indicating a transmission error occurring in the first HTTP message includes:

[0091] When the protected first HTTP message includes a plain text identifier of a first network function NF, the first indication information indicates that a network topology of a public land mobile network PLMN where the first SEPP is located is not hidden, and the first NF is a network element requesting the roaming service.

[0092] In one possible design, the processing unit is configured to:

[0093] Anonymizing the plaintext identifier of the first NF in the first HTTP message to obtain an anonymous identifier of the first NF;

[0094] The plain text identifier of the first NF in the first HTTP message is replaced with the anonymous identifier of the first NF to obtain the second HTTP message.

[0095] In one possible design, the first indication information indicating a transmission error occurring in the first HTTP message includes:

[0096] The first indication information indicates that the message format of the first HTTP message is not a first format.

[0097] In one possible design, the processing unit is configured to:

[0098] Convert the message format of the first HTTP message into the first format to obtain the second HTTP message.

[0099] In one possible design, the transceiver unit is configured to:

[0100] A first message is received from the IPX, where the first message includes problem details ProblemDetails, and the ProblemDetails includes the first indication information.

[0101] In one possible design, the ProblemDetails also includes a first signature corresponding to the first indication information, or the first message also includes a first signature corresponding to the first indication information; the first signature is used to protect the integrity of the first indication information;

[0102] Before executing the error response operation corresponding to the transmission error, the processing unit is configured to:

[0103] Verifying the integrity of the first indication information according to the first signature to obtain a verification result;

[0104] When executing the error response operation corresponding to the transmission error, the processing unit is configured to:

[0105] If the verification result is that the verification passes, an error response operation corresponding to the transmission error is performed.

[0106] In one possible design,

[0107] The transceiver unit is configured to receive a second message from the IPX, where the second message includes the first indication information and first reformatted data reformattedData;

[0108] The processing unit is configured to parse the first reformattedData to obtain the first indication information.

[0109] In one possible design, the first reformattedData includes one or more of the following information: an N32-f context identifier n32fContextID, a message identifier messageId, or an authorized IPX identifier authorizedIpxId, wherein the n32fContextID is the identifier of the first N32-f context, the messageId is the identifier of the first HTTP message, and the authorizedIpxId is the identifier of the IPX;

[0110] The obtaining the first indication information by parsing the first reformattedData includes:

[0111] In a case where n32fContextID in the first reformattedData is the same as n32fContextID in the first HTTP message, the first SEPP parses to obtain the first indication information in the second message; or

[0112] In the case where the messageId in the first reformattedData is the same as the messageId in the first HTTP message, the first SEPP parses to obtain the first indication information in the second message; or,

[0113] When the authorizedIpxId in the first reformattedData is the same as the authorizedIpxId in the first HTTP message, the first SEPP parses to obtain the first indication information in the second message.

[0114] In one possible design, the first reformattedData does not include one or more of the following information: ciphertext, or Json payload JsonPayload, wherein the ciphertext includes information obtained by encrypting the IE that needs to be encrypted in the first HTTP message based on the encryption policy in the first N32-f context, and the JsonPayload includes the IE that needs to be integrity protected in the first HTTP message; the IE that needs to be integrity protected in the first HTTP message is determined based on the integrity protection policy in the first N32-f context;

[0115] The obtaining the first indication information by parsing the first reformattedData includes:

[0116] In the case that the first reformattedData does not include ciphertext, the first SEPP parses to obtain the first indication information in the second message; or

[0117] When the first reformattedData does not include JsonPayload, the first SEPP parses to obtain the first indication information in the second message.

[0118] In a fourth aspect, the present application provides a communication device, which may be the IPX itself, or a unit or module (such as a chip) in the IPX with corresponding functions. The communication device includes:

[0119] a transceiver unit, configured to receive a protected first Hypertext Transfer Protocol (HTTP) message from a first SEPP, wherein the protected first HTTP message is obtained by performing security protection on the first HTTP message based on a first N32-f context between the first SEPP and a second SEPP;

[0120] The transceiver unit is configured to send first indication information to the first SEPP, where the first indication information indicates a transmission error that occurred in the first HTTP message;

[0121] The transmission error includes one or more of the following:

[0122] The IPX requires that the unencrypted first information element IE be encrypted in the first HTTP message; or,

[0123] The second IE that the IPX requires to be encrypted is not encrypted in the first HTTP message; or

[0124] The network topology of the public land mobile network PLMN where the first SEPP is located is not hidden; or,

[0125] The message format of the first HTTP message is not the first format.

[0126] In one possible design, the communication device further includes a processing unit, wherein:

[0127] the processing unit is configured to determine whether the first IE in the protected first HTTP message is encrypted, and if the first IE is encrypted, the transceiver unit is configured to send first indication information to the first SEPP, wherein the first indication information indicates that the IPX requires that the unencrypted first IE be encrypted in the protected first HTTP message; or

[0128] the processing unit is configured to determine whether the second IE in the protected first HTTP message is encrypted, and if the second IE is not encrypted, the transceiver unit is configured to send first indication information to the first SEPP, wherein the first indication information indicates that the second IE required to be encrypted by the IPX is not encrypted in the protected first HTTP message; or

[0129] When the IPX determines that the protected first HTTP message includes a plain text identifier of a first network function NF, the IPX sends first indication information to the first SEPP, where the first indication information indicates that a network topology of a PLMN where the first SEPP is located is not hidden, and the first NF is a network element requesting the roaming service; or

[0130] The processing unit is used to determine whether the name of the message format in the message header of the protected first HTTP message is the first format. If the name of the message format in the message header of the protected first HTTP message is not the first format, the transceiver unit is used to send first indication information to the first SEPP, and the first indication information indicates that the message format of the protected first HTTP message is not the first format.

[0131] In one possible design, the transceiver unit is configured to:

[0132] receiving a re-protected first HTTP message from the first SEPP, where the re-protected first HTTP message is obtained by performing security protection on the first HTTP message based on a second N32-f context between the first SEPP and the second SEPP, where the second N32-f context is obtained by re-exchanging parameters between the first SEPP and the second SEPP;

[0133] Sending the re-protected first HTTP message to the second SEPP.

[0134] In one possible design, the transceiver unit is configured to:

[0135] receiving a protected second HTTP message from the first SEPP, where the protected second HTTP message is obtained by performing security protection on the second HTTP message based on the first N32-f context, and the second HTTP message is obtained by modifying the first HTTP message based on the first indication information;

[0136] Send the protected second HTTP message to the second SEPP.

[0137] In a fifth aspect, the present application provides a communication device, which includes a processor, and the processor is used to execute a computer program so that the communication device performs the method as described in any one of the first aspect or the second aspect.

[0138] In one possible design, the communication device may be a chip that implements the method in the first aspect or the second aspect, or a device including a chip.

[0139] In one possible design, the communication device further includes a transceiver, and the processor is coupled to the transceiver.

[0140] In one possible design, the communication device further includes a memory. The processor and the memory are coupled, the memory stores a computer program, and the processor is further configured to call the computer program in the memory. Alternatively, the processor and the memory may be integrated.

[0141] In a sixth aspect, the present application provides a communication device, which includes a processor and an interface circuit, the interface circuit being used to receive signals from other communication devices outside the communication device and transmit them to the processor or send signals from the processor to other communication devices outside the communication device, and the processor being used to implement a method as described in any one of the first or second aspects through a logic circuit or executing code instructions.

[0142] In a seventh aspect, the present application provides a computer-readable storage medium, which stores a computer program or instruction. When the computer program or instruction is executed by a computer, the method as described in any one of the first aspect or the second aspect is implemented.

[0143] In an eighth aspect, the present application provides a computer program product, which, when read and executed by a computer, enables the computer to execute the method described in any one of the first aspect or the second aspect.

[0144] In a ninth aspect, the present application provides a communication system, which includes a communication device for implementing the method described in any one of the first aspects above, and a communication device for implementing the method described in any one of the second aspects above.

[0145] The beneficial effects of the third to ninth aspects can be referred to the beneficial effects of the first aspect and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0146] FIG1a is a schematic diagram of the architecture of a communication system used in an embodiment of the present application;

[0147] Figure 1b is a schematic diagram of the 5G system roaming architecture;

[0148] FIG2 a is a schematic diagram of the protection strategy negotiation process;

[0149] FIG2 b is a schematic diagram of the process of interrupting the N32 connection;

[0150] Figure 3 is a schematic diagram of PRINS;

[0151] FIG4 is a schematic diagram of the process of N32-f message transmission;

[0152] FIG5 is a schematic diagram of the format of reformattedData and modificationsBlock;

[0153] Figure 6 is a schematic diagram of the format of ProblemDetails;

[0154] FIG7 is a schematic diagram of an interaction flow of a communication method provided in an embodiment of the present application;

[0155] FIG8 is another interactive flow diagram of the communication method provided in an embodiment of the present application;

[0156] FIG9 is another interactive flow diagram of the communication method provided in an embodiment of the present application;

[0157] FIG10 is a schematic structural diagram of a possible communication device provided in an embodiment of the present application;

[0158] FIG11 is a schematic structural diagram of a possible communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0159] The specific embodiments of the present application are further described in detail below with reference to the accompanying drawings.

[0160] The terms "first" and "second" and the like in the specification, claims, and drawings of this application are used to distinguish between different objects, not to describe a particular order. Furthermore, the terms "including" and "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or elements is not limited to the listed steps or elements, but may optionally include steps or elements not listed, or may optionally include other steps or elements inherent to the process, method, product, or apparatus.

[0161] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute an independent or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0162] In this application, "at least one (item)" refers to one or more, "more than one" refers to two or more, "at least two (items)" refers to two or three and more than three, and "and / or" is used to describe the association relationship of associated objects, indicating that there can be three relationships. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.

[0163] To better understand the embodiments of the present application, the following first introduces the system architecture involved in the embodiments of the present application:

[0164] Please refer to Figure 1a, which is a schematic diagram of the architecture of the communication system used in the embodiment of the present application. As shown in Figure 1a, the communication system 1000 includes a radio access network (RAN) 100 and a core network (CN) 200. Optionally, the communication system 1000 may also include the Internet 300. The RAN 100 includes at least one RAN node (such as 110a and 110b in Figure 1a, collectively referred to as 110) and at least one terminal (such as 120a-120j in Figure 1a, collectively referred to as 120). The RAN 100 may also include other RAN nodes, such as wireless relay equipment and / or wireless backhaul equipment (not shown in Figure 1a). The terminal 120 is connected to the RAN node 110 wirelessly. The RAN node 110 is connected to the core network 200 wirelessly or wiredly. The core network device in the core network 200 and the RAN node 110 in the RAN 100 may be different physical devices, or may be the same physical device that integrates core network logical functions and radio access network logical functions.

[0165] The RAN 100 may be a cellular system related to the Third Generation Partnership Project (3GPP), such as a 4G or 5G mobile communication system, or a future-oriented evolutionary system (such as a 6G mobile communication system). The RAN 100 may also be an open access network (O-RAN or ORAN), a cloud radio access network (CRAN), or a wireless fidelity (WiFi) system. The RAN 100 may also be a communication system that integrates two or more of the above systems.

[0166] RAN node 110, sometimes also referred to as access network equipment, RAN entity, or access node, constitutes part of the communication system and facilitates wireless access for terminals. Multiple RAN nodes 110 in communication system 1000 can be of the same type or different types. In some scenarios, the roles of RAN node 110 and terminal 120 are relative. For example, network element 120i in Figure 1a can be a helicopter or drone, which can be configured as a mobile base station. For terminal 120j accessing RAN 100 via network element 120i, network element 120i is a base station; however, for base station 110a, network element 120i is a terminal. RAN node 110 and terminal 120 are sometimes referred to as communication devices. For example, base stations 110a and 110b in Figure 1a can be understood as communication devices with base station functionality, and terminals 120a-120j can be understood as communication devices with terminal functionality.

[0167] In one possible scenario, a RAN node may be a base station, an evolved NodeB (eNodeB), an access point (AP), a transmission reception point (TRP), a next generation NodeB (gNB), a next generation base station in a sixth generation (6G) mobile communication system, a base station in a future mobile communication system, or an access node in a WiFi system. A RAN node may be a macro base station (such as 110a in FIG1a ), a micro base station or an indoor station (such as 110b in FIG1a ), a relay node or a donor node, or a wireless controller in a CRAN scenario. Optionally, a RAN node may also be a server, a wearable device, a vehicle or an onboard device. For example, an access network device in vehicle to everything (V2X) technology may be a road side unit (RSU). All or part of the functions of the RAN node in this application may also be implemented by software functions running on hardware, or by virtualized functions instantiated on a platform (such as a cloud platform). The RAN node in this application may also be a logical node, a logical module or software that can implement all or part of the RAN node functions.

[0168] In another possible scenario, multiple RAN nodes collaborate to assist terminals in achieving wireless access, with different RAN nodes implementing portions of the base station's functions. For example, a RAN node can be a centralized unit (CU), a distributed unit (DU), a CU-control plane (CP), a CU-user plane (UP), or a radio unit (RU). The CU implements the base station's radio resource control protocol and packet data convergence protocol (PDCP) functions, as well as the service data adaptation protocol (SDAP) functions. The DU implements the base station's radio link control layer and medium access control (MAC) layer functions, as well as some or all of the physical layer functions. For detailed descriptions of each of these protocol layers, please refer to the relevant technical specifications of the 3rd Generation Partnership Project (3GPP). The CU and DU can be separate or included in the same network element, such as the baseband unit (BBU). The RU may be included in a radio frequency device or a radio frequency unit, for example, in a remote radio unit (RRU), an active antenna unit (AAU) or a remote radio head (RRH).

[0169] Optionally, the RAN node may be expressed differently, such as an access network device. Unless otherwise specified in this application, the access network device is used for expression.

[0170] In different systems, CU (or CU-CP and CU-UP), DU or RU may also have different names, but those skilled in the art can understand their meanings. For example, in the ORAN system, CU may also be called O-CU (Open CU), DU may also be called O-DU, CU-CP may also be called O-CU-CP, CU-UP may also be called O-CU-UP, and RU may also be called O-RU. For the convenience of description, this application uses CU, CU-CP, CU-UP, DU and RU as examples for description. Any unit of CU (or CU-CP, CU-UP), DU and RU in this application can be implemented by a software module, a hardware module, or a combination of a software module and a hardware module.

[0171] A terminal may also be referred to as a terminal device, user equipment (UE), mobile station, mobile terminal, mobile equipment (ME), etc. The terminal can be widely used in various scenarios, such as device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-type communication (MTC), Internet of Things (IOT), virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grid, smart furniture, smart office, smart wearable, smart transportation, smart city, etc. The terminal can be a mobile phone, tablet computer, computer with wireless transceiver function, wearable device, vehicle, drone, helicopter, airplane, ship, robot, robotic arm, smart home device, etc. The embodiments of the present application do not limit the device form of the terminal.

[0172] The core network may include one or more functional entities (also called core network elements, network elements, entities, network functions, logical network elements, etc.), such as network slice selection function (NSSF), network exposure function (NEF), network function repository function (NRF), policy control function (PCF), unified data management (UDM), access and mobility management function (AMF), authentication server function (AUSF), session management function (SMF), etc.

[0173] For example, please refer to Figure 1b, which is a schematic diagram of the roaming architecture of the 5G system. As shown in Figure 1b, the communication system includes two public land mobile networks (PLMNs): a visited public land mobile network (vPLMN) and a home public land mobile network (hPLMN). Each PLMN includes a security edge protection proxy (SEPP), where the SEPP in the vPLMN is a visited security edge protection proxy (vSEPP) and the SEPP in the hPLMN is a home security edge protection proxy (hSEPP).

[0174] In this application, vSEPP can also be replaced by consumer SEPP (cSEPP), and hSEPP can also be replaced by producer SEPP (pSEPP).

[0175] It should be understood that SEPP is a network element that supports message filtering, message supervision and topology hiding. For example, the functions of SEPP include: 1. Protecting messages between cNF and pNF (i.e., establishing TLS or PRINS connections, anti-spoofing based on PLMN ID), 2. Providing message filtering and supervision, for example, the receiving SEPP can verify whether the sending SEPP is authorized to use the PLMN ID in the N32 message, or discard incorrectly formatted N32 signaling messages, or refuse to receive JSON blocks containing "encBlockIndex", or have topology hiding functions.

[0176] The N32 interface is used to implement roaming message delivery between SEPPs of different PLMNs. Based on the N32 interface, the consumer network function (cNF) in the vPLMN can send roaming messages to the pSEPP of the hPLMN via the cSEPP, and the pSEPP forwards the roaming messages to the producer network function (pNF), thereby implementing the delivery of roaming messages between network elements across PLMNs. For example, the cNF can be the AMF in the vPLMN, and the pNF can be the AUSF in the hPLMN. In the main authentication process, the AMF in the vPLMN needs to send a user authentication request message to the AUSF in the hPLMN based on the N32 interface and through the SEPP agent.

[0177] Implementing roaming messaging between SEPPs over the N32 interface requires two logical interfaces: N32-c and N32-f. N32-c manages N32 connections, while N32-f transmits roaming messages between cSEPPs and pSEPPs. The concepts related to N32-c and N32-f are discussed later in this article and are not detailed here.

[0178] It is understandable that the other network elements / devices and interfaces shown in FIG1b can be found in the introduction in TS23.501, and are not described in detail in this application.

[0179] It should be noted that the above functional entity is merely a name and does not limit the entity. For example, the session management function could be replaced by "session management function entity" or another name. Furthermore, the session management function entity could correspond to an entity that includes other functions in addition to the session management function. The user plane function could also be replaced by "user plane function entity" or another name, and the user plane function entity could also correspond to an entity that includes other functions in addition to the user plane function. This is explained here in a unified manner and will not be repeated below.

[0180] It should be noted that the message names between network elements or the names of parameters in the messages in the following embodiments of the present application are only examples, and other names may be used in specific implementations. The embodiments of the present application do not make specific limitations on this.

[0181] In this application, "sending information to...(terminal)" can be understood as the destination of the information being the terminal. This can include sending information to the terminal directly or indirectly. "Receiving information from...(terminal)" can be understood as the source of the information being the terminal, which can include receiving information from the terminal directly or indirectly. The information may undergo necessary processing between the source and destination of the information, such as format changes, but the destination can understand the valid information from the source. Similar expressions in this application can be understood similarly and will not be repeated here.

[0182] It should be understood that the SEPP in the embodiments of this application can be any of the aforementioned devices or chips, without limitation herein. Whether used as a device or a chip, the SEPP can be manufactured, sold, or used as a standalone product. In this and subsequent embodiments, the SEPP is used as an example.

[0183] It should be understood that the device used to implement the IPX functionality in the embodiments of the present application may be the IPX itself, or a device capable of supporting the IPX in implementing the functionality, such as a system-on-chip (SoC) or a combination of devices or components capable of implementing the IPX functionality, which may be installed in the IPX. In the embodiments of the present application, the SoC may consist of a single chip or may include a chip and other discrete components. In this and subsequent embodiments, the IPX will be used as an example.

[0184] IPX is an inter-service provider network node that connects to mobile network operators (MNOs), including PLMN operators, fixed network operators (FNOs), and internet service providers (ISPs). It primarily provides roaming message routing, modification, and monitoring services. In this application, it can also provide more extended services. For example, IPX can determine whether a message that should be encrypted is transmitted in plain text, whether a message that should be transmitted in plain text is encrypted, whether an N32 connection can be established, and whether an NF message can be forwarded. If the determination fails, IPX can generate an error message and send it to the SEPP.

[0185] It should be noted that the IPX involved in the embodiments of the present application can also be a roaming hub (RH). This is because the RH can be deployed on the IPX to implement roaming services, or in the future the RH may directly replace the functions of the IPX. However, for ease of description, the following mainly uses the IPX as an example for schematic description.

[0186] The following is an explanation of the relevant technical features involved in the embodiments of the present application. It should be noted that these explanations are intended to make the embodiments of the present application easier to understand and should not be regarded as limiting the scope of protection claimed by the present application.

[0187] 1. Pre-configuration file

[0188] The operator to which the first SEPP belongs can sign a contract with the operator to which the second SEPP belongs. The contract corresponds to preconfiguration file 1 (or the preconfiguration file 1 is related to the signed contract). The preconfiguration file 1 indicates which IEs need to be encrypted and / or integrity protected, and which IEs can be modified by IPX. Generally speaking, the protection policy in the preconfiguration file 1 is more flexible than the protection policy negotiated in the N32-c handshake process. For example, the protection policy in the preconfiguration file 1 can indicate that the user permanent identifier (SUPI) can be encrypted or not, while the protection policy negotiated in the N32-c handshake process needs to explicitly indicate that the SUPI needs to be encrypted. In other words, the protection policy negotiated in the N32-c handshake process is constrained by the preconfiguration file 1, or the protection policy negotiated in the N32-c handshake process must meet / not exceed the requirements in the preconfiguration file 1.

[0189] A contract may also be signed between the operator to which the first SEPP belongs and the roaming intermediary service provider that deploys the first IPX. The contract corresponds to the pre-configuration file 2. The pre-configuration file 2 includes the requirements of the first IPX, such as the encryption policy required by the first IPX (for example, which IEs the first IPX requires should be encrypted and which IEs should not be encrypted), the modification policy required by the first IPX (for example, which IEs the first IPX requires can be modified), the service policy of the first IPX (for example, which services the first IPX needs to provide), and the inspection policy of the first IPX (for example, the message format required by the first IPX, whether the network topology needs to be hidden, and which IE-related messages are allowed or not to be forwarded).

[0190] Similarly, a contract may be signed between the operator to which the second SEPP belongs and the roaming intermediary service provider that deploys the second IPX. The contract corresponds to the pre-configuration file 3. The pre-configuration file 3 includes the requirements of the second IPX, such as the encryption policy required by the second IPX (for example, which IEs the first IPX requires should be encrypted and which IEs should not be encrypted), the modification policy required by the first IPX (for example, which IEs the second IPX requires can be modified), the service policy of the second IPX (for example, which services the second IPX needs to provide), and the inspection policy of the first IPX (for example, the message format required by the first IPX, whether the network topology requires to be hidden, and which IE-related messages are allowed / not allowed to be forwarded).

[0191] 2. N32-c handshake process and N32-f context

[0192] The SEPP manages the N32 connection through the N32-c handshake process, which primarily includes security capability negotiation, parameter exchange, and N32-f context termination (where the N32-f context termination is used to terminate N32-f message delivery and delete the N32-f context). After the security capability negotiation and parameter exchange processes are performed between the first and second SEPPs, an N32-f context is generated, which can be stored in the first and second SEPPs, respectively. Consequently, the first SEPP can subsequently provide security protection for roaming messages sent by the first SEPP based on the generated N32-f context, and vice versa. Alternatively, the second SEPP can provide security protection for roaming messages sent by the first SEPP based on the generated N32-f context.

[0193] The security capability negotiation process is used to negotiate the security capabilities supported by SEPP, namely the protocol for N32 interconnect security (PRINS) or transport layer secure (TLS). When there is no IP exchange service (IPX) deployed by the roaming intermediate service provider between SEPPs, the N32-f connection between SEPPs should use TLS. When the roaming intermediate service provider deploys IPX and the IPX only provides IP routing services, TLS or PRINS can be selected. When the roaming intermediate service provider deploys IPX and the IPX provides not only IP routing services (referred to as routing services) but also roaming message modification services (referred to as modification services) and roaming message monitoring services (referred to as monitoring services), PRINS should be used. This application mainly focuses on the scenario where the roaming intermediate service provider deploys IPX and IPX provides routing services, modification services, and monitoring services. Therefore, the following text will focus on the PRINS process.

[0194] The parameter exchange process consists of three sub-processes: cipher suite negotiation (or cipher suite negotiation), protection policy negotiation (or protection policy negotiation), and security information list exchange. The cipher suite negotiation process negotiates the cipher suite used for roaming message protection and also exchanges the N32-f context IDs of both parties (e.g., the first SEPP and the second SEPP). The protection policy negotiation process negotiates the encryption policy (i.e., which data types require encryption protection) and the modification policy (i.e., which data types can be modified by IPX). This section focuses on the protection policy negotiation process, as shown in Figure 2a.

[0195] Step 1: The first SEPP sends a parameter exchange request to the second SEPP via the N32-c interface. The parameter exchange request carries an information element (IE) called "SecParamExchReqData". The IE includes a protection policy, which includes a list of IE types in N32-f that need to be encrypted and / or integrity protected (i.e., encryption policy), a modification policy (indicating which IEs can be modified), etc.

[0196] In step 2a, the second SEPP sends a 200 OK status code and the protection policy selected by the second SEPP to the first SEPP via the N32-c interface. The 200 OK status code indicates successful processing of the parameter exchange request. Generally speaking, the protection policy selected by the second SEPP can be the same as the protection policy carried in the parameter exchange request, or the protection policy selected by the second SEPP can be a subset of the protection policy carried in the parameter exchange request.

[0197] In step 2b, the second SEPP sends a 4XX / 5XX status code to the first SEPP via the N32-c interface. The 4XX / 5XX status code indicates that the parameter exchange request processing has failed.

[0198] It should be understood that after the N32-c handshake process is executed, an N32-f context may be generated, and the N32-f context includes the protection policy and modification policy negotiated in the parameter exchange process.

[0199] 3. Disconnect N32

[0200] The process of interrupting the N32 connection is shown in Figure 2b:

[0201] In step 1, a first SEPP sends an n32-f interrupt request to a second SEPP via the N32-c interface. The n32-f interrupt request carries an IE called "N32-f context id." It should be understood that after the second SEPP receives the n32-f interrupt request, it stops sending all messages originally intended for transmission to the first SEPP via N32-f and deletes the security context corresponding to the N32-f context id. The first SEPP also stops sending all messages originally intended for transmission to the second SEPP via N32-f and deletes the security context corresponding to the local N32-f context id.

[0202] In step 2a, the second SEPP sends a successful interruption message to the first SEPP via the N32-c interface. The message carries the "N32-f context id".

[0203] Step 2b: The second SEPP sends a 4XX / 5XX status code to the first SEPP via the N32-c interface. The 4XX / 5XX status code indicates that the n32-f interrupt request processing failed.

[0204] 4. N32-f message delivery process

[0205] This section focuses on the PRINS process. Figures 3 and 4 show an overview of PRINS and the N32-f message delivery process, respectively. As shown in Figure 3, PRINS includes a cNF, cSEPP, consumer IPX (cIPX), producer IPX (pIPX), pSEPP, and pNF. The cNF and cSEPP belong to the vPLMN, while the pSEPP and pNF belong to the pPLMN. The following describes the PRINS process primarily through the cSEPP-to-pSEPP roaming process. The pSEPP-to-cSEPP roaming process is symmetrical to the cSEPP-to-pSEPP roaming process and will not be further described. As shown in Figure 4:

[0206] Step 1: The CNF sends a Hypertext Transfer Protocol (HTTP) request message to the cSEPP. In response, the cSEPP receives the HTTP request message from the CNF.

[0207] For example, taking the HTTP request message as the protocol data unit (PDU) session establishment process, the AMF in the vPLMN sends a request (Nsmf_PDUSession_CreateSMContext) message to the SMF in the hPLMN to create a PDU session management context. The AMF of the vPLMN sends a Create PDU session management context request message to the cSEPP. The Create PDU session management context request message carries parameters such as SUPI, data network name (DNN), and user location information (UE Location Information). These parameters can all be called information elements (IE).

[0208] Step 2: cSEPP uses JWE to encrypt and / or integrity-protect the HTTP request message to obtain a protected HTTP request message.

[0209] It should be understood that the function of cSEPP is to protect HTTP request messages from being leaked or tampered with during transmission. Therefore, after receiving the HTTP request message, cSEPP may first rewrite the HTTP request message into a JavaScript object notation (JSON) block (this facilitates subsequent JSON web encryption (JWE) protection). JSON is a format for describing information. Next, based on the protection policy negotiated during the aforementioned N32-c handshake process, cSEPP determines which IEs in the HTTP request message require encryption protection and which require integrity protection (also referred to as integrity protection). Therefore, cSEPP may use JWE to encrypt the IEs requiring encryption protection and integrity protect the IEs requiring integrity protection, thereby generating a protected HTTP request message. The protected HTTP request message generated in step 2 can be understood as containing a JSON block (hereinafter referred to as the original JSON block, which is reformattedData, for ease of distinction). This original JSON block contains the formatted request message, and the information in the original JSON block is protected by JWE.

[0210] For example, if the protection policy negotiated in the N32-c handshake process is that user location information requires encryption protection and SUPI and DNN require integrity protection, cSEPP will encrypt user location information based on JWE and generate integrity protection information for SUPI and DNN.

[0211] Step 3: cSEPP sends the protected HTTP request message to cIPX.

[0212] It should be noted that cIPX is deployed by the roaming intermediary service provider that provides roaming services for cSEPP (whether cIPX is deployed is optional, depending on whether the vPLMN requires the roaming intermediary service provider to provide roaming services). cIPX can be used to provide routing services, modification services and monitoring services.

[0213] Step 4: cIPX adds cIPX modifications.

[0214] It should be understood that in order to prevent cIPX from arbitrarily modifying the roaming message, cIPX needs to indirectly modify the roaming message by adding a JSON block (for example, the JSON block is modificationsBlock1) after the original JSON block in the protected HTTP request message (that is, the JSON block generated in the above step 2). The specific method is: cIPX places the modification instruction, modification position, and modification value in the JSON block, and the JSON block is integrity protected by cIPX according to the JSON web signature (JSON web signature, JWS). Subsequently, after the integrity of the JSON block is verified by pSEPP, the IE at the corresponding position is modified based on the modification instruction according to the modification policy negotiated in the N32-c handshake process.

[0215] For example, if cIPX wants to modify the value of a certain IE (such as SUPI) in the Create PDU Session Management Context Request message, cIPX needs to write the IE position to be modified and the modified value of the IE into a JSON block and append the JSON block to the original JSON block. For example, if the SUPI in the original JSON block is SUPI 1, cIPX indicates that the SUPI value needs to be modified to SUPI 2.

[0216] Step 5: cIPX sends the HTTP request message with the cIPX modification protection added to it to pIPX.

[0217] It should be noted that, similar to cIPX, pIPX is deployed by the roaming intermediary service provider that provides roaming services for pSEPP (whether pIPX is deployed is also optional, depending on whether the hPLMN requires the roaming intermediary service provider to provide roaming services). pIPX can also be used to provide routing services, modification services and monitoring services.

[0218] Step 6: pIPX Continue adding modifications to pIPX.

[0219] It should be understood that, similar to cIPX, pIPX needs to be able to modify the roaming message by continuing to add a JSON block (for example, the JSON block is modificationsBlock2) after the original JSON block (that is, the original JSON block generated in the aforementioned step 2) and the JSON block generated in step 4 (that is, modificationsBlock1). The added JSON block is integrity protected by pIPX according to JWS.

[0220] For example, when pIPX receives a Create PDU Session Management Context Request message, it will also provide DNN conversion services, re-determine the appropriate DNN based on the load of different DNNs and user location information, or provide other services. For example, if pIPX wants to modify the value of a certain IE (such as DNN) in the Create PDU Session Management Context Request message, pIPX needs to write the IE at the location to be modified and the modified value of the IE into a JSON block and append the JSON block to the original JSON block and the JSON block generated in step 4. For example, assuming that the DNN in the original JSON block is DNN 1, pIPX indicates that the value of DNN needs to be modified to DNN 2.

[0221] Step 7: pIPX sends the protected HTTP request message with the cIPX modification and the pIPX modification added to pSEPP. In response, pSEPP receives the message from pIPX.

[0222] Step 8: pSEPP verifies the integrity of the information in the original JSON block and decrypts the encrypted information in the original JSON block, then verifies the integrity of the modified content added by cIPX and pIPX, and then reconstructs the HTTP request message based on the modified content added by cIPX and pIPX and the content in the decrypted original JSON block.

[0223] In other words, pSEPP's function is to verify the integrity of messages protected by JWE and JWS, decrypt JWE-protected messages, and modify the HTTP request message based on the IPX modification description. Specifically, pSEPP first verifies the integrity of the JSON block generated by pIPX and cIPX using JWS. It then verifies the integrity protection information generated by cSEPP using JWE while simultaneously decrypting the ciphertext. pSEPP then retrieves the modification instructions from the JSON block generated by pIPX and cIPX. Based on the modification policy previously negotiated by N32-c, pSEPP modifies the corresponding IEs based on the modification instructions. Finally, pSEPP restores the message to HTTP format (i.e., reconstructs the HTTP request message) and sends it to the pNF.

[0224] For example, pSEPP can recover / reconstruct a Create PDU Session Management Context Request message, and the SUPI and DNN in the Create PDU Session Management Context Request message may have been legally modified by IPX. For example, assuming the SUPI in the original JSON block is SUPI 1 and the DNN is DNN 1, and cIPX indicates that the SUPI value needs to be changed to SUPI 2, and pIPX indicates that the DNN value needs to be changed to DNN 2, then the SUPI included in the recovered Create PDU Session Management Context Request message is SUPI 2 and the DNN is DNN 2.

[0225] Step 9: pSEPP sends the reassembled HTTP request message to pNF.

[0226] 5. JWE and JWS

[0227] JWE and JWS are two protection algorithms. JWE is used by SEPP to encrypt and integrity-protect corresponding IEs, or to integrity-protect only IEs. JWS is used by IPX (e.g., cIPX or pIPX) to integrity-protect roaming modification messages. A JSON-formatted message protected by JWE is called reformattedData, and a JSON-formatted message protected by JWS is called modificationsBlock.

[0228] For example, see Figure 5, which is a schematic diagram of the format of reformattedData and modificationsBlock. As shown in Figure 5 (a), the JSON block generated by SEPP and protected by JWE is reformattedData, where reformattedData includes:

[0229] (1) n32fContextID, used to identify which N32-f connection;

[0230] (2) messageId, used to confirm which message it is;

[0231] (3) authorizedIpxId, used to confirm the IPX ID of the SEPP next hop;

[0232] (4) ciphertext, which contains information generated by encrypting the IEs that need to be encrypted using JWE. Based on the characteristics of JWE, these IEs can also be integrity protected at the same time;

[0233] (5) JsonPayload, containing IE that only needs integrity protection;

[0234] (6) Tag, used for JWE integrity verification. Specifically, tag is the information generated after JWE performs integrity protection on the IE that requires both encryption and integrity protection, as well as the IE that only requires integrity protection. When performing integrity verification based on the tag, it is necessary to compare whether the tag and tag2 generated by JWE are equal. If they are equal, the integrity verification passes (or is called verification success, verification pass, etc.). Specifically, tag2 is the ciphertext in reformattedData and the information generated by JWE on the IE that only requires integrity protection.

[0235] (7) Other information is not relevant to this application and will not be detailed here.

[0236] As shown in Figure 5(b), the JSON block generated by IPX and protected by JWS is modificationsBlock, where modificationsBlock includes:

[0237] (1) A tag copied from the JWE format message to prevent replay attacks;

[0238] (2) JWS signature, used for JWS integrity verification. Specifically, the JWS signature is the information / signature generated after integrity protection is performed on the IE in the modificationsBlock that requires integrity protection. When performing integrity verification based on the JWS signature, it is necessary to compare this signature with Signature 2 generated by JWS to see if they are equal. If they are equal, the integrity verification passes. Specifically, Signature 2 is the information generated by JWS for the IE in the modificationsBlock that requires integrity protection.

[0239] (3) Other information is not relevant to this application and will not be described here.

[0240] It should be noted that a message protected by JWE can be understood as a JSON block, and a message protected by JWS can also be understood as a JSON block.

[0241] 6. Error message transmission between SEPPs

[0242] As shown in Table 1, 3GPP TS29.573 defines the error types between SEPPs, which are transmitted via ProblemDetails. It should be understood that ProblemDetails is also a JSON block. For example, see Figure 6, which is a schematic diagram of the format of ProblemDetails. ProblemDetails includes:

[0243] (1) title, which is a human-readable summary of the error type;

[0244] (2) detail, which refers to the human-readable error type;

[0245] (3) cause, which refers to the machine-readable error type;

[0246] (4) invalidParams, which refers to the IE that caused this error type to occur;

[0247] (5) Other information is not relevant to this application and will not be detailed here.

[0248] It should be understood that the SEPP can directly send ProblemDetails to the peer SEPP via the N32-f interface. ProblemDetails includes five error types: "PLMNID_MISMATCH", "SNPNID_MISMATCH", "REQUESTED_PURPOSE_NOT_ALLOWED", "CONTEXT_NOT_FOUND", and "UNSPECIFIED".

[0249] Table 1 Error types

[0250] It should be noted that as user needs increase, IPX may provide services other than routing, modification, and monitoring. It may also provide error message generation services. For example, IPX can determine whether a message that should be encrypted is being transmitted in plain text, or whether a message that should be transmitted in plain text is encrypted. If the determination fails, IPX generates an error message and sends it to the cSEPP or pSEPP. However, the relevant standards currently do not define the error message response mechanism between IPX and SEPP.

[0251] Based on this, the present application proposes a communication method, which defines an error message response mechanism between IPX and SEPP, which is conducive to improving the reliability of communication.

[0252] It should be noted that the first NF and the first SEPP mentioned in the following embodiments of this application belong to the same PLMN, for example, the first PLMN, and the second NF and the second SEPP belong to the same PLMN, for example, the second PLMN. The first IPX is an IPX deployed by a first roaming intermediary service provider on the first PLMN side, and the second IPX is an IPX deployed by a second roaming intermediary service provider on the second PLMN side. The first PLMN and the second PLMN are different PLMNs. For example, the first PLMN is a vPLMN and the second PLMN is an hPLMN. For another example, the first PLMN is an hPLMN and the second PLMN is a vPLMN, but this application does not impose any restrictions on this.

[0253] It should be understood that when the first PLMN is a vPLMN and the second PLMN is an hPLMN, the first NF is a cNF, the first SEPP is a cSEPP, the first IPX is a cIPX, the second NF is a pNF, the second SEPP is a pSEPP, and the second IPX is a pIPX. Accordingly, the HTTP message sent by the first SEPP is an HTTP request message. When the first PLMN is an hPLMN and the second PLMN is a vPLMN, the first SEPP is a pSEPP, the first IPX is pIPX, the second SEPP is a cSEPP, and the second IPX is cIPX. Accordingly, the HTTP message sent by the first SEPP is an HTTP response message. For ease of understanding, the following description mainly uses the example of the first PLMN being a vPLMN and the second PLMN being an hPLMN.

[0254] The communication method and communication device provided by this application are described in detail below:

[0255] Please refer to Figure 7, which is a schematic diagram of an interactive process of the communication method provided by an embodiment of the present application. As shown in Figure 7, the communication method includes the following steps S700 to S704. The execution subject of the method shown in Figure 7 can be cSEPP and IPX, or the execution subject of the method shown in Figure 7 can also be a chip in cSEPP and a chip in IPX. For the convenience of description, Figure 7 mainly uses cSEPP and IPX as the execution subject of the method for example. It should be noted that Figure 7 is a schematic flow chart of an embodiment of the method of the present application, showing the detailed communication steps or operations of the method, but these steps or operations are only examples. The embodiment of the present application can also perform other operations or variations of the various operations in Figure 7. In addition, the various steps in Figure 7 can be executed in a different order from that presented in Figure 7, and it is possible that not all operations in Figure 7 need to be executed. Among them:

[0256] S700. The cSEPP uses the first N32-f context between the cSEPP and the pSEPP to perform security protection on the first HTTP request message to obtain the protected first HTTP request message.

[0257] It should be understood that the first N32-f context is the N32-f context generated after the N32-c handshake process is executed between the cSEPP and the pSEPP. For an understanding of the "N32-c handshake process" and "N32-f context," please refer to the relevant description in "3. N32-c Handshake Process and N32-f Context" above, and will not be repeated here. Generally speaking, both the cSEPP and the pSEPP store this first N32-f context.

[0258] The first HTTP request message can be used to implement roaming services between cSEPP and pSEPP. For example, in the primary authentication process, the first HTTP request message can be a user authentication request message, which is used to trigger the AUSF in the hPLMN to authenticate the UE service. For another example, in the PDU session establishment process, the first HTTP request message can be a request message to create a PDU session management context, which is used to establish a session management context service between the vAMF and the hSMF.

[0259] Generally speaking, the first HTTP request message is an HTTP request message sent by the cNF to the cSEPP, such as described in step 1 of FIG. 4 . Furthermore, the cSEPP uses the first N32-f context between the cSEPP and the pSEPP to securely protect the first HTTP request message. For an understanding of the protected first HTTP request message, refer to the description of step 2 of FIG. 4 , which is not further elaborated here.

[0260] It should be understood that the protected first HTTP request message contains a JSON block, namely the original JSON block. The information in the original JSON block is protected by JWE, or the original JSON block is reformattedData.

[0261] S701: cSEPP sends a protected first HTTP request message to IPX. Correspondingly, IPX receives the protected first HTTP request message from cSEPP.

[0262] It should be understood that the IPX in the embodiments of the present application can be cIPX and / or pIPX. In one possible implementation, when only one IPX is deployed in the network, the IPX can be cIPX or pIPX. In another possible implementation, two IPXs can also be deployed simultaneously, and the two IPXs are cIPX and pIPX respectively.

[0263] S702: The IPX determines first indication information according to the protected first HTTP request message, where the first indication information indicates a transmission error that occurs in the first HTTP request message.

[0264] As will be appreciated, after IPX receives the protected first HTTP request message from cSEPP, it can process the message to determine whether a transmission error occurred or whether it meets IPX requirements. For example, IPX can determine whether an IE that should have been encrypted was transmitted in plain text, or whether an IE that should have been transmitted in plain text was encrypted. If the determination fails, IPX can generate first indication information and send it to cSEPP. Specifically, the first indication information can be included in an error message.

[0265] In Example 1, assuming that only one IPX is deployed on the network:

[0266] 1-1: If only cIPX is deployed in the network, then cSEPP can send a protected first HTTP request message to cIPX, and cIPX determines whether an error occurs based on the received protected first HTTP request message. If cIPX determines that an error occurs, cIPX discards the received message and generates an error message to send to cSEPP.

[0267] 1-2: If only pIPX is deployed in the network, cSEPP can send the protected first HTTP request message to pIPX, and pIPX determines whether an error occurs based on the received protected first HTTP request message. If pIPX determines that an error occurs, pIPX discards the received message and generates an error message to send to cSEPP.

[0268] In Example 2, if both cIPX and pIPX are deployed on the network, then:

[0269] 2-1: cSEPP may send the protected first HTTP request message to cIPX, and cIPX may determine whether an error occurs based on the protected first HTTP request message. If cIPX determines that an error occurs, cIPX discards the received message and generates an error message to send to cSEPP. pIPX does not participate in the routing / forwarding process of the first HTTP request message.

[0270] 2-2: cSEPP can send the protected first HTTP request message to cIPX. cIPX then processes the message normally and sends it to pIPX for forwarding / delivery (e.g., the description of step 4 in Figure 4 above is omitted here). pIPX then determines whether an error has occurred based on the received message. If pIPX determines an error has occurred, it discards the received message and generates an error message, which it sends to cIPX. cIPX then forwards / delivers the error message to cSEPP.

[0271] As can be seen from Examples 1 and 2 above, the IPX that performs error judgment and generates error messages can be either cIPX or pIPX. Therefore, for ease of description, IPX will be used in the following unified description.

[0272] In a possible implementation method 1, the error message generated by IPX may include a JSON block (hereinafter referred to as JSON block 1 for ease of distinction). The JSON block 1 includes two parts, namely the first part and the second part. The first part and the second part are described below:

[0273] The first part may contain the following two situations:

[0274] In scenario 1, the first part of the content does not include the ciphertext and / or JsonPayload defined in TS29.573 (or the ciphertext and / or JsonPayload are left blank), and the first part of the content includes other content in the reformattedData defined in TS29.573 besides the ciphertext and / or JsonPayload. For example, the first part of the content includes the tag, n32fContextID, messageId, authorizedIpxId, etc. generated by JWE for integrity verification.

[0275] In case 2, the first part of the content includes one or more of n32fContextID, messageId, and authorizedIpxId defined in TS29.573, and the first part of the content does not include other content in reformattedData defined in TS29.573 except the above n32fContextID, messageId, and authorizedIpxId.

[0276] Among them, the second part of the content includes first indication information, which indicates a transmission error (or error type) that occurs in the first HTTP request message. Different error types will be explained separately below and will not be described in detail here.

[0277] In one possible implementation method 2, the error message generated by IPX may include two JSON blocks (hereinafter referred to as JSON block 2 and JSON block 3 for ease of distinction). JSON block 2 includes the first portion of content, and JSON block 3 includes the second portion of content. It should be understood that in this implementation method 2, JSON block 2 may be in a JSON format protected by JWE, and JSON block 3 may be in a JSON format protected by JWS. Optionally, in addition to the first indication information, JSON block 3 may also include a tag (i.e., a tag copied from the original JSON block), a JWS signature (hereinafter referred to as JWS signature 1 for ease of distinction), and other content, without limitation. Exemplarily, JWS signature 1 may be a signature generated by integrity-protecting IEs in JSON block 3 that require integrity protection, or alternatively, by integrity-protecting IEs in JSON block 3 and IEs in JSON block 2 that require integrity protection.

[0278] In a possible implementation manner 3, the error message generated by IPX may include three JSON blocks (hereinafter described as JSON block 4, JSON block 5, and JSON block 6 for easy distinction), where:

[0279] JSON block 4 includes the first part of the content. For an introduction to the first part of the content, please refer to the relevant section above and will not be repeated here.

[0280] JSON block 5 is a JSON block generated by normal IPX processing (e.g., the modificationsBlock generated by the processing performed in step 4 of FIG. 4 ). However, unlike step 4 of FIG. 4 , JSON block 5 in this embodiment of the present application may also include a new indication (hereinafter referred to as the second indication for ease of distinction). This second indication indicates the presence of JSON block 6. Optionally, JSON block 5 may also include a JWS signature (hereinafter referred to as JWS signature 2 for ease of distinction). JWS signature 2 may be a signature generated by integrity-protecting any IEs in JSON block 5 that require integrity protection. Alternatively, JWS signature 2 may be a signature generated by integrity-protecting both the IEs in JSON block 4 that require integrity protection and the IEs in JSON block 5 that require integrity protection. This application does not impose any restrictions on this.

[0281] JSON block 6 includes the second part of the content. In addition, JSON block 6 may also include a tag (i.e., a tag copied from the original JSON block), a JWS signature (hereinafter referred to as JWS signature 3 for ease of distinction), and other information. JWS signature 3 may be a signature generated by integrity-protecting any IEs in JSON block 6 that require integrity protection. Alternatively, JWS signature 3 may be a signature generated by integrity-protecting any IEs in JSON block 4 that require integrity protection and any IEs in JSON block 6 that require integrity protection. The specific details are determined based on implementation and are not limited here.

[0282] In one possible implementation, IPX can reuse ProblemDetails to carry the first indication information. Specifically, the error message generated by IPX includes ProblemDetails, which includes the first indication information. It should be understood that, in this implementation, the first indication information can be placed in the title, detail, or cause fields of ProblemDetails, without limitation. Optionally, the IE that caused the error type indicated by the first indication information to occur can be placed in the invalidParams field of ProblemDetails. The definition of invalidParams is described in detail in the relevant section of S702 and will not be further explained here. It should be understood that, in this implementation, the content of ProblemDetails is not integrity protected.

[0283] In a possible implementation manner 5, IPX can reuse ProblemDetails to carry the first indication information and perform integrity protection on the IEs in ProblemDetails that require integrity protection. There are two solutions for IPX to perform integrity protection on the IEs in ProblemDetails that require integrity protection:

[0284] The first solution is to add a new JSON block after ProblemDetails (hereinafter referred to as JSON block 7 for ease of distinction). JSON block 7 includes integrity protection information generated after integrity protection is performed on the IEs in ProblemDetails that require integrity protection (hereinafter referred to as JWS signature 4 for ease of distinction). For example, the content in ProblemDetails that requires integrity protection may be IEs such as title / detail / cause and invalidParams. Therefore, JWS can be used to integrity protect the title / detail / cause and invalidParams in ProblemDetails to generate JWS signature 4. It should be understood that in this first solution, the first indication information and JWS signature 4 are carried in different JSON blocks, that is, the first indication information is carried in ProblemDetails, and the JWS signature 4 is carried in JSON block 7.

[0285] The second solution is to add a new signature attribute in ProblemDetails, which includes JWS signature 4. That is, in the second solution, JWS signature 4 and the first indication information are carried in the same JSON block, that is, ProblemDetails.

[0286] In addition, similar to Implementation 4, in Implementation 5, the first indication information can also be placed in the title, detail, or cause of ProblemDetails, without specific restrictions. Optionally, the IE that caused the error type indicated by the first indication information to occur can be placed in invalidParams of ProblemDetails.

[0287] It should be noted that the error messages in the above implementation methods 1 to 3 can also be called second messages, and the error messages in the above implementation methods 4 to 5 can also be called first messages. For the convenience of description, they will be uniformly expressed as "error messages" in the following text.

[0288] S703: IPX sends an error message to cSEPP. Correspondingly, cSEPP receives the error message from IPX.

[0289] It should be understood that in the embodiment shown in Figure 7, the error message is a message sent by IPX to cSEPP in response to the first protected HTTP request message sent by cSEPP. In step S703, IPX does not send the first protected HTTP request message to cSEPP at the same time as sending the error message, nor does IPX forward the received first protected HTTP request message to pSEPP. In other words, IPX discards the received first protected HTTP request message.

[0290] S704. cSEPP responds with an error message.

[0291] Here, the cSEPP response error message can be understood as cSEPP parsing the error message, obtaining the first indication information, and performing the error response operation corresponding to the transmission error (or error type) indicated by the first indication information. Optionally, if the error message contains integrity protection information (i.e., JWS signature), such as JWS signature 1, JWS signature 2, JWS signature 3, or JWS signature 4, then cSEPP needs to first perform integrity protection verification on the corresponding content in the error message based on the corresponding JWS signature. If the verification result is passed / successful, the error response operation corresponding to the transmission error (or error type) indicated by the first indication information is performed. For the method of performing integrity verification based on the JWS signature, please refer to the relevant description in the aforementioned "5. JWE and JWS" and will not be repeated here.

[0292] It should be noted that when the error message is generated in any of the above implementations 1 to 3:

[0293] When the first part of the content is the above-mentioned situation 1, cSEPP can determine that the received error message is a message sent by IPX in response to the protected first HTTP request message sent by cSEPP itself (that is, cSEPP can determine that the specific received error message is a message including a transmission error, so cSEPP can continue to parse the content carried in the error message instead of discarding the received error message) by determining that the ciphertext and / or JsonPayload in the first part of the content is empty (that is, the first part of the content does not include ciphertext and / or JsonPayload).

[0294] When the first part of the content is case 1 or case 2 above, if the cSEPP determines that the n32fContextID included in the first part of the content is the same as the n32fContextID included in the protected first HTTP request message sent by the cSEPP, and / or the messageId included in the first part of the content is the same as the messageId included in the protected first HTTP request message sent by the cSEPP, and / or the authorizedIpxId included in the first part of the content is the same as the authorizedIpxId included in the protected first HTTP request message sent by the cSEPP, then the cSEPP can determine that the received error message is a message fed back by the IPX in response to the protected first HTTP request message sent by the cSEPP itself.

[0295] It should be noted that when the error message is generated using the above implementation method 2 or 3:

[0296] If the error message also includes a tag (for example, the tag is included in JSON block 3 in implementation method 2, or the tag is included in JSON block 6 in implementation method 3), then the cSEPP can determine that the received error message is a message fed back by IPX in response to the first protected HTTP request message sent by the cSEPP itself by determining that the tag in the error message is the same as the tag included in the first protected HTTP request message sent by the cSEPP.

[0297] It should be noted that when the error message is generated using the above implementation method 4 or 5:

[0298] The cSEPP may determine, based on the format of the ProblemDetails, that the received first message includes a transmission error. Therefore, the cSEPP may directly parse the ProblemDetails to obtain the first indication information carried in the ProblemDetails.

[0299] The following describes how cSEPP performs different error response operations based on different transmission errors (i.e., error types) indicated by the first indication information. Specifically, this application mainly involves three types of response operations, namely:

[0300] Error Response Operation Type 1: The cSEPP and pSEPP renegotiate / exchange parameters to obtain a second N32-f context between the cSEPP and pSEPP; the cSEPP uses the second N32-f context to securely protect the first HTTP request message, obtaining a re-protected first HTTP request message; and the cSEPP sends the re-protected first HTTP request message to the IPX. In other words, the cSEPP can update the N32-f context between the cSEPP and pSEPP, securely protect the first HTTP request message based on the updated N32-f context, obtaining a re-protected first HTTP request message, and then send the re-protected first HTTP request message to the IPX. Accordingly, the IPX receives the re-protected first HTTP request message from the first SEPP and sends it to the pSEPP. The process of renegotiation / exchange of parameters between the cSEPP and pSEPP to obtain the second N32-f context between the cSEPP and pSEPP can be seen in Figure 2a above.

[0301] For example, in one possible scenario 1, the cSEPP can use the first N32-f context between the cSEPP and the pSEPP to securely protect the first HTTP request message, obtaining a protected first HTTP request message. The cSEPP can then send the protected first HTTP request message to the IPX, where the encryption policy for the first IE in the first HTTP request message in the first N32-f context is encryption. Therefore, after receiving the protected first HTTP request message, the IPX can determine whether the first IE in the protected first HTTP request message is encrypted. If the first IE is encrypted (this is because the IPX requires that the first IE be unencrypted, but the first IE in the protected first HTTP request message is actually encrypted; understandably, the IPX requirement can be determined based on preconfigured files 2 / 3), the IPX sends first indication information to the cSEPP, indicating that the IPX requires that the unencrypted first IE be encrypted in the protected first HTTP request message. Accordingly, after the cSEPP receives the first indication, the cSEPP and the pSEPP re-exchange parameters to obtain a second N32-f context between the cSEPP and the pSEPP. The cSEPP uses the second N32-f context to securely protect the first HTTP request message, obtaining a re-protected first HTTP request message. The cSEPP then sends the re-protected first HTTP request message to the IPX. The encryption policy for the first IE in the second N32-f context is to not encrypt the first IE. Accordingly, the IPX receives the re-protected first HTTP request message from the first SEPP and sends the re-protected first HTTP request message to the pSEPP.

[0302] Optionally, the explanation of Scenario 1 here can also be replaced by other descriptions of Scenario 1 in the following text, which will not be described in detail here.

[0303] For example, in possible scenario 2, the cSEPP can use the first N32-f context between the cSEPP and the pSEPP to perform security protection on the first HTTP request message, obtaining a protected first HTTP request message. The cSEPP can then send the protected first HTTP request message to the IPX, where the encryption policy for the second IE in the first HTTP request message in the first N32-f context is non-encryption. Therefore, after the IPX receives the protected first HTTP request message, the IPX can determine whether the second IE in the protected first HTTP request message is encrypted. If the second IE is not encrypted (this is because the IPX requires the second IE to be encrypted, but the second IE in the protected first HTTP request message is not encrypted; understandably, the IPX requirement can be determined based on preconfigured files 2 / 3), the IPX sends first indication information to the cSEPP, indicating that the second IE that the IPX requires to be encrypted is not encrypted in the protected first HTTP request message. Accordingly, after the cSEPP receives the first indication, the cSEPP and pSEPP re-exchange parameters to obtain a second N32-f context between the cSEPP and pSEPP. The cSEPP uses the second N32-f context to securely protect the first HTTP request message, obtaining a re-protected first HTTP request message. The cSEPP then sends the re-protected first HTTP request message to the IPX. The encryption policy for the second IE in the second N32-f context is to encrypt the second IE. Accordingly, the IPX receives the re-protected first HTTP request message from the first SEPP and sends it to the pSEPP.

[0304] Optionally, the explanation for Scenario 2 here can also be replaced by other descriptions of Scenario 2 in the following text, which will not be described in detail here.

[0305] Optionally, the error response operation type 1 described above can also be described as: the cSEPP re-establishing the N32 connection with the pSEPP, referred to as re-establishing the N32 connection (herein, re-establishing the N32 connection is also referred to as re-executing the N32-c handshake process), and sending the first HTTP request message based on the re-established N32 connection. For an understanding of the N32-c handshake process, please refer to the description of "2. N32-c handshake process" above and will not be repeated here.

[0306] It should be understood that since negotiating the protection policy is a sub-process within the parameter exchange process of the N32-c handshake process, error response operation type 1 in the embodiment of the present application can also be described as follows: the cSEPP and the pSEPP merely renegotiate the protection policy; the cSEPP re-protects the first HTTP request message based on the new protection policy to obtain a re-protected first HTTP request message; and the cSEPP sends the re-protected first HTTP request message to the IPX. The process for negotiating the protection policy is shown in Figure 2a and is not further described here.

[0307] Error response operation type 2: The cSEPP processes / modifies the first HTTP request message based on the first indication information to obtain a second HTTP request message. The cSEPP uses the first N32-f context to perform security protection on the second HTTP request message to obtain a protected second HTTP request message. The cSEPP sends the protected second HTTP request message to the IPX. In response, the IPX receives the protected second HTTP request message from the cSEPP and sends it to the pSEPP.

[0308] Optionally, the above-mentioned error response operation type 2 can also be described as: resending the HTTP request message, that is, sending a second HTTP request message.

[0309] For example, in possible scenario 3, if the IPX determines that the protected first HTTP request message includes the plaintext identifier of the CNF, the IPX sends a first indication to the cSEPP. The first indication indicates that the network topology of the PLMN where the cSEPP is located is not hidden and that the CNF is the network element requesting roaming services. Accordingly, the cSEPP may anonymize the plaintext identifier of the CNF in the first HTTP request message to obtain the anonymous identifier of the CNF. The cSEPP then replaces the plaintext identifier of the CNF in the first HTTP request message with the anonymous identifier of the CNF to obtain a second HTTP request message. The cSEPP then uses the first N32-f context to perform security protection on the second HTTP request message to obtain a protected second HTTP request message. The cSEPP then sends the protected second HTTP request message to the IPX. Accordingly, the IPX receives the protected second HTTP request message from the cSEPP and sends the protected second HTTP request message to the pSEPP.

[0310] Optionally, the explanation of scenario 3 here can also be replaced by other descriptions of scenario 3 in the following text, which will not be described in detail here.

[0311] For example, in possible scenario 4, IPX determines whether the message format name in the message header of the protected first HTTP request message is the first format. If the message format name in the message header of the protected first HTTP request message is not the first format, IPX sends first indication information to cSEPP, indicating that the message format of the protected first HTTP request message is not the first format. Accordingly, cSEPP can convert the message format of the first HTTP request message to the first format based on the first indication information, obtaining a second HTTP request message. Next, cSEPP can use the first N32-f context to perform security protection on the second HTTP request message, obtaining a protected second HTTP request message, and then cSEPP can send the protected second HTTP request message to IPX. For example, the first format can be JSON. Accordingly, IPX receives the protected second HTTP request message from cSEPP and sends the protected second HTTP request message to pSEPP.

[0312] Optionally, the explanation of scenario 4 here can also be replaced by other descriptions of scenario 4 in the following text, which will not be described in detail here.

[0313] Error Response Operation Type 3: The cSEPP deletes the N32-f context between the first SEPP and the second SEPP. Optionally, this Error Response Operation Type 3 can also be described as the cSEPP interrupting the N32 connection between the cSEPP and the pSEPP, referred to as interrupting the N32 connection (or interrupting the N32-f connection). The "interrupting the N32 connection" process is described in Figure 2b above and is not further described here.

[0314] Error response operation type four: cSEPP cancels sending the HTTP request message, that is, cancels sending the first HTTP request message.

[0315] The following describes in detail the error response operations adopted for different error types.

[0316] In one possible scenario, when IPX determines that a message that should have been transmitted in clear text was encrypted, causing IPX to be unable to provide normal services, the error type can be described as "an IE is encrypted while it was expected to be available in the clear." Accordingly, after the cSEPP detects this error type, it can reestablish or terminate the N32 connection. Specifically, the cSEPP can renegotiate the protection policy based on the instructions in preconfiguration profile 1. If preconfiguration profile 1 indicates that encryption is not required for the corresponding IE type (here, "corresponding IE type" refers to the IE that should have been transmitted in clear text), the new protection policy can be to not encrypt the corresponding IE type. If preconfiguration profile 1 indicates that encryption is required for the corresponding IE type, then: ① the cSEPP can terminate the N32 connection; or ② the operator to which the cSEPP belongs can re-sign a contract with the operator to which the pSEPP belongs. Based on the new contract, preconfiguration profile 1 in both the cSEPP and pSEPP will be updated, so the cSEPP can re-establish the N32 connection with the pSEPP based on the new preconfiguration profile 1. For example, the cSEPP can renegotiate the protection policy based on the new preconfiguration file 1; alternatively, (3) the operator to which the cSEPP belongs can also re-sign a contract with the roaming intermediary service provider that deploys IPX. It should be understood that the IPX here specifically refers to the IPX (i.e., cIPX) that provides roaming services for the cSEPP. For example, the IPX that provides roaming services for the cSEPP is cIPX, not pIPX. In other words, the implementation of (3) requires limiting the scenario. If the error message is generated by pIPX and sent to the cSEPP, the operator to which the cSEPP belongs will not renew the contract with the pIPX operator, and the solution (3) cannot be adopted. It should be noted that if the solution (3) is adopted, after the contract is re-signed, the corresponding preconfiguration file 2 will be updated. This new preconfiguration file 2 can indicate that the cIPX does not provide services related to the "corresponding IE type".

[0317] It should be understood that the indication in pre-configuration file 1 that encryption is not required for a certain IE type means that the IE type can be encrypted or not, and the specific encryption or non-encryption can be determined during the N32-c handshake process. It should be understood that whether IPX requires encryption for IE is determined based on the services provided by IPX, and this application does not limit this.

[0318] For example, assume that cIPX can provide SUPI-based routing services, where preconfigured file 1 indicates that SUPI encryption is not required, and the negotiated protection policy is that SUPI needs to be encrypted. Therefore, cSEPP will encrypt SUPI according to the protection policy and carry the encrypted SUPI in an HTTP request message to cIPX. When cIPX receives the HTTP request message, if cIPX determines that the SUPI in the HTTP request message is encrypted, cIPX will be unable to provide the SUPI-based routing service. Therefore, cIPX will send an error message carrying "an IE is encrypted while it was expected to be available in the clear" to cSEPP. After cSEPP obtains the error type, it can renegotiate the protection policy based on the instruction of preconfigured file 1, and the new protection policy is that SUPI does not need to be encrypted.

[0319] In possible scenario 2, when IPX determines that a message that should have been encrypted was transmitted in plaintext, the error type can be described as "an IE is not encrypted while its availability in the clear is not required." Accordingly, after cSEPP detects this error type, it can reestablish the N32 connection. Specifically, cSEPP can renegotiate the protection policy based on the instructions in preconfiguration file 1: If preconfiguration file 1 indicates that encryption is not required for the corresponding IE type (here, "corresponding IE type" refers to the IE that should have been encrypted), the new protection policy can be to encrypt the corresponding IE type.

[0320] For example, suppose cIPX requires that the user location should be transmitted encrypted, where preconfiguration file 1 indicates that mandatory encryption of the user location is not required, and the negotiated protection policy is that the user location does not need to be encrypted. Therefore, cSEPP will transmit the user location in plain text (i.e., encrypt the user location) according to the protection policy, and carry the plain text user location in an HTTP request message to cIPX. When cIPX receives the HTTP request message, if cIPX determines that the user location in the HTTP request message is not encrypted, and cIPX requires that the user location should be transmitted encrypted, then cIPX will send an error message carrying "an IE is not encrypted while its availability in the clear is not required" to cSEPP. After cSEPP obtains this error type, it can renegotiate the protection policy based on the indication of preconfiguration file 1, and the new protection policy is that the user location needs to be encrypted.

[0321] In one possible scenario, Scenario 3, when the IPX determines that the network topology of the PLMN where the cSEPP is located is not hidden, the error type may be described as "Network Topology is not hidden." Accordingly, after the cSEPP detects this error type, it resends the HTTP request message with the network topology hidden in the resent HTTP request message. Alternatively, the cSEPP may re-sign with the cIPX to indicate that the network topology hiding determination service is not required. Therefore, the cSEPP may resend the HTTP request message with the network topology not hidden.

[0322] It is understood that the "network topology of the PLMN where the cSEPP is located" in the embodiments of the present application can be understood as a collection of multiple network function (NF) full qualified domain names (FQDNs). The multiple NF FQDNs are NF FQDNs corresponding to multiple NFs included in the PLMN where the cSEPP is located, with one NF FQDN corresponding to each NF. An NF FQDN consists of an NF ID and a local network domain name. With respect to an HTTP request message, "hiding the network topology" can be understood as the anonymous transmission of the NF identifier (i.e., NF ID) in the HTTP request message, i.e., the HTTP request message contains the anonymous NF identifier. For example, SEPP transforms the NF FQDN into a telescopic FQDN (the telescopic FQDN consists of an anonymous identifier for the NF and a local network domain name. The anonymous identifier for the NF is a parameter obtained by processing the NF ID through a first function (e.g., Nsepp_Telescopic_FQDN_Mapping)). Alternatively, SEPP uses its own implementation algorithm to replace the NF ID portion of the NF FQDN with a random number to obtain the anonymous NF identifier, and carries the transformed anonymous NF identifier in the HTTP request message. "Not hiding the network topology" can be understood as meaning that the NF identifier (i.e., NF ID) in the HTTP request message is not transmitted anonymously, that is, the HTTP request message contains the NF identifier in plaintext. For example, the NF FQDN is sent in the HTTP request message without transformation or with only a simple transformation (even after a simple transformation, the NF ID can still be identified, which is equivalent to not being anonymized). Therefore, IPX determines whether the network topology is hidden by determining whether the NF FQDN has been transformed into a telescopic FQDN or whether the NF ID portion of the NF FQDN has been replaced with a random number.

[0323] In one possible scenario 4, when IPX determines that the received message format is incorrect, the error type may be described as "Incorrect message format." Accordingly, after the cSEPP detects the error type, it may modify the message format and resend the HTTP request message, or it may cancel sending the HTTP request message.

[0324] In one possible scenario 5, when the IPX determines that the N32 connection cannot be maintained due to contractual reasons (e.g., the contract between the cSEPP and cIPX has expired or is about to expire, so cIPX no longer provides routing services for the cSEPP; or the contract between the pSEPP and pIPX has expired or is about to expire, so pIPX no longer provides routing services for the cSEPP; or the contract between the cSEPP and pSEPP has expired or is about to expire, and the cSEPP notifies the cIPX of its contract expiration, or the pSEPP notifies the pIPX of its contract expiration, so that the IPX determines that the N32 connection cannot be maintained), the error type may be described as "The N32 connection cannot be setup due to contractual reasons." Accordingly, after the cSEPP receives this error type, it may terminate the N32 connection. Optionally, in this scenario 5, the cSEPP may wait until the contract between the cSEPP and cIPX is re-signed, or until the contract between the pSEPP and pIPX is re-signed, before re-establishing the N32 connection.

[0325] In one possible scenario 6, when IPX determines that the N32 connection cannot be maintained due to a connection failure (e.g., a connection failure between cIPX and pIPX, a connection failure between pIPX and pSEPP, a failure of cIPX itself, or a failure of pIPX itself, all of which result in the N32 connection being unable to be maintained), the error type may be described as "the N32 connection cannot be setup due to a connectivity issue." Accordingly, after cSEPP obtains this error type, cSEPP may terminate the N32 connection.

[0326] In one possible scenario 7, when IPX determines that a message was not successfully transmitted / forwarded due to contractual reasons (e.g., the contract between cSEPP and cIPX has expired or is about to expire, or the contract between pSEPP and pIPX has expired or is about to expire), the error type may be described as "The HTTP request message was not delivered due to contractual reasons." Accordingly, after cSEPP detects this error type, it may terminate the N32 connection. Alternatively, in this scenario 7, cSEPP may wait until the contract between cSEPP and cIPX is re-signed, or until the contract between pSEPP and pIPX is re-signed, before re-establishing the N32 connection.

[0327] In one possible scenario 8, when IPX rejects a request containing certain IE(s) (e.g., SUPI), the error type may be described as "NF request is rejected / disallowed." Accordingly, after cSEPP receives this error type, it may cancel sending the HTTP request message. Alternatively, cSEPP may re-sign with cIPX to obtain a new provisioning profile 2, instructing cIPX to provide services for the corresponding IE type, or instructing cIPX not to provide services associated with the corresponding IE type (here, "corresponding IE type" refers to an IE that may be rejected) (so that IPX cannot reject requests associated with the IE). Therefore, cSEPP may resend the HTTP request message.

[0328] For example, when cIPX provides user-level roaming services, cIPX can screen users who are allowed to roam and provide services to them. If cIPX finds that a user (such as SUPI 1) is not allowed to roam, cIPX will send an error message including "NF request is rejected / disallowed." Therefore, cSEPP can re-sign with cIPX to obtain a new provisioning profile 2. This new provisioning profile 2 can instruct cIPX to open / provide roaming services for SUPI 1. Therefore, cSEPP can resend the HTTP request message containing SUPI 1.

[0329] In one possible scenario 9, when the IPX fails to query the hPLMN to which the Generic Public Subscription Identifier (GPSI) carried in the HTTP request message actually belongs, the error type may be described as "PLMN not found." Accordingly, after the cSEPP obtains this error type, it cancels sending the HTTP request message.

[0330] For example, in the HTTP request message transmission in the number portability scenario, if the IPX fails to query the hPLMN to which the GPSI carried in the HTTP request message currently actually belongs from the UDM of the hPLMN, the HTTP request message will not be delivered normally. In this case, the IPX can send a "PLMN not found" message to the cSEPP, so that the cSEPP can cancel the sending of the HTTP request message. For example, assume that the vPLMN is Carrier A in Country M, hPLMN 1 is Carrier B in Country Z, and hPLMN 2 is Carrier C. Carrier B is the carrier before the user ported their number, and Carrier C is the carrier after the user ported their number. Suppose that the user sends an HTTP request message to hPLMN 1 in the vPLMN, carrying the GPSI (the GPSI suffix still identifies hPLMN 1). Therefore, the IPX will query the UDM of hPLMN 1 to determine which carrier the user belongs to. Since the user has already ported their number (i.e., the actual hPLMN they currently belong to is hPLMN 2), the IPX will not be able to query the UDM of hPLMN 1 to determine the carrier they belong to. In this case, the error type is "PLMN not found." Here, the IPX can be the IPX in Carrier A in Country M or the IPX in Carrier B, without restriction.

[0331] In one possible scenario 10, when IPX determines that routing fails based on SUPI, the error type may be described as "Routing failure." Alternatively, when IPX determines that SUPI translation fails, the error type may be described as "SUPI translation failure." Alternatively, when IPX determines that roaming is not allowed based on SUPI, the error type may be described as "Roaming not allowed." Accordingly, after receiving any of the above error types, the cSEPP may also cancel sending the HTTP request message.

[0332] For example, assuming that cIPX can provide SUPI translation service, when cIPX receives an HTTP request message carrying SUPI 1, if cIPX cannot complete the translation of SUPI 1, for example, the SUPI translation list of cIPX does not include the translated information corresponding to SUPI 1, the error type is "SUPI translation failure".

[0333] Optionally, when the error message generated is ProblemDetails (i.e., implementation 4 or 5 above), invalidParams in ProblemDetails can be defined as follows:

[0334] When the error type is "an IE is encrypted while it was expected to be available in the clear", "an IE is not encrypted while its availability in the clear is not required", or "an IE is encrypted while it was expected to be available in the clear", invalidParams is the IE that caused the error. For example, when IPX finds that SUPI should be encrypted but SUPI is not encrypted, invalidParams is SUPI.

[0335] When the error type is "the N32 connection cannot be setup due to a connectivity issue", "the message was not delivered due to contractual reasons", or "Incorrect message format", invalidParams is set to empty;

[0336] When the error type is "Network Topology is not hidden", invalidParams is the unhidden NF FQDN;

[0337] When the error message type is "NF request is rejected / disallowed", invalidParams is the IE that caused the NF to be rejected;

[0338] When the error type is "PLMN not Found", invalidParams is GPSI;

[0339] When the error type is "Routing failure", "SUPI translation failure", or "Roaming not allowed", invalidParams is SUPI.

[0340] Please refer to Figure 8, which is another interactive flow diagram of the communication method provided by an embodiment of the present application. As shown in Figure 8, the communication method includes the following steps S800 to S806. The execution subject of the method shown in Figure 8 can be cSEPP, pSEPP and IPX, or the execution subject of the method shown in Figure 8 can also be a chip in cSEPP, a chip in pSEPP and a chip in IPX. For the convenience of description, Figure 8 mainly uses cSEPP, pSEPP and IPX as the execution subject of the method for example. It should be noted that Figure 8 is a schematic flow chart of an embodiment of the method of the present application, showing the detailed communication steps or operations of the method, but these steps or operations are only examples. The embodiment of the present application can also perform other operations or variations of the various operations in Figure 8. In addition, the various steps in Figure 8 can be executed in a different order from that presented in Figure 8, and it is possible that not all operations in Figure 8 need to be executed. Among them:

[0341] S800. The cSEPP uses the first N32-f context between the cSEPP and the pSEPP to perform security protection on the first HTTP request message to obtain the protected first HTTP request message.

[0342] For understanding of step S800, please refer to the description of the aforementioned step S700, which will not be repeated here.

[0343] S801: cSEPP sends a protected first HTTP request message to IPX. Correspondingly, IPX receives the protected first HTTP request message from cSEPP.

[0344] For understanding of step S801, please refer to the description of the aforementioned step S701, which will not be repeated here.

[0345] S802: The IPX determines first indication information according to the protected first HTTP request message, where the first indication information indicates a transmission error that occurs in the first HTTP request message.

[0346] The first indication information is carried in the error message. In addition, in the embodiment shown in FIG8 , the IPX may continue to add an error message after receiving the first protected HTTP request message, and then send the first protected HTTP request message and the error message together to the pSEPP. In other words, in this application, the IPX does not discard the first protected HTTP request message, but instead adds the error message after the first protected HTTP request message and sends it to the pSEPP.

[0347] It should be understood that IPX in this application can be cIPX and / or pIPX. Therefore, for the convenience of description, IPX will be used for unified description. For more understanding of IPX, please refer to the relevant description in S702 above, which will not be repeated here.

[0348] S803: IPX sends a third message to pSEPP. Correspondingly, pSEPP receives the third message from IPX.

[0349] The third message includes the original JSON block in the protected first HTTP request message and the JSON block corresponding to the error message. The following describes the format of the third message:

[0350] In one possible implementation (1), the third message generated by IPX may include two JSON blocks, one of which is the original JSON block, and the other is JSON block 8. JSON block 8 is the JSON block corresponding to the error message, and JSON block 8 includes the first indication information and a tag (i.e., the tag copied from the original JSON block). Optionally, JSON block 8 may also include information such as a JWS Signature (hereinafter referred to as JWS Signature 5 for ease of distinction). JWS Signature 5 is a signature generated after integrity protection is performed on the IEs in JSON block 8 that require integrity protection.

[0351] In a possible implementation (2), the third message generated by IPX may include three JSON blocks, one of which is the original JSON block, and the other two are JSON block 9 and JSON block 10.

[0352] JSON block 9 is a JSON block generated by normal IPX processing (e.g., the modificationsBlock generated by the processing performed in step 4 of FIG. 4 ). It differs from the JSON block in step 4 of FIG. 4 in that, in this embodiment of the present application, JSON block 9 may also include an additional indication (hereinafter referred to as the third indication for ease of distinction), indicating the presence of JSON block 10. Optionally, JSON block 9 may also include a JWS signature (hereinafter referred to as JWS signature 6 for ease of distinction), which may be a signature generated after integrity protection is performed on any IEs in JSON block 9 that require integrity protection.

[0353] JSON block 10 is the JSON block corresponding to the error message. JSON block 10 includes the first indication information and a tag (i.e., the tag copied from the original JSON block). Optionally, JSON block 10 may also include information such as a JWS signature (hereinafter referred to as JWS signature 7 for ease of distinction). JWS signature 7 may be a signature generated after integrity protection is performed on any IEs in JSON block 10 that require integrity protection.

[0354] S804. pSEPP parses the third message.

[0355] In some feasible implementations, pSEPP parsing the third message can be understood as: pSEPP first verifies the integrity of the IE that needs integrity protection in the original JSON block based on the tag in the original JSON block, and decrypts the ciphertext in the reformatted. If the integrity verification is successful and the decryption is successful, pSEPP continues to verify the integrity of the error message (i.e., performs integrity verification based on the JWS signature in the JSOS block corresponding to the error message), and after the verification is passed, pSEPP parses the first indication information (similar to step 8 in Figure 4), and then pSEPP sends the first indication information to cSEPP.

[0356] It should be understood that for the integrity verification based on tags and the integrity verification based on JWS signature, please refer to the relevant description in the aforementioned "5. JWE and JWS", which will not be repeated here.

[0357] S805: The pSEPP sends first indication information to the cSEPP, where the first indication information indicates a transmission error in the first HTTP request message. Correspondingly, the cSEPP receives the first indication information from the IPX.

[0358] In a possible implementation 1, the first indication information sent by the pSEPP to the cSEPP may be carried in reformattedData, and the aad or ciphertext in the reformattedData is used to carry the first indication information. That is, the pSEPP may send the first indication information to the cSEPP in a PRINS manner.

[0359] Optionally, in a possible implementation 2, pSEPP may send the first indication information to cSEPP through ProblemDetails. It should be noted that this implementation requires adding more first indication information (for example, one or more of the error types described in the aforementioned scenarios 1 to 10) to the description column in the aforementioned Table 1. Therefore, pSEPP may send the newly added first indication information to cSEPP through ProblemDetails.

[0360] Optionally, invalidParams in ProblemDetails can be defined as follows:

[0361] When the error type is "an IE is encrypted while it was expected to be available in the clear", "an IE is not encrypted while its availability in the clear is not required", or "an IE is encrypted while it was expected to be available in the clear", invalidParams is the IE that caused the error. For example, when IPX finds that SUPI should be encrypted but SUPI is not encrypted, invalidParams is SUPI.

[0362] When the error type is "the N32 connection cannot be setup due to a connectivity issue", "the message was not delivered due to contractual reasons", or "Incorrect message format", invalidParams is set to empty;

[0363] When the error type is "Network Topology is not hidden", invalidParams is the unhidden NF FQDN;

[0364] When the error message type is "NF request is rejected / disallowed", invalidParams is the IE that caused the NF to be rejected;

[0365] When the error type is "PLMN not Found", invalidParams is GPSI;

[0366] When the error type is "Routing failure", "SUPI translation failure", or "Roaming not allowed", invalidParams is SUPI.

[0367] Optionally, the present application may further define the error type indicated by the first indication information to be specifically placed in the title, detail, or cause of ProblemDetails, without specific limitation.

[0368] S806. The cSEPP performs an error response operation corresponding to the transmission error indicated by the first indication information.

[0369] It should be noted that the implementation of the cSEPP determining different types of response operations according to the received error type in step S805 is the same as the implementation of the cSEPP determining different types of response operations according to the received error type in step S704 in Figure 7 above, and will not be repeated here.

[0370] Please refer to Figure 9, which is another interactive flow diagram of the communication method provided by an embodiment of the present application. As shown in Figure 9, the communication method includes the following steps S900 to S904. The execution subject of the method shown in Figure 9 can be cSEPP, pSEPP and IPX, or the execution subject of the method shown in Figure 9 can also be a chip in cSEPP, a chip in pSEPP and a chip in IPX. For the convenience of description, Figure 9 mainly uses cSEPP, pSEPP and IPX as the execution subject of the method for example. It should be noted that Figure 9 is a schematic flow chart of an embodiment of the method of the present application, showing the detailed communication steps or operations of the method, but these steps or operations are only examples. The embodiment of the present application can also perform other operations or variations of the various operations in Figure 9. In addition, the various steps in Figure 9 can be executed in a different order from that presented in Figure 9, and it is possible that not all operations in Figure 9 need to be executed. Among them:

[0371] S900. The cSEPP uses the first N32-f context between the cSEPP and the pSEPP to perform security protection on the first HTTP request message to obtain the protected first HTTP request message.

[0372] For understanding of step S900, please refer to the description of the aforementioned step S800, which will not be repeated here.

[0373] S901: cSEPP sends a protected first HTTP request message to IPX. Correspondingly, IPX receives the protected first HTTP request message from cSEPP.

[0374] For understanding of step S901, please refer to the description of the aforementioned step S801, which will not be repeated here.

[0375] S902: The IPX determines first indication information according to the protected first HTTP request message, where the first indication information indicates a transmission error that occurs in the first HTTP request message.

[0376] For understanding of step S902, please refer to the description of the aforementioned step S802, which will not be repeated here.

[0377] S903: IPX sends a third message to pSEPP. Correspondingly, pSEPP receives the third message from IPX.

[0378] For understanding of step S903, please refer to the description of the aforementioned step S803, which will not be repeated here.

[0379] S904. The pSEPP parses the third message and performs an error response operation corresponding to the transmission error indicated by the first indication information.

[0380] Specifically, pSEPP parses the third message to obtain a JSON block including the original JSON block and a JSON block corresponding to the error message. Then, pSEPP parses the ciphertext and / or JsonPayload carried in the original JSON block and the first indication information carried in the JSON block corresponding to the error message.

[0381] It should be noted that in step S904, after the pSEPP parses the specific content included in the third message, the pSEPP itself performs the error response operation corresponding to the transmission error indicated by the first indication information. The implementation of the pSEPP performing different types of response operations based on the error type indicated by the first indication information in step S904 is similar to the implementation of the cSEPP performing different types of response operations based on the error type indicated by the first indication information in step S702 of FIG. 7 , with the following differences:

[0382] In scenario 1, scenario 2, scenario 5, scenario 6, or scenario 7, the pSEPP directly performs the corresponding error response operation in step S904. The manner in which the pSEPP performs the error response operation corresponding to scenario 1, scenario 2, scenario 5, scenario 6, or scenario 7 can be referred to the manner in which the cSEPP performs the error response operation corresponding to scenario 1, scenario 2, scenario 5, scenario 6, or scenario 7 in step S704, and is not further described here.

[0383] In scenario 3, scenario 4, scenario 8, scenario 9 or scenario 10, the pSEPP responds to the error message by sending an indication message to the cSEPP (hereinafter described as the fourth indication message for the convenience of distinction). The fourth indication message indicates that the error type of the transmission error is "Network Topology is not hidden", "Incorrect message format", "NF request is rejected / disallowed", "PLMN not Found", "Routing failure", "SUPI translation failure", or "Roaming not allowed", and the cSEPP then determines whether to send a second HTTP request message (i.e., resend the HTTP request message) or cancel the first HTTP request message (i.e., cancel the sending of the first HTTP request message).

[0384] It can be understood that the implementation method of the pSEPP sending the fourth indication information to the cSEPP in the embodiment of the present application is the same as the implementation method of the pSEPP sending the first indication information to the cSEPP in the aforementioned step S805, that is, the pSEPP can send the error type indicated by the fourth indication information to the cSEPP through PRINS, or the pSEPP sends the error type indicated by the fourth indication information to the cSEPP through ProblemDetails, which will not be repeated here.

[0385] The communication device provided in this application will be described in detail below with reference to FIG. 10 and FIG. 11 .

[0386] It is understood that in order to implement the functions in the above embodiments, the communication device includes hardware structures and / or software modules corresponding to the execution of each function. It should be readily apparent to those skilled in the art that, in combination with the units and method steps of each example described in the embodiments disclosed in this application, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in hardware or in a manner driven by computer software depends on the specific application scenario and design constraints of the technical solution.

[0387] Figures 10 and 11 are schematic diagrams of possible communication devices provided in embodiments of the present application. These communication devices can be used to implement the functions of a SEPP (e.g., the first SEPP or the second SEPP, etc.) or an IPX (e.g., the first IPX or the second IPX) in the above-described method embodiments, thereby also achieving the beneficial effects of the above-described method embodiments. In the embodiments of the present application, the communication device can be a cSEPP or pSEPP as shown in Figure 3, or a cIPX or pIPX as shown in Figure 3. Alternatively, the communication device can be a module (e.g., a chip) for use with a SEPP or IPX.

[0388] As shown in FIG. 10 , the communication device 1000 includes a processing unit 1010 and a transceiver unit 1020 .

[0389] When the communication device 1000 is used to implement the function of the first SEPP:

[0390] A processing unit 1010 is configured to securely protect a first Hypertext Transfer Protocol (HTTP) message using a first N32-f context between the first SEPP and the second SEPP, to obtain a protected first HTTP message, wherein the first HTTP message is used to implement a roaming service between the first SEPP and the second SEPP;

[0391] a transceiver unit 1020, configured to send the protected first HTTP message to an Internet Protocol exchange service IPX, wherein the IPX is configured to route messages sent from the first SEPP to the second SEPP;

[0392] The transceiver unit 1020 is configured to receive first indication information from the IPX, where the first indication information indicates a transmission error that occurred in the first HTTP message;

[0393] The processing unit 1010 is configured to execute an error response operation corresponding to the transmission error.

[0394] The error response operation includes any of the following:

[0395] The first SEPP and the second SEPP re-exchange parameters to obtain a second N32-f context between the first SEPP and the second SEPP, the first SEPP uses the second N32-f context to perform security protection on the first HTTP message to obtain a re-protected first HTTP message, and the first SEPP sends the re-protected first HTTP message to the IPX; or

[0396] The first SEPP modifies the first HTTP message according to the first indication information to obtain a second HTTP message. The first SEPP uses the first N32-f context to perform security protection on the second HTTP message to obtain a protected second HTTP message. The first SEPP sends the protected second HTTP message to the IPX.

[0397] When the communication device 1000 is used to implement the IPX function:

[0398] The transceiver unit 1020 is configured to receive a protected first Hypertext Transfer Protocol (HTTP) message from a first SEPP, where the protected first HTTP message is obtained by performing security protection on the first HTTP message based on a first N32-f context between the first SEPP and a second SEPP;

[0399] The transceiver unit 1020 is configured to send first indication information to the first SEPP, where the first indication information indicates a transmission error that occurred in the first HTTP message;

[0400] The transmission error includes one or more of the following:

[0401] The IPX requires that the unencrypted first information element IE be encrypted in the first HTTP message; or,

[0402] The second IE that the IPX requires to be encrypted is not encrypted in the first HTTP message; or

[0403] The network topology of the public land mobile network PLMN where the first SEPP is located is not hidden, and the network function fully qualified domain name NF in the first HTTP message belongs to the network topology of the PLMN where the first SEPP is located; or

[0404] The message format of the first HTTP message is not the first format.

[0405] For a more detailed description of the processing unit 1010 and the transceiver unit 1020 , reference may be made to the relevant description in any of the method embodiments shown in FIG. 7 to FIG. 9 .

[0406] As shown in Figure 11, communication device 1100 includes a processor 1110 and an interface circuit 1120. Processor 1110 and interface circuit 1120 are coupled to each other. It is understood that interface circuit 1120 may be a transceiver or an input / output interface. Optionally, communication device 1000 may further include a memory 1130 for storing instructions executed by processor 1110, input data required by processor 1110 to execute instructions, or data generated by processor 1110 after executing instructions.

[0407] When the communication device 1000 is used to implement any of the methods shown in FIG. 7 to FIG. 9 , the processor 1110 is used to implement the functions of the processing unit 1010 , and the interface circuit 1120 is used to implement the functions of the transceiver unit 1020 .

[0408] When the communication device is a chip used in a SEPP, the SEPP chip implements the functions of the SEPP in the above method embodiments. The SEPP chip receives information sent by the IPX to the SEPP through other modules in the SEPP (such as a radio frequency module or antenna); alternatively, the SEPP chip sends information to other modules in the SEPP (such as a radio frequency module or antenna), where the information is sent by the SEPP to the IPX.

[0409] When the communication device is a module for an IPX, the IPX module implements the IPX functionality described in the method embodiment. The IPX module receives information from other modules in the IPX (e.g., a radio frequency module or antenna), which is information sent by the SEPP to the IPX; or the IPX module sends information to other modules in the IPX (e.g., a radio frequency module or antenna), which is information sent by the IPX to the SEPP.

[0410] It is understood that the processor in the embodiments of the present application may be a central processing unit (CPU), or may be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0411] The method steps in the embodiments of the present application can be implemented in hardware or in software instructions that can be executed by a processor. The software instructions can be composed of corresponding software modules, which can be stored in a random access memory, a flash memory, a read-only memory, a programmable read-only memory, an erasable programmable read-only memory, an electrically erasable programmable read-only memory, a register, a hard disk, a mobile hard disk, a CD-ROM, or any other form of storage medium well known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. The storage medium can also be an integral part of the processor. The processor and the storage medium can be located in an ASIC. In addition, the ASIC can be located in an IPX or SEPP. The processor and the storage medium can also be present in an IPX or SEPP as discrete components.

[0412] In the above embodiments, all or part of the embodiments may be implemented using software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments may be implemented in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the embodiments of the present application are performed in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user device, or other programmable device. The computer program or instructions may be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another. For example, the computer program or instructions may be transferred from one website, computer, server, or data center to another website, computer, server, or data center via wired or wireless means. The computer-readable storage medium may be any available medium that can be accessed by a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; an optical medium, such as a digital video disk; or a semiconductor medium, such as a solid-state drive. The computer-readable storage medium may be a volatile or nonvolatile storage medium, or may include both volatile and nonvolatile types of storage media.

[0413] In the various embodiments of the present application, unless otherwise specified or there is a logical conflict, the terms and / or descriptions between different embodiments are consistent and can be referenced by each other. The technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.

[0414] It is understood that the various numbers used in the embodiments of this application are merely for ease of description and are not intended to limit the scope of the embodiments of this application. The order of the sequence numbers of the above-mentioned processes does not necessarily imply a specific order of execution; the order of execution of the processes should be determined by their functions and inherent logic.

Claims

1. A communication method, characterized in that: include: The first security edge protection proxy SEPP uses the first N32-f context between the first SEPP and the second SEPP to perform security protection on a first hypertext transfer protocol HTTP message to obtain a protected first HTTP message, wherein the first HTTP message is used to implement a roaming service between the first SEPP and the second SEPP; The first SEPP sends the protected first HTTP message to an Internet Protocol exchange service IPX, wherein the IPX is used to route the message sent by the first SEPP to the second SEPP; The first SEPP receives an error message from the IPX, where the error message includes first indication information, and the first indication information indicates a transmission error that occurs in the first HTTP message; The first SEPP performs an error response operation corresponding to the transmission error.

2. The method according to claim 1, characterized in that The error response operation includes any of the following: The first SEPP and the second SEPP re-exchange parameters to obtain a second N32-f context between the first SEPP and the second SEPP; The first SEPP uses the second N32-f context to perform security protection on the first HTTP message to obtain a re-protected first HTTP message; The first SEPP sends the re-protected first HTTP message to the IPX; or, The first SEPP modifies the first HTTP message according to the first indication information to obtain a second HTTP message; The first SEPP uses the first N32-f context to perform security protection on the second HTTP message to obtain a protected second HTTP message; The first SEPP sends the protected second HTTP message to the IPX.

3. The method according to claim 1 or 2, characterized in that: The first indication information indicates a transmission error that occurs in the first HTTP message, including: The first indication information indicates that the IPX requires that the unencrypted information element IE be encrypted in the first HTTP message; or, The first indication information indicates that the IPX information element IE requiring encryption is not encrypted in the first HTTP message.

4. The method according to claim 3, characterized in that The encryption policy for the IE in the first N32-f context is that the IE should be encrypted, and the encryption policy for the IE in the second N32-f context is that the IE should not be encrypted; or, The encryption policy for the IE in the first N32-f context is that the IE should not be encrypted, and the encryption policy for the IE in the second N32-f context is that the IE should be encrypted.

5. The method according to claim 4, characterized in that The first SEPP and the second SEPP re-exchange parameters to obtain a second N32-f context between the first SEPP and the second SEPP, including: The first SEPP sends a parameter exchange request to the second SEPP, wherein the encryption policy for the IE included in the parameter exchange request is that the IE should not be encrypted; The first SEPP receives a parameter exchange response from the second SEPP, wherein the encryption policy for the IE included in the parameter exchange response is that the IE should not be encrypted; or, The first SEPP sends a parameter exchange request to the second SEPP, wherein the encryption policy for the IE included in the parameter exchange request is that the IE should be encrypted; The first SEPP receives a parameter exchange response from the second SEPP, and the encryption policy for the IE included in the parameter exchange response is that the IE should be encrypted.

6. The method according to claim 1 or 2, characterized in that: The first indication information indicates a transmission error that occurs in the first HTTP message, including: When the protected first HTTP message includes a plain text identifier of a first network function NF, the first indication information indicates that a network topology of a public land mobile network PLMN where the first SEPP is located is not hidden, and the first NF is a network element requesting the roaming service.

7. The method according to claim 6, characterized in that The first SEPP modifies the first HTTP message according to the first indication information to obtain a second HTTP message, including: Anonymize the plain text identifier of the first NF in the first HTTP message to obtain an anonymous identifier of the first NF; The plain text identifier of the first NF in the first HTTP message is replaced with the anonymous identifier of the first NF to obtain the second HTTP message.

8. The method according to claim 1 or 2, characterized in that: The first indication information indicates a transmission error that occurs in the first HTTP message, including: The first indication information indicates that the message format of the first HTTP message is not a first format.

9. The method according to claim 8, characterized in that The first SEPP modifies the first HTTP message according to the first indication information to obtain a second HTTP message, including: The first SEPP converts the message format of the first HTTP message into the first format to obtain the second HTTP message.

10. The method according to claims 1-9, characterized in that The first SEPP receives first indication information from the IPX, including: The first SEPP receives a first message from the IPX, the first message includes problem details ProblemDetails, and the ProblemDetails includes the first indication information.

11. The method according to claim 10, characterized in that The ProblemDetails also includes a first signature corresponding to the first indication information, or the first message also includes a first signature corresponding to the first indication information; the first signature is used to protect the integrity of the first indication information; Before the first SEPP performs the error response operation corresponding to the transmission error, the method further includes: The first SEPP verifies the integrity of the first indication information according to the first signature to obtain a verification result; The first SEPP performs an error response operation corresponding to the transmission error, including: When the verification result is verification passed, the first SEPP performs an error response operation corresponding to the transmission error.

12. The method according to any one of claims 1 to 9, characterized in that: The first SEPP receives first indication information from the IPX, including: The first SEPP receives a second message from the IPX, where the second message includes the first indication information and first reformatted data reformattedData; The first indication information is obtained by parsing the first reformattedData.

13. The method according to claim 12, characterized in that The first reformattedData includes one or more of the following information: an N32-f context identifier n32fContextID, a message identifier messageId, or an authorized IPX identifier authorizedIpxId, wherein the n32fContextID is the identifier of the first N32-f context, the messageId is the identifier of the first HTTP message, and the authorizedIpxId is the identifier of the IPX; The obtaining the first indication information by parsing the first reformattedData includes: When n32fContextID in the first reformattedData is the same as n32fContextID in the first HTTP message, the first SEPP parses to obtain the first indication information in the second message; or, In the case where the messageId in the first reformattedData is the same as the messageId in the first HTTP message, the first SEPP parses to obtain the first indication information in the second message; or, When the authorizedIpxId in the first reformattedData is the same as the authorizedIpxId in the first HTTP message, the first SEPP parses to obtain the first indication information in the second message.

14. The method according to claim 13, characterized in that The messageId in the first reformattedData is used to determine the message in which the error occurs; when the messageId in the first reformattedData is the same as the messageId in the first HTTP message, the first SEPP determines that the message in which the transmission error occurs is the first HTTP message.

15. The method according to claim 12, characterized in that The first reformattedData does not include one or more of the following information: ciphertext, or Json load JsonPayload, wherein the ciphertext includes information obtained by encrypting the IE that needs to be encrypted in the first HTTP message based on the encryption policy in the first N32-f context, and the JsonPayload includes the IE that needs to be integrity protected in the first HTTP message; the IE that needs to be integrity protected in the first HTTP message is determined based on the integrity protection policy in the first N32-f context; The obtaining the first indication information by parsing the first reformattedData includes: In the case that the first reformattedData does not include ciphertext, the first SEPP parses to obtain the first indication information in the second message; or, When the first reformattedData does not include JsonPayload, the first SEPP parses to obtain the first indication information in the second message.

16. A communication method, characterized in that: include: The Internet Protocol exchange service IPX receives a protected first Hypertext Transfer Protocol HTTP message from a first security edge protection proxy SEPP, wherein the protected first HTTP message is obtained by performing security protection on the first HTTP message based on a first N32-f context between the first SEPP and a second SEPP; The IPX sends first indication information to the first SEPP, where the first indication information indicates a transmission error that occurs in the first HTTP message; The transmission error includes one or more of the following: The IPX requires that the information element IE that should not be encrypted be encrypted in the first HTTP message; or, The information element IE that the IPX requires to be encrypted is not encrypted in the first HTTP message; or The network topology of the public land mobile network PLMN where the first SEPP is located is not hidden; or, The message format of the first HTTP message is not the first format.

17. The method according to claim 16, characterized in that The IPX sends first indication information to the first SEPP, including: The IPX sends a second message to the first SEPP, where the second message includes the first indication information and first reformatted Data.

18. The method according to claim 17, characterized in that The first reformattedData includes one or more of the following information: an N32-f context identifier n32fContextID, a message identifier messageId, or an authorized IPX identifier authorizedIpxId, wherein the n32fContextID is the identifier of the first N32-f context, the messageId is the identifier of the first HTTP message, and the authorizedIpxId is the identifier of the IPX.

19. The method according to any one of claims 16 to 18, characterized in that: The IPX sends first indication information to the first SEPP, including: The IPX determines whether the IE in the protected first HTTP message is encrypted. If the IE is encrypted, the IPX sends first indication information to the first SEPP, wherein the first indication information indicates that the IPX requires that the IE that should not be encrypted be encrypted in the protected first HTTP message; or The IPX determines whether the IE in the protected first HTTP message is encrypted. If the IE is not encrypted, the IPX sends first indication information to the first SEPP, wherein the first indication information indicates that the IE that the IPX requires to be encrypted is not encrypted in the protected first HTTP message; or When the IPX determines that the protected first HTTP message includes a plain text identifier of a first network function NF, the IPX sends first indication information to the first SEPP, where the first indication information indicates that a network topology of a PLMN where the first SEPP is located is not hidden, and the first NF is a network element requesting the roaming service; or The IPX determines whether the name of the message format in the message header of the protected first HTTP message is the first format. If the name of the message format in the message header of the protected first HTTP message is not the first format, the IPX sends first indication information to the first SEPP, and the first indication information indicates that the message format of the protected first HTTP message is not the first format.

20. The method according to any one of claims 16 to 19, characterized in that: The method further comprises: The IPX receives a re-protected first HTTP message from the first SEPP, wherein the re-protected first HTTP message is obtained by performing security protection on the first HTTP message based on a second N32-f context between the first SEPP and the second SEPP, wherein the second N32-f context is obtained by re-exchanging parameters between the first SEPP and the second SEPP; The IPX sends the re-protected first HTTP message to the second SEPP.

21. The method according to any one of claims 16 to 19, characterized in that: The method further comprises: The IPX receives a protected second HTTP message from the first SEPP, wherein the protected second HTTP message is obtained by performing security protection on the second HTTP message based on the first N32-f context, and the second HTTP message is obtained by modifying the first HTTP message based on the first indication information; The IPX sends the protected second HTTP message to the second SEPP.

22. A communication device, comprising a module for executing the method according to any one of claims 1 to 15, or a module for executing the method according to any one of claims 16 to 21.

23. A communication device, characterized in that: The method comprises a processor and a memory, wherein the memory is used to store a computer program, and the processor is used to call the computer program from the memory to execute the method according to any one of claims 1 to 15, or to implement the method according to any one of claims 16 to 21.

24. A computer-readable storage medium, characterized in that: The storage medium stores a computer program or an instruction. When the computer program or the instruction is executed by the communication device, the method according to any one of claims 1 to 15 is implemented, or the method according to any one of claims 16 to 21 is implemented.

25. A computer program product, characterized in that The method comprises a computer program code, and when the computer program code is executed on a computer, the method according to any one of claims 1 to 15 is implemented, or the method according to any one of claims 16 to 21 is implemented.

26. A communication system, characterized in that: The method comprises a first security edge protection proxy SEPP and an Internet protocol exchange service IPX, wherein the first SEPP is used to implement the method according to any one of claims 1 to 15, and the IPX is used to implement the method according to any one of claims 16 to 21.

Images