Communication method and related device

Abstract

A communication method and related device, the method comprising: a first SEPP sending a protected first HTTP message to an IPX, the protected first HTTP message being determined after protecting the first HTTP message based on a first N32-f context; the first SEEP executes a corresponding error response operation based on a transmission error indicated by first indication information sent by the IPX, for example, the first SEEP and the second SEPP re-exchange parameters to obtain a second N32-f context, and after the first HTTP message is protected based on the second N32-f context, the re-protected first HTTP message is sent to the IPX, or the first SEEP modifies the first HTTP message to obtain a second N32-f context. And obtaining a second HTTP message, and after the second HTTP message is protected based on the first N32-f context, sending the protected second HTTP message to the IPX. According to the invention, normal communication can be maintained.

Description

Technical Field

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

[0002] Currently, in a roaming architecture, a consumer's SEPP (cSEPP) in a visited public land mobile network (vPLMN) can send a roaming message to a consumer IPX (cIPX), which then sends the roaming message to a producer IPX (pIPX), which finally sends the roaming message to a producer SEPP (pSEPP) in a home PLMN (hPLMN) to achieve the transmission of roaming messages between different PLMNs.

[0003] Currently, SEPP can detect errors that occur during the transmission of roaming messages and generate error messages to send to the peer SEPP. With the expansion of IPX functions, IPX may also detect errors and generate error messages, but the relevant standards currently do not define the response mechanism after IPX generates error messages, resulting in the inability of SEPPs in different PLMNs to communicate normally. Summary of the invention

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

[0005] In a first aspect, the present application provides a communication method, which is executed by a first SEPP, and the first SEPP may be the first SEPP itself, or a unit or module (such as a chip) with corresponding functions in the first SEPP. In the method, the first SEPP uses a 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 first indication information from the IPX, wherein the first indication information indicates a transmission error of the first HTTP message; and the first SEPP performs an error response operation corresponding to the transmission error.

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

[0007] The first SEEP 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,

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

[0009] In the present application, IPX may be cIPX or pIPX, and there is no limitation on this. It should be understood that the present application defines the operation mode of how SEPP responds after receiving the first indication information sent by IPX to indicate a transmission error, which is conducive to maintaining normal communication between SEPPs of different PLMNs.

[0010] In a possible design, the first indication information indicating a transmission error that occurs in the first HTTP message includes:

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

[0012] The first indication information indicates that the second IE that the IPX requires to be encrypted is not encrypted in the first HTTP message.

[0013] In this implementation, two new error types are proposed, namely: ① IPX determines whether the first IE in the first HTTP message after protection is encrypted. If the first IE is encrypted (i.e., IPX determines that the IE that should be transmitted in plain text is transmitted encrypted), IPX sends a first indication message to the first SEPP, and the first indication message indicates that IPX requires the first IE that is not encrypted to be encrypted in the first HTTP message after protection. ② IPX determines whether the second IE in the first HTTP message after protection is encrypted. If the second IE is not encrypted (i.e., IPX determines that the IE that should be transmitted in encrypted text is transmitted in plain text), IPX sends a first indication message to the first SEPP, and the first indication message indicates that IPX requires the second IE that is encrypted to be not encrypted in the first HTTP message after protection. For this error type ①, the first SEEP can transmit the first IE in the first HTTP message in plain text to solve the transmission error caused by this error type. For this error type ②, the first SEEP can transmit the second IE in the first HTTP message in encrypted text to solve the transmission error caused by this error type.

[0014] In a 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,

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

[0016] In one possible design, the first SEEP and the second SEPP re-exchange parameters to obtain a second N32-f context between the first SEPP and the second SEPP, including:

[0017] The first SEEP 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;

[0018] The first SEEP 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,

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

[0020] The first SEEP receives a parameter exchange response from the second SEEP, and the encryption policy for the second IE included in the parameter exchange response is to encrypt the second IE.

[0021] In a possible design, the first indication information indicating a transmission error that occurs in the first HTTP message includes:

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

[0023] In this implementation, a new error type is proposed, that is, the network topology of the PLMN where the first SEPP is located is not hidden. For this error type, the first SEEP can convert the plaintext identifier of the first NF in the first HTTP message into an anonymous identifier of the first NF, and replace the plaintext identifier of the first NF in the first HTTP message with the anonymous identifier of the first NF to obtain a second HTTP message. The second HTTP message includes the anonymous identifier of the first NF, which means that the network topology of the PLMN where the first SEPP is located is hidden, thereby meeting the transmission requirements of the IPX, so that the IPX can correctly route the second HTTP message.

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

[0025] Anonymize the plain text identifier of the first NF in the first HTTP message to obtain an anonymous identifier of the first NF;

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

[0027] In a possible design, the first indication information indicating a transmission error that occurs in the first HTTP message includes:

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

[0029] In this implementation, a new error type is proposed, that is, the message format of the first HTTP message is not in the first format, where the first format may be a preset format, such as a JSON format. For this error type, the first SEEP may convert the message format of the first HTTP message into the first format to obtain a second HTTP message, thereby satisfying the IPX's requirement for transmitting messages in the first format, so that the IPX can subsequently correctly route the second HTTP message.

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

[0031] The first SEEP converts the message format of the first HTTP message into the first format to obtain the second HTTP message.

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

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

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

[0035] In a 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;

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

[0037] The first SEPP verifies the integrity of the first indication information according to the first signature to obtain a verification result;

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

[0039] When the verification result is verification passed, the first SEEP performs an error response operation corresponding to the transmission error.

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

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

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

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

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

[0045] In a 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 an identifier of the first N32-f context, the messageId is an identifier of the first HTTP message, and the authorizedIpxId is an identifier of the IPX;

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

[0047] 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,

[0048] 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,

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

[0050] In a possible design, 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 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 to be integrity protected in the first HTTP message; the IE to be integrity protected in the first HTTP message is determined based on the integrity protection policy in the first N32-f context;

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

[0052] 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,

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

[0054] In a second aspect, the present application provides a communication method, which is executed by an IPX, and the IPX may be the IPX itself, or a unit or module (such as a chip) in the IPX with corresponding functions. In the method, the IPX receives 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; the IPX sends first indication information to the first SEPP, wherein the first indication information indicates a transmission error that occurred in the first HTTP message. The transmission error includes one or more of the following:

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

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

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

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

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

[0060] 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, wherein the first indication information indicates that the IPX requires the unencrypted first IE to be encrypted in the protected first HTTP message; or

[0061] The IPX determines whether the second IE in the protected first HTTP message is encrypted, and if the second IE is not encrypted, the IPX sends first indication information to the first SEPP, wherein the first indication information indicates that the second IE that the IPX requires to be encrypted is not encrypted in the protected first HTTP message; or

[0062] 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

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

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

[0065] 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;

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

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

[0068] 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;

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

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

[0071] a processing unit, configured to perform security protection on 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;

[0072] 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;

[0073] 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;

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

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

[0076] The first SEEP 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,

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

[0078] In a possible design, the first indication information indicating a transmission error that occurs in the first HTTP message includes:

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

[0080] The first indication information indicates that the second IE that the IPX requires to be encrypted is not encrypted in the first HTTP message.

[0081] In a 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,

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

[0083] In one possible design, the transceiver unit is used to:

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

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

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

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

[0088] In a possible design, the first indication information indicating a transmission error that occurs in the first HTTP message includes:

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

[0090] In one possible design, the processing unit is used to:

[0091] Anonymize the plain text identifier of the first NF in the first HTTP message to obtain an anonymous identifier of the first NF;

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

[0093] In a possible design, the first indication information indicating a transmission error that occurs in the first HTTP message includes:

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

[0095] In one possible design, the processing unit is used to:

[0096] The message format of the first HTTP message is converted into the first format to obtain the second HTTP message.

[0097] In one possible design, the transceiver unit is used to:

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

[0099] In a 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;

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

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

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

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

[0104] In one possible design,

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

[0106] The processing unit is used to parse the first reformattedData to obtain the first indication information.

[0107] In a 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 an identifier of the first N32-f context, the messageId is an identifier of the first HTTP message, and the authorizedIpxId is an identifier of the IPX;

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

[0109] 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,

[0110] 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,

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

[0112] In a possible design, 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 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 to be integrity protected in the first HTTP message; the IE to be integrity protected in the first HTTP message is determined based on the integrity protection policy in the first N32-f context;

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

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

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

[0116] 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:

[0117] 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;

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

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

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

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

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

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

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

[0125] The processing unit is used to determine whether the first IE in the protected first HTTP message is encrypted. In the case that the first IE is encrypted, the transceiver unit is used 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

[0126] The processing unit is used to determine whether the second IE in the protected first HTTP message is encrypted. If the second IE is not encrypted, the transceiver unit is used to send first indication information to the first SEPP, where 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

[0127] 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

[0128] 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. When 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.

[0129] In one possible design, the transceiver unit is used to:

[0130] receiving 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;

[0131] The re-protected first HTTP message is sent to the second SEPP.

[0132] In one possible design, the transceiver unit is used to:

[0133] receiving 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;

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

[0135] 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 a method as described in any one of the first aspect or the second aspect.

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

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

[0138] In a possible design, the communication device further includes a memory. The processor is coupled to the memory, a computer program is stored in the memory, and the processor is further used to call the computer program in the memory. Optionally, the processor and the memory may also be integrated together.

[0139] 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 to 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 aspect or the second aspect through a logic circuit or executing code instructions.

[0140] In a seventh aspect, the present application provides a computer-readable storage medium, in which a computer program or instruction is stored. 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.

[0141] In an eighth aspect, the present application provides a computer program product. When a computer reads and executes the computer program product, the computer executes the method described in any one of the first aspect or the second aspect.

[0142] In a ninth aspect, the present application provides a communication system, comprising a communication device for implementing any one of the methods described in the first aspect above, and a communication device for implementing any one of the methods described in the second aspect above.

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

[0144] Figure 1a It is a schematic diagram of the architecture of a communication system applied in an embodiment of the present application;

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

[0146] Figure 2a It is a flowchart of protection strategy negotiation;

[0147] Figure 2b It is a flowchart of interrupting N32 connection;

[0148] Figure 3 It is a schematic diagram of PRINS;

[0149] Figure 4 It is a flow chart of N32-f message transmission;

[0150] Figure 5 It is a format diagram of reformattedData and modificationsBlock;

[0151] Figure 6 This is a diagram of the format of ProblemDetails;

[0152] Figure 7 It is a schematic diagram of an interaction process of the communication method provided in an embodiment of the present application;

[0153] Figure 8 is another interactive flow diagram of the communication method provided in an embodiment of the present application;

[0154] Fig. 9 It is another interactive flow diagram of the communication method provided in the embodiment of the present application;

[0155] Fig.10 is a schematic diagram of the structure of a possible communication device provided in an embodiment of the present application;

[0156] Fig.11 It is a schematic diagram of the structure of a possible communication device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0157] The specific embodiments of the present application are further described in detail below in conjunction with the accompanying drawings.

[0158] The terms "first" and "second" and the like in the specification, claims and drawings of this application are used to distinguish different objects, rather than to describe a specific order. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device comprising a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products or devices.

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

[0160] In the present application, "at least one (item)" means one or more, "more than one" means two or more, "at least two (items)" means two or three and more than three, and "and / or" is used to describe the association relationship of associated objects, indicating that three relationships may exist. 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.

[0161] In order to better understand the embodiments of the present application, the system architecture involved in the embodiments of the present application is first introduced below:

[0162] See also Figure 1a , Figure 1a Schematic diagram of the architecture of the communication system used in the embodiment of the present application. Figure 1aAs shown, 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 FIG. 1, collectively referred to as 110) and at least one terminal (such as 120a-120j in FIG. 1, collectively referred to as 120). The RAN 100 may also include other RAN nodes, such as a wireless relay device and / or a wireless backhaul device (not shown in FIG. 1). The terminal 120 is connected to the RAN node 110 in a wireless manner. The RAN node 110 is connected to the core network 200 in a wireless or wired manner. 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 the core network logical function and the radio access network logical function.

[0163] RAN 100 may be a cellular system related to the third generation partnership project (3GPP), for example, a 4G, 5G mobile communication system, or a future evolution system (for example, a 6G mobile communication system). RAN 100 may also be an open access network (open RAN, O-RAN or ORAN), a cloud radio access network (cloud radio access network, CRAN), or a wireless fidelity (wireless fidelity, WiFi) system. RAN 100 may also be a communication system that integrates two or more of the above systems.

[0164] The RAN node 110, which may also be sometimes referred to as an access network device, a RAN entity or an access node, constitutes a part of the communication system to help the terminal achieve wireless access. The multiple RAN nodes 110 in the communication system 1000 may be nodes of the same type or nodes of different types. In some scenarios, the roles of the RAN node 110 and the terminal 120 are relative, for example, Figure 1a The network element 120i may be a helicopter or a drone, which may be configured as a mobile base station. For the terminals 120j that access the RAN 100 through the network element 120i, the network element 120i is a base station; but for the base station 110a, the network element 120i is a terminal. The RAN node 110 and the terminal 120 are sometimes referred to as communication devices, for example Figure 1a The base stations 110a and 110b may be understood as communication devices having base station functions, and the terminals 120a-120j may be understood as communication devices having terminal functions.

[0165] In one possible scenario, the 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. The RAN node may be a macro base station (such as 110a in FIG. 1 ), a micro base station or an indoor station (such as 110b in FIG. 1 ), a relay node or a donor node, or a wireless controller in a CRAN scenario. Optionally, the RAN node may also be a server, a wearable device, a vehicle or an onboard device, etc. For example, the access network device in the vehicle to everything (V2X) technology may be a road side unit (RSU). All or part of the functions of the RAN node in the present application may also be implemented by software functions running on hardware, or by virtualization functions instantiated on a platform (such as a cloud platform). The RAN node in the present application may also be a logical node, a logical module or software that can implement all or part of the RAN node functions.

[0166] In another possible scenario, multiple RAN nodes collaborate to assist the terminal in achieving wireless access, and different RAN nodes respectively implement part of the functions of the base station. For example, the 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 here completes the functions of the radio resource control protocol and the packet data convergence layer protocol (PDCP) of the base station, and can also complete the function of the service data adaptation protocol (SDAP); the DU completes the functions of the radio link control layer and the medium access control (MAC) layer of the base station, and can also complete the functions of part of the physical layer or all of the physical layer. For the specific description of the above-mentioned various protocol layers, please refer to the relevant technical specifications of the 3rd Generation Partnership Project (3GPP). The CU and DU can be set separately, or can also be 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).

[0167] Optionally, the RAN node may also be expressed in different ways, such as access network equipment. Unless otherwise specified in this application, access network equipment is used for expression.

[0168] 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, CU, CU-CP, CU-UP, DU and RU are described as examples in this application. Any unit of CU (or CU-CP, CU-UP), DU and RU in this application may be implemented by a software module, a hardware module, or a combination of a software module and a hardware module.

[0169] The 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, for example, device-to-device (D2D), vehicle to everything (V2X) communication, machine-type communication (MTC), Internet of Things (IOT), virtual reality, augmented reality, industrial control, automatic driving, telemedicine, smart grid, smart furniture, smart office, smart wear, smart transportation, smart city, etc. The terminal may be a mobile phone, a tablet computer, a computer with wireless transceiver function, a wearable device, a vehicle, a drone, a helicopter, an airplane, a ship, a robot, a mechanical arm, a smart home device, etc. The embodiments of the present application do not limit the device form of the terminal.

[0170] The core network may include one or more functional entities (or core network elements, network elements, entities, network functions, logical network elements, etc.), such as network slice selection function (NSSF), network exposure function (NEF), network storage 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.

[0171] For example, see Figure 1b , Figure 1b This is a schematic diagram of the 5G system roaming architecture. Figure 1bAs shown, 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), wherein 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).

[0172] In the present application, vSEPP may also be replaced by consumer's SEPP (cSEPP), and hSEPP may also be replaced by producer's SEPP (pSEPP).

[0173] 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 connection, 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 the N32 signaling message with an incorrect format, or refuse to receive the JSON block containing "encBlockIndex", or have topology hiding and other functions.

[0174] The N32 interface is used to implement the roaming message transmission function 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 through the cSEPP, and the pSEPP forwards the roaming message to the producer network function (pNF), thereby realizing the transmission 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. 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 via the SEPP agent in the main authentication process.

[0175] Two logical interfaces are required to implement roaming message transmission between SEPPs based on the N32 interface, namely N32-c and N32-f. N32-c is used to manage N32 connections, and N32-f is used to transmit roaming messages between cSEPP and pSEPP. The concepts related to N32-c and N32-f will be introduced separately in the following text, and will not be described in detail here.

[0176] Understandable, Figure 1b For other network elements / devices and interfaces shown in , please refer to the introduction in TS23.501, and this application will not describe them in detail here.

[0177] It should be noted that the above functional entity is only a name, and the name itself does not limit the entity. For example, the session management function may also be replaced by "session management function entity" or other names. Moreover, the session management function entity may also correspond to an entity including other functions in addition to the session management function. The user plane function may also be replaced by "user plane function entity" or other names, and the user plane function entity may also correspond to an entity including other functions in addition to the user plane function. A unified explanation is given here, and no further description is given below.

[0178] 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 merely examples, and other names may be used in specific implementations, and the embodiments of the present application do not impose any specific limitations on this.

[0179] In this application, "sending information to...(terminal)" can be understood as the destination of the information being the terminal. It 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 be processed as necessary 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.

[0180] It should be understood that the SEPP in the embodiment of the present application can be any of the above-mentioned devices or chips, and the specific details are not limited here. Whether as a device or as a chip, the SEPP can be manufactured, sold or used as an independent product. In this embodiment and subsequent embodiments, only SEPP is used as an example for introduction.

[0181] It should be understood that the device for implementing the function of IPX in the embodiment of the present application may be IPX itself, or may be a device capable of supporting IPX to implement the function, such as a chip system or a combination device or component capable of implementing the function of IPX, and the device may be installed in IPX. In the embodiment of the present application, the chip system may be composed of a chip, or may include a chip and other discrete devices. In this embodiment and subsequent embodiments, only IPX is used as an example for introduction.

[0182] IPX is an inter-service provider network node that can connect to mobile network operators (MNO), namely PLMN operators, fixed network operators (FNO), Internet service providers (ISP), etc. It is mainly used to provide routing services, modification services, monitoring services, etc. for roaming messages. 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, whether an NF message can be forwarded, etc. If the judgment fails, IPX can generate an error message and send the error message to SEPP.

[0183] It should be noted that the IPX involved in the embodiment of the present application may also be a roaming hub (RH), because the RH can be deployed on the IPX, and the RH implements the roaming service, or the RH may directly replace the function of the IPX in the future. However, for the convenience of description, the following mainly takes the IPX as an example for schematic description.

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

[0185] 1. Pre-configuration file

[0186] 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 the 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 clearly indicate that the SUPI needs to be encrypted. In other words, the protection policy negotiated in the N32-c handshake process is subject to the constraints of 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.

[0187] A contract may also be signed between the operator to which the first SEPP belongs and the roaming intermediate 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), the inspection policy of the first IPX (for example, the message format required by the first IPX, whether the network topology is required to be hidden, and which IE-related messages are allowed / not allowed to be forwarded), etc.

[0188] Similarly, a contract may be signed between the operator to which the second SEPP belongs and the roaming intermediate service provider that deploys the second IPX. The contract corresponds to the pre-configuration file 3, which 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), the inspection policy of the first IPX (for example, the message format required by the first IPX, whether the network topology is required to be hidden, and which IE-related messages are allowed / not allowed to be forwarded), etc.

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

[0190] SEPP manages N32 connection through N32-c handshake process, and N32-c handshake process mainly includes security capability negotiation process, parameter exchange process, N32-f context termination process (wherein N32-f context termination process is used to terminate N32-f message transmission and delete N32-f context), etc. After the security capability negotiation process and parameter exchange process are executed between the first SEPP and the second SEPP, N32-f context can be generated, and the first SEPP and the second SEPP can store the N32-f context respectively. Therefore, the first SEPP can subsequently perform security protection on the roaming message sent by the first SEPP based on the generated N32-f context, or the second SEPP can perform security protection on the roaming message sent by the first SEPP based on the generated N32-f context.

[0191] The security capability negotiation process is used to negotiate the security capabilities supported by SEPP, namely the protocol for N32 interconnect security (PRINS) or the 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 PRINS process will be focused on later.

[0192] The parameter exchange process has three sub-processes, namely, the cipher suite negotiation (or negotiated cipher suite), the protection policy negotiation (or negotiated protection policy), and the security information list exchange process. Among them, the cipher suite negotiation process negotiates the cipher suite used for roaming message protection, and also exchanges the N32-f contextID of both parties (for example, the first SEPP and the second SEPP). The protection policy negotiation process negotiates the encryption policy of the data type (that is, indicating which data type needs encryption protection) and the modification policy (that is, indicating which data type can be modified by IPX). Here we focus on the protection policy negotiation process, such as Figure 2a As shown:

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

[0194] In step 2a, the second SEPP sends a 200ok status code and the protection policy selected by the second SEPP to the first SEPP through the N32-c interface, and the 200ok status code indicates that the parameter exchange request is successfully processed. Generally speaking, the protection policy selected by the second SEPP can be equal to 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.

[0195] Step 2b: The second SEPP sends a 4XX / 5XX status code to the first SEPP through the N32-c interface, where the 4XX / 5XX status code indicates that the parameter exchange request processing fails.

[0196] 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 strategy, modification strategy, etc. negotiated in the parameter exchange process.

[0197] 3. Disconnect N32

[0198] The process of interrupting N32 connection is as follows Figure 2b As shown:

[0199] Step 1: The first SEPP sends an n32-f interruption request to the second SEPP through the N32-c interface. The n32-f interruption request carries an IE called "N32-f context id". It should be understood that after the second SEPP receives the n32-f interruption request, the second SEPP stops sending all messages that should have been sent to the first SEPP through N32-f, and deletes the security context corresponding to the N32-f context id. For the first SEPP, the first SEPP also stops sending all messages that should have been sent to the second SEPP through N32-f, and deletes the security context corresponding to the local N32-f context id.

[0200] Step 2a: The second SEPP sends a successful interruption message to the first SEPP through the N32-c interface, where the message carries "N32-f context id".

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

[0202] 4. N32-f message delivery process

[0203] Here we mainly introduce the PRINS process. The overview of PRINS and the N32-f message delivery process are as follows: Figure 3 and Figure 4 As shown. Figure 3 As shown in the figure, PRINS includes cNF, cSEPP, consumer IPX (consumer's IPX, cIPX), producer IPX (producer's IPX, pIPX), pSEPP, and pNF. Among them, cNF and cSEPP belong to vPLMN, and pSEPP and pNF belong to pPLMN. The following mainly describes the PRINS process based on the roaming process from cSEPP to pSEPP. The roaming process from pSEPP to cSEPP is a symmetric process with the roaming process from cSEPP to pSEPP, and will not be described in detail later. Figure 4 As shown:

[0204] Step 1: The cNF sends a hypertext transfer protocol (HTTP) request message to the cSEPP. Correspondingly, the cSEPP receives the HTTP request message from the cNF.

[0205] For example, taking the HTTP request message as the protocol data unit (PDU) session establishment process, in which 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 request message to create a PDU session management context to the cSEPP. The request message to create a PDU session management context carries parameters such as SUPI, data network name (DNN), and user location information (UE Location Information), which can all be called information elements (IE).

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

[0207] It should be understood that the function of cSEPP is to protect the HTTP request message from being leaked and tampered during transmission. Therefore, after receiving the HTTP request message, cSEPP can first rewrite the HTTP request message into a JavaScript object notation (JSON) block (this is to facilitate the subsequent JSON web encryption (JWE) protection), where JSON is a format for information description. Then, cSEPP determines which IEs in the HTTP request message need encryption protection and which IEs need integrity protection (also referred to as complete protection) according to the protection strategy negotiated in the aforementioned N32-c handshake process. Therefore, cSEPP can use JWE to encrypt the above IEs that need encryption protection, and perform integrity protection on the IEs that need integrity protection to generate a protected HTTP request message. Here, the protected HTTP request message generated in step 2 can be understood as an HTTP message containing a JSON block (for ease of distinction, it is described as an original JSON block in the following, and the original JSON block is reformattedData), the original JSON block contains a formatted request message, and the information in the original JSON block is protected by JWE.

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

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

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

[0211] Step 4: cIPX adds modifications to cIPX.

[0212] 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 aforementioned 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.

[0213] 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 at which position is modified and the modified value of the IE into a JSON block, and add the JSON block to the end of the original JSON block. For example, assuming that the SUPI in the original JSON block is SUPI 1, cIPX indicates that the value of SUPI needs to be modified to SUPI 2.

[0214] Step 5: cIPX sends the HTTP request message with the protection modified by cIPX to pIPX.

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

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

[0217] It should be understood that, like 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), and the added JSON block is integrity protected by pIPX according to JWS.

[0218] For example, when pIPX receives a request message for creating a PDU session management context, pIPX will also provide a DNN conversion service, re-determine the appropriate DNN according to the load of different DNNs, user location information, or provide other services, etc. Exemplarily, if pIPX wants to modify the value of a certain IE (such as DNN) in the request message for creating a PDU session management context, pIPX needs to write the IE at which position is modified and the modified value of the IE into a JSON block, and add 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 DNN2.

[0219] Step 7, pIPX sends the protected HTTP request message with the cIPX modification and the pIPX modification added to pSEPP. Correspondingly, pSEPP receives the message from pIPX.

[0220] 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 decrypted content of the original JSON block.

[0221] That is, the function of pSEPP is to verify the integrity of messages protected by JWE and JWS, decrypt messages protected by JWE, and modify HTTP request messages based on the modification description of IPX. Specifically, pSEPP first verifies the integrity of the JSON block generated by pIPX and cIPX based on JWS, then verifies the integrity protection information generated in cSEPP based on JWE, and decrypts the ciphertext at the same time. Then pSEPP obtains the modification instructions from the JSON block generated by pIPX and cIPX, and under the specification of the modification policy negotiated by N32-c before, pSEPP modifies the IE at the corresponding position based on the modification instructions. Finally, pSEPP restores the message to a message in HTTP format (i.e., reconstructs the HTTP request message) and sends them to pNF.

[0222] For example, pSEPP can recover / reconstruct the 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 that the SUPI in the original JSON block is SUPI 1 and the DNN is DNN1, where cIPX indicates that the value of SUPI needs to be modified to SUPI 2, and pIPX indicates that the value of DNN needs to be modified 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.

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

[0224] 5. JWE and JWS

[0225] JWE and JWS are two protection algorithms, where JWE is used by SEPP to encrypt and integrity protect the corresponding IE, or to only perform integrity protection on the corresponding IE, and JWS is used by IPX (such as cIPX or pIPX) to perform integrity protection on roaming modification messages. The JSON format message protected by JWE is called reformattedData, and the JSON format message protected by JWS is called modificationsBlock.

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

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

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

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

[0230] (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;

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

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

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

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

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

[0236] (2) JWS signature, used for JWS integrity verification. Specifically, JWS signature is the information / signature generated after integrity protection is performed on the IE in the modificationsBlock that needs integrity protection. When performing integrity verification based on JWSsignature, it is necessary to compare whether the signature is equal to the signature 2 generated by JWS. If they are equal, the integrity verification passes. Specifically, signature 2 is the information generated by JWS for the IE in the modificationsBlock that needs integrity protection.

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

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

[0239] 6. Error message transmission between SEPPs

[0240] As shown in Table 1, 3GPP TS29.573 has defined the error type between SEPPs, which is transmitted through ProblemDetails. It should be understood that ProblemDetails is also a JSON block. For example, see Figure 6 , Figure 6 This is a diagram of the format of ProblemDetails.

[0241] ProblemDetails includes:

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

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

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

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

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

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

[0248] Table 1 Error types

[0249]

[0250] It should be noted that, with the increase in user demand, IPX may provide error message generation services in addition to routing services, modification services, and monitoring services. For example, IPX can determine whether a message that should be transmitted encrypted is transmitted in plain text, and whether a message that should be transmitted in plain text is encrypted. If the judgment fails, IPX will generate an error message and send it to 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 the present 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. Among them, the first IPX is the IPX deployed by the first roaming intermediate service provider on the first PLMN side, and the second IPX is the IPX deployed by the second roaming intermediate service provider on the second PLMN side. Among them, 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, and this application does not limit this.

[0253] It should be understood that, when the first PLMN is a vPLMN and the second PLMN is a 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 a pIPX, the second SEPP is a cSEPP, and the second IPX is a cIPX. Accordingly, the HTTP message sent by the first SEPP is an HTTP response message. For ease of understanding, the following mainly takes the first PLMN as a vPLMN and the second PLMN as an hPLMN for exemplary explanation.

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

[0255] See also Figure 7 , Figure 7 Schematic diagram of an interactive process of the communication method provided in the embodiment of the present application. Figure 7 As shown, the communication method includes the following steps S700 to S704. Figure 7 The method shown can be performed by cSEPP and IPX, or, Figure 7 The execution subject of the method shown can also be a chip in cSEPP and a chip in IPX. For the convenience of description, Figure 7 The following mainly uses cSEPP and IPX as examples of the execution subjects of the method. It should be noted that: Figure 7 is a schematic flow chart of a method embodiment of the present application, showing detailed communication steps or operations of the method, but these steps or operations are only examples, and the present application embodiment may also perform other operations or Figure 7 In addition, Figure 7 The steps in Figure 7are executed in a different order than those presented, and may not be executed in the order Figure 7 All operations in . 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 the understanding of the "N32-c handshake process" and the "N32-f context", please refer to the relevant description in the aforementioned "3. N32-c handshake process and N32-f context", which will not be repeated here. Generally speaking, the first N32-f context is stored in both the cSEPP and the pSEPP.

[0258] The first HTTP request message may be used to implement roaming services between cSEPP and pSEPP. For example, in the main authentication process, the first HTTP request message may be a user authentication request message, which is used to trigger the AUSF authentication service in the hPLMN. For another example, in the PDU session establishment process, the first HTTP request message may be a request message for creating a PDU session management context, which is used to create 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 cNF to cSEPP, such as the aforementioned Figure 4 In addition, the cSEPP uses the first N32-f context between the cSEPP and the pSEPP to perform security protection on the first HTTP request message, and the understanding of the protected first HTTP request message can be referred to the aforementioned Figure 4 The description of step 2 in the above is not repeated here.

[0260] It should be understood that the first HTTP request message after protection contains a JSON block, that is, 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 embodiment of the present application can be cIPX and / or pIPX. In a 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] It is understandable that after IPX receives the protected first HTTP request message from cSEPP, IPX can process the received message to determine whether an error occurs in its transmission / whether it meets IPX requirements. For example, IPX can determine whether an IE that should be transmitted encrypted is transmitted in plain text, or determine whether an IE that should be transmitted in plain text is encrypted. If the determination fails, IPX can generate first indication information and send the first indication information to cSEPP. Specifically, the first indication information can be carried in an error message.

[0265] In Example 1, assume that only one IPX is deployed in the network. Then:

[0266] 1-1: If only cIPX is deployed in the network, 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 in the network, then:

[0269] 2-1: cSEPP can send the protected first HTTP request message to cIPX, and cIPX determines 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, wherein 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, and then cIPX processes the message normally and sends it to pIPX for forwarding / sending (for example, the aforementioned Figure 4 The relevant description of step 4 in the above is not repeated here), and then pIPX determines whether an error occurs based on the received message. If pIPX determines that an error occurs, pIPX discards the received message and generates an error message and sends it to cIPX, which then forwards / sends the error message to cSEPP.

[0271] As can be seen from the above examples 1 and 2, the IPX that performs error judgment and generates an error message can be either cIPX or pIPX. Therefore, for the convenience of description, IPX is used for unified description in the following.

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

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

[0274] In one case 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 except the above ciphertext and / or JsonPayload. For example, the first part of the content includes tags, 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] The second part 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 described separately below and will not be described in detail here.

[0277] In a possible implementation 2, the error message generated by IPX may include two JSON blocks (hereinafter described as JSON block 2 and JSON block 3 for the convenience of distinction), wherein JSON block 2 includes the first part of the content, and JSON block 3 includes the second part of the content. It should be understood that in this implementation 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, the 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 JWSsignature 1 for the convenience of distinction), and other contents, which are not limited here. Exemplarily, the JWS signature 1 may be a signature generated after integrity protection is performed on the IE in the JSON block 3 that itself needs integrity protection, or the JWS signature 1 may also be a signature generated after integrity protection is performed on the IE in the JSON block 3 that needs integrity protection and the IE in the JSON block 2 that needs integrity protection.

[0278] In a possible implementation manner 3, the error message generated by IPX may include three JSON blocks (hereinafter respectively 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 content. For an introduction to the first part of content, please refer to the aforementioned relevant part and will not be repeated here.

[0280] JSON block 5 is the JSON block generated by normal IPX processing (for example, Figure 4 modificationsBlock) generated by the processing performed in step 4 of Figure 4The difference in step 4 is that in the embodiment of the present application, an indication information (hereinafter referred to as the second indication information for the convenience of distinction) may be added to the JSON block 5, and the second indication information indicates that there is also a JSON block 6. Optionally, the JSON block 5 may also include a JWS signature (hereinafter referred to as JWS signature 2 for the convenience of distinction), and the JWS signature 2 may be a signature generated after integrity protection is performed on the IE that needs integrity protection in the JSON block 5 itself, or the JWS signature 2 may be a signature generated after integrity protection is performed on the IE that needs integrity protection in the JSON block 4 and the IE that needs integrity protection in the JSON block 5, and the present application does not limit this.

[0281] JSON block 6 includes the second part of the content. In addition, the JSON block 6 may also include information such as tags (i.e. tags copied from the original JSON block), JWS signature (hereinafter referred to as JWS signature 3 for easy distinction). The JWS signature 3 may be a signature generated after integrity protection is performed on the IEs that need integrity protection in the JSON block 6 itself, or the JWS signature 3 may be a signature generated after integrity protection is performed on the IEs that need integrity protection in the JSON block 4 and the IEs that need integrity protection in the JSON block 6, etc. The specific details are determined based on the implementation and are not limited here.

[0282] In a possible implementation mode 4, IPX can reuse ProblemDetails to carry the first indication information, that is, the error message generated by IPX includes ProblemDetails, and the ProblemDetails includes the first indication information. It should be understood that in this implementation mode 4, the first indication information can be placed in the title, detail, or cause of ProblemDetails, without specific limitation. Optionally, the IE that causes the error type indicated by the first indication information to appear can be placed in invalidParams in ProblemDetails. The definition of invalidParams will be described in detail in the relevant part of S702, and no further explanation will be given here. It should be understood that in this implementation mode 4, the content in ProblemDetails is not integrity protected.

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

[0284] The first solution is to add a JSON block after ProblemDetails (to facilitate distinction, it will be described as JSON block 7 later), and the JSON block 7 includes the integrity protection information generated after integrity protection is performed on the IEs in ProblemDetails that need to be integrity protected (that is, to facilitate distinction, it will be referred to as JWS signature 4 later). For example, the content that needs integrity protection in ProblemDetails may be IEs such as title / detail / cause and invalidParams. Therefore, JWS can be used to perform integrity protection on title / detail / cause and invalidParams in ProblemDetails to generate JWS signature 4. It should be understood that in the 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 JWS signature 4 is carried in JSON block 7.

[0285] The second solution is to add a signature attribute in ProblemDetails, and the signature attribute includes JWSsignature 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 limitation. Optionally, the IE that causes the error type indicated by the first indication information to appear can be placed in invalidParams in ProblemDetails.

[0287] It should be noted that the error message in the above implementation methods 1 to 3 can also be called the second message, and the error message in the above implementation methods 4 to 5 can also be called the first message. For the convenience of description, they are uniformly expressed as "error message" 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 Figure 7 In the illustrated embodiment, the error message is a message sent by IPX to cSEPP in response to the first HTTP request message after protection sent by cSEPP. In step S703, IPX will not send the first HTTP request message after protection to cSEPP while sending the error message, and IPX will not continue to forward the first HTTP request message after protection received by it to pSEPP, that is, IPX will discard the first HTTP request message after protection received.

[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 executing the error response operation corresponding to the transmission error (or error type) indicated by the first indication information. Optionally, if there is integrity protection information (i.e., JWS signature) in the error message, 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 according to the corresponding JWS signature, and when the verification result is verification passed / successful, execute the error response operation corresponding to the transmission error (or error type) indicated by the first indication information. For the method of performing 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.

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

[0294] When the first part of the content is the above-mentioned situation 1 or situation 2, if cSEPP determines that the n32fContextID included in the first part of the content is the same as the n32fContextID included in the first protected HTTP request message sent by cSEPP, and / or, the messageId included in the first part of the content is the same as the messageId included in the first protected HTTP request message sent by cSEPP, and / or, the authorizedIpxId included in the first part of the content is the same as the authorizedIpxId included in the first protected HTTP request message sent by cSEPP, then 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 cSEPP itself.

[0295] It should be noted that when the error message is generated in the above implementation method 2 or implementation method 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 cSEPP can determine that the received error message is a message fed back by IPX in response to the protected first HTTP request message sent by cSEPP itself by determining that the tag in the error message is the same as the tag included in the protected first HTTP request message sent by cSEPP.

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

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

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

[0300] Error response operation type one: cSEPP and pSEPP renegotiate / exchange parameters to obtain a second N32-f context between cSEPP and pSEPP; cSEPP uses the second N32-f context to perform security protection on the first HTTP request message to obtain a re-protected first HTTP request message; cSEPP sends the re-protected first HTTP request message to IPX. In other words, cSEPP can update the N32-f context between cSEPP and pSEPP, and perform security protection on the first HTTP request message based on the updated N32-f context to obtain a re-protected first HTTP request message, and then send the re-protected first HTTP request message to IPX. Accordingly, IPX receives the re-protected first HTTP request message from the first SEPP, and sends the re-protected first HTTP request message to pSEPP. It can be understood that the process of cSEPP and pSEPP renegotiating / exchanging parameters to update the second N32-f context between cSEPP and pSEPP can be referred to the aforementioned Figure 2a .

[0301] For example, in a possible scenario 1, cSEPP can use the first N32-f context between cSEPP and pSEPP to perform security protection on the first HTTP request message to obtain the protected first HTTP request message, and then cSEPP can send the protected first HTTP request message to IPX, wherein the encryption policy for the first IE in the first HTTP request message in the first N32-f context is encryption. Therefore, after IPX receives the protected first HTTP request message, IPX can determine whether the first IE in the protected first HTTP request message is encrypted. In the case where the first IE is encrypted (this is because IPX requires that the first IE is not encrypted, but the first IE in the actually protected first HTTP request message is encrypted, and it is understandable that the requirement of IPX can be determined based on the preconfiguration file 2 / 3), IPX sends first indication information to cSEPP, and the first indication information indicates that IPX requires that the unencrypted first IE be encrypted in the protected first HTTP request message. Correspondingly, after cSEPP receives the first indication information, cSEEP and pSEPP re-exchange parameters to obtain the second N32-f context between cSEPP and pSEPP, cSEPP uses the second N32-f context to perform security protection on the first HTTP request message, obtains the re-protected first HTTP request message, and cSEPP sends the re-protected first HTTP request message to IPX. The encryption policy for the first IE in the second N32-f context is not to encrypt the first IE. Correspondingly, IPX receives the re-protected first HTTP request message from the first SEPP, and sends the re-protected first HTTP request message to 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 a possible scenario 2, cSEPP can use the first N32-f context between cSEPP and pSEPP to perform security protection on the first HTTP request message to obtain the protected first HTTP request message, and then cSEPP can send the protected first HTTP request message to IPX, wherein the encryption policy for the second IE in the first HTTP request message in the first N32-f context is not encrypted. Therefore, after IPX receives the protected first HTTP request message, IPX can determine whether the second IE in the protected first HTTP request message is encrypted. In the case where the second IE is not encrypted (this is because IPX requires the second IE to be encrypted, but the second IE in the actually protected first HTTP request message is not encrypted, and it is understandable that the requirement of IPX can be determined based on the preconfiguration file 2 / 3), IPX sends a first indication information to cSEPP, and the first indication information indicates that IPX requires the encrypted second IE to be not encrypted in the protected first HTTP request message. Correspondingly, after cSEPP receives the first indication information, cSEEP and pSEPP re-exchange parameters to obtain the second N32-f context between cSEPP and pSEPP, cSEPP uses the second N32-f context to perform security protection on the first HTTP request message, obtains the re-protected first HTTP request message, and cSEPP sends the re-protected first HTTP request message to IPX. The encryption policy for the second IE in the second N32-f context is to encrypt the second IE. Correspondingly, IPX receives the re-protected first HTTP request message from the first SEPP, and sends the re-protected first HTTP request message to pSEPP.

[0304] Optionally, the explanation of 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 can also be described as: cSEPP re-establishes the N32 connection with pSEPP, referred to as re-establishing the N32 connection (here, 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 the understanding of the N32-c handshake process, please refer to the introduction of the aforementioned "2. N32-c handshake process", which will not be repeated here.

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

[0307] Error response operation type 2: cSEPP processes / modifies the first HTTP request message according to the first indication information to obtain a second HTTP request message; 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; cSEPP sends the protected second HTTP request message to IPX. Accordingly, IPX receives the protected second HTTP request message from cSEPP and sends the protected second HTTP request message to pSEPP.

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

[0309] For example, in a possible scenario 3, when IPX determines that the protected first HTTP request message includes a plain text identifier of a cNF, IPX sends a first indication message to cSEPP, the first indication message indicating that the network topology of the PLMN where the cSEPP is located is not hidden, and the cNF is a network element requesting a roaming service. Accordingly, cSEEP may anonymize the plain text identifier of the cNF in the first HTTP request message to obtain an anonymous identifier of the cNF; cSEEP replaces the plain text identifier of the cNF in the first HTTP request message with the anonymous identifier of the cNF to obtain a second HTTP request message. Then, cSEPP may use the first N32-f context to perform security protection on the second HTTP request message to obtain a protected second HTTP request message, and then cSEPP may send the protected second HTTP request message to IPX. Accordingly, IPX receives the protected second HTTP request message from cSEPP, and sends the protected second HTTP request message to 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] Exemplarily, in a possible scenario 4, IPX determines whether the name of the message format in the message header of the first HTTP request message after protection is the first format. If the name of the message format in the message header of the first HTTP request message after protection is not the first format, IPX sends a first indication message to cSEPP, and the first indication message indicates that the message format of the first HTTP request message after protection is not the first format. Accordingly, cSEEP can convert the message format of the first HTTP request message into the first format according to the first indication message to obtain a second HTTP request message. Then, cSEPP can use the first N32-f context to perform security protection on the second HTTP request message to obtain the protected second HTTP request message, and then cSEPP can send the protected second HTTP request message to IPX. Exemplarily, the first format can be a JSON format. 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 three: cSEPP deletes the N32-f context between the first SEPP and the second SEPP. Optionally, the error response operation type three can also be described as cSEPP interrupting the N32 connection between the cSEPP and the pSEPP, referred to as interrupting the N32 connection (or interrupting the N32-f connection). For the process of "interrupting the N32 connection", please refer to the above Figure 2b , which will not be elaborated 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 a possible scenario 1, when IPX determines that a message that should be transmitted in plain text is transmitted encrypted, resulting in IPX being unable to provide services normally, the error type can be described as "an IE is encrypted while it was expected to be available in the clear". Accordingly, after cSEPP obtains the error type, cSEPP can re-establish the N32 connection or interrupt the N32 connection. Specifically, cSEPP can renegotiate the protection policy according to the instructions of the pre-configuration file 1: if the pre-configuration file 1 indicates that the corresponding IE type (here, "the corresponding IE type" is the IE that should be transmitted in plain text) is not required to be encrypted, then the new protection policy can be not to encrypt the corresponding IE type; if the pre-configuration file 1 indicates that the corresponding IE type is required to be encrypted, then: ① cSEPP can interrupt the N32 connection; or ② the operator to which cSEPP belongs can re-sign a contract with the operator to which pSEPP belongs. Based on the new contract, the pre-configuration file 1 in cSEPP and pSEPP will be updated, so cSEPP can re-establish the N32 connection with pSEPP according to the new pre-configuration file 1. Exemplarily, cSEPP can renegotiate the protection strategy based on the new pre-configuration file 1; or, ③ the operator to which cSEPP belongs can also re-sign a contract with the roaming intermediate 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 cSEPP. For example, the IPX that provides roaming services for cSEPP is cIPX, not pIPX. In other words, the adoption of ③ requires limiting the scenario. If the error message is generated by pIPX and sent to cSEPP, the operator to which cSEPP belongs will not update the contract with the pIPX operator, that is, the solution of ③ cannot be adopted. It should be noted that if the solution of ③ is adopted, after the contract is re-signed, the corresponding pre-configuration file 2 will be updated, and the new pre-configuration file 2 can indicate that cIPX does not provide services related to the "corresponding IE type".

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

[0318] For example, assume that cIPX can provide SUPI-based routing services, where preconfiguration file 1 indicates that mandatory encryption of SUPI 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, cSEPP can renegotiate the protection policy based on the indication of preconfiguration file 1, and the new protection policy is that SUPI does not need to be encrypted.

[0319] In a possible scenario 2, when IPX determines that a message that should be encrypted is transmitted in plain text, the error type can be described as "an IE is not encrypted while its availability in the clear is not required". Accordingly, after cSEPP obtains the error type, cSEPP can re-establish the N32 connection. Specifically, cSEPP can renegotiate the protection policy according to the instructions of pre-configuration file 1: if pre-configuration file 1 indicates that the corresponding IE type (here "corresponding IE type" is the IE that should be encrypted) does not need to be forced to be encrypted, the new protection policy can be to encrypt the corresponding IE type.

[0320] For example, assume that 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 transmitted 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 the error type, cSEPP 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 a possible scenario 3, when IPX determines that the network topology of the PLMN where cSEPP is located is not hidden, the error type can be described as "Network Topology is not hidden". Accordingly, after cSEPP obtains the error type, cSEPP resends the HTTP request message, and the network topology in the resent HTTP request message is hidden. Optionally, cSEPP can also re-sign with cIPX to indicate that the judgment service of network topology hiding is not required, so cSEPP can resend the HTTP request message, and the network topology in the HTTP request message is not hidden.

[0322] It is understandable that the "network topology of the PLMN where the cSEPP is located" in the embodiment of the present application can be understood as a set of multiple network function (NF) full qualified domain name (FQDN), and the multiple NF FQDNs are NF FQDNs corresponding to multiple NFs included in the PLMN where the cSEPP is located, one NF FQDN corresponding to one NF, and one NF FQDN consists of an NF ID and a local network domain name. For a certain HTTP request message, "hiding the network topology" can be understood as the NF identifier (i.e., NF ID) in the HTTP request message is transmitted anonymously, that is, the HTTP request message contains the anonymous identifier of the NF. For example, SEPP transforms the NF FQDN into a telescopic FQDN (the telescopic FQDN consists of an anonymous identifier of the NF and a local network domain name, and the anonymous identifier of the NF is a parameter obtained by processing the NF ID through the first function (such as Nsepp_Telescopic_FQDN_Mapping)), or SEPP replaces the NF ID part in the NF FQDN with a random number through its own implementation algorithm to obtain the anonymous identifier of the NF, and carries the transformed anonymous identifier of the NF in the HTTP request message. "Not hiding the network topology" can be understood as the identifier of the NF in the HTTP request message (i.e., NF ID) is not transmitted anonymously, that is, the HTTP request message contains the plain text identifier of the NF. For example, the NF FQDN is carried in the HTTP request message and sent without being transformed or only after a simple transformation (the NF ID can be identified only after a simple transformation, which is equivalent to not being anonymous). Therefore, the way for IPX to determine whether the network topology is hidden is to determine whether the NF FQDN is transformed into a telescopic FQDN, or to determine whether the NF ID part in the NF FQDN is replaced with a random number.

[0323] In a 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 cSEPP obtains the error type, cSEPP may modify the message format and resend the HTTP request message, or cSEPP may cancel sending the HTTP request message.

[0324] In a possible scenario 5, when IPX determines that the N32 connection cannot be maintained due to contractual reasons (for example, the contract between cSEPP and cIPX expires or is about to expire, so cIPX no longer provides routing services for cSEPP, or the contract between pSEPP and pIPX expires or is about to expire, so pIPX no longer provides routing services for cSEPP, or the contract between cSEPP and pSEPP expires or is about to expire, and cSEPP notifies cIPX of its contract expiration or pSEPP notifies pIPX of the contract expiration, so 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 cSEPP obtains the error type, cSEPP may interrupt the N32 connection. Optionally, in this scenario 5, cSEPP may also wait for the contract between cSEPP and cIPX to be re-signed, or the contract between pSEPP and pIPX to be re-signed before re-establishing the N32 connection.

[0325] In a possible scenario 6, when IPX determines that the N32 connection cannot be maintained due to a connection failure (for example, a connection failure between cIPX and pIPX, or a connection failure between pIPX and pSEPP, or a failure of cIPX itself, or a failure of pIPX itself, etc., which will cause the N32 connection to be 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 the error type, cSEPP may interrupt the N32 connection.

[0326] In a possible scenario 7, when IPX determines that the message was not successfully transmitted / forwarded due to contractual reasons (for example, the contract between cSEPP and cIPX expires or is about to expire, or the contract between pSEPP and pIPX expires or is about to expire), the error type can be described as "the HTTP request message was not delivered due to contractual reasons". Accordingly, after cSEPP obtains the error type, cSEPP can interrupt the N32 connection. Optionally, in this scenario 7, cSEPP can also wait for the contract between cSEPP and cIPX to be re-signed, or the contract between pSEPP and pIPX to be re-signed, and then re-establish the N32 connection.

[0327] In a possible scenario 8, when IPX rejects a request containing a certain IE / some IEs (such as SUPI), the error type may be described as "NF request is rejected / disallowed". Accordingly, after cSEPP obtains the error type, cSEPP may cancel sending the HTTP request message, or cSEPP may re-sign with cIPX to obtain a new provisioning profile 2 to instruct cIPX to open services for the corresponding IE type, or instruct cIPX not to provide services related to the corresponding IE type (here, "corresponding IE type" is an IE that may be rejected) (so that IPX cannot reject requests related to the IE), so 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 for them. When cIPX finds that a certain user (such as SUPI 1) is not allowed to roam, cIPX will send an error message including "NFrequest is rejected / disallowed". Therefore, cSEPP can re-sign with cIPX to obtain a new pre-configuration file 2, and the new pre-configuration file 2 can indicate that cIPX opens / provides roaming services for SUPI 1. Therefore, cSEPP can re-send the HTTP request message containing SUPI 1.

[0329] In a possible scenario 9, when IPX fails to query the hPLMN to which the generic public subscription identifier (GPSI) carried in the HTTP request message actually currently belongs, the error type can be described as "PLMN not found". Accordingly, after cSEPP obtains the error type, cSEPP cancels sending the HTTP request message.

[0330] For example, in the HTTP request message transmission in the number portability scenario, if the IPX does not 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 cannot be delivered normally. Then the IPX can send "PLMN not Found" to the cSEPP, so the cSEPP can cancel sending the HTTP request message. For example, assuming that vPLMN is the network of operator A in country M, hPLMN 1 is the network of operator B in country Z, and hPLMN 2 is operator C, where operator B is the operator before the user ported his number, and operator C is the operator after the user ported his number. Assuming that the user sent an HTTP request message to hPLMN 1 in vPLMN, and carried GPSI (the suffix of the GPSI still identifies hPLMN 1), the IPX will query the UDM of hPLMN 1 to which operator the user belongs. Since the user has ported his number (that is, the actual hPLMN currently belongs to is hPLMN 2), the IPX will not be able to query the operator to which the user belongs in the UDM of hPLMN 1, and the error type is "PLMN not Found". Here, the IPX can be the IPX in the network of operator A in country M, or the IPX in operator B, without restriction.

[0331] In a possible scenario 10, when IPX determines that routing fails based on SUPI, the error type may be described as "Routing failure", or when IPX determines that SUPI translation fails, the error type may be described as "SUPI translation failure", or 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, 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 implementation 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 empty;

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

[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] See also Figure 8 , Figure 8 is another interactive flow diagram of the communication method provided in the embodiment of the present application. Figure 8 As shown, the communication method includes the following steps S800 to S806. Figure 8 The method shown can be performed by cSEPP, pSEPP and IPX, or, Figure 8 The execution subject of the method shown can also be a chip in cSEPP, a chip in pSEPP and a chip in IPX. For the convenience of description, Figure 8 The following mainly uses cSEPP, pSEPP and IPX as examples of the execution subjects of the method. It should be noted that: Figure 8 is a schematic flow chart of a method embodiment of the present application, showing detailed communication steps or operations of the method, but these steps or operations are only examples, and the present application embodiment may also perform other operations or Figure 8 In addition, Figure 8 The steps in Figure 8 are executed in a different order than those presented, and may not be executed in the order Figure 8 All operations in . Among them:

[0341] S800. cSEPP uses the first N32-f context between cSEPP and 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, Figure 8 In the illustrated embodiment, IPX can continue to add an error message after receiving the first HTTP request message after protection, and then send the first HTTP request message after protection and the error message to pSEPP. That is to say, in the present application, IPX will not discard the first HTTP request message after protection, but will add the error message after the first HTTP request message after protection and send it to pSEPP.

[0347] It should be understood that IPX in the present application can be cIPX and / or pIPX, so for the convenience of description, IPX is used for unified description in the following. For more understanding of IPX, please refer to the related 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 format of the third message is described below:

[0350] In a 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, which is the JSON block corresponding to the error message, and 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 JWS Signature (hereinafter described as JWS Signature 5 for easy distinction), and JWSSignature 5 is a signature generated after integrity protection is performed on the IE in JSON block 8 that itself needs integrity protection.

[0351] In a possible implementation manner (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. Among them:

[0352] JSON block 9 is the JSON block generated by normal IPX processing (for example, Figure 4modificationsBlock) generated by the processing performed in step 4 of Figure 4 The difference in step 4 is that in the embodiment of the present application, an indication information (hereinafter referred to as the third indication information for the convenience of distinction) may be added to the JSON block 9, and the third indication information indicates that there is also a JSON block 10. Optionally, the JSON block 9 may also include a JWS signature (hereinafter referred to as JWSsignature 6 for the convenience of distinction), and the JWS signature 6 may be a signature generated after integrity protection is performed on the IE in the JSON block 9 that itself needs integrity protection.

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

[0354] S804. pSEPP parses the third message.

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

[0356] It should be understood that for the integrity check based on the tag and the integrity check based on the 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 that occurs 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 the 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 via 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) in the description column in the aforementioned Table 1. Therefore, pSEPP may send the newly added first indication information to cSEPP via 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 empty;

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

[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 also define that the error type indicated by the first indication information is 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 above Figure 7 The implementation of the cSEPP determining different types of response operations according to the received error types in step S704 is the same and will not be repeated here.

[0370] See also Fig. 9 , Fig. 9 FIG. 1 is another interactive flow diagram of the communication method provided in the embodiment of the present application. Fig. 9 As shown, the communication method includes the following steps S900 to S904. Fig. 9 The method shown can be performed by cSEPP, pSEPP and IPX, or, Fig. 9 The execution subject of the method shown can also be a chip in cSEPP, a chip in pSEPP and a chip in IPX. For the convenience of description, Fig. 9 The following mainly uses cSEPP, pSEPP and IPX as examples of the execution subjects of the method. It should be noted that: Fig. 9 is a schematic flow chart of a method embodiment of the present application, showing detailed communication steps or operations of the method, but these steps or operations are only examples, and the present application embodiment may also perform other operations or Fig. 9 In addition, Fig. 9 The steps in Fig. 9 are executed in a different order than those presented, and may not be executed in the order Fig. 9 All operations in . Among them:

[0371] S900. cSEPP uses the first N32-f context between cSEPP and 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. 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 the original JSON block and the JSON block corresponding to the error message in the third message. Then pSEPP parses out the ciphertext and / or JsonPayload carried in the original JSON block, and parses out 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 according to the error type indicated by the first indication information in step S904 is similar to the above Figure 7 The implementation of the cSEPP performing different types of response operations according to the error type indicated by the first indication information in step S702 is similar, except that:

[0382] In scenario 1, scenario 2, scenario 5, scenario 6 or scenario 7, the corresponding error response operation is directly performed by pSEPP in step S904, and the manner in which pSEPP performs the error response operation corresponding to scenario 1, scenario 2, scenario 5, scenario 6 or scenario 7 can refer to the manner in which cSEPP performs the error response operation corresponding to scenario 1, scenario 2, scenario 5, scenario 6 or scenario 7 in step S704, which will not be repeated here.

[0383] In scenario 3, scenario 4, scenario 8, scenario 9 or scenario 10, the way in which pSEPP responds to the error message is that pSEPP sends an indication message to cSEPP (for the convenience of distinction, described as the fourth indication message later), and the fourth indication message indicates that the error types of the transmission error are "Network Topology is not hiddend", "Incorrect message format", "NF request is rejected / disallowed", "PLMN not Found", "Routing failure", "SUPItranslation failure", "Roaming not allowed", and then cSEPP determines whether to send a second HTTP request message (i.e., resend the HTTP request message) or cancel the sending of 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 pSEPP sending the fourth indication information to cSEPP in the embodiment of the present application is the same as the implementation method of pSEPP sending the first indication information to cSEPP in the aforementioned step S805, that is, pSEPP can send the error type indicated by the fourth indication information to cSEPP by means of PRINS, or pSEPP sends the error type indicated by the fourth indication information to cSEPP by means of ProblemDetails, which will not be repeated here.

[0385] The following will be combined Figure 10-11 The communication device provided in this application is described in detail.

[0386] It is understandable 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 easily appreciated by 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 the form of hardware or computer software driving hardware depends on the specific application scenario and design constraints of the technical solution.

[0387] Fig.10 and Fig.11 Schematic diagram of the structure of possible communication devices provided by embodiments of the present application. These communication devices can be used to implement the functions of SEPP (such as the first SEPP or the second SEPP, etc.) or IPX (such as the first IPX or the second IPX) in the above method embodiments, and thus can also achieve the beneficial effects of the above method embodiments. In the embodiments of the present application, the communication device can be such as Figure 3 cSEPP or pSEPP as shown, it can also be Figure 1b Optionally, the communication device may also be a module (such as a chip) applied to SEPP or IPX.

[0388] like Fig.10 As shown, 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] The processing unit 1010 is configured to perform security protection on 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] The transceiver unit 1020 is used to send the protected first HTTP message to an Internet Protocol exchange service IPX, wherein the IPX is used to route the message 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 SEEP 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 SEEP modifies the first HTTP message according to the first indication information to obtain a second HTTP message, the first SEEP 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 SEEP 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, 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;

[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 full domain name NF FQDN 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 more detailed description of the processing unit 1010 and the transceiver unit 1020, please refer to Figure 7 to Figure 9 Any of the method embodiments shown in .

[0406] like Fig.11 As shown, the communication device 1100 includes a processor 1110 and an interface circuit 1120. The processor 1110 and the interface circuit 1120 are coupled to each other. It is understood that the interface circuit 1120 can be a transceiver or an input-output interface. Optionally, the communication device 1000 may also include a memory 1130 for storing instructions executed by the processor 1110 or storing input data required by the processor 1110 to execute instructions or storing data generated after the processor 1110 executes instructions.

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

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

[0409] When the above communication device is a module applied to IPX, the IPX module implements the function of IPX in the above method embodiment. The IPX module receives information from other modules in IPX (such as radio frequency module or antenna), and the information is sent by SEPP to IPX; or the IPX module sends information to other modules in IPX (such as radio frequency module or antenna), and the information is sent by IPX to SEPP.

[0410] It is understood that the processor in the embodiments of the present application may be a central processing unit (CPU), or 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, and the software modules 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 can write information to the storage medium. The storage medium can also be a component 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 a SEPP. The processor and the storage medium can also be present in an IPX or a SEPP as discrete components.

[0412] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented by software, it can be implemented in whole or in part 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 instruction is loaded and executed on a computer, the process or function described in the embodiment of the present application is executed 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 instruction may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer program or instruction may be transmitted from one website site, computer, server or data center to another website site, computer, server or data center by wired or wireless means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server, data center, etc. that integrates one or more available media. The available medium may be a magnetic medium, for example, a floppy disk, a hard disk, a tape; it may also be an optical medium, for example, a digital video disc; it may also be a semiconductor medium, for example, a solid-state hard disk. 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 provided for in any logical conflict, the terms and / or descriptions between the different embodiments are consistent and may be referenced to each other, and the technical features in the different embodiments may be combined to form new embodiments according to their inherent logical relationships.

[0414] It is understood that the various numbers involved in the embodiments of the present application are only for the convenience of description and are not used to limit the scope of the embodiments of the present application. The size of the sequence number of the above-mentioned processes does not mean the order of execution, and the execution order of each process should be determined by its function and internal 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 first indication information from the IPX, where the first indication information indicates a transmission error that occurs in the first HTTP message; The first SEEP 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 SEEP 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 SEEP modifies the first HTTP message according to the first indication information to obtain a second HTTP message; the first SEEP uses the first N32-f context to perform security protection on the second HTTP message to obtain a protected second HTTP message; the first SEEP 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 first information element IE be encrypted in the first HTTP message; or, The first indication information indicates that the second IE that the IPX requires to be encrypted is not encrypted in the first HTTP message.

4. The method according to claim 3, characterized in that 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, 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.

5. The method according to claim 4, characterized in that The first SEEP 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 SEEP 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; The first SEEP 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, The first SEEP sends a parameter exchange request to the second SEPP, where the encryption strategy for the second IE included in the parameter exchange request is to encrypt the second IE; The first SEEP receives a parameter exchange response from the second SEEP, and the encryption policy for the second IE included in the parameter exchange response is to encrypt the second IE.

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 SEEP 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 SEEP modifies the first HTTP message according to the first indication information to obtain a second HTTP message, including: The first SEEP 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 SEEP 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 SEEP performs an error response operation corresponding to the transmission error, including: When the verification result is verification passed, the first SEEP 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 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.

15. 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 unencrypted first information element IE be encrypted in the first HTTP message; or, The second 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.

16. The method according to claim 15, characterized in that The IPX sends first indication information to the first SEPP, including: 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, wherein the first indication information indicates that the IPX requires the unencrypted first IE to be encrypted in the protected first HTTP message; or The IPX determines whether the second IE in the protected first HTTP message is encrypted, and if the second IE is not encrypted, the IPX sends first indication information to the first SEPP, wherein the first indication information indicates that the second 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.

17. The method according to claim 15 or 16, 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.

18. The method according to claim 15 or 16, 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.

19. A communication device, comprising a module for executing the method according to any one of claims 1 to 14, or a module for executing the method according to any one of claims 15 to 18.

20. 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 14, or to implement the method according to any one of claims 15 to 18.

21. 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 14 is implemented, or the method according to any one of claims 15 to 18 is implemented.

22. 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 14 is implemented, or the method according to any one of claims 15 to 18 is implemented.

23. 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 14, and the IPX is used to implement the method according to any one of claims 15 to 18.

Images