Apparatus, methods and computer programs

Abstract

An apparatus is provided, comprising: means for receiving a first identifier from an entity in a first core network at an entity in a second core network during a process for establishing a first connection at 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

Technical Field

[0001] This application relates to a method, apparatus, system, and computer program, and specifically, but not exclusively, to 5GS interconnect enhancement for N32-c and N32-f connection association. Background Technology

[0002] A communication system can be viewed as a facility that enables a communication session between two or more entities (such as user terminals, base stations, and / or other nodes) by providing carrier waves between various entities involved in the communication path. The communication system can be provided, for example, by means of a communication network and one or more compatible communication devices. The communication session can include, for example, the communication of data used to carry communications such as voice, video, email, text messages, multimedia, and / or content data. Non-limiting examples of the services provided include two-way or multiplexed calls, data communication or multimedia services, and access to data network systems such as the Internet.

[0003] In wireless communication systems, at least a portion of a communication session between at least two stations occurs over a wireless link. Examples of wireless systems include Public Land Mobile Networks (PLMNs), satellite-based communication systems, and various wireless local area networks, such as Wireless Local Area Networks (WLANs). Some wireless systems can be divided into cells and are therefore often referred to as cellular systems.

[0004] Users can access the communication system using appropriate communication equipment or terminals. A user's communication equipment may be referred to as user equipment (UE) or user device. The communication equipment is equipped with appropriate signal receiving and transmitting means for enabling communication, such as access to a communication network or direct communication with other users. The communication equipment can access a carrier provided by a station (e.g., a base station in a cell) and transmit and / or receive communication on that carrier.

[0005] Communication systems and associated equipment typically operate according to a given standard or specification that outlines what the various entities associated with the system are allowed to do and how these should be implemented. The communication protocols and / or parameters used for connectivity are also usually defined. One example of a communication system is the Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN) (3G radio). Other examples of communication systems include the Long Term Evolution (LTE) of 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 above) and 6G. Summary of the Invention

[0006] In a first aspect, an apparatus is provided, comprising: means for receiving a first identifier from an entity in a first core network at an entity in a second core network during a process for establishing a first connection at 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.

[0007] The device may include a component for receiving a first identifier in a security capability exchange request.

[0008] The device may include a component for providing a second identifier in a security capability exchange response.

[0009] The apparatus may include: components for receiving another security capability exchange request from an entity in the first core network at a first connection in the second core network, the other security capability exchange request including a first identifier; and components for deducing, based on the first identifier, that the other security capability exchange request is associated with the first connection.

[0010] The apparatus may include a component for associating a first identifier with another identifier received in a security parameter exchange request.

[0011] The device may include a component for also receiving a first identifier in a security parameter exchange request.

[0012] The apparatus may include: a component for receiving a message including a second identifier from an entity in the first core network at an entity in the second core network using a second connection on an interface between the entity in the first core network and the entity in the second core network; and a component for associating the second connection with the first connection based on the second identifier.

[0013] The apparatus may include: components for removing a second identifier from the message; and components for providing a message from an entity in the second core network to another entity in the second core network.

[0014] The device may include a component for also receiving a second identifier in an HTTP custom header.

[0015] The custom header may also include a fully qualified domain name (FQDN) associated with an entity in the first core network. The apparatus may include components for further associating the second connection with the first connection based on the FQDN.

[0016] The first identifier and the second identifier can be the same or different.

[0017] The first and second identifiers can include handshake identifiers.

[0018] Entities in the first core network and entities in the second core network may include the Security Edge Protection Agent (SEPP).

[0019] The interface can be an N32 interface. The first connection can be an N32-C connection. The second connection can be an N32-F connection.

[0020] Transport layer security or application layer security can be used to protect messages forwarded over a second connection.

[0021] In a second aspect, an apparatus is provided, 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 process for establishing a first connection at an interface between the entities in the first core network and the entities in the second core network, wherein the identifier is associated with the first connection; and means for receiving a second identifier from an entity in the second core network at the entity in the first core network in response to the entity in the first core network, wherein the second identifier is associated with the first connection.

[0022] The device may include a component for providing a first identifier in a security capability exchange request.

[0023] The device may include a component for receiving a second identifier in a security capability exchange response.

[0024] The apparatus may include: a component for providing another security capability exchange request from an entity in a first core network to an entity in a second core network for a first connection, the other security capability exchange request including a first identifier.

[0025] The device may include a component for also providing a first identifier in a security parameter exchange request.

[0026] The apparatus may include: components for receiving, at an entity in a first core network, a message to be sent to a second core network from another entity in the first core network; components for inserting a second identifier into the message; and components for forwarding the message to an entity in the second core network using a second connection on the interface.

[0027] The device may include a component for also inserting a second identifier into the HTTP custom header.

[0028] HTTP custom headers can also include fully qualified domain names (FQDNs) associated with entities in the first core network.

[0029] The first identifier and the second identifier can be the same or different.

[0030] The first and second identifiers can include handshake identifiers.

[0031] Entities in the first core network and entities in the second core network may include the Security Edge Protection Agent (SEPP).

[0032] The interface can be an N32 interface. The first connection can be an N32-C connection. The second connection can be an N32-F connection.

[0033] Transport layer security or application layer security can be used to protect messages forwarded over a second connection.

[0034] In a third aspect, a method is provided, comprising: during the process of establishing a first connection on an interface between an entity in a first core network and an entity in a second core network, receiving a first identifier at an entity in the second core network from an entity in the first core network, wherein the first identifier is associated with the first connection; and in response, providing a second identifier from an entity in the second core network to an entity in the first core network, wherein the second identifier is associated with the first connection.

[0035] The method may include receiving a first identifier in a security capability exchange request.

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

[0037] The method may include: receiving, at an entity in the first core network, another security capability exchange request from an entity in the first core network for the first connection, the other security capability exchange request including a first identifier; and deriving the association of the other security capability exchange request with the first connection based on the first identifier.

[0038] The method may include associating a first identifier with another identifier received in a security parameter exchange request.

[0039] The method may also include receiving a first identifier in a security parameter exchange request.

[0040] The method may include: receiving a message including a second identifier from an entity in the first core network at an entity in the second core network using a second connection on an interface between an entity in the first core network and an entity in the second core network; and associating the second connection with the first connection based on the second identifier.

[0041] The method may include: removing the second identifier from the message; and providing the message from an entity in the second core network to another entity in the second core network.

[0042] The method may also include receiving a second identifier in an HTTP custom header.

[0043] The custom header may also include a fully qualified domain name (FQDN) associated with an entity in the first core network. The method may also include associating the second connection with the first connection based on the FQDN.

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

[0045] The first and second identifiers can include handshake identifiers.

[0046] Entities in the first core network and entities in the second core network may include the Security Edge Protection Agent (SEPP).

[0047] The interface can be an N32 interface. The first connection can be an N32-C connection. The second connection can be an N32-F connection.

[0048] Transport layer security or application layer security can be used to protect messages forwarded over a second connection.

[0049] In a fourth aspect, a method is provided, comprising: during the process of establishing a first connection on an interface between an entity in a first core network and an entity in a second core network, providing a first identifier from an entity in the first core network to an entity in the second core network, wherein the identifier is associated with the first connection; and in response, receiving a second identifier from an entity in the second core network at an entity in the first core network, wherein the second identifier is associated with the first connection.

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

[0051] The method may include receiving a second identifier in a security capability exchange response.

[0052] The method may include: providing another security capability exchange request from an entity in a first core network to an entity in a second core network for a first connection, the other security capability exchange request including a first identifier.

[0053] The method may also include providing a first identifier in the security parameter exchange request.

[0054] The method may include: receiving a message to be sent to a second core network from another entity in the first core network at an entity in the first core network; inserting a second identifier into the message; and forwarding the message to an entity in the second core network using a second connection on the interface.

[0055] The method may also include inserting a second identifier into a custom HTTP header.

[0056] HTTP custom headers can also include fully qualified domain names (FQDNs) associated with entities in the first core network.

[0057] The first identifier and the second identifier can be the same or different.

[0058] The first and second identifiers can include handshake identifiers.

[0059] Entities in the first core network and entities in the second core network may include the Security Edge Protection Agent (SEPP).

[0060] The interface can be an N32 interface. The first connection can be an N32-C connection. The second connection can be an N32-F connection.

[0061] Transport layer security or application layer security can be used to protect messages forwarded over a second connection.

[0062] In a fifth aspect, an apparatus is provided, the apparatus including at least one processor; and at least one memory storing instructions that, when executed by the processor, cause the apparatus to at least: receive a first identifier at an entity in the second core network from an entity in the first core network, wherein the first identifier is associated with the first connection, during the process of establishing a first connection at an interface between an entity in the first core network and an entity in the second core network; and, in response, provide a second identifier from an entity in the second core network to an entity in the first core network, wherein the second identifier is associated with the first connection.

[0063] The device is also configured to receive a first identifier in a security capability exchange request.

[0064] The device is also configured to provide a second identifier in the security capability exchange response.

[0065] The device is also configured to: receive, at an entity in the first core network, another security capability exchange request from an entity in the first core network for the first connection, the other security capability exchange request including a first identifier, and deduce, based on the first identifier, that the other security capability exchange request is associated with the first connection.

[0066] The device is also configured to associate the first identifier with another identifier received in the security parameter exchange request.

[0067] The device is also configured to receive a first identifier in a security parameter exchange request.

[0068] The device is also configured to: receive a message including a second identifier from an entity in the first core network at an 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 associate the second connection with the first connection based on the second identifier.

[0069] The device is also configured to: remove the second identifier from the message and provide the message from an entity in the second core network to another entity in the second core network.

[0070] The device is also enabled to receive a second identifier in a custom HTTP header.

[0071] The custom header may also include a fully qualified domain name (FQDN) associated with an entity in the first core network. The device is also configured to associate the second connection with the first connection based on the FQDN.

[0072] The first identifier and the second identifier can be the same or different.

[0073] The first and second identifiers can include handshake identifiers.

[0074] Entities in the first core network and entities in the second core network may include the Security Edge Protection Agent (SEPP).

[0075] The interface can be an N32 interface. The first connection can be an N32-C connection. The second connection can be an N32-F connection.

[0076] Transport layer security or application layer security can be used to protect messages forwarded over a second connection.

[0077] In a sixth aspect, an apparatus is provided, including at least one processor; and at least one memory storing instructions that, when executed by the processor, cause the apparatus to at least: provide a first identifier from an entity in the first core network to an entity in the second core network, wherein the identifier is associated with the first connection, during the process of establishing a first connection at an interface between an entity in the first core network and an entity in the second core network; and, in response, receive a second identifier from an entity in the second core network at an entity in the first core network, wherein the second identifier is associated with the first connection.

[0078] The device is also configured to provide a first identifier in a security capability exchange request.

[0079] The device is also configured to receive a second identifier in a security capability exchange response.

[0080] The device is also configured to: provide another security capability exchange request from an entity in the first core network to an entity in the second core network for the first connection, the other security capability exchange request including a first identifier.

[0081] The device is also configured to provide a first identifier in the security parameter exchange request.

[0082] The device is also configured to: receive a message to be sent to a second core network from another entity in the first core network at an entity in the first core network, insert a second identifier in the message, and forward the message to an entity in the second core network using a second connection on the interface.

[0083] The device is also configured to insert the second identifier into the HTTP custom header.

[0084] HTTP custom headers can also include fully qualified domain names (FQDNs) associated with entities in the first core network.

[0085] The first identifier and the second identifier can be the same or different.

[0086] The first and second identifiers can include handshake identifiers.

[0087] Entities in the first core network and entities in the second core network may include the Security Edge Protection Agent (SEPP).

[0088] The interface can be an N32 interface. The first connection can be an N32-C connection. The second connection can be an N32-F connection.

[0089] Transport layer security or application layer security can be used to protect messages forwarded over a second connection.

[0090] In a seventh aspect, a computer-readable medium is provided, including instructions that, when executed by a device, cause the device to at least: receive a first identifier at an entity in the first core network at an entity in the second core network, wherein the first identifier is associated with the first connection, during the process of establishing a first connection at an interface between an entity in a first core network and an entity in a second core network; and, in response, provide a second identifier from an entity in the second core network to an entity in the first core network, wherein the second identifier is associated with the first connection.

[0091] The device is also enabled to perform: receiving a first identifier in a security capability exchange request.

[0092] The device is also enabled to perform: providing a second identifier in a security capability exchange response.

[0093] The device is also configured to perform: receiving, for the first connection, another security capability exchange request from an entity in the first core network at an entity in the second core network, the other security capability exchange request including a first identifier, and deducing, based on the first identifier, that the other security capability exchange request is associated with the first connection.

[0094] The device is also made to perform the following: associate the first identifier with another identifier received in the security parameter exchange request.

[0095] The device is also enabled to perform: receiving the first identifier in a security parameter exchange request.

[0096] The device is also made to perform: at an 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, receiving a message including a second identifier from an entity in the first core network; and associating the second connection with the first connection based on the second identifier.

[0097] The device is also configured to perform: removing a second identifier from a message, and providing a message from an entity in the second core network to another entity in the second core network.

[0098] The device is also enabled to receive a second identifier in a custom HTTP header.

[0099] The custom header may also include a fully qualified domain name (FQDN) associated with an entity in the first core network. The device is also configured to perform the association of the second connection with the first connection based on the FQDN.

[0100] The first identifier and the second identifier can be the same or different.

[0101] The first and second identifiers can include handshake identifiers.

[0102] Entities in the first core network and entities in the second core network may include the Security Edge Protection Agent (SEPP).

[0103] The interface can be an N32 interface. The first connection can be an N32-C connection. The second connection can be an N32-F connection.

[0104] Transport layer security or application layer security can be used to protect messages forwarded over a second connection.

[0105] In an eighth aspect, a computer-readable medium is provided, including instructions that, when executed by a device, cause the device to at least: provide a first identifier from an entity in the first core network to an entity in the second core network during the process of establishing a first connection at an interface between an entity in the first core network and an entity in the second core network, wherein the identifier is associated with the first connection; and, in response, receive a second identifier from an entity in the second core network at an entity in the first core network, wherein the second identifier is associated with the first connection.

[0106] The device is also enabled to perform: providing a first identifier in a security capability exchange request.

[0107] The device is also enabled to perform: receiving a second identifier in a security capability exchange response.

[0108] The device is also made to perform: providing another security capability exchange request from an entity in the first core network to an entity in the second core network for the first connection, the other security capability exchange request including a first identifier.

[0109] The device is also enabled to perform: providing a first identifier in the security parameter exchange request.

[0110] The device is also configured to: receive a message to be sent to a second core network from another entity in the first core network at an entity in the first core network; insert a second identifier into the message; and forward the message to an entity in the second core network using a second connection on the interface.

[0111] The device is also enabled to perform the following: insert a second identifier into the HTTP custom header.

[0112] HTTP custom headers can also include fully qualified domain names (FQDNs) associated with entities in the first core network.

[0113] The first identifier and the second identifier can be the same or different.

[0114] The first and second identifiers can include handshake identifiers.

[0115] Entities in the first core network and entities in the second core network may include the Security Edge Protection Agent (SEPP).

[0116] The interface can be an N32 interface. The first connection can be an N32-C connection. The second connection can be an N32-F connection.

[0117] Transport layer security or application layer security can be used to protect messages forwarded over a second connection.

[0118] In a ninth aspect, a non-transitory computer-readable medium is provided, including instructions for causing the apparatus to execute at least the method according to the third or fourth aspect.

[0119] Many different embodiments have been described above. It should be understood that other embodiments can be provided by any combination of two or more of the above embodiments. Attached Figure Description

[0120] Embodiments will now be described by way of example only with reference to the accompanying drawings, in which: Figure 1 A schematic diagram of an example 5GS communication system is shown; Figure 2 A schematic diagram of an example mobile communication device is shown; Figure 3 A schematic diagram of an example control device is shown; Figure 4 A flowchart of a method according to an example embodiment is shown; Figure 5 A flowchart of a method according to an example embodiment is shown; Figure 6 An example signaling flow between the initiating SEPP and the responding SEPP according to an example embodiment is shown; Figure 7 An example signaling flow between NF A, SEPP A, SEPP B, and NF B according to an example embodiment is shown. Detailed Implementation

[0121] Before explaining the examples in detail, please refer to... Figure 1 , Figure 2 and Figure 3 A brief explanation of some general principles of wireless communication systems and mobile communication devices is provided to help understand the underlying technology of the described examples.

[0122] Examples of suitable communication systems are the 5G or NR concepts. The network architecture in NR can be similar to the advanced network architecture of LTE. Base stations in an NR system can be referred to as next-generation node Bs (gNBs). Changes to the network architecture can depend on the need to support various radio technologies and the need for more granular quality of service (QoS) support, as well as some on-demand requirements for QoS levels, such as to support the user's quality of experience (QoE). Furthermore, network-aware services and applications, and service and application-aware networks, may bring about changes to the architecture. These involve information-centric networks (ICNs) and user-centric content delivery networks (UC-CDNs). NR can use multiple-input multiple-output (MIMO) antennas, far more base stations or nodes than LTE (the so-called small cell concept), including macro sites cooperating with smaller stations, and may also employ various radio technologies to achieve better coverage and enhanced data rates.

[0123] Future networks can leverage Network Functions Virtualization (NFV), a network architecture concept that proposes virtualizing network node functions as "building blocks" or entities that can be operatively connected or linked together to provide services. Virtualized network functions (VNFs) can include one or more virtual machines running computer program code using standard or general-purpose type servers instead of custom hardware. Cloud computing or data storage can also be utilized. In radio communications, this might mean that node operations are performed at least partially within a server, host, or node operatively coupled to a remote radio head. Node operations can also be distributed across multiple servers, nodes, or hosts. It should also be understood that the division of labor between core network operations and base station operations may differ from, or even not exist, in LTE.

[0124] Figure 1 A schematic diagram of a 5G system (5GS) 100 is shown. The 5GS may include a user equipment (UE) 102 (which may also be referred to as a communication device or 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.

[0125] The example 5G core network (CN) includes functional entities. 5GCN 106 may include one or more Access and Mobility Management Functions (AMF) 112, one or more Session Management Functions (SMF) 114, Authentication Server Function (AUSF) 116, Unified Data Management (UDM) 118, one or more User Plane Functions (UPF) 120, Unified Data Repository (UDR) 122, and / or Network Openness Function (NEF) 124. The UPF is controlled by the SMF (Session Management Function) that receives policies from the PCF (Policy Control Function).

[0126] The CN connects to the UE via a radio access network (RAN). The 5G RAN may include one or more gNodeB (gNB) distributed unit (DU) functions connected to one or more gNodeB (gNB) centralized unit (CU) functions. The RAN may include one or more access nodes.

[0127] The User Plane Function (UPF), known as the PDU Session Anchor (PSA), is responsible for forwarding frames back and forth between the DN and the tunnel, which is established by 5G and directed toward (multiple) UEs exchanging services with the DN.

[0128] Now refer to Figure 2 Possible mobile communication devices are described in more detail. Figure 2 A schematic partial cross-sectional view of a communication device 200 is shown. Such a communication device is generally referred to as a user equipment (UE) or terminal. Suitable mobile communication devices can be provided by any device capable of transmitting and receiving radio signals. Non-limiting examples include mobile stations (MS) or mobile devices (such as mobile phones or so-called smartphones), computers equipped with wireless interface cards or other wireless interface facilities (e.g., USB dongles), personal data assistants (PDAs), or tablet computers equipped with wireless communication capabilities, Voice over IP (VoIP) phones, portable computers, desktop computers, image capture terminal devices (such as digital cameras), gaming terminal devices, music storage and playback devices, in-vehicle wireless terminal devices, wireless endpoints, mobile stations, laptop embedded devices (LEEs), laptop devices (LMEs), smart devices, wireless customer premises equipment (CPEs), or any combination thereof. Mobile communication devices can provide, for example, data communication used to carry communications such as voice, email, text messages, multimedia, etc. Therefore, various services can be provided to the user via the user's communication device. Non-limiting examples of these services include two-way or multiplexed calling, data communications, or multimedia services, or simply access to data communications network systems such as the Internet. Broadcast or multicast data may also be provided to users. Non-limiting examples of content include downloads, television and radio programs, videos, advertisements, various alarms, and other information.

[0129] Mobile devices typically include at least one data processing entity 201, at least one memory 202, and other possible components 203 for software and hardware-assisted execution of tasks designed to be performed, including controlling access to and communication with access systems and other communication devices. The data processing, storage, and other related components may be housed on appropriate circuit boards and / or chipsets. This feature is indicated by reference numeral 204. Users can control the operation of the mobile device using a suitable user interface (e.g., keypad 205, voice commands, touchscreen or keypad, combinations thereof). A display 208, speaker, and microphone may also be provided. Furthermore, mobile communication devices may include appropriate connectors (wired or wireless) for connecting to other devices and / or for attaching external accessories (e.g., hands-free devices).

[0130] Mobile device 200 can receive signals via air or radio interface 207 through appropriate means for receiving, and can transmit signals via appropriate means for transmitting radio signals. Figure 2 In the diagram, the transceiver device is schematically indicated by box 206. The transceiver device 206 can be provided, for example, by means of radio components and an associated antenna arrangement. The antenna arrangement can be located inside or outside the mobile device.

[0131] Figure 3 An example of a control device 300 for a communication system is shown, which is coupled to and / or used to control a station accessing the 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 a Serving Gateway (S-GW), or a Packet Data Network Gateway (P-GW)), or a core network function (such as an AMF / SMF), or a server or host. The method can be implemented in a single control device or across more than one control device. The control device can be integrated with or external to a node or module of the core network or RAN. In some embodiments, a base station includes a separate control device unit or module. In other embodiments, the control device can be another network element, such as a radio network controller or a spectrum controller. In some embodiments, each base station can have such a control device as well as control devices provided in the radio network controller. The control device 300 can be arranged to provide control over communications within the service area of ​​the system. The control device 300 includes at least one memory 301, at least one data processing unit 302, 303, and an input / output interface 304. The control device can be coupled to a receiver and transmitter of a base station via the interface. The receiver and / or transmitter can be implemented as a radio front end or a remote radio head.

[0132] For PLMN (or SNPN) signaling between 5GCs, two types of connections are defined on the N32 interface between SEPPs.

[0133] The first connection type is the N32-c connection. N32-c connections can be used for the management of N32 interfaces (e.g., negotiating protection and security policies to apply to HTTP messages exchanged between two PLMNs, reporting N32-f errors to the peer SEPP, and / or tearing down N32-c / f connections).

[0134] The second connection type is the N32-f connection. N32-f connections can be used to forward protected messages (e.g., HTTP request and response messages exchanged between 5GC NFs of two PLMNs) using Transport Layer Security (TLS) or messages protected by JSON Web Encryption (JWE) and JSON Web Signature (JWS).

[0135] Depending on the choice made during the SEPP handshake process, connections via N32-c and N32-f can be protected at the transport layer using TLS, or at the application layer using the Protocol for N32 Interconnect Security (PRINS).

[0136] If TLS is selected for security, all N32 signaling between the visited PLMN (VPLMN) and the home PLMN (HPLMN) will be end-to-end encrypted. Since roaming connections grow exponentially N-to-N with the number of roaming networks, TLS protection for the N32 interface can be used for top roaming relationships.

[0137] If PRINS are selected, SEPP will use JavaScript Object Notation (JSON) Web Encryption (JWE) to protect their messages transmitted across N32. Parts of messages transmitted across N32 can be sent in plaintext, and these parts can be modified by the IPX service provider during transmission. Any modifications by the IPX service provider will be signed using its JSON Web Signature (JWS).

[0138] When PRINS security is used, an N32-f context identifier can be used at either Security Edge Protection Agent (SEPP) to associate an N32-c connection with an N32-f connection. This N32-f context identifier is exchanged during the N32-c handshake and is included in every N32-f message forwarded between SEPPs. The N32-c protocol supports an N32-f context termination procedure, which allows the termination of an N32-f context and the teardown of the corresponding N32-f connection.

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

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

[0141] For example, multiple SEPPs A1, A2, ... of MNO A (deployed for purposes such as redundancy, load sharing, or dedicated N32) can establish one (or more) N32 connections with SEPP B1 of another MNO B.

[0142] Multiple N32 connections can be established for different N32 purposes, such as SMS interconnection, roaming, emergency roaming, etc. Multiple N32 connections can also be established for services between different PLMNs (e.g., between SEPP and roaming hubs (RHUB)). SEPP can open new N32 connections where peer SEPPs negotiate new security or protection policies (e.g., PRINS), while keeping older connections utilizing previously negotiated security and protection open during grace periods (e.g., TLS), and for other possible future reasons.

[0143] In the case of multiple N32-c and N32-f connections being established, it is important to be able to associate the N32-c and N32-f connections for several reasons, including (but not limited to) when SEPP or RHUB supports serving multiple PLMNs, so that any renegotiation policy for N32-c can be applied to the associated N32-f connection, to be able to tear down the N32-f connection(s) associated with the N32-c connection, to be able to identify the N32-f connection(s) for a specific PLMN, or to be able to identify the N32 connection(s) for which some N32-f errors have been reported.

[0144] When TLS security is used, it is insufficient to associate N32-c and N32-f connections solely based on the PLMN ID of the peer SEPP received in the TLS certificate. For example, SEPPs A1 and A2 of MNO A will present the same PLMN ID to SEPP B1. Similarly, when multiple N32 connections can be established between the same pair of SEPPs (e.g., for different N32 purposes), associating N32-c and N32-f connections using the PLMN ID and the fully qualified domain name (FQDN) of the peer SEPP is also insufficient.

[0145] Regarding TLS security, when multiple N32-c and N32-f connections exist, there is the question of how SEPP should associate N32-c connections with N32-f connections, and how to identify the N32-f connection that should be terminated when SEPP requests its peer SEPP to terminate the N32-f connection via N32-c.

[0146] For PRINS security, when multiple N32-c connections can be established between a pair of SEPPs, for example for different N32 purposes, there is a question of how to identify a specific N32-c connection during the security capability negotiation process.

[0147] Figure 4 A flowchart of a method according to an example embodiment is shown. This method can be performed at an entity in the core network. The network can be, for example, the core network of a PLMN or SNPN.

[0148] In 401, the method includes: during the process of establishing a first connection on an interface between an entity in a first core network and an entity in a second core network, receiving a first identifier at an entity in the second core network from an entity in the first core network, wherein the first identifier is associated with the first connection.

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

[0150] Figure 5 A flowchart of a method according to an example embodiment is shown. This method can be performed at an entity in the core network. The core network can be, for example, the core network of a PLMN.

[0151] In 501, the method includes: during the process of establishing a first connection on an interface between an entity in a first core network and an entity in a second core network, providing a first identifier from an entity in the first core network to an entity in the second core network, wherein the identifier is associated with the first connection.

[0152] In 502, the method includes: in response, receiving a second identifier at an entity in a second core network from an entity in a first core network, wherein the second identifier is associated with a first connection.

[0153] Entities in the first core network can be SEPPs (and may also be referred to as initiating SEPPs, sending SEPPs, or peering SEPPs). Entities in the second core network can be SEPPs (and may also be referred to as responding SEPPs, receiving SEPPs, or peering SEPPs) or RHUBs.

[0154] The interface can be an N32 interface. The first connection can be an N32-C connection. The second connection can be an N32-F connection.

[0155] The first identifier and the second identifier may include a handshake identifier. The handshake identifier may be referred to as the "N32 handshake ID" below. The first identifier and the second identifier may be the same or different.

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

[0157] In both TLS and PRINS protocols, an identifier or "N32 handshake ID" allows for the association of N32-f and N32-c.

[0158] It describes different alternatives that can be applied to either protocol or both.

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

[0160] In the example embodiment, the security capability negotiation process (SecNegotiateReq / Rsp) is enhanced to enable signaling transmission of the N32 handshake ID that uniquely identifies the N32-c connection and the associated N32-f connection.

[0161] In an example embodiment, the Security Negotiation Request Data (SecNegotiateReqData) message is extended with the N32 handshake ID, which includes sending the SEPP. This is an example of an entity in a first core network providing a first identifier to an entity in a second core network in a Security Capability Exchange Request.

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

[0163] Figure 6 The signaling flow for a security capability negotiation process between an initiating SEPP and a responding SEPP, according to an example embodiment, is illustrated. In 601, the initiating SEPP sends SecNegotiateReqData including n32handshakeId. In 602, the responding SEPP sends SecNegotiateRspData including n32handshakeId.

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

[0165]

[0166] Table 1

[0167] Table 2 For reference Figure 4 The described method may include: receiving, at an entity in a second core network, another security capability exchange request from an entity in a first core network for a first connection, the other security capability exchange request including a first identifier; and deriving, based on the first identifier, the association of the other security capability exchange request with the first connection.

[0168] Therefore, when requesting the removal of N32-f, SEPP can determine the correct N32-c connection from the "N32 handshake ID", and optionally together with the sender's FQDN, determine the correct N32-c connection.

[0169] In an example implementation, when initiating a subsequent security capability negotiation process for an existing N32-c connection (e.g., requesting the peer SEPP to tear down an N32-f TLS connection), the sending SEPP includes the N32 handshake ID signaled during the initial N32-c connection establishment. This is an example where, for a first connection, an entity in a second core network receives another security capability exchange request from an entity in the first core network, this other security capability exchange request including a first identifier. This allows the receiving SEPP to determine that the N32-c connection is the object of the subsequent security capability negotiation process. This is an example where, based on the first identifier, the other security capability exchange request is deduced to be associated with the first connection.

[0170] Since SEPP may have created several N32-c connections associated with different N32-f connections, it may be important to correctly identify the N32-c connections and their associated N32-f connections. This mechanism allows for differentiation of which N32-f connection needs to be removed.

[0171] Transport layer security (TLS) or application layer security (e.g., PRINS) can be used to protect messages forwarded over a second connection.

[0172] The handshake identifier can be different from the PRINS N32-f context ID (n32fcontextId). Alternatively or additionally, for PRINS, the first identifier (e.g., N32 handshake ID) can take the form of the PRINS-specific N32-f context ID. See reference... Figure 4 The described method may include associating a first identifier with another identifier received in a security parameter exchange request (e.g., an N32-F context ID in SecParamExchReq).

[0173] For PRINS, see reference Figure 4 The described method may also include receiving a first identifier in a security parameter exchange request (e.g., SecParamExchReq).

[0174] For PRINS security, two example options that allow associating N32-f and N32-c in PRINS are: adding an N32 handshake ID to SecNegotiateReqData, SecNegotiateRspData, and SecParamExchReq, or adding a new N32 handshake only to SecNegotiateReqData and SecNegotiateRspData, in which case the N32 handshake ID should contain the same value as the existing N32-f context ID that is part of SecParamExchReq / Rsp.

[0175] Table 3 shows example definitions for the SecNegotiateReqData and SecNegotiateRspData types for PRINS.

[0176]

[0177] Table 3 For TLS security, refer to Figure 5 The described method may include: receiving a message to be sent to a second core network from another entity (e.g., NF) in the first core network at an entity in the first core network; inserting a second identifier into the message; and forwarding the message to an entity in the second core network using a second connection on the interface.

[0178] For reference Figure 4 The described method may include: receiving a message including a second identifier from an entity in the first core network at an entity in the second core network using a second connection on an interface between the entity in the first core network and the entity in the second core network; and associating the second connection with the first connection based on the second identifier. The method may further include: removing the second identifier from the message and providing the message from the entity in the second core network to another entity in the second core network (e.g., NF).

[0179] A second identifier can be inserted and received separately in the HTTP custom header.

[0180] The HTTP custom header may also include a fully qualified domain name (FQDN) associated with an entity in the first core network, and the method may include associating the second connection with the first connection based on the FQDN.

[0181] In the example implementation, a custom header can be introduced for TLS security.

[0182] HTTP custom headers (which may be referred to as, for example, "3gpp-Sbi-n32c-Correlation" or "3gpp-Sbi-N32-Handshake-Id") can be signaled in (TLS-protected) N32-f messages, where the N32 handshake ID is signaled by the peer SEPP during the N32-c handshake.

[0183] In the example implementation, the sender's FQDN can be included in the HTTP custom header.

[0184] In an example embodiment, the sending SEPP inserts a custom HTTP header into a message forwarded to a peer SEPP. This is an example where an entity in the first core network receives a message to be sent to the second core network from another entity in the first core network, and inserts a second identifier into that message.

[0185] The receiving (peer-to-peer) SEPP retrieves the FQDN from the certificate or from the 3gpp-Sbi-n32c-Correlation header. The receiving SEPP uses the N32 handshake ID received in that header (and optionally, the retrieved FQDN) to associate the N32-f message and the N32-c connection with the N32-c connection. Here is an example: using a second connection on the interface between an entity in the first core network and an entity in the second core network, the entity in the second core network receives a message including a second identifier from the entity in the first core network, and associates the second connection with the first connection based on the second identifier.

[0186] The receiving SEPP removes the header before forwarding the message to its target recipient (target NF). Here's an example: removing the second identifier from the message and providing the message from an entity in the second core network to another entity in the second core network (e.g., the target NF).

[0187] Figure 7 The signaling flow in which TLS security is used for N32-f communication is shown. Figure 7 The example signaling flow 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 other entities in the core network, and SEPP A and SEPP B are examples of entities in the first core network and the second core network, respectively.

[0188] In step 701, NF A sends a message to SEPP A. In step 702, SEPP A adds an HTTP header including the n32handshakeId to the message. In step 703, SEPP A sends a message including the HTTP header and the n32handshakeId to SEPP B using an N32-f connection. In step 704, SEPP removes the header, associates N32-f and N32-c, and in step 705, SEPPB forwards the message to NF B.

[0189] An apparatus may include: means for receiving a first identifier at an entity in the second core network from an entity in the first core network during the process of establishing a first connection on an interface between an entity in the first core network and an entity in the second core network, wherein the first identifier is associated with the first connection; and means for providing a second identifier from an entity in the second core network to an entity in the first core network in response, wherein the second identifier is associated with the first connection.

[0190] Alternatively or additionally, an apparatus may include: means for providing a first identifier from an entity in the first core network to an entity in the second core network during the process of establishing a first connection at an interface between an entity in the first core network and an entity in the second core network, wherein the identifier is associated with the first connection; and means for receiving a second identifier from an 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.

[0191] The device may include a network function (e.g., SEPP), be a network function, or be included in a network function or chipset for performing at least some actions of the network function / for at least some actions of the network function.

[0192] It should be understood that the device may include or be coupled to other units or modules, such as radio sections or radio heads, used in or for transmitting and / or receiving. Although the device has been described as a single entity, different modules and memories may be implemented in one or more physical or logical entities.

[0193] Note that while some embodiments have been described with respect to 5G networks, similar principles can be applied to other networks and communication systems, such as 6G networks or 5G advanced networks. Therefore, although some embodiments have been described above by way of example with respect to certain example architectures for wireless networks, technologies, and standards, these embodiments can be applied to any other suitable form of communication system besides those shown and described herein.

[0194] It should also be noted in this document that although exemplary embodiments have been described above, several changes and modifications may be made to the disclosed solutions without departing from the scope of this disclosure.

[0195] 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 is connected by “and” or “or”) means at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

[0196] Generally, various embodiments can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects of this disclosure can be implemented in hardware, while others can be implemented in firmware or software that can be executed by a controller, microprocessor, or other computing device, but this disclosure is not limited thereto. Although various aspects of this disclosure may be shown and described as block diagrams, flowcharts, or using some other graphical representation, it should be understood that, as non-limiting examples, these blocks, apparatuses, systems, techniques, or methods described herein can be implemented in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware, or controllers, other computing devices, or some combination thereof.

[0197] As used in this application, the term "circuit system" may refer to one or more of the following: (a) Hardware circuit implementation only (such as implementation in analog and / or digital circuit systems only), and (b) A combination of hardware circuitry and software, such as (if applicable): (i) A combination of (multiple) analog and / or (multiple) digital hardware circuits and software / firmware, and (ii) Any part of a device (such as a mobile phone or server) that has software (including multiple digital signal processors), software, and multiple memories working together to enable the device to perform various functions, and I requires software (e.g., firmware) to operate (but the software may not exist when it is not needed) hardware circuitry and / or processors, such as microprocessors or portions of microprocessors.

[0198] This definition of circuit system applies to all uses of the term in this application, including in any claim. As another example, as used herein, the term circuit system also covers implementations of only hardware circuitry or processors (or processors in general) or portions thereof and their accompanying software and / or firmware. For instance, if applicable to a particular claim element, the term circuit system also covers baseband integrated circuits or processor integrated circuits for mobile devices, or similar integrated circuits in servers, cellular network devices, or other computing or network devices.

[0199] Embodiments of this disclosure may be implemented by computer software executable by a data processor of a mobile device (e.g., in a processor entity), or by hardware, or by a combination of software and hardware. Computer software or programs (also referred to as program products, including software routines, applets, and / or macros) may be stored in any device-readable data storage medium, and they include instructions for performing specific tasks. A computer program product may include one or more computer-executable components configured to perform the embodiments when the program is run. The one or more computer-executable components may be at least one piece of software code or a portion thereof.

[0200] Furthermore, it should be noted in this regard that any block in the logical flow shown in the accompanying drawings may represent a program step, or an interconnected logic circuit, block, and function, or a combination of a program step and a logic circuit, block, and function. Software may be stored on physical media such as memory chips, or blocks of memory implemented within a processor, magnetic media such as hard disks or floppy disks, and optical media such as DVDs and their data variants, CDs. Physical media are non-transitory media. As used herein, the term "non-transitory" is a limitation on the medium itself (i.e., tangible, not tactile), not a limitation on the persistence of data storage (e.g., RAM versus ROM).

[0201] The memory can be of any type suitable for the local technical environment and can 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. As a non-limiting example, the data processor can be of any type suitable for the local technical environment and can include one or more of the following: general-purpose computers, special-purpose computers, microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), FPGAs, gate-level circuits, and processors based on multi-core processor architectures.

[0202] The embodiments of this disclosure can be practiced in various components such as integrated circuit modules. The design of integrated circuits is primarily a highly automated process. Complex and powerful software tools can be used to transform logic-level designs into semiconductor circuit designs ready for etching and formation on semiconductor substrates.

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

[0204] The foregoing description has provided a complete and detailed description of exemplary embodiments of the present disclosure by way of non-limiting example. However, various modifications and adjustments may become apparent to those skilled in the art when read in conjunction with the accompanying drawings and appended claims, given the foregoing description. Nevertheless, all such and similar modifications to the teachings of this disclosure will still fall within the scope of the disclosure as defined in the appended claims. Indeed, there exists another embodiment that comprises a combination of one or more embodiments with any other embodiments previously discussed.

Claims

1. An apparatus comprising: Components for receiving a first identifier from an entity in a first core network at an entity in a second core network during a process, the process being used to establish a first connection at 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; as well as A component 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: A component for receiving the first identifier in a security capability exchange request.

3. The apparatus according to claim 2, comprising: A component used to provide the second identifier in a security capability exchange response.

4. The apparatus according to any one of claims 2 to 3, comprising: A component for receiving another security capability exchange request from the entity in the first core network at the entity connected to the first connection in the second core network, the other security capability exchange request including the first identifier; as well as Components used to deduce the other security capability exchange request related to the first connection based on the first identifier.

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

6. The apparatus according to any one of claims 2 to 4, comprising: The component is used to receive the first identifier in the security parameter exchange request.

7. The apparatus according to any one of claims 1 to 4, comprising: A component for receiving a message including the second identifier from an 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; as well as A component for associating the second connection with the first connection based on the second identifier.

8. The apparatus according to claim 7, comprising: A component for removing the second identifier from the message; And components for providing the message from the entity in the second core network to another entity in the second core network.

9. The apparatus according to claim 7 or 8, comprising: The component used to also receive the second identifier in the HTTP custom header.

10. The apparatus of 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 components for further associating the second connection with the first connection based on the FQDN.

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

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

13. The apparatus according to any one 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 Agent (SEPP).

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

15. The apparatus according to any one of claims 1 to 4, wherein transport layer security or application layer security is used to protect messages forwarded through the second connection.

16. An apparatus comprising: A component for providing a first identifier from an entity in a first core network to an entity in a second core network during a process for establishing 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; as well as A component for receiving a second identifier at the entity in the second core network in response to the first core network, wherein the second identifier is associated with the first connection.

17. The apparatus of claim 16, comprising: A component used to provide the first identifier in a security capability exchange request.

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

19. The apparatus according to any one of claims 16 to 18, comprising: A component for providing another 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 other security capability exchange request including the first identifier.

20. The apparatus according to any one of claims 16 to 19, comprising: The component used to also provide the first identifier in the security parameter exchange request.

21. The apparatus according to any one of claims 16 to 19, comprising: A component for receiving, at the entity in the first core network, a message to be sent to the second core network from another entity in the first core network; A component for inserting the second identifier into the message; as well as A component for forwarding the message to the entity in the second core network using the second connection on the interface.

22. The apparatus of claim 21, comprising: This component is used to also insert the second identifier into the HTTP custom header.

23. The apparatus of 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 one of claims 16 to 23, wherein the first identifier and the second identifier are the same or different.

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

26. The apparatus according to any one of claims 16 to 25, wherein the entity in the first core network and the entity in the second core network comprise a Secure Edge Protection Agent (SEPP).

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

28. The apparatus according to any one of claims 16 to 19, wherein transport layer security or application layer security is used to protect messages forwarded through the second connection.

29. A method comprising: During the process of establishing a first connection on an interface between an entity in a first core network and an entity in a second core network, a first identifier is received at the entity in the second core network from the entity in the first core network, wherein the first identifier is associated with the first connection. as well as In response, the entity in the second core network provides a second identifier to the entity in the first core network, wherein the second identifier is associated with the first connection.

30. A method comprising: In the process of establishing a first connection on an interface between an entity in a first core network and an entity in a second core network, a first identifier is provided from the entity in the first core network to the entity in the second core network, wherein the identifier is associated with the first connection; as well as In response, a second identifier is received at the entity in the first core network from the entity in the second core network, wherein the second identifier is associated with the first connection.

31. An apparatus comprising: At least one processor and at least one memory, the memory storing instructions that, when executed by the processor, cause the device to at least: During the process of establishing a first connection on an interface between an entity in a first core network and an entity in a second core network, a first identifier is received at the entity in the second core network from the entity in the first core network, wherein the first identifier is associated with the first connection. as well as In response, the entity in the second core network provides a second identifier to the entity in the first core network, wherein the second identifier is associated with the first connection.

32. An apparatus comprising: At least one processor and at least one memory, the memory storing instructions that, when executed by the processor, cause the device to at least: In the process of establishing a first connection on an interface between an entity in a first core network and an entity in a second core network, a first identifier is provided from the entity in the first core network to the entity in the second core network, wherein the identifier is associated with the first connection; as well as In response, a second identifier is received at the entity in the first core network from the entity in the second core network, wherein the second identifier is associated with the first connection.

33. A computer-readable medium comprising instructions that, when executed by a means, cause the means to perform at least the following: During the process of establishing a first connection on an interface between an entity in a first core network and an entity in a second core network, a first identifier is received at the entity in the second core network from the entity in the first core network, wherein the first identifier is associated with the first connection; and In response, the entity in the second core network provides a second identifier to the entity in the first core network, wherein the second identifier is associated with the first connection.

34. A computer-readable medium comprising instructions that, when executed by a device, cause the device to perform at least the following: During the process of establishing a first connection on an interface between an entity in a first core network and an entity in a second core network, a first identifier is provided from the entity in the first core network to the entity in the second core network, wherein the identifier is associated with the first connection; and In response, a second identifier is received at the entity in the first core network from the entity in the second core network, wherein the second identifier is associated with the first connection.

Images