Apparatus, method and computer program

Abstract

There is provided an apparatus comprising means for receiving a first identifier from an entity in a first core network at an entity in a second core network in a procedure for setting up a first connection on an interface between the entity in the first core network and the entity in the second core network, wherein the first identifier is associated with the first connection and means for providing a second identifier from the entity in the second core network to the entity in the first core network in response, wherein the second identifier is associated with the first connection.

Description

[0001] APPARATUS, METHOD AND COMPUTER PROGRAM

[0002] Field

[0003] The present application relates to a method, apparatus, system and computer program and in particular but not exclusively to 5GS interconnect enhancements for N32-c and N32-f connections correlation.

[0004] Background

[0005] A communication system can be seen as a facility that enables communication sessions between two or more entities such as user terminals, base stations and / or other nodes by providing carriers between the various entities involved in the communications path. A communication system can be provided for example by means of a communication network and one or more compatible communication devices. The communication sessions may comprise, for example, communication of data for carrying communications such as voice, video, electronic mail (email), text message, multimedia and / or content data and so on. Nonlimiting examples of services provided comprise two-way or multi-way calls, data communication or multimedia services and access to a data network system, such as the Internet.

[0006] In a wireless communication system at least a part of a communication session between at least two stations occurs over a wireless link. Examples of wireless systems comprise public land mobile networks (PLMN), satellite based communication systems and different wireless local networks, for example wireless local area networks (WLAN). Some wireless systems can be divided into cells, and are therefore often referred to as cellular systems.

[0007] A user can access the communication system by means of an appropriate communication device or terminal. A communication device of a user may be referred to as user equipment (UE) or user device. A communication device is provided with an appropriate signal receiving and transmitting apparatus for enabling communications, for example enabling access to a communication network or communications directly with other users. The communication device may access a carrier provided by a station, for example a base station of a cell, and transmit and / or receive communications on the carrier. The communication system and associated devices typically operate in accordance with a given standard or specification which sets out what the various entities associated with the system are permitted to do and how that should be achieved. Communication protocols and / or parameters which shall be used for the connection are also typically defined. One example of a communications system is Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN) (3G radio). Other examples of communication systems are the long-term evolution (LTE) of the Universal Mobile Telecommunications System (UMTS) radio-access technology and so-called 5G or New Radio (NR) networks. NR is being standardized by the 3rd Generation Partnership Project (3GPP). Other examples of communication systems include 5G-Advanced (NR Rel-18 and beyond) and 6G.

[0008] Summary

[0009] In a first aspect there is provided an apparatus comprising means for receiving a first identifier from an entity in a first core network at an entity in a second core network in a procedure for setting up a first connection on an interface between the entity in the first core network and the entity in the second core network, wherein the first identifier is associated with the first connection and means for providing a second identifier from the entity in the second core network to the entity in the first core network in response, wherein the second identifier is associated with the first connection.

[0010] The apparatus may comprise means for receiving the first identifier in a security capability exchange request.

[0011] The apparatus may comprise means for providing the second identifier in a security capability exchange response.

[0012] The apparatus may comprise means for receiving a further security capability exchange request from the entity in the first core network at the entity in the second core network for the first connection, the further security capability exchange request comprising the first identifier and means for deriving that the further security capability exchange request relates to the first connection based on the first identifier.

[0013] The apparatus may comprise means for associating the first identifier with another identifier received in a security parameter exchange request. The apparatus may comprise means for further receiving the first identifier in a security parameter exchange request.

[0014] The apparatus may comprise means for receiving a message comprising the second identifier from the entity in the first core network at the entity in the second core network using a second connection on the interface between the entity in the first core network and the entity in the second core network and means for correlating the second connection with the first connection based on the second identifier.

[0015] The apparatus may comprise means for removing the second identifier from the message and means for providing the message from the entity in the second core network to a further entity in the second core network.

[0016] The apparatus may comprise means for further receiving the second identifier in a HTTP custom header.

[0017] The custom header may further include a fully qualified domain name, FQDN, associated with the entity in the first core network. The apparatus may comprise means for correlating the second connection with the first connection further based on the FQDN.

[0018] The first identifier and the second identifier may be the same or different.

[0019] The first identifier and the second identifier may comprise a handshake identifier.

[0020] The entity in the first core network and the entity in the second core network may comprise a security edge protection proxy, SEPP.

[0021] The interface may be a N32 interface. The first connection may be a N32-c connection. The second connection may be a N32-f connection.

[0022] Transport layer security or application layer security may be used to secure messages forwarded over the second connection.

[0023] In a second aspect there is provided an apparatus comprising means for providing a first identifier from an entity in a first core network to an entity in a second core network in a procedure for setting up a first connection on an interface between the entity in the first core network and the entity in the second core network, wherein the identifier is associated with the first connection and means for receiving a second identifier from the entity in the second core network at the entity in the first core network in response, wherein the second identifier is associated with the first connection.

[0024] The apparatus may comprise means for providing the first identifier in a security capability exchange request.

[0025] The apparatus may comprise means for receiving the second identifier in a security capability exchange response.

[0026] The apparatus may comprise means for providing a further security capability exchange request from the entity in the first core network to the entity in the second core network for the first connection, the further security capability exchange request comprising the first identifier.

[0027] The apparatus may comprise means for further providing the first identifier in a security parameter exchange request.

[0028] The apparatus may comprise means for receiving a message at the entity in the first core network from a further entity in the first core network that is to be sent to the second core network, means for inserting in the message the second identifier, and means for forwarding the message to the entity in the second core network using a second connection on the interface.

[0029] The apparatus may comprise means for further inserting the second identifier in a HTTP custom header.

[0030] The HTTP custom header may further include a fully qualified domain name, FQDN, associated with the entity in the first core network.

[0031] The first identifier and the second identifier may be the same or different.

[0032] The first identifier and the second identifier may comprise a handshake identifier.

[0033] The entity in the first core network and the entity in the second core network may comprise a security edge protection proxy, SEPP. The interface may be a N32 interface. The first connection may be a N32-c connection. The second connection may be a N32-f connection.

[0034] Transport layer security or application layer security may be used to secure messages forwarded over the second connection.

[0035] In a third aspect there is provided a method comprising receiving a first identifier from an entity in a first core network at an entity in a second core network in a procedure for setting up a first connection on an interface between the entity in the first core network and the entity in the second core network, wherein the first identifier is associated with the first connection and providing a second identifier from the entity in the second core network to the entity in the first core network in response, wherein the second identifier is associated with the first connection.

[0036] The method may comprise receiving the first identifier in a security capability exchange request.

[0037] The method may comprise providing the second identifier in a security capability exchange response.

[0038] The method may comprise receiving a further security capability exchange request from the entity in the first core network at the entity in the second core network for the first connection, the further security capability exchange request comprising the first identifier and deriving that the further security capability exchange request relates to the first connection based on the first identifier.

[0039] The method may comprise associating the first identifier with another identifier received in a security parameter exchange request.

[0040] The method may comprise further receiving the first identifier in a security parameter exchange request.

[0041] The method may comprise receiving a message comprising the second identifier from the entity in the first core network at the entity in the second core network using a second connection on the interface between the entity in the first core network and the entity in the second core network and correlating the second connection with the first connection based on the second identifier. The method may comprise removing the second identifier from the message and means for providing the message from the entity in the second core network to a further entity in the second core network.

[0042] The method may comprise further receiving the second identifier in a HTTP custom header.

[0043] The custom header may further include a fully qualified domain name, FQDN, associated with the entity in the first core network. The method may comprise correlating the second connection with the first connection further based on the FQDN.

[0044] The first identifier and the second identifier may be the same or different.

[0045] The first identifier and the second identifier may comprise a handshake identifier.

[0046] The entity in the first core network and the entity in the second core network may comprise a security edge protection proxy, SEPP.

[0047] The interface may be a N32 interface. The first connection may be a N32-c connection. The second connection may be a N32-f connection.

[0048] Transport layer security or application layer security may be used to secure messages forwarded over the second connection.

[0049] In a fourth aspect there is provided a method comprising providing a first identifier from an entity in a first core network to an entity in a second core network in a procedure for setting up a first connection on an interface between the entity in the first core network and the entity in the second core network, wherein the identifier is associated with the first connection and receiving a second identifier from the entity in the second core network at the entity in the first core network in response, wherein the second identifier is associated with the first connection.

[0050] The method may comprise providing the first identifier in a security capability exchange request.

[0051] The method may comprise receiving the second identifier in a security capability exchange response. The method may comprise providing a further security capability exchange request from the entity in the first core network to the entity in the second core network for the first connection, the further security capability exchange request comprising the first identifier.

[0052] The method may comprise further providing the first identifier in a security parameter exchange request.

[0053] The method may comprise receiving a message at the entity in the first core network from a further entity in the first core network that is to be sent to the second core network, inserting in the message the second identifier, and forwarding the message to the entity in the second core network using a second connection on the interface.

[0054] The method may comprise further inserting the second identifier in a HTTP custom header.

[0055] The HTTP custom header may further include a fully qualified domain name, FQDN, associated with the entity in the first core network.

[0056] The first identifier and the second identifier may be the same or different.

[0057] The first identifier and the second identifier may comprise a handshake identifier.

[0058] The entity in the first core network and the entity in the second core network may comprise a security edge protection proxy, SEPP.

[0059] The interface may be a N32 interface. The first connection may be a N32-c connection. The second connection may be a N32-f connection.

[0060] Transport layer security or application layer security may be used to secure messages forwarded over the second connection.

[0061] In a fifth aspect there is provided an apparatus comprising at least one processor, and at least one memory storing instructions which, when executed by the processor, cause the apparatus at least to receive a first identifier from an entity in a first core network at an entity in a second core network in a procedure for setting up a first connection on an interface between the entity in the first core network and the entity in the second core network, wherein the first identifier is associated with the first connection and provide a second identifier from the entity in the second core network to the entity in the first core network in response, wherein the second identifier is associated with the first connection.

[0062] The apparatus may be caused to receive the first identifier in a security capability exchange request.

[0063] The apparatus may be caused to provide the second identifier in a security capability exchange response.

[0064] The apparatus may be caused to receive a further security capability exchange request from the entity in the first core network at the entity in the second core network for the first connection, the further security capability exchange request comprising the first identifier and derive that the further security capability exchange request relates to the first connection based on the first identifier.

[0065] The apparatus may be caused to associate the first identifier with another identifier received in a security parameter exchange request.

[0066] The apparatus may be caused to further receive the first identifier in a security parameter exchange request.

[0067] The apparatus may be caused to receive a message comprising the second identifier from the entity in the first core network at the entity in the second core network using a second connection on the interface between the entity in the first core network and the entity in the second core network and correlate the second connection with the first connection based on the second identifier.

[0068] The apparatus may be caused to remove the second identifier from the message and provide the message from the entity in the second core network to a further entity in the second core network.

[0069] The apparatus may be caused to further receive the second identifier in a HTTP custom header.

[0070] The custom header may further include a fully qualified domain name, FQDN, associated with the entity in the first core network. The apparatus may be caused to correlate the second connection with the first connection further based on the FQDN. The first identifier and the second identifier may be the same or different.

[0071] The first identifier and the second identifier may comprise a handshake identifier.

[0072] The entity in the first core network and the entity in the second core network may comprise a security edge protection proxy, SEPP.

[0073] The interface may be a N32 interface. The first connection may be a N32-c connection. The second connection may be a N32-f connection.

[0074] Transport layer security or application layer security may be used to secure messages forwarded over the second connection.

[0075] In a sixth aspect there is provided an apparatus comprising at least one processor, and at least one memory storing instructions which, when executed by the processor, cause the apparatus at least to provide a first identifier from an entity in a first core network to an entity in a second core network in a procedure for setting up a first connection on an interface between the entity in the first core network and the entity in the second core network, wherein the identifier is associated with the first connection and receive a second identifier from the entity in the second core network at the entity in the first core network in response, wherein the second identifier is associated with the first connection.

[0076] The apparatus may be caused to provide the first identifier in a security capability exchange request.

[0077] The apparatus may be caused to receive the second identifier in a security capability exchange response.

[0078] The apparatus may be caused to provide a further security capability exchange request from the entity in the first core network to the entity in the second core network for the first connection, the further security capability exchange request comprising the first identifier.

[0079] The apparatus may be caused to further provide the first identifier in a security parameter exchange request. The apparatus may be caused to receive a message at the entity in the first core network from a further entity in the first core network that is to be sent to the second core network, insert in the message the second identifier, and forward the message to the entity in the second core network using a second connection on the interface.

[0080] The apparatus may be caused to further insert the second identifier in a HTTP custom header.

[0081] The HTTP custom header may further include a fully qualified domain name, FQDN, associated with the entity in the first core network.

[0082] The first identifier and the second identifier may be the same or different.

[0083] The first identifier and the second identifier may comprise a handshake identifier.

[0084] The entity in the first core network and the entity in the second core network may comprise a security edge protection proxy, SEPP.

[0085] The interface may be a N32 interface. The first connection may be a N32-c connection. The second connection may be a N32-f connection.

[0086] Transport layer security or application layer security may be used to secure messages forwarded over the second connection.

[0087] In a seventh aspect there is provided a computer readable medium comprising instructions which, when executed by an apparatus, cause the apparatus to perform at least the following: receiving a first identifier from an entity in a first core network at an entity in a second core network in a procedure for setting up a first connection on an interface between the entity in the first core network and the entity in the second core network, wherein the first identifier is associated with the first connection and providing a second identifier from the entity in the second core network to the entity in the first core network in response, wherein the second identifier is associated with the first connection.

[0088] The apparatus may be caused to perform receiving the first identifier in a security capability exchange request.

[0089] The apparatus may be caused to perform providing the second identifier in a security capability exchange response. The apparatus may be caused to perform receiving a further security capability exchange request from the entity in the first core network at the entity in the second core network for the first connection, the further security capability exchange request comprising the first identifier and deriving that the further security capability exchange request relates to the first connection based on the first identifier.

[0090] The apparatus may be caused to perform associating the first identifier with another identifier received in a security parameter exchange request.

[0091] The apparatus may be caused to perform further receiving the first identifier in a security parameter exchange request.

[0092] The apparatus may be caused to perform receiving a message comprising the second identifier from the entity in the first core network at the entity in the second core network using a second connection on the interface between the entity in the first core network and the entity in the second core network and correlating the second connection with the first connection based on the second identifier.

[0093] The apparatus may be caused to perform removing the second identifier from the message and means for providing the message from the entity in the second core network to a further entity in the second core network.

[0094] The apparatus may be caused to perform further receiving the second identifier in a HTTP custom header.

[0095] The custom header may further include a fully qualified domain name, FQDN, associated with the entity in the first core network. The apparatus may be caused to perform correlating the second connection with the first connection further based on the FQDN.

[0096] The first identifier and the second identifier may be the same or different.

[0097] The first identifier and the second identifier may comprise a handshake identifier.

[0098] The entity in the first core network and the entity in the second core network may comprise a security edge protection proxy, SEPP. The interface may be a N32 interface. The first connection may be a N32-c connection. The second connection may be a N32-f connection.

[0099] Transport layer security or application layer security may be used to secure messages forwarded over the second connection.

[0100] In an eighth aspect there is provided a computer readable medium comprising instructions which, when executed by an apparatus, cause the apparatus to perform at least the following: providing a first identifier from an entity in a first core network to an entity in a second core network in a procedure for setting up a first connection on an interface between the entity in the first core network and the entity in the second core network, wherein the identifier is associated with the first connection and receiving a second identifier from the entity in the second core network at the entity in the first core network in response, wherein the second identifier is associated with the first connection.

[0101] The apparatus may be caused to perform providing the first identifier in a security capability exchange request.

[0102] The apparatus may be caused to perform receiving the second identifier in a security capability exchange response.

[0103] The apparatus may be caused to perform providing a further security capability exchange request from the entity in the first core network to the entity in the second core network for the first connection, the further security capability exchange request comprising the first identifier.

[0104] The apparatus may be caused to perform further providing the first identifier in a security parameter exchange request.

[0105] The apparatus may be caused to perform receiving a message at the entity in the first core network from a further entity in the first core network that is to be sent to the second core network, inserting in the message the second identifier, and forwarding the message to the entity in the second core network using a second connection on the interface.

[0106] The apparatus may be caused to perform further inserting the second identifier in a HTTP custom header. The HTTP custom header may further include a fully qualified domain name, FQDN, associated with the entity in the first core network.

[0107] The first identifier and the second identifier may be the same or different.

[0108] The first identifier and the second identifier may comprise a handshake identifier.

[0109] The entity in the first core network and the entity in the second core network may comprise a security edge protection proxy, SEPP.

[0110] The interface may be a N32 interface. The first connection may be a N32-c connection. The second connection may be a N32-f connection.

[0111] Transport layer security or application layer security may be used to secure messages forwarded over the second connection.

[0112] In a ninth aspect there is provided a non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least the method according to the third or fourth aspect.

[0113] In the above, many different embodiments have been described. It should be appreciated that further embodiments may be provided by the combination of any two or more of the embodiments described above.

[0114] Description of Figures

[0115] Embodiments will now be described, by way of example only, with reference to the accompanying Figures in which:

[0116] Figure 1 shows a schematic diagram of an example 5GS communication system;

[0117] Figure 2 shows a schematic diagram of an example mobile communication device;

[0118] Figure 3 shows a schematic diagram of an example control apparatus;

[0119] Figure 4 shows a flowchart of a method according to an example embodiment; Figure 5 shows a flowchart of a method according to an example embodiment;

[0120] Figure 6 shows an example signalling flow between an initiating SEPP and a responding SEPP according to an example embodiment;

[0121] Figure 7 shows an example signalling flow between a NF A, SEPP A, SEPP B and NF B according to an example embodiment.

[0122] Detailed description

[0123] Before explaining in detail the examples, certain general principles of a wireless communication system and mobile communication devices are briefly explained with reference to Figure 1 , Figure 2 and Figure 3 to assist in understanding the technology underlying the described examples.

[0124] An example of a suitable communications system is the 5G or NR concept. Network architecture in NR may be similar to that of LTE-advanced. Base stations of NR systems may be known as next generation NodeBs (gNBs). Changes to the network architecture may depend on the need to support various radio technologies and finer Quality of Service (QoS) support, and some on-demand requirements for e.g. QoS levels to support Quality of Experience (QoE) for a user. Also network aware services and applications, and service and application aware networks may bring changes to the architecture. Those are related to Information Centric Network (ICN) and User-Centric Content Delivery Network (UC-CDN) approaches. NR may use Multiple Input - Multiple Output (MIMO) antennas, many more base stations or nodes than the LTE (a so-called small cell concept), including macro sites operating in co-operation with smaller stations and perhaps also employing a variety of radio technologies for better coverage and enhanced data rates.

[0125] Future networks may utilise network functions virtualization (NFV) which is a network architecture concept that proposes virtualizing network node functions into “building blocks” or entities that may be operationally connected or linked together to provide services. A virtualized network function (VNF) may comprise one or more virtual machines running computer program codes using standard or general type servers instead of customized hardware. Cloud computing or data storage may also be utilized. In radio communications this may mean node operations to be carried out, at least partly, in a server, host or node operationally coupled to a remote radio head. It is also possible that node operations will be distributed among a plurality of servers, nodes or hosts. It should also be understood that the distribution of labour between core network operations and base station operations may differ from that of the LTE or even be non-existent.

[0126] Figure 1 shows a schematic representation of a 5G system (5GS) 100. The 5GS may comprise a user equipment (UE) 102 (which may also be referred to as a communication device or a terminal), a 5G radio access network (5GRAN) 104, a 5G core network (5GCN) 106, one or more internal or external application functions (AF) 108 and one or more data networks (DN) 110.

[0127] An example 5G core network (CN) comprises functional entities. The 5GCN 106 may comprise one or more Access and mobility Management Functions (AMF) 112, one or more session management functions (SMF) 114, an authentication server function (ALISF) 116, a Unified Data Management (UDM) 118, one or more user plane functions (UPF) 120, a Unified Data Repository (UDR) 122 and / or a Network Exposure Function (NEF) 124. The UPF is controlled by the SMF (Session Management Function) that receives policies from a PCF (Policy Control Function).

[0128] The CN is connected to a UE via the Radio Access Network (RAN). The 5GRAN may comprise one or more gNodeB (gNB) Distributed Unit (DU) functions connected to one or more gNodeB (gNB) Centralized Unit (CU) functions. The RAN may comprise one or more access nodes.

[0129] A User Plane Function (UPF) referred to as PDU Session Anchor (PSA) may be responsible for forwarding frames back and forth between the DN and the tunnels established over the 5G towards the UE(s) exchanging traffic with the DN.

[0130] A possible mobile communication device will now be described in more detail with reference to Figure 2 showing a schematic, partially sectioned view of a communication device 200. Such a communication device is often referred to as user equipment (UE) or terminal. An appropriate mobile communication device may be provided by any device capable of sending and receiving radio signals. Non-limiting examples comprise a mobile station (MS) or mobile device such as a mobile phone or what is known as a ’smart phone’, a computer provided with a wireless interface card or other wireless interface facility (e.g., USB dongle), personal data assistant (PDA) or a tablet provided with wireless communication capabilities, voice over IP (VoIP) phones, portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehiclemounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart devices, wireless customer- premises equipment (CPE), or any combinations of these or the like. A mobile communication device may provide, for example, communication of data for carrying communications such as voice, electronic mail (email), text message, multimedia and so on. Users may thus be offered and provided numerous services via their communication devices. Non-limiting examples of these services comprise two-way or multi-way calls, data communication or multimedia services or simply an access to a data communications network system, such as the Internet. Users may also be provided broadcast or multicast data. Non-limiting examples of the content comprise downloads, television and radio programs, videos, advertisements, various alerts, and other information.

[0131] A mobile device is typically provided with at least one data processing entity 201 , at least one memory 202 and other possible components 203 for use in software and hardware aided execution of tasks it is designed to perform, including control of access to and communications with access systems and other communication devices. The data processing, storage and other relevant components can be provided on an appropriate circuit board and / or in chipsets. This feature is denoted by reference 204. The user may control the operation of the mobile device by means of a suitable user interface such as key pad 205, voice commands, touch sensitive screen or pad, combinations thereof or the like. A display 208, a speaker and a microphone can be also provided. Furthermore, a mobile communication device may comprise appropriate connectors (either wired or wireless) to other devices and / or for connecting external accessories, for example hands-free equipment, thereto.

[0132] The mobile device 200 may receive signals over an air or radio interface 207 via appropriate apparatus for receiving and may transmit signals via appropriate apparatus for transmitting radio signals. In Figure 2 transceiver apparatus is designated schematically by block 206. The transceiver apparatus 206 may be provided for example by means of a radio part and associated antenna arrangement. The antenna arrangement may be arranged internally or externally to the mobile device.

[0133] Figure 3 shows an example of a control apparatus 300 for a communication system, for example to be coupled to and / or for controlling a station of an access system, such as a RAN node, e.g. a base station, eNB or gNB, a relay node or a core network node such as an MME or Serving Gateway (S-GW) or Packet Data Network Gateway (P-GW), or a core network function such as AMF / SMF, or a server or host. The method may be implemented in a single control apparatus or across more than one control apparatus. The control apparatus may be integrated with or external to a node or module of a core network or RAN. In some embodiments, base stations comprise a separate control apparatus unit or module. In other embodiments, the control apparatus can be another network element such as a radio network controller or a spectrum controller. In some embodiments, each base station may have such a control apparatus as well as a control apparatus being provided in a radio network controller. The control apparatus 300 can be arranged to provide control on communications in the service area of the system. The control apparatus 300 comprises at least one memory 301 , at least one data processing unit 302, 303 and an input / output interface 304. Via the interface the control apparatus can be coupled to a receiver and a transmitter of the base station. The receiver and / or the transmitter may be implemented as a radio front end or a remote radio head.

[0134] For inter-PLMN (or inter-SNPN) signaling between 5GCs, two types of connections on the N32 interface between SEPPs have been defined.

[0135] A first connection type is a N32-c connection. An N32-c connection may be used for the management of the N32 interface (e.g., to negotiate the protection and security policies to apply to HTTP messages exchanged between the two PLMNs, report N32-f errors to the peer SEPP and / or tear down the N32-c / f connections).

[0136] A second connection type is a N32-f connection. A N32-f connection may be used for the forwarding of protected messages (e.g., HTTP requests and responses messages exchanged between 5GC NFs of both PLMNs) between the SEPPs, using Transport Layer Security (TLS) or JSON Web Encryption (JWE) and JSON Web Signature (JWS) protected messages (PRINS).

[0137] Connections via N32-c and N32-f can be secured either at transport layer using TLS, or at application layer using Protocol for N32 Interconnect Security (PRINS), based on a selection during SEPP handshake procedure.

[0138] If TLS is selected for security, all N32 signaling between the visited PLMN (VPLMN) and home PLMN (HPLMN) will be encrypted end-to-end. TLS protection of the N32 interface may be used for the top roaming relationships, due to exponential N-to-N growth of roaming connections with increasing number of roaming networks.

[0139] If PRINS is selected, SEPPs will use JavaScript Object Notation (JSON) Web Encryption (JWE) to protect messages they send across N32. Parts of the messages sent across N32 may be sent in the clear, and these parts may be modified by IPX service providers during transit. Any modifications by an IPX service provider will be signed using their JSON Web Signature (JWS).

[0140] When PRINS security is used, the N32-c and N32-f connections may be correlated at either Security Edge Protection Proxy (SEPP) using an N32-f context Identifier that is exchanged during the N32-c handshake and that is included in every N32-f message forwarded between the SEPPs. The N32-c protocol supports a N32-f Context Termination Procedure which allows termination of an N32-f context and tearing down the corresponding N32-f connections.

[0141] When TLS security is used, the SEPPs correlate the N32-c and N32-f connections using the peer SEPP's PLMN ID received in the TLS certificate during the setup of the N32-c and N32- f connections. No further details are defined. The N32-c protocol also supports tearing down the N32-f connection by sending an N32-c security capability exchange request with the security capability set to "NONE".

[0142] Multiple N32c and N32-f connections may be established between one SEPP of a PLMN and one or more SEPPs of a peer PLMN.

[0143] For example, several SEPPs A1 , A2, ... of M NO A (deployed e.g. for redundancy, load sharing or dedicated N32 purposes) may establish (each) one (or more) N32 connection with a SEPP B1 of another MNO B.

[0144] Multiple N32 connections may be established for different N32 purposes, e.g. SMS interconnect, roaming, disaster roaming, etc. Multiple N32 connections may be established for traffic targeting different PLMNs (e.g. between a SEPP and a Roaming Hub (RHUB)). A SEPP may open a new N32 connection with a peer SEPP negotiating new security or protection policies (e.g., PRINS), while keeping the old connection with the formerly negotiated security and protection open for a grace period (e.g. TLS) and possibly other reasons in future.

[0145] Where multiple N32-c and N32-f connections are established it is important to be able to correlate the N32-c and N32-f connections for several reasons, including (but not limited to) to enable any renegotiated policy for N32-c to be applied to the related N32-f connection, to be able to tear down N32-f connection(s) associated to an N32-c connection, to be able to identify the N32-f connection(s) used for a specific PLMN, when a SEPP or RHUB supports serving multiple PLMNs or to be able to identify the N32 connection for which some N32-f errors are reported. When using TLS security, correlating the N32-c and N32-f connections relying only on the peer SEPP's PLMN ID received in the TLS certificate is not sufficient, e.g. SEPP A1 , A2 of MNO A would exhibit the same PLMN ID towards SEPP B1. Correlating the N32-c and N32-f connections using the PLMN ID and the peer SEPP's fully qualified domain name (FQDN) does not suffice either when multiple N32 connections can be setup (e.g., for different N32 purposes) between the same pair of SEPP.

[0146] For TLS security, there is a question of how SEPPs correlate an N32-c connection and N32-f connections when there are multiple N32-c and N32-f connections and, when a SEPP requests the peer SEPP via N32-c to terminate an N32-f connection, how to identify the N32- f connection that shall be terminated.

[0147] For PRINS security, there is a question of how to identify a specific N32-c connection during the Security Capability Negotiation procedure, when multiple N32-c connections can be setup between a pair of SEPPs e.g. for different N32 purposes.

[0148] Figure 4 shows a flowchart of a method according to an example embodiment. The method may be performed at an entity in a core network. The network may be the core network of e.g., a PLMN or SNPN.

[0149] In 401 , the method comprises receiving a first identifier from an entity in a first core network at an entity in a second core network in a procedure for setting up a first connection on an interface between the entity in the first core network and the entity in the second core network, wherein the first identifier is associated with the first connection.

[0150] In 402, the method comprises providing a second identifier from the entity in the second core network to the entity in the first core network in response, wherein the second identifier is associated with the first connection.

[0151] Figure 5 shows a flowchart of a method according to an example embodiment. The method may be performed at an entity in a core network. The core network may be the core network of e.g., a PLMN.

[0152] In 501 , the method comprises providing a first identifier from an entity in a first core network to an entity in a second core network in a procedure for setting up a first connection on an interface between the entity in the first core network and the entity in the second core network, wherein the identifier is associated with the first connection. In 502, the method comprises receiving a second identifier from the entity in the second core network at the entity in the first core network in response, wherein the second identifier is associated with the first connection.

[0153] The entity in the first core network may be a SEPP (and may also be referred to as an initiating SEPP, sending SEPP or peer SEPP). The entity in the second core network may be a SEPP (and may also be referred to as a responding SEPP, a receiving SEPP or peer SEPP) or a RHUB.

[0154] The interface may be a N32 interface. The first connection may be a N32-c connection. The second connection may be a N32-f connection.

[0155] The first identifier and the second identifier may comprise a handshake identifier. The handshake identifier may be referred to in the following as “N32 handshake ID”. The first identifier and the second identifier may be the same or different.

[0156] For example, a distinct N32 handshake ID may be used for each N32 connection. During the initial setup of the N32 connection, both SEPPs exchange messages with a N32 handshake ID as described below (in an alternative, the same ID is used in both directions).

[0157] The identifier or "N32 handshake ID" may allow correlation of N32-f and N32-c in both protocols, TLS and PRINS.

[0158] Different alternatives are described, that may be applied to either of the protocols or both at the same time.

[0159] The method may comprise receiving the first identifier in a security capability exchange request from the entity in the first core network at the entity in the second core network and providing the second identifier in a security capability exchange response from the entity in the second core network to the entity in the first core network.

[0160] In an example embodiment, a Security Capability Negotiation procedure (SecNegotiateReq / Rsp) is enhanced to enable signalling of a N32 handshake ID uniquely identifying the N32-c connection and the related N32-f connections. In an example embodiment, the Security Negotiate Request Data (SecNegotiateReqData) message is extended with N32 handshake ID by including the sending SEPP's N32 handshake ID. This is an example of providing the first identifier in a security capability exchange request from the entity in the first core network to the entity in the second core network.

[0161] In an example embodiment, the Security Negotiate Response Data (SecNegotiateRspData) message is extended with a new N32 handshake ID by including the receiving SEPP's N32 handshake ID. This is an example of providing the second identifier in a security capability exchange response from the entity in the second core network to the entity in the first core network.

[0162] Figure 6 shows a signalling flow for a Security Capability Negotiation procedure between an initiating SEPP and a responding SEPP according to an example embodiment. In 601 , the initiating SEPP sends SecNegotiateReqData including the n32handshakeld. In 602, the responding SEPP sends SecNegotiateRspData including the n32handshakeld.

[0163] Table 1 shows an example definition of type SecNegotiateReqData. Table 2 shows an example definition of type SecNegotiateRspData.

[0164] Table 1

[0165] Table 2

[0166] A method as described with reference to Figure 4 may comprise receiving a further security capability exchange request from the entity in the first core network at the entity in the second core network for the first connection, the further security capability exchange request comprising the first identifier and deriving that the further security capability exchange request relates to the first connection based on the first identifier By this, a SEPP may be enabled to determine from "N32 handshake ID", and, optionally, together with the sender FQDN, the correct N32-c connection, when requested to tear down N32-f.

[0167] In an example embodiment, when initiating a subsequent Security Capability Negotiation procedure for an existing N32-c connection (e.g. to request the peer SEPP to tear down the N32-f TLS connection), the sending SEPP includes the N32 handshake ID that was signaled during the initial N32-c connection establishment. This is an example of receiving a further security capability exchange request from the entity in the first core network at the entity in the second core network for the first connection, the further security capability exchange request comprising the first identifier. This may enable the receiving SEPP to determine the N32-c connection that is subject of the subsequent Security Capability Negotiation procedure. This is an example of deriving that the further security capability exchange request relates to the first connection based on the first identifier.

[0168] Since a SEPP may have created several N32-c connections that correlate to distinct N32-f connections, it may be important to identify correctly the N32-c connection and correlating N32-f connection. This mechanism allows to distinguish, which N32-f connection need to be torn down.

[0169] Transport layer security (TLS) or application layer security (e.g., PRINS) may be used to secure messages forwarded over the second connection.

[0170] The handshake identifier may be distinct in comparison to the PRINS N32-f context id (n32fcontextld). Alternatively, or in addition, for PRINS, the first identifier (e.g., N32 handshake ID) may take the form of a N32-f context ID for PRINS. A method as described with reference to Figure 4 may comprise associating the first identifier with another identifier received in a security parameter exchange request (e.g., N32-F context ID in SecParam Exch Req).

[0171] For PRINS, a method as described with reference to Figure 4 may comprise further receiving the first identifier in a security parameter exchange request (e.g., SecParam Exch Req).

[0172] For PRINS security, two example options to allow for correlating N32-f and N32-c in PRINS are adding the N32 handshake ID in SecNegotiateReqData, SecNegotiateRspData and SecParamExchReq, or adding the new N32 handshake only in SecNegotiateReqData and SecNegotiateRspData in which case the N32 handshake ID shall contain the same value as the existing N32-f context id which is part of SecParam Exch Req / Rsp. Table 3 shows an example definition of type SecNegotiateReqData and SecNegotiateRspData for PRINS.

[0173] Table 3

[0174] For TLS security, a method as described with reference to Figure 5 may comprise receiving a message at the entity in the first core network from a further entity (e.g., a NF) in the first core network that is to be sent to the second core network, inserting in the message the second identifier, and forwarding the message to the entity in the second core network using a second connection on the interface.

[0175] A method as described with reference to Figure 4 may comprise receiving a message comprising the second identifier from the entity in the first core network at the entity in the second core network using a second connection on the interface between the entity in the first core network and the entity in the second core network and correlating the second connection with the first connection based on the second identifier. The method may further comprise removing the second identifier from the message and providing the message from the entity in the second core network to a further entity (e.g., a NF) in the second core network.

[0176] The second identifier may be inserted, and received, respectively, in a HTTP custom header.

[0177] The HTTP custom header may further include a fully qualified domain name, FQDN, associated with the entity in the first core network and a method may comprise correlating the second connection with the first connection further based on the FQDN.

[0178] In an example embodiment, for TLS security, a custom header may be introduced. The HTTP custom header (which may be called, e.g. "3gpp-Sbi-n32c-Correlation" or "3gpp- Sbi-N32-Handshake-ld") may be signaled in (TLS protected) N32-f messages, where a N32 handshake ID was signaled by a peer SEPP during the N32-c handshake.

[0179] In an example embodiment, the sender FQDN may be included in the HTTP custom header.

[0180] In an example embodiment, a sending SEPP inserts the HTTP custom header to the message forwarded towards the peer SEPP. This is an example of receiving a message at the entity in the first core network from a further entity in the first core network that is to be sent to the second core network and inserting in the message the second identifier.

[0181] The receiving (peer) SEPP retrieves the FQDN from the certificate or from the 3gpp-Sbi-n32c- Correlation header. The receiving SEPP correlates the N32-f message and N32-c connection with the N32-c connection using the N32 Handshake ID received in this header (and optionally the retrieved FQDN). This is an example of receiving a message comprising the second identifier from the entity in the first core network at the entity in the second core network using a second connection on the interface between the entity in the first core network and the entity in the second core network and correlating the second connection with the first connection based on the second identifier.

[0182] The receiving SEPP removes this header before forwarding the message towards the target recipient of the message (target NF). This is an example of removing the second identifier from the message and providing the message from the entity in the second core network to a further entity in the second core network (e.g., target NF).

[0183] Figure 7 shows a signalling flow where TLS security is used for N32-f communications. The example signalling flow in Figure 7 is between NF A and SEPP A of PLMN A and NF B and SEPP B of PLMN B. NF A and NF B are examples of further entities in the core network and SEPP A and SEPP B are examples of an entity in a first core network and an entity in a second core network, respectively.

[0184] In 701 , NF A sends a message to SEPP A. In 702, SEPP A adds a HTTP header including the n32handshakeld to the message. In 703, SEPP A sends the message including the HTTP header and n32handshakeld to SEPP B using the N32-f connection. In 704, SEPP removes the header, correlates N32-f and N32-c and in 705, SEPP B forwards the message to NF B. An apparatus may comprise means for receiving a first identifier from an entity in a first core network at an entity in a second core network in a procedure for setting up a first connection on an interface between the entity in the first core network and the entity in the second core network, wherein the first identifier is associated with the first connection and means for providing a second identifier from the entity in the second core network to the entity in the first core network in response, wherein the second identifier is associated with the first connection.

[0185] Alternatively, or in addition, an apparatus may comprise means for means for providing a first identifier from an entity in a first core network to an entity in a second core network in a procedure for setting up a first connection on an interface between the entity in the first core network and the entity in the second core network, wherein the identifier is associated with the first connection and means for receiving a second identifier from the entity in the second core network at the entity in the first core network in response, wherein the second identifier is associated with the first connection.

[0186] An apparatus may comprise a network function (e.g., a SEPP), be the network function or be comprised in the network function or a chipset for performing at least some actions of / for the network function.

[0187] It should be understood that the apparatuses may comprise or be coupled to other units or modules etc., such as radio parts or radio heads, used in or for transmission and / or reception. Although the apparatuses have been described as one entity, different modules and memory may be implemented in one or more physical or logical entities.

[0188] It is noted that whilst some embodiments have been described in relation to 5G networks, similar principles can be applied in relation to other networks and communication systems such as 6G networks or 5G-Advanced networks. Therefore, although certain embodiments were described above by way of example with reference to certain example architectures for wireless networks, technologies and standards, embodiments may be applied to any other suitable forms of communication systems than those illustrated and described herein.

[0189] It is also noted herein that while the above describes example embodiments, there are several variations and modifications which may be made to the disclosed solution without departing from the scope of the present invention.

[0190] As used herein, “at least one of the following: ” and “at least one of ” and similar wording, where the list of two or more elements are joined by “and” or “or”, mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

[0191] In general, the various embodiments may be implemented in hardware or special purpose circuitry, software, logic or any combination thereof. Some aspects of the disclosure may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the disclosure is not limited thereto. While various aspects of the disclosure may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

[0192] As used in this application, the term “circuitry” may refer to one or more or all of the following:

[0193] (a) hardware-only circuit implementations (such as implementations in only analog and / or digital circuitry) and

[0194] (b) combinations of hardware circuits and software, such as (as applicable):

[0195] (i) a combination of analog and / or digital hardware circuit(s) with software / firmware and

[0196] (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and

[0197] I hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.”

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

[0199] The embodiments of this disclosure may be implemented by computer software executable by a data processor of the mobile device, such as in the processor entity, or by hardware, or by a combination of software and hardware. Computer software or program, also called program product, including software routines, applets and / or macros, may be stored in any apparatus-readable data storage medium and they comprise program instructions to perform particular tasks. A computer program product may comprise one or more computerexecutable components which, when the program is run, are configured to carry out embodiments. The one or more computer-executable components may be at least one software code or portions of it.

[0200] Further in this regard it should be noted that any blocks of the logic flow as in the Figures may represent program steps, or interconnected logic circuits, blocks and functions, or a combination of program steps and logic circuits, blocks and functions. The software may be stored on such physical media as memory chips, or memory blocks implemented within the processor, magnetic media such as hard disk or floppy disks, and optical media such as for example DVD and the data variants thereof, CD. The physical media is a non-transitory media. The term “non-transitory,” as used herein, is a limitation of the medium itself (i.e. , tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM).

[0201] The memory may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The data processors may be of any type suitable to the local technical environment, and may comprise one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASIC), FPGA, gate level circuits and processors based on multi core processor architecture, as non-limiting examples.

[0202] Embodiments of the disclosure may be practiced in various components such as integrated circuit modules. The design of integrated circuits is by and large a highly automated process. Complex and powerful software tools are available for converting a logic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate.

[0203] The scope of protection sought for various embodiments of the disclosure is set out by the independent claims. The embodiments and features, if any, described in this specification that do not fall under the scope of the independent claims are to be interpreted as examples useful for understanding various embodiments of the disclosure.

[0204] The foregoing description has provided by way of non-limiting examples a full and informative description of the exemplary embodiment of this disclosure. However, various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings and the appended claims. However, all such and similar modifications of the teachings of this disclosure will still fall within the scope of this invention as defined in the appended claims. Indeed, there is a further embodiment comprising a combination of one or more embodiments with any of the other embodiments previously discussed.

Claims

CLAIMS1. An apparatus comprising: means for receiving a first identifier from an entity in a first core network at an entity in a second core network in a procedure for setting up a first connection on an interface between the entity in the first core network and the entity in the second core network, wherein the first identifier is associated with the first connection; and means for providing a second identifier from the entity in the second core network to the entity in the first core network in response, wherein the second identifier is associated with the first connection.

2. The apparatus according to claim 1 , comprising means for receiving the first identifier in a security capability exchange request.

3. The apparatus according to claim 2, comprising means for providing the second identifier in a security capability exchange response.

4. The apparatus according to any of claims 2 to 3, comprising means for receiving a further security capability exchange request from the entity in the first core network at the entity in the second core network for the first connection, the further security capability exchange request comprising the first identifier; and means for deriving that the further security capability exchange request relates to the first connection based on the first identifier.

5. The apparatus according to any of claims 2 to 4, comprising means for associating the first identifier with another identifier received in a security parameter exchange request.

6. The apparatus according to any of claims 2 to 4, comprising means for further receiving the first identifier in a security parameter exchange request.

7. The apparatus according to any of claims 1 to 4, comprising means for receiving a message comprising the second identifier from the entity in the first core network at the entity in the second core network using a second connection on the interface between the entity in the first core network and the entity in the second corenetwork and means for correlating the second connection with the first connection based on the second identifier.

8. The apparatus according to claim 7, comprising means for removing the second identifier from the message and means for providing the message from the entity in the second core network to a further entity in the second core network.

9. The apparatus according to claim 7 or claim 8, comprising means for further receiving the second identifier in a HTTP custom header.

10. The apparatus according to claim 9, wherein the HTTP custom header further includes a fully qualified domain name, FQDN, associated with the entity in the first core network and means for correlating the second connection with the first connection further based on the FQDN.

11. The apparatus according to any of claims 1 to 10, wherein the first identifier and the second identifier are the same or different.

12. The apparatus according to any of claims 1 to 11 , wherein the first identifier and the second identifier comprise a handshake identifier.

13. The apparatus according to any of claims 1 to 12, wherein the entity in the first core network and the entity in the second core network comprise a security edge protection proxy, SEPP.

14. The apparatus according to any of claims 1 to 13, wherein the interface is a N32 interface, the first connection is a N32-c connection and the second connection is a N32-f connection.

15. The apparatus according to any of claims 1 to 4, wherein transport layer security or application layer security are used to secure messages forwarded over the second connection.

16. An apparatus comprising: means for providing a first identifier from an entity in a first core network to an entity in a second core network in a procedure for setting up a first connection on aninterface between the entity in the first core network and the entity in the second core network, wherein the identifier is associated with the first connection; and means for receiving a second identifier from the entity in the second core network at the entity in the first core network in response, wherein the second identifier is associated with the first connection.

17. The apparatus according to claim 16, comprising means for providing the first identifier in a security capability exchange request.

18. The apparatus according to claim 16 or claim 17, comprising means for receiving the second identifier in a security capability exchange response.

19. The apparatus according to any of claims 16 to 18, comprising means for providing a further security capability exchange request from the entity in the first core network to the entity in the second core network for the first connection, the further security capability exchange request comprising the first identifier.

20. The apparatus according to any of claims 16 to 19, comprising means for further providing the first identifier in a security parameter exchange request.21 . The apparatus according to any of claims 16 to 19, comprising means for receiving a message at the entity in the first core network from a further entity in the first core network that is to be sent to the second core network, means for inserting in the message the second identifier, and means for forwarding the message to the entity in the second core network using a second connection on the interface.

22. The apparatus according to claim 21 , comprising means for further inserting the second identifier in a HTTP custom header.

23. The apparatus according to claim 22, wherein the HTTP custom header further includes a fully qualified domain name, FQDN, associated with the entity in the first core network.

24. The apparatus according to any of claims 16 to 23, wherein the first identifier and the second identifier are the same or different.

25. The apparatus according to any of claims 16 to 23, wherein the first identifier and the second identifier comprise a handshake identifier.

26. The apparatus according to any of claims 16 to 25, wherein the entity in the first core network and the entity in the second core network comprise a security edge protection proxy, SEPP.

27. The apparatus according to any of claims 16 to 26, wherein the interface is a N32 interface, the first connection is a N32-c connection and the second connection is a N32-f connection.

28. The apparatus according to any of claims 16 to 19, wherein transport layer security or application layer security are used to secure messages forwarded over the second connection.

29. A method comprising: receiving a first identifier from an entity in a first core network at an entity in a second core network in a procedure for setting up a first connection on an interface between the entity in the first core network and the entity in the second core network, wherein the first identifier is associated with the first connection; and providing a second identifier from the entity in the second core network to the entity in the first core network in response, wherein the second identifier is associated with the first connection.

30. A method comprising: providing a first identifier from an entity in a first core network to an entity in a second core network in a procedure for setting up a first connection on an interface between the entity in the first core network and the entity in the second core network, wherein the identifier is associated with the first connection; and receiving a second identifier from the entity in the second core network at the entity in the first core network in response, wherein the second identifier is associated with the first connection.

31. An apparatus comprising: at least one processor, and at least one memory storing instructions which, when executed by the processor, cause the apparatus at least to:receive a first identifier from an entity in a first core network at an entity in a second core network in a procedure for setting up a first connection on an interface between the entity in the first core network and the entity in the second core network, wherein the first identifier is associated with the first connection; and provide a second identifier from the entity in the second core network to the entity in the first core network in response, wherein the second identifier is associated with the first connection.

32. An apparatus comprising: at least one processor, and at least one memory storing instructions which, when executed by the processor, cause the apparatus at least to: provide a first identifier from an entity in a first core network to an entity in a second core network in a procedure for setting up a first connection on an interface between the entity in the first core network and the entity in the second core network, wherein the identifier is associated with the first connection; and receive a second identifier from the entity in the second core network at the entity in the first core network in response, wherein the second identifier is associated with the first connection.

33. A computer readable medium comprising instructions which, when executed by an apparatus, cause the apparatus to perform at least the following: receiving a first identifier from an entity in a first core network at an entity in a second core network in a procedure for setting up a first connection on an interface between the entity in the first core network and the entity in the second core network, wherein the first identifier is associated with the first connection; and providing a second identifier from the entity in the second core network to the entity in the first core network in response, wherein the second identifier is associated with the first connection.

34. A computer readable medium comprising instructions which, when executed by an apparatus, cause the apparatus to perform at least the following: providing a first identifier from an entity in a first core network to an entity in a second core network in a procedure for setting up a first connection on an interface between the entity in the first core network and the entity in the second core network, wherein the identifier is associated with the first connection; andreceiving a second identifier from the entity in the second core network at the entity in the first core network in response, wherein the second identifier is associated with the first connection.

Images