Payload Compression

Abstract

According to an example aspect of the invention, there is provided an apparatus configured to: initiate a handshake procedure configured to establish a control plane connection prior to establishing an associated data plane connection from the apparatus to a gateway node in a second network, the apparatus being in a first network different from the second network; during establishment of the control plane connection, indicate that compression of a payload communicated over the data plane connection is requested, and wherein the data plane connection to the gateway node traverses at least one intermediate Internet Protocol switch.

Description

Technical Field

[0001] The present disclosure relates to managing payload compression in inter-network connectivity interworking scenarios. Background Art

[0002] A communication network provides communication services to users within its communication domain. For example, a public land mobile network PLMN can connect users with terminals registered to the PLMN by arranging the exchanged communication paths together to convey information between the terminals. In order to obtain connectivity between communication entities registered in different networks, the network requires an inter-network interface to convey information across their respective boundaries.

[0003] Typically, a gateway is a network node that is responsible for exchanging information with entities in other networks. In other words, a gateway enables networks to be connected together so that nodes in different networks can communicate with each other. In general, such inter-network connections may pass through at least one gateway in each network along the overall communication path between entities in different networks. For example, in the case of two networks, inter-network communications may pass through one gateway in the first of the two networks and another gateway in the other network. Summary of the invention

[0004] According to some aspects, the subject matter of independent claims is provided. Some embodiments are defined in the dependent claims. The scope of protection sought by various embodiments of the present invention is set forth by the independent claims. Embodiments, examples and features described in this specification that do not fall within the scope of the independent claims (if any) will be interpreted as examples useful for understanding the various embodiments of the present invention.

[0005] According to a first aspect of the present disclosure, a device is provided, comprising: at least one processing core; at least one memory including computer program code; the at least one memory and the computer program code are configured to, together with the at least one processing core, enable the device to at least: initiate a handshake process, the handshake process being configured to establish a control plane connection before establishing an associated data plane connection from the device to a gateway node in a second network, the device being in a first network different from the second network; during establishment of the control plane connection, indicating that compression of a payload transferred on the data plane connection is requested, and wherein the data plane connection to the gateway node passes through at least one intermediate Internet Protocol switch.

[0006] According to a second aspect of the present disclosure, a method is provided, comprising: initiating a handshake process from a device, the handshake process being configured to establish a control plane connection before establishing an associated data plane connection from the device to a gateway node in a second network, the device being in a first network different from the second network; during establishment of the control plane connection, indicating that compression of a payload communicated on the data plane connection is requested, and wherein the data plane connection to the gateway node passes through at least one intermediate Internet Protocol switch.

[0007] According to a third aspect of the present disclosure, a device is provided, comprising: at least one processing core; at least one memory including computer program code; the at least one memory and the computer program code are configured to, together with the at least one processing core, enable the device to at least: participate in a handshake process, the handshake process being configured to establish a control plane connection before establishing an associated data plane connection from the device to a gateway node in a first network, the device being in a second network different from the first network; during establishment of the control plane connection, indicating that compression of a payload transferred on the data plane connection is supported, and wherein the data plane connection to the gateway node passes through at least one intermediate Internet Protocol switch.

[0008] According to a fourth aspect of the present disclosure, a device is provided, comprising: at least one processing core; at least one memory, including computer program code; the at least one memory and the computer program code are configured to, together with the at least one processing core, enable the device to at least: participate in a handshake process, the handshake process being configured to establish a control plane connection before establishing an associated data plane connection from the device to a gateway node in a first network, the device being in a second network different from the first network, wherein the data plane connection to the gateway node passes through at least one intermediate Internet Protocol exchange; receive a Hypertext Transfer Protocol (HTTP) payload transmitted on the data plane connection, the HTTP payload being compressed or uncompressed; and determine whether to compress the reconstructed Hypertext Transfer Protocol (HTTP) payload received on the data plane connection before forwarding the reconstructed Hypertext Transfer Protocol (HTTP) payload forwarded to a network function in the second network.

[0009] According to a fifth aspect of the present disclosure, a method is provided, comprising: participating in a handshake process by a device, the handshake process being configured to establish a control plane connection before establishing an associated data plane connection from the device to a gateway node in a first network, the device being in a second network different from the first network; during establishment of the control plane connection, indicating that compression of a payload transmitted on the data plane connection is supported, and wherein the data plane connection to the gateway node passes through at least one intermediate Internet Protocol exchange.

[0010] According to a sixth aspect of the present disclosure, a method is provided, comprising: participating in a handshake process by a device, the handshake process being configured to establish a control plane connection before establishing an associated data plane connection from the device to a gateway node in a first network, the device being in a second network different from the first network, wherein the data plane connection to the gateway node passes through at least one intermediate Internet Protocol exchange; receiving a Hypertext Transfer Protocol (HTTP) payload transmitted on the data plane connection, the HTTP payload being compressed or uncompressed; and determining whether to compress the reconstructed Hypertext Transfer Protocol (HTTP) payload received on the data plane connection before forwarding the reconstructed Hypertext Transfer Protocol (HTTP) payload forwarded to a network function in the second network.

[0011] According to a seventh aspect of the present disclosure, a device is provided, comprising a component for performing the following operations: initiating a handshake process from the device, the handshake process being configured to establish a control plane connection before establishing an associated data plane connection from the device to a gateway node in a second network, the device being in a first network different from the second network; during establishment of the control plane connection, indicating that compression of a payload transferred on the data plane connection is requested, and wherein the data plane connection to the gateway node passes through at least one intermediate Internet Protocol exchange.

[0012] According to an eighth aspect of the present disclosure, there is provided a non-transitory computer-readable medium having a set of computer-readable instructions stored thereon, which, when executed by at least one processor, causes a device to at least: initiate a handshake process, the handshake process being configured to establish a control plane connection before establishing an associated data plane connection from the device to a gateway node in a second network, the device being in a first network different from the second network; during establishment of the control plane connection, indicating that compression of a payload being transferred on the data plane connection is requested, and wherein the data plane connection to the gateway node passes through at least one intermediate Internet Protocol exchange.

[0013] According to a ninth aspect of the present disclosure, a computer program is provided, which is configured to cause at least the following operations to be performed by a device when executed by at least one processor: initiating a handshake process, the handshake process being configured to establish a control plane connection before establishing an associated data plane connection from the device to a gateway node in a second network, the device being in a first network different from the second network; during establishment of the control plane connection, indicating that compression of a payload transferred on the data plane connection is requested, and wherein the data plane connection to the gateway node passes through at least one intermediate Internet Protocol exchange.

[0014] According to the tenth aspect of the present disclosure, there is provided a non-transitory computer-readable medium having a set of computer-readable instructions stored thereon, which, when executed by at least one processor, causes a device to at least: participate in a handshake process, the handshake process being configured to establish a control plane connection before establishing an associated data plane connection from the device to a gateway node in a first network, the device being in a second network different from the first network, wherein the data plane connection to the gateway node passes through at least one intermediate Internet Protocol exchange; receive a Hypertext Transfer Protocol (HTTP) payload transmitted on the data plane connection, the HTTP payload being compressed or uncompressed; and determine whether to compress the reconstructed Hypertext Transfer Protocol (HTTP) payload received on the data plane connection before forwarding the reconstructed Hypertext Transfer Protocol (HTTP) payload forwarded to a network function in the second network. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 An example system is shown in accordance with at least some embodiments of the present invention;

[0016] Figure 2A shows example embodiments in accordance with at least some embodiments of the present invention;

[0017] Figure 2B shows example embodiments in accordance with at least some embodiments of the present invention;

[0018] Figure 3 An example apparatus capable of supporting at least some embodiments of the present invention is shown;

[0019] Figure 4 illustrates signaling in accordance with at least some embodiments of the present invention; and

[0020] Figure 5 is a flow chart of a method according to at least some embodiments of the present invention. DETAILED DESCRIPTION

[0021] Disclosed herein is a method for employing payload compression in an inter-network interoperability scenario, in which, for example, a network function NF in a first network needs to invoke a service produced by a network repository function NRF or other network function producer NFp of a second network, the interoperability scenario involving an intermediate Internet Protocol IP exchange IPX. For example, the inter-network interface may include an N32 interface, although the present invention is not limited to this particular interface.

[0022] Figure 1An example system according to at least some embodiments of the present invention is shown. The system includes two public land mobile networks PLMN 110, 112, each equipped with a network function NF 120, 122. A network function may refer to an operation and / or a physical entity. A network function may be a specific network node or element, or a specific function or set of functions performed by one or more entities (such as a virtualized network element VNF). A physical node may be configured to execute multiple NFs. Examples of such network functions include resource control or management functions, session management or control functions, intercommunication, data management or storage functions, authentication functions, or a combination of one or more of these functions.

[0023] In the case of a 3GPP 5G system service-based architecture SBA core network, the NF may include at least some of the following: access and mobility management function AMF, session management function SMF, network slice selection function NSSF, network open function NEF, network repository function NRF, unified data management node UDM, authentication server function AUSF, policy control function PCF, and application function AF. Each PLMN may further include a security edge protection agent SEPP 130, 132, which is configured to operate as a security edge node and / or a gateway. For example, NFs may communicate with each other using representational state transfer application programming interfaces. These may be referred to as Restful APIs. Further examples of NFs include NFs related to gaming, streaming, or industrial process control. The system may also include nodes from 3G or 4G systems (such as home subscriber servers HSS) and suitable interworking functions for protocol conversion between, for example, diameter and REST API Json. Although the terminology of the 5G system is mainly used herein, the principles of the present invention are also applicable to other communication networks using gateways as described herein, such as, for example, non-3GPP networks.

[0024] In the case of two PLMNs, Figure 1In the embodiment, SEPP 130, 132 is a network node at the border of the operator's network, which can be configured to receive messages (such as HTTP requests or HTTP responses from NFs), apply protection to the transmission, and forward the reformatted messages to the receiving SEPP through a chain of intermediate nodes (such as IP eXchanges, IPX). The receiving SEPP receives the message sent by the sending SEPP and forwards the message to the NF within its operator's network, such as AUSF. The SEPP can perform additional security verification. An end-to-end protocol connection can be established between SEPP 130, 132. This end-to-end connection can be based on transport layer security TLS, for example. The data of the end-to-end connection can be conveyed by intermediate IPXs, however, the role of these IPXs relative to the end-to-end connection may only be forwarding, and the IPXs do not act on the data of the end-to-end connection. A handshake process may be performed between SEPPs to initialize an end-to-end connection, negotiate security and protection policies to be applied to control plane messages (such as HTTP requests and responses issued by NFs) exchanged between SEPPs, for example, over an N32-f interface, and establish the end-to-end connection with the SEPP, with the SEPP acting as an endpoint of the end-to-end connection. An example of such a handshake process is an N32-c handshake.

[0025] SEPP 130, 132 is a network node at the border of the operator's network, which can be configured to receive messages (such as HTTP requests or HTTP responses from NFs), apply protection to the transmission, and forward the reformatted messages to the receiving SEPP through a chain of intermediate nodes (such as IPeXchanges, IPX). The receiving SEPP receives the message sent by the sending SEPP and forwards the message to the NF within its operator's network, such as AUSF. The SEPP can perform additional security verification.

[0026] exist Figure 1 In the example of FIG. 1 , communication is performed between a service consuming NF and a service producing NF (hereinafter referred to as NFc 120 and NFp 122). They may also be referred to as NF service consumer and NF service producer, respectively.

[0027] The service communication agent SCP 150 may be deployed for indirect communication between network functions NF or between NF and SEPP. SCP is an intermediate network entity that assists indirect communication between NFc and NFp, including routing messages (such as, for example, control plane messages between NFs), and optionally including discovering and selecting NFp on behalf of NFc or requesting an access token from NRF or authentication server on behalf of NFc to access the services of NFp.

[0028] For NF services, direct communication may be applied between NFc 120 and NFp 122, or NF service communication may be performed indirectly via (one or more) SCPs 150. In direct communication, NFc 120 performs discovery of target NFp 122 by local configuration or via local NRF (cNRF 140). In indirect communication, NFc 120 may delegate discovery of target NFp 122 to SCP 150. In the latter case, SCP may perform discovery and / or selection of target NFp using parameters provided by NFc 120, for example, with reference to one or more NRFs.

[0029] NF discovery and NF service discovery enable an entity (e.g., NFc or SCP) to discover a set of (one or more) NF instances and (one or more) NF service instances for a specific NF service or NF type. NFc and / or SCP may be core network entities. The network repository function NRF may include functions for supporting NF and NF service registration, discovery, authentication, and status notification. NRF may maintain NF profiles of available NFp entities and the services they support. NRF may notify the subscribed NFc or SCP of newly registered, updated, or deregistered NFp entities along with their NF services. Therefore, NRF may suggest to NFc entities where they can get the services they need (i.e., from which NFp entities). NRF may be co-located with SCP, for example, running in the same computing substrate. Alternatively, NRF may be in a node physically different from SCP, or even hosted by a service provider.

[0030] In order for NFc 120 or SCP 150 to obtain information about NFp and / or (one or more) NF services registered or configured in the PLMN / slice, NFc 120 or SCP 150 may initiate a discovery process with an NRF (such as cNRF 140) based on local configuration. The discovery process may be initiated by providing the type of NF and optionally a list of (one or more) specific services it is trying to discover. NFc 120 or SCP 150 may also provide other service parameters, such as information related to the network slice.

[0031] It should be noted that at least some of the entities or nodes 120, 122, 140, 142 may play both a service consumption role and a service provision role, and their physical structures may be similar or identical, while their roles in delivering a particular message or service in the current example are identified by using a prefix / suffix "c" or "p" indicating whether they are acting as a service consumption NF or a service production NF. It should be noted that instead of "c" and "p", "v" may be used for visiting and "h" for home to refer to at least some of the corresponding entities in the visiting and home PLMNs. In some embodiments, a system implementing an embodiment of the present disclosure includes both a fourth generation 4G part and a fifth generation 5G part.

[0032] In the 3GPP interoperability scenario, the interface between two SEPPs in different PLMNs may be referred to as the N32 interface. In detail, N32-c is a control connection for managing the N32 interface, and N32-f is a data plane connection for sending payload data (such as, for example, HTTP requests and responses issued by NFs in each PLMN) over the N32 interface between SEPPs. The N32-f payload may, for example, include JSON web encryption JWE messages and JSON web signature JWS messages between SEPPs. N32-c may, for example, be used for key negotiation, parameter exchange, and error handling between endpoint SEPPs. For example, a TLS end-to-end connection may be used to convey information over the N32-c interface.

[0033] When the cSEPP 130 prepares the payload data for transmission to another N32 endpoint, it has been observed that if payload compression is used between NFc and NFp, the cSEPP needs to first decompress the payload received from the sending NF, and the reformatting and / or encryption operations performed by the cSEPP before submitting the payload data to the N32 interface can further increase the payload size. In some cases, the payload size can even increase to an integer multiple of its original size. This poses a problem because the increase in payload size along the communication path between, for example, the cSEPP 130 and the NFp 122 can render the performance of the aggregation system unpredictable. Therefore, in order to obtain the technical effect of more predictable network performance, data compression mechanisms on end-to-end inter-SEPP data plane connections (such as N32-f) are of interest. Regarding reformatting, the SEPP can reformat the HTTP / 2 message, for example, by encapsulating the entire message into the body of a new HTTP POST message. The body of the HTTP POST request / response message can then contain the reformatted original HTTP / 2 request / response message, respectively. The HTTP POST request / response body may then be encoded as a "N32fReformattedReqMsg" / "N32fReformattedRspMsg" JSON body, respectively. When receiving the N32-f payload, the receiving SEPP (pSEPP 132) needs to reconstruct the original HTTP message. The second problem here is that no process has been defined to enable the pSEPP to determine whether it should compress the reconstructed HTTP payload before forwarding it to the receiving NF (NFp), for example if the original HTTP message that has been received by the cSEPP 130 has been compressed by the NFc 120.

[0034] In detail, N32-f JSON payload compression may be negotiated on a hop-by-hop or end-to-end basis by negotiating support / use of N32-f payload compression during a handshake process that establishes an end-to-end inter-SEPP connection. An example of such a handshake process is the N32-c handshake. In the latter case, an initiating gateway (such as a SEPP) will indicate during establishment of a logical control plane connection prior to establishing an associated data plane connection (such as N32-f) that compression of payloads transferred over the data plane connection is requested and / or supported. Establishing a control plane connection is a process that begins before a control plane connection exists and ends when the control plane connection exists.

[0035] When payload compression is negotiated hop by hop, the cSEPP may provide an indication that compression of the payload delivered on the data plane connection is supported in a message addressed to the next node on the N32-f path (e.g., an intermediate Internet Protocol exchange IPX1, the first intermediate IPX being an endpoint of the connection for communicating the message). Similarly, the next node on the N32-f path (e.g., IPX1) may also indicate support for payload compression to the cSEPP in a message addressed to the cSEPP. The indication may be communicated, for example, by including a Content-encodings header indicating support for compression in an HTTP request and response. Examples of HTTP requests and responses include HTTP POST requests and responses. Supported compression mechanisms, such as gzip, may be indicated. Alternatively, the cSEPP may discover whether the next node on the N32-f path supports payload compression by sending, for example, an HTTP OPTIONS request and responding with a response including a Content-encodings header indicating support for compression (e.g., gzip) by the next node on the N32-f path. The first IPX may be the first IPX along the communication path from cSEPP to pSEPP. The first IPX may be directed toward its next hop node on the N32-f path (e.g., Figure 1 The two IPXs shown are IPX2 in the same manner. In a hop-by-hop payload compression negotiation, the handshake process (such as, for example, the N32-c handshake) that establishes an end-to-end data plane connection between SEPPs may be silent for payload compression indications associated with a data plane connection (such as N32-f). The end-to-end data plane connection between gateway devices (such as SEPPs) includes and traverses multiple subsegments between participating gateways and various entities in the IPX. When negotiating hop-by-hop, support for payload compression is negotiated separately on each subsegment.

[0036] The result of the hop-by-hop payload compression negotiation may be that some inter-IPX connections along a communication path between gateways (such as SEPPs) use payload compression, and other inter-IPX connections along the communication path do not use payload compression. For example, some intermediate IPX units may not be configured to support payload compression, while other intermediate IPX units may be configured to support payload compression and be willing to use it when requested.

[0037] cSEPP may employ payload compression after encrypting N32-f payload data to be sent to another gateway device (such as pSEPP) over an end-to-end data plane connection.

[0038] On the other hand, during the end-to-end negotiation, the cSEPP may provide an indication that compression of the payload delivered on the data plane connection is requested or supported in a handshake process (e.g., an N32-c handshake process) that establishes a logical control plane connection before establishing the associated data plane end-to-end connection between the gateways. Another gateway (such as a SEPP) is then an endpoint of a connection for communicating a message including an indication that compression of the payload is requested. In this case, the initiating gateway (such as a cSEPP) may be configured with information defining which compression mechanisms are supported by at least one of at least one intermediate IPX along the communication path of the end-to-end data plane connection (such as N32-f). For example, the gateway may have information about the compression mechanism supported by the IPX local to the gateway's PLMN via a service level agreement SLA between the gateway network operator and (one or more) IPX providers. When both gateways (e.g., SEPPs) have such information about the IPXs with which they have SLAs, the negotiation may take into account the payload compression capabilities of the IPXs that will participate in the data plane connection. In some cases, this may enable information about the payload compression capabilities of all intermediate IPXs to be considered. This is the case when all intermediate IPXs have SLAs with one or both of the gateways (such as SEPP).

[0039] When payload compression is negotiated end-to-end, the handshake process of establishing a logical control plane connection before establishing the associated data plane end-to-end connection between gateways may include a negotiation about which compression mechanism is used to compress the payload data transmitted on the data plane connection. Examples of suitable compression mechanisms include gzip and variations of the Lempel-Ziv-Welch (LZW) compression algorithm. This may be based on the compression capabilities of the intermediate IPX so that a compression mechanism supported by the SEPP and the intermediate IPX may be selected for the payload data on the data plane connection.

[0040] The payload may be provided into the data plane connection, for example as compressed javascript object notation JSON data. An example of payload data is a discovery request to be provided to a network function producer 122 in the PLMN 112. The NFp 122 may be, for example, an NRF.

[0041] In order to enable the receiving SEPP (pSEPP) to determine whether it should compress the reconstructed HTTP payload before forwarding it onwards to a receiving NF (such as NFp), in some embodiments of the invention the receiving SEPP is configured to determine whether compression is required by inspecting the content-coding header of the original HTTP payload that has been received by the cSEPP. This content-coding header is received by the pSEPP in the HttpHeader attribute within the DataToIntegrityProtectBlock of the N32-f payload, as defined in clause 6.2.5.2.5 of 3GPP document TS 29.573. If the block indicates, for example, gzip compression, the receiving SEPP may be configured to compress the payload with gzip before sending it onwards to the receiving NF (NFp). This may be relevant, for example, in the case where the original HTTP message that has been received by the cSEPP has been compressed by NFc.

[0042] Figure 2A Example embodiments according to at least some embodiments of the present invention are shown. In particular, Figure 2A A hop-by-hop negotiation is shown. Gateways (SEPPs in the embodiment shown) are placed on the left and right, and between them are intermediate IPXs, of which there are two in this non-limiting example.

[0043] Stage 210 represents the handshake process of establishing a logical N32-c control plane connection from the cSEPP to the pSEPP before establishing the N32-f connection. As discussed above, the data plane connection may include, for example, an N32-f data plane connection. As discussed herein above, the data plane connection may pass through an intermediate IPX along the way.

[0044] Phase 220 includes the cSEPP discovering whether the next node IPX1 on the N32-f path supports compression of the payload on the data plane connection. This discovery can be performed, for example, using an HTTP POST or HTTP OPTIONS request message. Phase 230 includes IPX1 responding to the request, for example by returning a response message indicating support for payload compression. In some embodiments, the message of phase 230 includes a suggestion of one or more compression mechanisms supported by IPX1, together reaching a negotiation on the compression mechanism to be used between the cSEPP and IPX1.

[0045] Phase 250 includes IPX1 discovering whether the next node IPX2 on the N32-f path supports compression of the payload on the data plane connection. This discovery can be performed, for example, using an HTTP POST or HTTP OPTIONS request message. Phase 260 includes IPX2 responding to the request, for example, by returning a response message indicating support for payload compression. In some embodiments, the message of phase 260 includes a suggestion of one or more compression mechanisms supported by IPX2, together reaching a negotiation about the compression mechanism to be used between IPX1 and IPX2.

[0046] Phase 280 includes IPX2 discovering whether the next node pSEPP on the N32-f path supports compression of the payload on the data plane connection. This discovery can be performed, for example, using an HTTP POST or HTTP OPTIONS request message. Phase 290 includes pSEPP responding to the request, for example by returning a response message indicating support for payload compression. In some embodiments, the message of phase 290 includes a suggestion of one or more compression mechanisms supported by pSEPP, together reaching a negotiation about the compression mechanism to be used between IPX2 and pSEPP.

[0047] Message flows 240, 270, 295 represent the communication of payload data over an end-to-end data plane connection from cSEPP to pSEPP according to the payload compression convention between the participating SEPPs and IPX. For example, the payload in stage 240 may include an N32-f payload compressed with gzip, and the payloads in stages 270 and 295 may include an N32-f payload that is not compressed or compressed with a different compression algorithm.

[0048] It is worth noting that in Figure 2A In the embodiment of the present invention, the payload compression mechanism agreed between nodes does not need to be the same in the connection path of the entire data plane connection. Therefore, a first payload compression mechanism can be used between cSEPP and IPX1, and a second payload compression mechanism can be used between IPX1 and IPX2. In order to achieve this, the payload data can be first encrypted in cSEPP and then compressed so that the intermediate IPX can decompress the payload, even if they cannot decrypt it. Further, payload compression can only be used for a subset of the connection along the connection path of the data plane connection. For example, a first payload compression mechanism can be used between cSEPP and IPX1, a second payload compression mechanism can be used between IPX1 and IPX2, and there can be no payload compression in the connection from IPX2 to pSEPP. Non-limiting examples of payload compression mechanisms include gzip and LZW, as discussed herein above.

[0049] Figure 2B Example embodiments according to at least some embodiments of the present invention are shown. In particular, Figure 2B shows an end-to-end negotiation. In this figure, place the gateway and the intermediate IPX as in Figure 2A middle.

[0050] Stage 2100 represents the handshake process of establishing a logical control plane connection N32-c from the cSEPP to the pSEPP before establishing the N32-f data plane connection. As discussed above, the data plane connection may, for example, include an N32-f data plane connection. As discussed above, the data plane connection may pass through an intermediate IPX along the way. Figure 2B In an embodiment, the cSEPP includes an indication during the handshake process that compression of the payload delivered on the data plane connection is supported and desired. For example, the indication may be included in a message sent by the cSEPP to the pSEPP during the handshake process.

[0051] Prior to or during stage 2100, the cSEPP may be configured to select a preferred payload compression mechanism that at least some of the intermediate IPXs (such as IPX1 and IPX2) that it knows will support. To this effect, the cSEPP may be configured to store information defining which compression mechanisms are supported by at least some of the IPXs. For example, the cSEPP may be configured with information defining compression mechanisms supported by an IPX that has an SLA with a network that includes the cSEPP.

[0052] In the example shown, where the cSEPP has an SLA with IPX1, the cSEPP can negotiate a compression mechanism for itself and IPX1. Where the pSEPP has an SLA with IPX2, the pSEPP can negotiate a compression mechanism for itself and IPX2. Thus, in the example shown, the compression mechanism can be agreed upon by the cSEPP and the pSEPP and supported by all SEPPs and IPX along the communication path of the data plane connection (such as N32-f).

[0053] Stages 2110, 2120, and 2130 represent communicating payload data over the data plane connection according to payload compression negotiated, for example, in handshake process 2100. The payload may be compressed, for example, with gzip in stages 2110, 2120, and 2130. The payload may include any service request by the target PLMN to the service producer, such as, for example, a discovery request.

[0054] Figure 3 An example apparatus capable of supporting at least some embodiments of the present invention is shown. Shown is a device 300, which may include, for example Figure 1Or the gateway of Figure 2, such as SEPP. A processor 310 is included in the device 300, which may include, for example, a single-core or multi-core processor, wherein the single-core processor includes one processing core and the multi-core processor includes more than one processing core. Generally, the processor 310 may include a control device. The processor 310 may include more than one processor. The processor 310 may be a control device. The processing core may include, for example, a Cortex-A8 processing core manufactured by ARM or a Steamroller processing core designed by Advanced MicroDevices. The processor 310 may include at least one Qualcomm Snapdragon and / or Intel Xeon processor. The processor 310 may include at least one application-specific integrated circuit ASIC. The processor 310 may include at least one field programmable gate array FPGA. The processor 310 may be a device for performing method steps (such as, for example, initiating and indicating) in the device 300. The processor 310 may be configured to perform actions at least in part by computer instructions.

[0055] The processor may include circuitry or be configured as one or more circuits configured to perform the stages of the method according to the embodiments described herein. As used in this application, the term "circuitry" may refer to one or more or all of the following: (a) a hardware circuit implementation only, such as an implementation using only analog and / or digital circuits, (b) a combination of hardware circuitry and software, such as (if applicable): (i) a combination of (one or more) analog and / or digital hardware circuits with software / firmware and (ii) any portion of (one or more) hardware processors with software (including (one or more) digital signal processors, software and (one or more) memories that work together to enable the device (such as a gateway or IPX) to perform various functions), and (c) (one or more) hardware circuits and / or (one or more) processors, such as (one or more) microprocessors or (one or more) microprocessor parts, which require software (e.g., firmware) for operation, but the software may not be present when it is not required for operation.

[0056] This definition of "circuitry" applies to all uses of the term in this application, including in any claims. As another example, as used in this application, the term "circuitry" also covers an implementation of only a hardware circuit or processor (or multiple processors) or a portion of a hardware circuit or processor and its (or their) accompanying software and / or firmware. For example and if applicable, the term "circuitry" also covers a specific claimed element, a baseband integrated circuit or processor integrated circuit for a mobile device, or a similar integrated circuit in a server, cellular network device, or other computing or network device.

[0057] Device 300 may include memory 320. Memory 320 may include random access memory and / or permanent memory. Memory 320 may include at least one RAM chip. For example, memory 320 may include, for example, solid-state, magnetic, optical and / or holographic memory. Memory 320 may be at least partially accessible to processor 310. Memory 320 may be at least partially included in processor 310. Memory 320 may be a device for storing information. Memory 320 may include computer instructions that processor 310 is configured to execute. When computer instructions configured to cause processor 310 to perform certain actions are stored in memory 320 and device 300 is generally configured to run under the guidance of processor 310 using computer instructions from memory 320, processor 310 and / or at least one of its processing cores may be considered to be configured to perform the certain actions described. Memory 320 may be at least partially included in processor 310. Memory 320 may be at least partially external to device 300, but accessible to device 300.

[0058] Device 300 may include a transmitter 330. Device 300 may include a receiver 340. Transmitter 330 and receiver 340 may be configured to transmit and receive information, respectively, according to at least one cellular or non-cellular standard. Transmitter 330 may include more than one transmitter. Receiver 340 may include more than one receiver.

[0059] Device 300 may include a user interface UI 360. UI 360 may include at least one of: a display, a keyboard, a touch screen, a vibrator configured to signal the user by vibrating device 300, a speaker, and a microphone. The user may be able to operate device 300 via UI 360, for example to configure interoperability parameters.

[0060] The processor 310 may be equipped with a transmitter, wherein the transmitter is arranged to output information from the processor 310 to other devices included in the device 300 via electrical conductors inside the device 300. Such a transmitter may include a serial bus transmitter arranged to output information to the memory 320 for storage therein, for example, via at least one electrical conductor. Alternatively to the serial bus, the transmitter may include a parallel bus transmitter. Similarly, the processor 310 may include a receiver arranged to receive information in the processor 310 from other devices included in the device 300 via electrical conductors inside the device 300. Such a receiver may include a serial bus receiver arranged to receive information from the receiver 340, for example, via at least one electrical conductor, for processing in the processor 310. Alternatively to the serial bus, the receiver may include a parallel bus receiver.

[0061] The device 300 may include Figure 3 Other devices not shown in the figure. For example, where the device 300 comprises a smartphone, it may comprise at least one digital camera. Such a device 300 may comprise a rear camera and a front camera, wherein the rear camera may be intended for digital photography and the front camera for video telephony. The device 300 may comprise a fingerprint sensor arranged to at least partially authenticate a user of the device 300. In some embodiments, the device 300 lacks at least one of the devices described above.

[0062] The processor 310, the memory 320, the transmitter 330, the receiver 340 and / or the UI 360 may be interconnected in a variety of different ways via electrical conductors within the device 300. For example, each of the aforementioned devices may be separately connected to a main bus within the device 300 to allow the devices to exchange information. However, as will be appreciated by the skilled person, this is only an example, and depending on the embodiment, various ways of interconnecting at least two of the aforementioned devices may be selected without departing from the scope of the present invention.

[0063] Figure 4 1 shows signaling according to at least some embodiments of the present invention. Figure 1 Or the cSEPP in Figure 2, the setting on the right is Figure 1 Or pSEPP in Figure 2. Time progresses from top to bottom. Figure 4 The process can correspond to, for example Figure 2B Stage 2100.

[0064] Phase 410 includes a TLS handshake process, whereby a secure connection, such as a Hypertext Transfer Protocol 2 (HTTP / 2) connection, may be formed between the SEPPs.

[0065] Phase 420 is the security capability negotiation process. The initiating SEPP initiates this process to the responding SEPP to negotiate the security mechanism to be used to protect the network function NF service-related signaling on N32-f. An end-to-end TLS connection may be established between the SEPPs before initiating this process. The agreed security mechanism may be, for example, the use of TLS or the protocol PRINS for N32 interconnect security to protect the data sent on the N32-f connection.

[0066] Stage 430 is the parameter exchange process. If the security capability negotiation process selects the security mechanism as PRINS, the parameter exchange process is performed. The parameter exchange process is performed to agree on the cipher suite to be used to protect the NF service related signaling on N32-f. Optionally, the protection policy to be used to protect the NF service related signaling on N32 is exchanged as part of the parameter exchange process. The initiating SEPP (such as cSEPP) can provide a list of supported cipher suites, and the responding SEPP (such as pSEPP) can select one of the cipher suites in the list for use in the N32-f interface. The initiating SEPP can also provide an N32-f context identifier to be used by the responding SEPP towards the initiating SEPP for the subsequent JavaScript Object Signing and Encryption (JOSE) protected message forwarding process on N32-f.

[0067] An indication that compression of the payload delivered on the data plane connection is supported and desired may be included, for example, in stage 420 or stage 430. Such an indication may include an ordered list of compression mechanisms supported by the initiating SEPP. The ordered list may be sorted in order of preference, for example, based on computational efficiency and / or compression performance. The list may include compression mechanisms that the initiating SEPP and the IPX with which it has an SLA may support. Negotiations regarding payload compression methods may also be included in stage 420 or 430, respectively. For example, supported payload compression methods may be included in a message including a list of cipher suites in stage 430. Alternatively or additionally, supported payload compression methods may be included in a message including a list of supported security mechanisms in stage 420.

[0068] Optional stage 440 is the N32-f Error Reporting procedure. When a SEPP is unable to process a message it receives over the N32-f interface due to an error, the error information is communicated to the sending SEPP using the N32-f Error Reporting procedure over the N32-c interface.

[0069] Figure 5 is a flow chart of a method according to at least some embodiments of the present invention. The stages of the method shown may be performed in a SEPP or in a control device configured to control its operation when installed therein.

[0070] Stage 510 includes initiating a handshake procedure from a device, the handshake procedure configured to establish a logical control plane connection prior to establishing a data plane connection from the device to a gateway node in a second network, the device being in a first network different from the second network. Stage 520 includes indicating during establishment of the control plane connection that compression of a payload communicated on the data plane connection is requested, and wherein the data plane connection to the gateway node traverses at least one intermediate Internet Protocol switch. A compression mechanism agreed upon in the negotiation with the gateway may then be used in compressing the payload communicated on the data plane connection.

[0071] It will be understood that the disclosed embodiments of the invention are not limited to the specific structures, process steps, or materials disclosed herein, but are extended to their equivalents as would be recognized by those of ordinary skill in the relevant art. It should also be understood that the terminology employed herein is only used for the purpose of describing specific embodiments and is not intended to be limiting.

[0072] Reference to an embodiment or embodiments throughout the specification means that a particular feature, structure, or characteristic described in conjunction with that embodiment is included in at least one embodiment of the invention. Thus, the appearance of the phrase "in one embodiment" or "in an embodiment" in various places throughout the specification does not necessarily refer to the same embodiment. Where terms such as, for example, "about" or "substantially" are used to refer to values, the exact value is also disclosed.

[0073] As used herein, for convenience, multiple items, structural elements, constituent elements and / or materials can be presented in a common list. However, these lists should be interpreted as if each member in the list is individually identified as a separate and unique member. Therefore, in the absence of contrary instructions, based only on its presentation in a common group, the individual members of such lists should not be interpreted as being actually equivalent to any other member in the same list. In addition, various embodiments and examples of the present invention together with the alternatives of its various parts may also be related to in this article. It should be understood that such embodiments, examples and alternatives will not be interpreted as actually equivalent to each other, but will be considered as separate and autonomous representations of the present invention.

[0074] In addition, in one or more embodiments, the described features, structures or characteristics can be combined in any suitable manner. In the foregoing description, many specific details (such as examples of length, width, shape, etc.) are provided to provide a thorough understanding of embodiments of the present invention. However, those skilled in the relevant art will recognize that the present invention can be practiced without one or more of the specific details or with other methods, parts, materials, etc. In other examples, well-known structures, materials or operations are not shown or described in detail to avoid blurring aspects of the present invention.

[0075] Although the foregoing examples illustrate the principles of the present invention in one or more specific applications, it is obvious to those skilled in the art that many modifications may be made in the form, use and details of implementation without exercising the inventive power and without departing from the principles and concepts of the present invention. Therefore, the present invention is not intended to be limiting, except as set forth in the claims below.

[0076] The verbs "comprise" and "include" are used in this document as open limitations that neither exclude nor require the existence of features not yet recited. The features recited in the dependent claims are mutually freely combinable unless explicitly stated otherwise. Furthermore, it will be understood that the use of "a" or "an" (i.e. the singular) throughout this document does not exclude a plurality.

[0077] At least some embodiments of the present invention find industrial utility in operating communication networks.

[0078] List of abbreviations

[0079] JSON JavaScript Object Notation

Claims

1. An apparatus for managing payload compression, comprising: at least one processing core; at least one memory including computer program code; The at least one memory and the computer program code are configured to, with the at least one processing core, cause the apparatus to at least: participating as a first gateway in a handshake process, the handshake process being configured to establish a control plane connection prior to establishing an associated data plane connection from the apparatus to a gateway node in a first network, the apparatus being in a second network different from the first network, wherein the data plane connection to the gateway node traverses at least one intermediate Internet Protocol switch; receiving a Hypertext Transfer Protocol (HTTP) payload transmitted on the data plane connection, wherein the HTTP payload is compressed or uncompressed; Before forwarding the reconstructed Hypertext Transfer Protocol (HTTP) payload received on the data plane connection onward to a network function in the second network, determining whether to compress the reconstructed Hypertext Transfer Protocol (HTTP) payload.

2. The device according to claim 1, wherein: The apparatus is configured to perform the determination based on a content-encoding header of the reconstructed HTTP payload received in the HTTP payload communicated over the data plane connection.

3. A method for managing payload compression, comprising: engaging, by a device as a first gateway, in a handshake procedure, the handshake procedure being configured to establish a control plane connection prior to establishing an associated data plane connection from the device to a gateway node in a first network, the device being in a second network different from the first network, wherein the data plane connection to the gateway node traverses at least one intermediate Internet Protocol switch; receiving a Hypertext Transfer Protocol (HTTP) payload transmitted on the data plane connection, the HTTP payload being compressed or uncompressed; and Before forwarding the reconstructed Hypertext Transfer Protocol (HTTP) payload received on the data plane connection onward to a network function in a second network, determining whether to compress the reconstructed Hypertext Transfer Protocol (HTTP) payload.

4. The method according to claim 3, wherein: The determining is performed based at least in part on a content-encoding header of the reconstructed HTTP payload received in the HTTP payload communicated over the data plane connection.

Images