Error message generation and handling

Abstract

There are provided measures for error message generation and handling. The measures exemplarily include receiving, at a first network entity associated with a first network roaming interconnected with a second network, a message indicating a roaming service related error, where the message includes first error cause information related to the roaming service related error and addressed to the first network entity, and determining further processing of the message based on the first error cause information.

Description

Technical Field

[0001] Various example embodiments relate to error message generation and handling. More specifically, various example embodiments exemplarily relate to measures (including methods, apparatuses, and computer program products) for implementing error message generation and handling, particularly in network deployments that implement roaming between connected networks. Background Art

[0002] The present specification generally relates to network deployments that enable roaming between connected networks.

[0003] Roaming and interconnection services are important components of the mobile ecosystem.

[0004] To date, a Secure Edge Protection Proxy (SEPP) is provided. The SEPP serves as an egress and ingress point for service-based messages between 3rd Generation Partnership Project (3GPP) 5th Generation Core (5GC) networks.

[0005] Internet interconnection allows secure communication between service-consuming and service-producing network functions (NFs) in different public land mobile networks (PLMNs).

[0006] Security is achieved by two network SEPPs, hereinafter referred to as cSEPP (on the service consumption side) and pSEPP (on the service production side).

[0007] SEPP enforces protection policies regarding application layer security, thereby ensuring integrity and confidentiality protection for those elements to be protected. SEPP is a non-transparent proxy that supports message filtering and policing on the inter-PLMN control plane interface, as well as topology hiding for fifth generation (5G) standalone (SA) roaming and interconnection.

[0008] The roaming service infrastructure provided by mobile operators to their subscribers usually utilizes third parties. Internet Protocol (IP) Interconnection Exchanges (IPXs), Roaming Hubs (RHs), and Roaming Value Added Services (RVAS) providers make available roaming services to mobile network operators (MNOs) in an efficient and scalable manner. IPXs and RHs are examples of Roaming Intermediaries (RIs), which are entities that provide roaming-related services.

[0009] There may be an interconnection provider between the cSEPP and the pSEPP.

[0010] The interconnection provider with which the operator of a cSEPP has a business relationship is called a cIPX (IPX), while the interconnection provider with which the operator of a pSEPP has a business relationship is called a pIPX (IPX).

[0011] There can be additional interconnect providers between cIPX and pIPX, but they are considered transparent and only forward traffic.

[0012] Figure 7 A schematic diagram of an example of a system environment with signalling variants is shown and in particular illustrates the scenario outlined above.

[0013] SEPP may use JavaScript Object Notation (JSON) Web Encryption (JWE) to protect messages on, for example, the N32-f interface, and IPX providers may use JSON Web Signatures (JWS) to sign modifications required by their mediation services.

[0014] For example, Figure 7 As shown, in the case where a service consuming NF sends a message to a service producing NF and the communication crosses PLMN operators via the N32-f interface, the cSEPP receives the message and applies application layer protection, such as based on symmetric keys. The resulting JWE object is forwarded to the intermediary. pIPX and cIPX can provide services that require modification of messages transmitted over the interconnect (N32) interface. These modifications are attached to the message as a digitally signed JWS object containing the desired changes. The pSEPP receiving the message from the pIPX verifies the JWE object, extracts the original message sent by the NF, verifies the signature in the JWS object, and applies a patch corresponding to the modification of the intermediary. The pSEPP then forwards the message to the destination NF.

[0015] N32 interfaces include:

[0016] - N32-c connection, for managing the N32 interface, and

[0017] - N32-f connection for sending JWE and JWS protected messages between SEPPs.

[0018] One possible application layer security protocol for the N32 interface is the N32 Interconnection Security Protocol (PRINS).

[0019] PRINS provides application layer security and enables intermediate IPXs to make modifications to the messages they forward (describing those modifications as patches to the original message and providing digital signatures for the modifications). The receiving SEPP can then process the requested changes to the message as described above.

[0020] While errors may occur in the above scenarios or generally during roaming and interconnection implementations, the generation, transmission, processing and handling of such errors, e.g. between the involved entities, i.e. SEPP, RI (e.g. IPX) and NFs, is not provided or well specified.

[0021] Therefore, error message generation and handling needs to be provided. Summary of the invention

[0022] Various example embodiments are directed to addressing at least some of the above-mentioned challenges and / or problems and disadvantages.

[0023] Various aspects of example embodiments are set out in the accompanying claims.

[0024] According to an exemplary aspect, a method is provided for a first network entity associated with a first network roamingly interconnected with a second network, the method comprising: receiving a message indicating a roaming service related error, wherein the message comprises first error cause information, the first error cause information being related to the roaming service related error and addressed to the first network entity, and determining further processing of the message based on the first error cause information.

[0025] According to an exemplary aspect, a method for a second network entity involved in roaming-related communications between a first network roamingly interconnected with the second network and a second network is provided, the method comprising: generating a message indicating a roaming service-related error, wherein the message comprises first error cause information and second error cause information, the first error cause information being related to the roaming service-related error and addressed to the first network entity, the second error cause information being related to the roaming service-related error and addressed to the second network entity, and sending the message to the first network entity, wherein with respect to the generating, the method further comprises encrypting the first error cause information using a first encryption key.

[0026] According to an exemplary aspect, a device of a first network entity is provided, the first network entity being associated with a first network that is roamingly interconnected with a second network, the device comprising a receiving circuit system and a deciding circuit system, the receiving circuit system being configured to receive a message indicating a roaming service-related error, wherein the message comprises first error cause information, the first error cause information being associated with the roaming service-related error and addressed to the first network entity, the deciding circuit system being configured to decide on further processing of the message based on the first error cause information.

[0027] According to an exemplary aspect, a device of a second network entity is provided, which is involved in roaming-related communications between a first network and a second network, and the first network is roamingly interconnected with the second network. The device includes a generating circuit system, a sending circuit system and an encryption circuit system, the generating circuit system is configured to generate a message indicating a roaming service-related error, wherein the message includes first error cause information and second error cause information, the first error cause information is related to the roaming service-related error and addressed to the first network entity, and the second error cause information is related to the roaming service-related error and addressed to the second network entity, the sending circuit system is configured to send the message to the first network entity, and the encryption circuit system is configured to encrypt the first error cause information using a first encryption key.

[0028] According to an exemplary aspect, a device of a first network entity is provided, the first network entity being associated with a first network that is roamingly interconnected with a second network, the device comprising at least one processor and at least one memory storing instructions, the instructions, when executed by the at least one processor, causing the device to at least perform: receiving a message indicating a roaming service-related error, wherein the message comprises first error cause information, the first error cause information being associated with the roaming service-related error and addressed to the first network entity, and determining further processing of the message based on the first error cause information.

[0029] According to an exemplary aspect, a device of a second network entity is provided, the second network entity being involved in roaming-related communications between a first network and a second network, the first network being roamingly interconnected with the second network, the device comprising at least one processor and at least one memory storing instructions, the instructions, when executed by the at least one processor, causing the device to at least perform: generating a message indicating a roaming service-related error, wherein the message comprises first error cause information and second error cause information, the first error cause information being related to the roaming service-related error and addressed to the first network entity, the second error cause information being related to the roaming service-related error and addressed to the second network entity, and sending the message to the first network entity, and regarding the generating, the instructions, when executed by the at least one processor, causing the device to at least perform: encrypting the first error cause information using a first encryption key.

[0030] According to an exemplary aspect, a computer program product is provided, which includes a computer executable computer program code. When the program is run on a computer (for example, a computer of an apparatus according to any one of the above-mentioned apparatus-related exemplary aspects of the present disclosure), the computer program code is configured to cause the computer to execute a method according to any one of the above-mentioned method-related exemplary aspects of the present disclosure.

[0031] Such a computer program product may include (or be implemented as) a (tangible) computer-readable (storage) medium or the like having computer-executable computer program code stored thereon, and / or the program may be directly loadable into the internal memory of a computer or its processor.

[0032] Any of the above aspects can enable efficient and secure error notification handling, thereby addressing at least some of the problems and disadvantages associated with prior art identification.

[0033] As an example embodiment, the generation and processing of error messages are provided. More specifically, through the example embodiments, measures and mechanisms for implementing the generation and processing of error messages are provided.

[0034] Therefore, improvements are achieved through methods, apparatus, and computer program products that support / implement error message generation and handling. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In the following, the present disclosure will be described in more detail by way of non-limiting examples with reference to the accompanying drawings, in which

[0036] Figure 1 is a block diagram illustrating an apparatus according to an example embodiment;

[0037] Figure 2 is a block diagram illustrating an apparatus according to an example embodiment;

[0038] Figure 3 is a block diagram illustrating an apparatus according to an example embodiment;

[0039] Figure 4 is a block diagram illustrating an apparatus according to an example embodiment;

[0040] Figure 5 is a schematic diagram of a process according to an example embodiment;

[0041] Figure 6 is a schematic diagram of a process according to an example embodiment;

[0042] Figure 7 A schematic diagram showing an example of a system environment with signaling variants;

[0043] Figure 8 Fig. 8A and Figure 8B ) shows a schematic diagram of a signaling sequence according to an example embodiment;

[0044] Figure 9 Fig.9A and Fig. 9B ) shows a schematic diagram of a signaling sequence according to an example embodiment; and

[0045] Fig.10is a block diagram alternatively illustrating an apparatus according to example embodiments. DETAILED DESCRIPTION

[0046] The present disclosure is described herein with reference to specific non-limiting examples and embodiments that are presently considered to be conceivable. It will be appreciated by those skilled in the art that the present disclosure is by no means limited to these examples and can be applied more broadly.

[0047] It should be noted that the following description of the present disclosure and its embodiments mainly refers to specifications used as non-limiting examples of certain exemplary network configurations and deployments. That is, the present disclosure and its embodiments are mainly described in conjunction with 3GPP specifications used as non-limiting examples of certain exemplary network configurations and deployments. Therefore, the description of the example embodiments given herein specifically refers to terms directly related thereto. Such terms are only used in the context of the non-limiting examples presented and naturally do not limit the present disclosure in any way. On the contrary, any other communication or communication-related system deployment, etc., may also be utilized as long as it meets the features described herein.

[0048] In the following, various embodiments and implementations of the present disclosure and aspects or embodiments thereof are described using several variants and / or alternatives. It should generally be noted that, depending on certain requirements and constraints, all described variants and / or alternatives may be provided individually or in any possible combination (also including combinations of individual features of various variants and / or alternatives).

[0049] As used herein, “at least one of the following elements: ” and “at least one of ” and similar expressions (wherein a list of two or more elements is connected by “and” or “or”) refer to at least any one of these elements, or at least any two or more of these elements, or at least all of these elements.

[0050] According to example embodiments, generally speaking, measures and mechanisms are provided for (enabling / implementing) error message generation and handling.

[0051] As described above, although errors may occur during roaming and interconnection implementations, the generation, transmission, processing and handling of errors between the involved entities (ie, SEPP, RI (eg, IPX) and NF) are not provided or well specified.

[0052] That is, as mentioned above, RI is the entity that provides roaming related services and can be a roaming hub or IPX. RI needs to be able to reject service-based request messages and provide appropriate information about the reasons for the rejection so that the initiating SEPP can decide the appropriate handling of the request and its rejection.

[0053] Furthermore, a security mechanism is needed to enable, for example, an initiating SEPP to verify whether the rejection and related reason information is provided by a trusted entity.

[0054] Furthermore, the SEPP may receive error messages from other SEPPs, other SEPP neighboring RIs, or its own neighboring RIs. The error message may be directed to the SEPP directly, or to the NF service consumer or NF service producer.

[0055] Therefore, the receiving entity (eg, SEPP, RI) must also be able to distinguish between different error messages and process them accordingly.

[0056] In short, therefore, according to an example embodiment, an error message originating from a roaming agent of a 5GC interconnect is provided.

[0057] As mentioned above, roaming and interconnection services are an important part of the mobile ecosystem. The roaming service infrastructure provided by mobile operators to their users usually utilizes third parties. IPX, RH, and RVAS providers provide available roaming services to MNOs in an efficient and scalable manner. Current 5G systems provide an end-to-end security design. This design is different from the long-established 2G / 3G / 4G roaming ecosystem, which utilizes a hop-by-hop approach via an intermediary without end-to-end security.

[0058] In 5G systems, several use cases can be foreseen for mobile operators to support roaming services for subscribers, e.g.

[0059] - Delegating the SEPP of the PLMN to an intermediate provider (SEPP hosting), whether

[0060] Whether SEPP is deployed in the mobile operator / PLMN;

[0061] - delegate roaming-related services (whether in whole or in part), contractual agreements, financial responsibilities

[0062] to a trusted third party (e.g., RH); and

[0063] - The ability to support deployment models in parallel, including the ability for PLMNs to use bilateral direct interconnection, delegation of SEPP functionality, and the ability to use a third party to provide roaming services on a per partner PLMN basis.

[0064] While existing services can be provided using a hop-by-hop approach utilizing Transport Layer Security (TLS) (similar to 2G / 3G / 4G networks), the Fifth Generation System (5GS) specification does not support third-party entities providing the same or similar services over 5G.

[0065] Existing 3GPP service requirements and 5G capabilities do not include support for the above specific roaming service use cases.

[0066] That is, the requirement is that, among other things, the 5G system should allow the roaming service provider to reject registration attempts based on the roaming agreement on behalf of the PLMNs involved (rejecting user registration with an appropriate release cause allows the UE to reselect another roaming partner or technology).

[0067] Furthermore, another requirement is that error messages can go from a PLMN SEPP to a neighbouring RH, or from a RH to a neighbouring PLMN SEPP, in an identifiable manner.

[0068] If allowed by PLMN policy, the SEPP shall be able to send error messages to the Roaming Hub over the N32 interface via the N32-f interface.

[0069] Specific RH-related error messages should be supported (such as "Information Element (IE) was encrypted when it was expected to be available in clear text", "IE was not encrypted when it did not need to be available in clear text", "N32 connection could not be established due to contractual reasons", "N32 connection could not be established due to connectivity problems" and "Message not delivered due to contractual reasons").

[0070] For a brief overview of an example embodiment, consider the following use case:

[0071] N32-f The security context is established, but the RI (e.g., cRI, a neighboring RI of the cSEPP) rejects the request initiated by the cNF and processed by the cSEPP.

[0072] According to an example embodiment, when RI rejects a request (initiated by a NF service consumer (cNF) from a sending network and forwarded to a pSEPP via a cSEPP), it provides a response message containing error cause information to be consumed by the cSEPP or the cNF. In the case of a pRI (a neighboring RI of a pSEPP), the error cause information can also be consumed by the cRI.

[0073] According to an example embodiment, the cSEPP or cRI decides whether and how to modify the request and resend the request and / or whether and how to send the request via another route based on the error cause information to be consumed by itself.

[0074] According to an example embodiment, if the cSEPP or cRI decides not to resend the request, it further sends an error message back to the cNF.

[0075] According to an example embodiment, in addition to providing error information to the cSEPP or cRI, the RI that rejects the request also provides error information to the NF consumer. If the cSEPP decides not to resend the request, according to an example embodiment, it removes the error cause information that it is to consume from the response message before forwarding the response message to the NF consumer. Alternatively, according to an example embodiment, the cSEPP modifies the error cause information to a more generic cause and removes details that are not relevant to the NF consumer.

[0076] The rejecting RI may encrypt, integrity protect and / or sign the response message or part thereof so that it can only be consumed by the cSEPP (eg, by encrypting using the cSEPP's public key and signing using its own private key).

[0077] The rejecting RI may also include error cause information to be consumed by another RI (e.g., cRI) in the response message, and encrypt, integrity protect and / or sign it so that the error cause information can only be consumed by the cRI (e.g., by encrypting using the RI's public key and signing using the rejecting RI's own private key).

[0078] While the above brief overview of example embodiments considers a specific use case, example embodiments are also applicable to other use cases, such as:

[0079] -cRI receives information from pSEPP (possibly via pRI) and needs to

[0080] SEPP reporting errors; and

[0081] -cRI may have been informed via Operations, Administration and Maintenance (OAM) that the data volume is now limited, therefore, cRI needs to provide errors to cSEPP, for sufficiency,

[0082] Errors may also need to be sent to the cNF.

[0083] According to an example embodiment, SEPP behavior differs between error handling in the SEPP itself and errors specific to the NF.

[0084] Example embodiments are described in more detail below.

[0085] Figure 1is a block diagram illustrating an apparatus according to an example embodiment. The apparatus may be a (first) network node or entity 10 (associated with a first network roaming interconnected with a second network) comprising a receiving circuit system 11 and a deciding circuit system 12. The receiving circuit system 11 receives a message indicating a roaming service related error, wherein the message includes first error cause information related to the roaming service related error and addressed to the first network entity. The deciding circuit system 12 decides on further processing of the message based on the first error cause information. Figure 5 is a schematic diagram of a process according to an example embodiment. Figure 1 The device can perform Figure 5 method, but not limited to this method. Figure 5 The method can be Figure 1 The present invention is performed by a device, but is not limited to being performed by the device.

[0086] like Figure 5 As shown, the process according to the example embodiment includes the operation of receiving (S51) a message indicating a roaming service-related error, wherein the message includes first error cause information related to the roaming service-related error and addressed to the first network entity, and the operation of deciding (S52) further processing of the message based on the first error cause information.

[0087] Figure 2 is a block diagram illustrating an apparatus according to an example embodiment. Specifically, Figure 2 Pictured Figure 1 A variation of the device shown. Thus, according to Figure 2 The apparatus may also include a determination circuit system 21 , a termination circuit system 22 , a modification circuit system 23 , a forwarding circuit system 24 , a removal circuit system 25 and / or a summarization circuit system 26 .

[0088] In an embodiment, Figure 1 (or Figure 2 ) At least some of the functions of the apparatus shown in the figure can be shared between two physically independent devices forming an operational entity. Therefore, the apparatus can be regarded as depicting an operational entity including one or more physically independent devices for performing at least some of the processes described.

[0089] according to Figure 5 A variation of the process shown, exemplary additional operations are given, which are themselves independent of each other. According to this variation, the error is related to a roaming service related request, and the exemplary method according to the exemplary embodiment may include deciding on further processing of the roaming service related request based on the first error cause information.

[0090] according to Figure 5The variations of the process shown give exemplary details of the decision operation (deciding on further processing of the roaming service-related request), which are themselves independent of each other. Such exemplary decision operation (deciding on further processing of the roaming service-related request) according to an exemplary embodiment may include an operation of determining whether to modify and resend the roaming service-related request, or whether to send the roaming service-related request via a different route.

[0091] according to Figure 5 A variation of the process shown gives exemplary details of the decision operation (determining further processing of the message, S52), which are independent of each other. Such exemplary decision operation (determining further processing of the message, S52) according to an exemplary embodiment may include: if it is determined that the roaming service-related request is to be modified and resent, or the roaming service-related request is to be sent via the different route, then the operation of terminating the message; if it is not determined that the roaming service-related request is to be modified and resent, or the roaming service-related request is to be sent via the different route, then the operation of modifying the message into a modified message; and the operation of forwarding the modified message.

[0092] according to Figure 5 The variations of the process shown give exemplary details of the modification operation, which are themselves independent of each other. Such exemplary modification operations according to example embodiments may include an operation of removing the first error cause information.

[0093] according to Figure 5 The variations of the process shown give exemplary details of the modification operation, which are themselves independent of each other. Such exemplary modification operations according to example embodiments may include an operation of summarizing the first error cause information.

[0094] According to a further example embodiment, the message is a roaming service related response in response to the roaming service related request.

[0095] According to a further exemplary embodiment, the first error cause information is encrypted using a first encryption key.

[0096] According to a further exemplary embodiment, the message comprises second error cause information related to the roaming service related error and addressed to a second network entity.

[0097] According to a further exemplary embodiment, the second error cause information is encrypted using a second encryption key.

[0098] According to a further exemplary embodiment, the first error cause information and the second error cause information are combined.

[0099] According to a further exemplary embodiment, the message comprises third error cause information related to the roaming service related error and addressed to a third network entity.

[0100] According to a further exemplary embodiment, the third error cause information is encrypted using the first encryption key.

[0101] According to a further exemplary embodiment, the third error cause information is encrypted using a third encryption key.

[0102] According to another exemplary embodiment, the first error cause information is signed using a signature key of the message originating entity. Alternatively or additionally, according to another exemplary embodiment, the second error cause information is signed using a signature key of the message originating entity. Alternatively or additionally, according to another exemplary embodiment, the third error cause information is signed using a signature key of the message originating entity.

[0103] According to a further example embodiment, the message is a multi-part message having a multi-part body, and the first error cause information is included in a part of the multi-part body.

[0104] Figure 3 is a block diagram illustrating an apparatus according to an example embodiment. The apparatus may be a (second) network node or entity 30 (involved in roaming-related communications between a first network and a second network that are roamingly interconnected with the second network) comprising a generation circuit system 31, a transmission circuit system 32, and an encryption circuit system 33. The generation circuit system 31 generates a message indicating a roaming service related error, wherein the message includes first error cause information related to the roaming service related error and addressed to the first network entity, and second error cause information related to the roaming service related error and addressed to the second network entity. The transmission circuit system 32 sends the message to the first network entity. The encryption circuit system 33 encrypts the first error cause information with a first encryption key. Figure 6 is a schematic diagram of a process according to an example embodiment. Figure 3 The device can perform Figure 6 method, but not limited to this method. Figure 6 The method can be Figure 3 The present invention is performed by a device, but is not limited to being performed by the device.

[0105] like Figure 6As shown, the process according to the example embodiment includes an operation of generating (S61) a message indicating a roaming service-related error, wherein the message includes first error cause information related to the roaming service-related error and addressed to a first network entity, and second error cause information related to the roaming service-related error and addressed to a second network entity, an operation of sending (S62) the message to the first network entity, and an operation of encrypting (S63) the first error cause information using a first encryption key in relation to the generation (S61).

[0106] Figure 4 is a block diagram illustrating an apparatus according to an example embodiment. Specifically, Figure 4 Shows Figure 3 A variation of the device shown. Thus, according to Figure 4 The device may also include a combining circuit system 41 and / or a signature circuit system 42.

[0107] In an embodiment, Figure 3 (or Figure 4 ) At least some of the functions of the apparatus shown in the figure can be shared between two physically independent devices forming an operational entity. Therefore, the apparatus can be regarded as depicting an operational entity including one or more physically independent devices for performing at least some of the processes described.

[0108] according to Figure 6 The variation of the process shown gives exemplary details of the generating operation (S61), which are independent of each other. Such exemplary generating operation (S61) according to the exemplary embodiment may include the operation of encrypting the second error cause information with a second encryption key.

[0109] according to Figure 6 The variation of the process shown gives exemplary details of the generating operation (S61), which are independent of each other. Such exemplary generating operation (S61) according to the exemplary embodiment may include the operation of combining the first error cause information with the second error cause information.

[0110] According to a further exemplary embodiment, the message comprises third error cause information related to the roaming service related error and addressed to a third network entity.

[0111] according to Figure 6 The variation of the process shown gives exemplary details of the generating operation (S61), which are independent of each other. Such exemplary generating operation (S61) according to the exemplary embodiment may include the operation of encrypting the third error cause information with the first encryption key.

[0112] according to Figure 6The variation of the process shown gives exemplary details of the generating operation (S61), which are independent of each other. Such exemplary generating operation (S61) according to the exemplary embodiment may include an operation of encrypting the third error cause information with a third encryption key.

[0113] according to Figure 6 A variation of the process shown, exemplary details of the generation operation (S61) are given, which are independent of each other. Such an exemplary generation operation (S61) according to an exemplary embodiment may include an operation of signing the first error cause information using its own signature key. Alternatively or additionally, such an exemplary generation operation (S61) according to an exemplary embodiment may include an operation of signing the second error cause information using its own signature key. Alternatively or additionally, such an exemplary generation operation (S61) according to an exemplary embodiment may include an operation of signing the third error cause information using its own signature key.

[0114] According to a further example embodiment, the error is related to a roaming service related request, and the message is a roaming service related response in response to the roaming service related request.

[0115] According to a further example embodiment, the message is a multi-part message having a multi-part body, and the first error cause information is included in a part of the multi-part body.

[0116] The example embodiments summarized and specified above are explained below in more specific terms.

[0117] Figure 8 Fig. 8A and Figure 8B ) shows a schematic diagram of a signaling sequence according to an exemplary embodiment, and specifically illustrates an example of a call flow rejected by pRI according to an exemplary embodiment. Here, Figure 8B express Fig. 8A The continuation of.

[0118] As shown in FIG. 8 , in step 1 of FIG. 8 , NFc sends a request message to (toward) cSEPP.

[0119] In step 2 of FIG. 8 , for the pSEPP, the cSEPP encrypts part of the request message and selects a next hop, such as the cRI.

[0120] In step 3 of FIG. 8 , the cSEPP sends a request message to (towards) the cRI.

[0121] In step 4 of Figure 8, the cRI examines the unencrypted portion of the request message and decides whether to forward or reject the message.

[0122] In step 5 of FIG. 8 , the cRI sends a request message to (toward) the pRI.

[0123] In step 6 of Figure 8, the pRI examines the unencrypted portion of the request message and decides whether to forward or reject the message.

[0124] In step 7 of Figure 8, according to an example embodiment, the pRI decides to reject the message. According to an example embodiment, the pRI provides the error reason of the NFc and the error reason of the cSEPP, and encrypts and / or signs with the private key plus the public key of the cSEPP. According to an example embodiment, the pRI provides the error reason of the cRI, and encrypts and / or signs with the private key plus the public key of the cRI.

[0125] In step 8 of FIG. 8 , according to an example embodiment, the pRI sends a response message (error cause of NFc, error cause of cRI, and error cause of cSEPP) to (or toward) the cRI.

[0126] In step 9 of FIG. 8 , according to an example embodiment, the cRI decrypts the error cause of the cRI.

[0127] In step 10 of FIG. 8 , according to an example embodiment, the cRI decides whether to reroute the request based on the error cause of the cRI.

[0128] In step 11b of FIG. 8, according to an example embodiment, upon deciding to reroute the request, the cRI resends the request message to (toward) the alternative pRI.

[0129] In step 11a of FIG. 8 , according to an example embodiment, the cRI sends a response message (error cause of NFc, error cause of cSEPP) to (towards) the cSEPP, eg upon deciding not to reroute the request.

[0130] In step 12 of FIG. 8 , according to an example embodiment, the cSEPP decrypts the response message.

[0131] In step 13 of FIG. 8 , according to an example embodiment, the cSEPP decides whether to modify, resend and / or reroute the request based on the cause of the error of the cSEPP.

[0132] In step 14b of FIG. 8, according to an example embodiment, upon deciding to modify and resend the request, the cSEPP sends a modified request message to (towards) the cRI.

[0133] In step 14c of FIG. 8, according to an example embodiment, upon deciding to reroute the request, the cSEPP sends a request message to (towards) the alternative cRI.

[0134] In step 14a of FIG. 8 , according to an example embodiment, upon deciding not to modify, resend and reroute the request, the cSEPP sends a response message (Error Cause of NFc) to (towards) NFc.

[0135] According to an example embodiment, the error cause information to be consumed by the cRI and the error cause information to be consumed by the cSEPP may be combined or may be provided separately (if separate encryption and / or signing is required, as shown in FIG. 8 ).

[0136] According to an example embodiment, error cause information of NFc may be provided separately.

[0137] According to an example embodiment, the error cause information of NFc follows the existing HTTP encoding for 5GC (with HTTP response status code and problem details), and the error cause message of cSEPP or cRI can apply new encoding, such as a (new) dedicated HTTP header or a dedicated type of HTTP body (possibly as part of a multi-part body if other HTTP bodies are also required) (step 8 of Figure 8).

[0138] According to an example embodiment, the error cause information that can be consumed by both cSEPP and cRI may include information such as "N32 connection cannot be established due to contractual reasons", "N32 connection cannot be established due to connection problems", and "Message not delivered due to contractual reasons". According to an example embodiment, if a suitable alternative RI is available, cSEPP or cRI may resend the message via an alternative RI (cRI or pRI, respectively) upon receiving such an error code (step 7, step 10, step 11b, step 13, step 14c of Figure 8).

[0139] According to an example embodiment, the pRI derives the NFc error cause information from the more specific error of the cSEPP: the pRI modifies the error cause information of the cSEPP to a more generic cause and removes details not relevant to the NF consumer. According to an example embodiment, the pRI uses a class default HTTP status code instead of a more specific status code (e.g., 400 instead of other 4xx codes) (step 7 of FIG. 8 ).

[0140] According to an exemplary embodiment, when forwarding the error response to the cSEPP, the cRI removes the error cause information of the cRI (step 11 of FIG. 8 ).

[0141] According to an example embodiment, the error cause information that the cSEPP may consume may also include information such as "IE was encrypted when it was expected to be available in plain text", "IE was not encrypted when it was not required to be available in plain text", etc. According to an example embodiment, if permitted according to the policy of the cSEPP, the cSEPP may then modify the encryption of the request message accordingly (step 7, step 10, step 13, step 14b of FIG. 8 ).

[0142] According to an example embodiment, when forwarding the error response to the NFc, the cSEPP removes the error cause information of the cSEPP (step 14a of FIG. 8 ).

[0143] According to an example embodiment, cSEPP modifies the error cause information to a more generic cause and removes details not relevant to the NF consumer. According to an example embodiment, cSEPP uses a class default HTTP status code instead of a more specific status code (eg, 400 instead of other 4xx codes).

[0144] Specific example embodiments covered by what has been outlined, specified and explained above can be precisely defined as follows.

[0145] In particular, message authentication by receiving SEPP can be precisely defined as follows.

[0146] The receiving SEPP SHOULD decrypt the JWE ciphertext using the shared session key and the following parameters obtained from the JWE object - Initialization Vector, Additional Authentication Data value (clearTextEncapsulatedMessage in "aad"), and the JWE Authentication Tag ("Tag").

[0147] If the reformattedData IE is not empty, the receiving SEPP shall check the integrity and authenticity of the clearTextEncapsulatedMessage and the encrypted text by verifying the JWE authentication tag in the JWE object with the JWE AAD algorithm. The algorithm returns the decrypted plaintext (dataToIntegrityProtectAndCipher) only if the JWE authentication tag is correct.

[0148] The receiving SEPP refers to the NF API data type placement mapping table to reconstruct the original reformatted message by updating the corresponding entry in the clearTextEncapsulatedMessage with the value in the dataToIntegrityProtectAndCipher array.

[0149] The receiving SEPP shall next verify the IPX provider update (if included) by verifying the JWS signature added by the roaming broker. The SEPP shall verify the JWS signature using the corresponding original public key or certificate contained in the IPX provider security information list obtained during the parameter exchange in the relevant N32-c connection establishment, or alternatively, which has been configured for the specific peer SEPP. If the reformattedData IE is not empty, the receiving SEPP shall then check whether the original public key or certificate of the identity of the JWS signed IPX in the modifiedDataDataToIntegrity block matches the IPX provider mentioned in the "authorizedIPX ID" field added by the sending SEPP based on the information given in the IPX provider security information list. If the reformattedData IE is empty, the receiving SEPP shall check if the original public key or certificate of the identity of the JWS Signing IPX in the modifiedDataToIntegrityProtect block matches that of the neighboring roaming hub in the N32-f security context of the first roaming hub (extracted from the defined modifiedDataToIntegrityProtect block).

[0150] The receiving SEPP shall check whether the modification performed by the roaming agent is permitted by the corresponding modification policy.The receiving SEPP shall use the modification policy of the cIPX acquired during the parameter exchange in the establishment of the related N32-c connection and use the modification policy of the pIPX configured in the receiving SEPP.

[0151] If this is the case, the receiving SEPP should apply the patch in the action field in order, perform sanity checks, and create a new HTTP request based on the "patched" clearTextEncapsulatedMessage.

[0152] The receiving SEPP shall verify that the PLMN-ID contained in the incoming N32-f message matches the PLMN-ID in the associated N32-f context.

[0153] Furthermore, the SEPP's handling of erroneous initiation by roaming intermediaries can be precisely defined as follows.

[0154] A SEPP receiving an error message originating from a roaming intermediary should be able to determine whether the received error information is related to itself or for further processing by the NF. Different error causes are necessary.

[0155] If the SEPP determines that an error message or part of an error message needs to be provided to the NF, it will take appropriate action for further processing. For example, in the case of an error message in response to a registration request, the payload is not necessarily empty and may need to be encoded differently for the NF. In this case, error information addressed to the SEPP and not relevant to the NF may be removed.

[0156] If the SEPP determines that another roaming intermediary needs to be addressed, it sends a request message to the alternative roaming intermediary.

[0157] If the SEPP determines from the error code that the roaming intermediary requires a modified request message, it may modify and resend the modified request message accordingly.

[0158] An error message from a roaming agent that is not adjacent to the SEPP to a roaming agent that is adjacent to the SEPP may also affect the SEPP.

[0159] Error messages should be integrity protected and signed by the roaming agent.

[0160] Furthermore, the message flow between two SEPPs can be precisely defined as follows, with modifications from cIPX and pIPX.

[0161] Figure 9 Fig.9A and Fig. 9B ) shows a schematic diagram of a signaling sequence according to an example embodiment, and in particular shows a message flow between two SEPPs with modifications from cIPX and pIPX. Here, Fig. 9B express Fig.9A The continuation of.

[0162] Step 1 of Figure 9: cSEPP receives HTTP request message from network function. If the message contains a telescoping FQDN, cSEPP removes its domain name from the FQDN to obtain the original FQDN.

[0163] Step 2 of Figure 9: The cSEPP shall reformat the HTTP request message as follows:

[0164] a.cSEPP shall generate blocks (JSON objects) for integrity-protected and encrypted data and protect them:

[0165] cSEPP should encapsulate the HTTP request into a clearTextEncapsulatedMessage block containing the following sub-JSON object:

[0166] -Pseudo_Headers.

[0167] -HTTP_Headers, one element for each header of the original request.

[0168] - A payload containing the message body of the original request.

[0169] For each attribute that needs to be end-to-end encrypted between two SEPPs, the attribute value is copied into the dataToIntegrityProtectAndCipher JSON object and the value of the attribute in the clearTextEncapsulatedMessage is replaced by the index of the attribute value in the dataToIntegrityProtectAndCipher block.

[0170] The cSEPP shall create a metadata block containing the N32-f context ID, the message ID generated by the cSEPP for this request / response transaction, and the next hop identifier.

[0171] The cSEPP shall protect the dataToIntegrityProtect block and the dataToIntegrityProtectAndCipher block. This will result in a single JWE object representing the protected HTTP request message.

[0172] b.cSEPP should generate the payload for SEPP to SEPP HTTP message:

[0173] The JWE object becomes the payload of the new HTTP message generated by cSEPP.

[0174] Step 3 of Figure 9: The cSEPP shall send an HTTP message to the first roaming agent using HTTP POST.

[0175] Step 4 of Figure 9: The first roaming agent (e.g., the IPX provider of the visited network) should create a new modifiedDataToIntegrityProtect JSON object with three elements:

[0176] a. The operational JSON patch document includes modifications performed by the first roaming agent in accordance with RFC 6902.

[0177] b. The first roaming agent shall include its own identity in the identity field of modifiedDataToIntegrityProtect.

[0178] c. The first roaming agent shall copy the "Tag" element present in the JWE object generated by the cSEPP into the modifiedDataToIntegrityProtect object. This can serve as a replay protection for updates made by the first roaming agent.

[0179] The roaming agent should perform JWS on the modifiedDataToIntegrityProtect JSON object and attach the resulting JWS object to the message.

[0180] Step 5 of FIG. 9 : The first roaming agent shall send the modified HTTP message request to the second roaming agent (eg, IPX of the home network), as shown in step 3 of FIG. 9 .

[0181] Step 6 of Figure 9: If necessary, the second roaming agent shall perform further modifications as in step 4 of Figure 9. The second roaming agent shall further perform JWS on the modifiedDataToIntegrityProtect JSON object and attach the resulting JWS object to the message.

[0182] Step 7 of FIG. 9 : The second roaming agent shall send the modified HTTP message to the pSEPP, as shown in step 3 of FIG. 9 .

[0183] The behavior of the roaming agent is not normative, but pSEPP assumes the behavior of handling the resulting request.

[0184] Step 8 of Figure 9: The pSEPP receives the message and shall perform the following actions:

[0185] -pSEPP extracts serialized values ​​from components of a JWE object.

[0186] -pSEPP calls the JWE AEAD algorithm to check the integrity of the message and decrypts the dataToIntegrityProtectAndCipher block. This causes the entries in the encrypted block to become visible in plaintext.

[0187] -pSEPP updates the clearTextEncapsulationMessage block in the message by replacing the reference to the dataToIntegrityProtectAndCipher block with the decrypted value referenced in the dataToIntegrityProtectAndCipher block.

[0188] - Then, pSEPP verifies the IPX provider updates of the attributes in modificationsArray. It checks whether the modifications performed by the roaming agent are permitted by the policy.

[0189] The pSEPP further verifies that the PLMN-ID contained in the message is equal to the "Remote PLMN-ID" in the relevant N32-f context.

[0190] -pSEPP updates the modified values ​​of the attributes in the clearTextEncapsulationMessage in sequence.

[0191] pSEPP should reassemble the complete HTTP request based on the contents of clearTextEncapsulationMessage.

[0192] Step 9 of Figure 9: pSEPP shall send the HTTP request generated in step 8 to the NF of the home network.

[0193] Steps 10 to 18 of FIG. 9 : These steps are similar to steps 1 to 9 in FIG. 9 .

[0194] Furthermore, as shown in FIG. 8 , the message flow between two SEPPs may be precisely defined for error handling in the event that the roaming agent (RI) rejects the request message.

[0195] As described above, the above processes and functions can be implemented by corresponding functional elements, processors, etc.

[0196] In the exemplary description of the above network entity, only the units related to understanding the principles of the present disclosure are described using functional blocks. The network entity may include other units required for its corresponding operation. However, the description of these units is omitted in this specification. The arrangement of the functional blocks of the device should not be interpreted as limiting the present disclosure, and the functions may be performed by one block or further split into sub-blocks.

[0197] When it is stated in the foregoing description that the device (i.e., a network node or entity (or some other component)) is configured to perform some functions, this should be interpreted as being equivalent to the following description, that is, (i.e., at least one) processor or corresponding circuit system (possibly in cooperation with computer program code stored in the memory of the corresponding device) is configured so that the device performs at least the above functions. In addition, such functions should be interpreted as being equivalently achievable by circuit systems or components specially configured for performing the corresponding functions (i.e., the expression "a unit configured to..." is interpreted as being equivalent to expressions such as "components for...").

[0198] exist Fig.10 In FIG. 1 , an alternative diagram of an apparatus according to an example embodiment is depicted. Fig.10As shown, according to an exemplary embodiment, a device (network node or entity) 10' (corresponding to the network node or entity 10) includes a processor 101, a memory 102, and an interface 103, which are connected via a bus 104, etc. In addition, according to an exemplary embodiment, a device (network node or entity) 30' (corresponding to the network node or entity 30) includes a processor 105, a memory 106, and an interface 107, which are connected via a bus 108, etc., and these devices can be connected via links 109, respectively.

[0199] The processor 101 / 105 and / or the interface 103 / 107 may also include a modem or the like to facilitate communication over a (hardwired or wireless) link, respectively. The interface 103 / 107 may include a suitable transceiver coupled to one or more antennas or communication components for (hardwired or wireless) communication with (multiple) linked or connected devices, respectively. The interface 103 / 107 is typically configured to communicate with at least one other device (i.e., its interface).

[0200] The memory 102 / 106 may store a respective program assumed to include program instructions or computer program codes which, when executed by a respective processor, enable a respective electronic device or apparatus to operate in accordance with example embodiments.

[0201] Generally speaking, the corresponding devices / apparatuses (and / or parts thereof) may represent components for performing corresponding operations and / or exhibiting corresponding functions, and / or the corresponding devices (and / or parts thereof) may have functions for performing corresponding operations and / or exhibiting corresponding functions.

[0202] When it is stated in the subsequent description that a processor (or some other component) is configured to perform a certain function, this should be interpreted as equivalent to the following description, that is, at least one processor (possibly in cooperation with computer program code stored in the memory of the corresponding device) is configured to cause the device to perform at least the above-mentioned function. In addition, such functions should be interpreted as being equivalently achievable by components specially configured for performing the corresponding functions (i.e., the expression "a processor configured to [cause the device] to perform xxx" is interpreted as being equivalent to expressions such as "components for xxx").

[0203] According to an example embodiment, an apparatus representing a network node or entity 10 (associated with a first network entity of a first network roamingly interconnected with a second network) comprises at least one processor 101, at least one memory 102 including computer program code, and at least one interface 103 configured for communication with at least another apparatus. The processor (i.e., at least one processor 101, together with at least one memory 102 and computer program code) is configured to perform: receiving a message indicating a roaming service related error, wherein the message comprises first error cause information related to the roaming service related error and addressed to the first network entity (therefore, the apparatus comprises corresponding means for receiving), and deciding on further processing of the message based on the first error cause information (therefore, the apparatus comprises corresponding means for deciding).

[0204] According to an example embodiment, an apparatus representing a network node or entity 30 (a second network entity involved in roaming-related communications between a first network roamingly interconnected with the second network and a second network) comprises at least one processor 105, at least one memory 106 comprising computer program code, and at least one interface 107 configured for communication with at least another apparatus. The processor (i.e., at least one processor 105, together with at least one memory 106 and computer program code) is configured to perform: generating a message indicating a roaming service-related error, wherein the message comprises first error cause information related to the roaming service-related error and addressed to the first network entity, and second error cause information related to the roaming service-related error and addressed to the second network entity (therefore, the apparatus comprises corresponding means for generating), sending the message to the first network entity (therefore, the apparatus comprises corresponding means for transmitting), and encrypting the first error cause information with a first encryption key in relation to the generating (therefore, the apparatus comprises corresponding means for encrypting).

[0205] For more details on the operability / functionality of individual devices, please refer to the respective Figure 1 To any one of the related descriptions of Figure 9.

[0206] For the purposes of the present disclosure as described above, it should be noted that

[0207] - the method steps that may be implemented as software code portions and executed using a processor at a network server or network entity (as an example of a device, apparatus and / or its modules, or as an example of an entity including apparatus and / or modules) are independent of the software code and may be specified using any known or future developed programming language as long as the functionality defined by the method steps is preserved;

[0208] - generally, any method step is suitable for being implemented as software or by hardware without changing the idea of ​​the embodiment and its modification in terms of the implemented functions;

[0209] - the method steps and / or devices, units or parts that may be implemented as hardware components on the above-defined apparatus or any (multiple) modules thereof (e.g., devices that perform the functions of the apparatus according to the above-described embodiments) are hardware-independent and may be implemented using any known or future-developed hardware technology or any mixture of these technologies, such as MOS (Metal Oxide Semiconductor), CMOS (Complementary MOS), BiMOS (Bipolar MOS), BibMOS (Bipolar CMOS), ECL (Emitter Coupled Logic), TTL (Transistor Transistor Logic), etc., using, for example, ASIC (Application Specific IC (Integrated Circuit)) components, FPGA (Field Programmable Gate Array) components, CPLD (Complex Programmable Logic Device) components or DSP (Digital Signal Processor) components;

[0210] - devices, units or components (e.g., any of the network entities or network registers defined above, or their corresponding units / components) may be implemented as individual devices, units or components, but this does not exclude that they are implemented in a distributed manner throughout the system, as long as the functionality of the devices, units and components is preserved;

[0211] - Apparatuses such as user equipment and network entities / network registers may be represented by semiconductor chips, chipsets, or (hardware) modules comprising such chips or chipsets; however, this does not exclude the possibility of implementing the functionality of an apparatus or module as software in a (software) module rather than hardware implementation, such as a computer program or computer program product comprising executable software code portions for execution / running on a processor;

[0212] - For example, a device may be considered as one apparatus or as an assembly of more than one apparatus, whether they function in conjunction with each other or function independently of each other but in the same apparatus housing.

[0213] In general, it should be noted that if only the above functions of the corresponding parts are suitable for performing, the corresponding functional blocks or elements according to the above aspects can be implemented in any known manner of hardware and / or software, respectively. The above method steps can be implemented in individual functional blocks or by individual devices, or one or more method steps can be implemented by a single functional block or a single device.

[0214] Generally, any method step is suitable for implementation as software or by hardware without changing the idea of ​​the present disclosure. Devices and components can be implemented as individual devices, but this does not exclude that they are implemented in a distributed manner throughout the system, as long as the functionality of the device is preserved. These and similar principles are considered to be known to those skilled in the art.

[0215] Software in the sense of this specification comprises software code, which itself comprises code means or parts or a computer program or computer program product for performing the corresponding functions, as well as software (or computer program, computer program product) implemented on a tangible medium (such as a computer-readable (storage) medium) on which the corresponding data structures or code means / parts are stored, or implemented in a signal or a chip, possibly during its processing.

[0216] The present disclosure also covers any conceivable combination of the above method steps and operations, and any conceivable combination of the above nodes, devices, modules or elements, as long as the concepts of the above methods and structural arrangements are applicable.

[0217] In view of the above situation, measures for error message generation and processing are provided. These measures exemplarily include: receiving, at a first network entity associated with a first network roamingly interconnected with a second network, a message indicating a roaming service related error, wherein the message includes first error cause information related to the roaming service related error and addressed to the first network entity, and determining further processing of the message based on the first error cause information.

[0218] Although the present disclosure is described above with reference to the examples according to the accompanying drawings, it should be understood that the present disclosure is not limited thereto. Instead, it is obvious to those skilled in the art that the present disclosure can be modified in various ways without departing from the scope of the inventive concept disclosed herein.

[0219] List of abbreviations

[0220] 3GPP Third Generation Partnership Project

[0221] 5G Fifth Generation

[0222] 5GC Fifth Generation Core

[0223] 5GS Fifth Generation System

[0224] c-RI, cRI Consumer RI

[0225] c-SEPP, cSEPP Consumer SEPP

[0226] IE Information Elements

[0227] IP Internet Protocol

[0228] IPX IP interconnection exchange, IP exchange service

[0229] JSON JavaScript Object Notation

[0230] JWE JSON Web Encryption

[0231] JWS JSON Web Signature

[0232] MNO Mobile Network Operator

[0233] NF Network Function

[0234] NF-c, NFc Network Function Consumer

[0235] NF-p, NFp Network Function Producer

[0236] OAM Operations, Administration and Maintenance

[0237] PLMN Public Land Mobile Network

[0238] PRINS N32 Interconnection Security Protocol

[0239] p-RI, pRI Manufacturer's RI

[0240] p-SEPP, pSEPP Manufacturer's SEPP

[0241] RH Roaming Hub

[0242] RI Roaming Broker

[0243] RVAS roaming value-added service

[0244] SA Independence

[0245] SEPP Security Edge Protection Proxy

[0246] TLS Transport Layer Security

Claims

1. A device of a first network entity, the first network entity being associated with a first network roamingly interconnected with a second network, the device comprising at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least perform: receiving a message indicating a roaming service related error, wherein the message includes first error cause information, the first error cause information being related to the roaming service related error and being addressed to the first network entity, and Based on the first error cause information, further processing of the message is determined.

2. The device according to claim 1, wherein The error is related to a roaming service related request, and the instructions, when executed by the at least one processor, cause the apparatus to at least perform: Based on the first error cause information, decide on further processing of the roaming service related request.

3. The device according to claim 2, wherein With respect to the determining of further processing of the roaming service-related request, the instructions, when executed by the at least one processor, cause the apparatus to at least perform: determining whether to modify and resend the roaming service-related request, or whether to send the roaming service-related request via a different route, and With respect to the determining of further processing of the message, the instructions, when executed by the at least one processor, cause the apparatus to at least perform: if it is determined that the roaming service-related request is to be modified and resent, or is to be sent via the different route, terminating the message, and If it is not determined that the roaming service-related request is to be modified and resent, or that the roaming service-related request is to be sent via the different route, modifying the message into a modified message, and The modified message is forwarded.

4. The device according to claim 3, wherein With respect to modifying the message, the instructions, when executed by the at least one processor, cause the apparatus to at least perform: Remove the first error cause information, or Summarize the first error cause information.

5. The device according to claim 2, wherein The message is a roaming service-related response in response to the roaming service-related request.

6. The device according to claim 1, wherein The first error cause information is encrypted using a first encryption key.

7. The device according to claim 6, wherein The message comprises second error cause information, the second error cause information being related to the roaming service related error and addressed to a second network entity, and optionally the second error cause information being encrypted using a second encryption key.

8. The device according to claim 7, wherein The first error cause information and the second error cause information are combined.

9. The device according to claim 6, wherein The message includes third error cause information, the third error cause information being related to the roaming service related error and being addressed to a third network entity.

10. The device according to claim 9, wherein The third error cause information is encrypted using the first encryption key, or The third error cause information is encrypted using a third encryption key.

11. The apparatus of claim 9, wherein at least one of the following: The first error cause information is signed using a signature key of the message initiating entity, or The second error cause information is signed using a signature key of the message originating entity, or The third error cause information is signed using a signature key of the message originating entity.

12. The device according to claim 1, wherein The message is a multipart message with a multipart body, and The first error cause information is included in a part of the multi-part body.

13. An apparatus of a second network entity, the second network entity being involved in roaming-related communications between a first network and a second network, the first network and the second network being interconnected by roaming, the apparatus comprising at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus to at least perform: generating a message indicating a roaming service related error, wherein the message comprises first error cause information and second error cause information, the first error cause information being related to the roaming service related error and being addressed to a first network entity, the second error cause information being related to the roaming service related error and being addressed to a second network entity, and Sending the message to the first network entity, wherein With respect to the generating, the instructions, when executed by the at least one processor, cause the apparatus to at least perform: The first error cause information is encrypted using a first encryption key.

14. The device according to claim 13, wherein With respect to the generating, the instructions, when executed by the at least one processor, cause the apparatus to at least perform: The second error cause information is encrypted using a second encryption key.

15. The device according to claim 13, wherein With respect to the generating, the instructions, when executed by the at least one processor, cause the apparatus to at least perform: The first error cause information is combined with the second error cause information.

16. The device according to claim 13, wherein The message includes third error cause information, the third error cause information being related to the roaming service related error and being addressed to a third network entity.

17. The device according to claim 16, wherein With respect to the generating, the instructions, when executed by the at least one processor, cause the apparatus to at least perform: encrypting the third error cause information using the first encryption key, or The third error cause information is encrypted using a third encryption key.

18. The device according to claim 16, wherein With respect to the generating, the instructions, when executed by the at least one processor, cause the apparatus to perform at least one of the following: Use its own signature key to sign the first error cause information, or Sign the second error cause information using the own signature key, or The third error cause information is signed by using the own signature key.

19. The device according to claim 13, wherein The error is related to a roaming service related request, and The message is a roaming service-related response in response to the roaming service-related request.

20. The device according to claim 13, wherein The message is a multipart message with a multipart body, and The first error cause information is included in a part of the multi-part body.

Images