EP4152691B1 - Roaming-hub zur sicheren verbindung in roaming-szenarien - Google Patents

Roaming-hub zur sicheren verbindung in roaming-szenarien

Info

Publication number
EP4152691B1
EP4152691B1 EP22196005.7A EP22196005A EP4152691B1 EP 4152691 B1 EP4152691 B1 EP 4152691B1 EP 22196005 A EP22196005 A EP 22196005A EP 4152691 B1 EP4152691 B1 EP 4152691B1
Authority
EP
European Patent Office
Prior art keywords
message
http
plmn
custom header
roaming
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
EP22196005.7A
Other languages
English (en)
French (fr)
Other versions
EP4152691A1 (de
Inventor
Saurabh Khare
Bruno Landais
Anja Jerichow
Laurent Thiebaut
Georgios GKELLAS
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia Technologies Oy
Original Assignee
Nokia Technologies Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Technologies Oy filed Critical Nokia Technologies Oy
Publication of EP4152691A1 publication Critical patent/EP4152691A1/de
Application granted granted Critical
Publication of EP4152691B1 publication Critical patent/EP4152691B1/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/123—Applying verification of the received information received data contents, e.g. message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/106—Packet or message integrity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/02—Hierarchically pre-organised networks, e.g. paging networks, cellular networks, WLAN [Wireless Local Area Network] or WLL [Wireless Local Loop]
    • H04W84/04—Large scale networks; Deep hierarchical networks
    • H04W84/042—Public Land Mobile systems, e.g. cellular systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • This disclosure is related to the field of communication systems and, in particular, to next generation networks.
  • Next generation networks such as Fifth Generation (5G) denote the next major phase of mobile telecommunications standards beyond Fourth Generation (4G) standards.
  • 5G Fifth Generation
  • 4G Fourth Generation
  • next generation networks may be enhanced in terms of radio access and network architecture.
  • Next generation networks intend to utilize new regions of the radio spectrum for Radio Access Networks (RANs), such as centimeter and millimeter wave bands.
  • RANs Radio Access Networks
  • a user of a 5G network has a home Public Land Mobile Network (HPLMN), and the user may access services when located in the coverage area of the HPLMN.
  • HPLMN Public Land Mobile Network
  • the 5G Core Network (5GC) of the HPLMN is able to interconnect or interwork with the 5GC of the VPLMN so that the user can access services even when roaming outside of their HPLMN.
  • SEPP Security Edge Protection Proxy
  • a SEPP is an entity sitting at the perimeter of a PLMN and is configured to protect control plane messages as is further described in 3GPP TS 33.501 (v17.2.1).
  • a SEPP is implemented at the edge of a VPLMN, and another SEPP is implemented at the edge of the HPLMN. Control plane messages are exchanged between the SEPPs over the N32 interface.
  • intermediate proxies may be implemented between SEPPs of PLMNs.
  • the use of intermediate proxies in this manner may cause issues with secure interconnect.
  • a sending SEPP in scenarios not including intermediate proxies is e.g. specified in the following documents:
  • a roaming hub is a type of intermediate proxy implemented in a signaling path between a SEPP of one PLMN and a SEPP of another PLMN.
  • the roaming hub When receiving a message over the signaling path from a sending entity, the roaming hub is configured to add a custom header or custom headers to the message as defined herein, and/or modify the custom headers if already present.
  • the roaming hub is configured to add a custom header that indicates a PLMN of the sending entity that is validated by the roaming hub.
  • the roaming hub is configured to add a custom header that indicates an identifier for the roaming hub.
  • the information contained in the custom header(s) may be used at a responding SEPP or another entity for validation, charging, troubleshooting, etc., which is described in more detail below.
  • One embodiment comprises a method of message forwarding.
  • the method comprises receiving, at a roaming hub, a message from a sending entity across an N32 interface, and determining, at the roaming hub, whether the message includes a first Hypertext Transfer Protocol (HTTP) custom header that indicates a PLMN that is validated.
  • HTTP Hypertext Transfer Protocol
  • the method further comprises adding the first HTTP custom header to the message that indicates the PLMN of the sending entity, integrity protecting the first HTTP custom header, and forwarding the message from the roaming hub toward a receiving entity.
  • the method when the message as received includes the first HTTP custom header, the method further comprises performing integrity verification on the first HTTP custom header to validate content of the first HTTP custom header, integrity protecting the first HTTP custom header, and forwarding the message from the roaming hub toward the receiving entity.
  • the first HTTP custom header is defined to indicate a PLMN identifier of a service consumer of the message that is validated.
  • the method further comprises receiving the message from the roaming hub at a SEPP across the N32 interface, and determining at the SEPP whether the message includes the first HTTP custom header.
  • the method further comprises validating a PLMN of a service consumer based at least on a token contained in an HTTP standard header of the message and a PLMN identifier contained in the first HTTP custom header.
  • the method further comprises determining, at the roaming hub, whether the message includes a second HTTP custom header that indicates one or more roaming hubs that relayed the message.
  • the method further comprises adding the second HTTP custom header to the message that indicates a roaming hub identifier of the roaming hub, and integrity protecting the second HTTP custom header.
  • the method when the message as received includes the second HTTP custom header, the method further comprises performing integrity verification on the second HTTP custom header to validate content of the second HTTP custom header, adding the roaming hub identifier to an instance of the second HTTP custom header, and integrity protecting the second HTTP custom header or second HTTP custom headers.
  • the second HTTP custom header is defined to indicate a list of roaming hub identifiers. Adding the roaming hub identifier to an instance of the second HTTP custom header comprises modifying a present instance of the second HTTP custom header as received in the message to indicate the roaming hub identifier in the list.
  • the second HTTP custom header is defined to indicate an identifier of a single roaming hub. Adding the roaming hub identifier to an instance of the second HTTP custom header comprises adding another instance of the second HTTP custom header to the message that indicates the roaming hub identifier.
  • the method further comprises receiving the message from the roaming hub at a SEPP across the N32 interface, and determining whether the message includes one or more instances of the second HTTP custom header.
  • the method further comprises forwarding one or more roaming hub identifiers contained in the second HTTP custom header or the second HTTP custom headers to another entity.
  • forwarding one or more roaming hub identifiers contained in the second HTTP custom header or the second HTTP custom headers comprises at least one of forwarding the one or more roaming hub identifiers to a charging function, and forwarding the one or more roaming hub identifiers to a tracing function.
  • integrity protecting the first HTTP custom header and integrity protecting the second HTTP custom header comprises signing the first HTTP custom header and the second HTTP custom header with an indication of the roaming hub.
  • the second HTTP custom header indicates at least one of a PLMN identifier for the roaming hub, a Fully Qualified Domain Name (FQDN) identifier for the roaming hub, an Internet Protocol (IP) address for the roaming hub, and an instance identifier for the roaming hub.
  • FQDN Fully Qualified Domain Name
  • IP Internet Protocol
  • Another embodiment comprises an apparatus, such as a roaming hub, comprising at least one memory including computer program code.
  • the memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to receive a message from a sending entity across an N32 interface, and determine whether the message includes a first HTTP custom header that indicates a PLMN that is validated.
  • the computer program code and the processor cause the apparatus to add the first HTTP custom header to the message that indicates the PLMN of the sending entity, integrity protect the first HTTP custom header, and forward the message toward a receiving entity.
  • the computer program code and the processor when the message as received includes the first HTTP custom header, the computer program code and the processor cause the apparatus to perform integrity verification on the first HTTP custom header to validate content of the first HTTP custom header, integrity protect the first HTTP custom header, and forward the message toward the receiving entity.
  • the computer program code and the processor cause the apparatus to determine whether the message includes a second HTTP custom header that indicates one or more roaming hubs that relayed the message.
  • the computer program code and the processor cause the apparatus to add the second HTTP custom header to the message that indicates a roaming hub identifier of the apparatus, and integrity protect the second HTTP custom header.
  • the computer program code and the processor when the message as received includes the second HTTP custom header, the computer program code and the processor cause the apparatus to perform integrity verification on the second HTTP custom header to validate content of the second HTTP custom header, add the roaming hub identifier to an instance of the second HTTP custom header, and integrity protect the second HTTP custom header or second HTTP custom headers.
  • the second HTTP custom header is defined to indicate a list of roaming hub identifiers.
  • the computer program code and the processor cause the apparatus to modify a present instance of the second HTTP custom header as received in the message to indicate the roaming hub identifier in the list.
  • the second HTTP custom header is defined to indicate an identifier of a single roaming hub.
  • the computer program code and the processor cause the apparatus to add another instance of the second HTTP custom header to the message that indicates the roaming hub identifier.
  • FIG. 1 illustrates a high-level architecture of a 5G system 100.
  • a 5G system 100 is a communication system (e.g., a 3GPP system) comprising a 5G Access Network ((R)AN) 102, a 5G Core Network (CN) 104, and 5G User Equipment (UE) 106.
  • Access network 102 may comprise an NG-RAN and/or non-3GPP access network connecting to a 5G core network 104.
  • Access network 102 may support Evolved-UMTS Terrestrial Radio Access Network (E-UTRAN) access (e.g., through an eNodeB, gNodeB, and/or ng-eNodeB), Wireless Local Area Network (WLAN) access, fixed access, satellite radio access, new Radio Access Technologies (RAT), etc.
  • Core network 104 interconnects access network 102 with a data network (DN) 108.
  • Core network 104 is comprised of Network Functions (NF) 110, which may be implemented either as a network element on dedicated hardware, as a software instance running on dedicated hardware, as a virtualized function instantiated on an appropriate platform (e.g., a cloud infrastructure), etc.
  • NF Network Functions
  • Data network 108 may be an operator external public or private data network, or an intra-operator data network (e.g., for IMS services).
  • UE 106 is configured to register with core network 104 to access services.
  • UE 106 may be an end user device, such as a mobile phone (e.g., smartphone), a tablet or PDA, a computer with a mobile broadband adapter, etc.
  • UE 106 may be enabled for voice services, data services, Machine-to-Machine (M2M) or Machine Type Communications (MTC) services, and/or other services.
  • M2M Machine-to-Machine
  • MTC Machine Type Communications
  • FIG. 2 illustrates a non-roaming architecture 200 of a 5G system.
  • the architecture 200 in FIG. 2 is a service-based representation, as is further described in 3GPP TS 23.501 (v17.1.1).
  • Architecture 200 is comprised of Network Functions (NF) for a core network 104, and the NFs for the control plane (CP) are separated from the user plane (UP).
  • NF Network Functions
  • CP control plane
  • UP user plane
  • the control plane of the core network 104 includes an Authentication Server Function (AUSF) 210, an Access and Mobility Management Function (AMF) 212, a Session Management Function (SMF) 214, a Policy Control Function (PCF) 216, a Unified Data Management (UDM) 218, a Network Slice Selection Function (NSSF) 220, and an Application Function (AF) 222.
  • the control plane of the core network 104 further includes a Network Exposure Function (NEF) 224, a NF Repository Function (NRF) 226, a Service Communication Proxy (SCP) 228, a Network Slice Admission Control Function (NSACF) 230, and a Network Slice-specific and SNPN Authentication and Authorization Function (NSSAAF) 232.
  • the user plane of the core network 104 includes one or more User Plane Functions (UPF) 240 that communicate with data network 108.
  • UE 106 is able to access the control plane and the user plane of the core network 104 through (R)AN 102.
  • FIG. 3 illustrates a roaming architecture 300 of a 5G system.
  • the roaming architecture 300 in FIG. 3 illustrates a local breakout scenario in a service-based representation, as is further described in 3GPP TS 23.501.
  • a home PLMN (HPLMN) 302 and a serving or visited PLMN (VPLMN) 304 are shown for roaming architecture 300.
  • An HPLMN 302 is the PLMN in which the profile of a mobile subscriber is held.
  • a VPLMN 304 is a PLMN upon which the mobile subscriber has roamed when leaving their HPLMN 302.
  • a local breakout (LBO) is a roaming scenario for a Protocol Data Unit (PDU) Session where the PDU Session Anchor and its controlling SMF 214 are located in the serving PLMN (VPLMN 304).
  • PDU Protocol Data Unit
  • VPLMN 304 serving PLMN
  • Data traffic is routed directly from the VPLMN 304 to the data network 108 while authentication and handling of subscription data is handled in HPLMN 302.
  • HPLMN 302. only signaling is routed to HPLMN 302.
  • a SEPP acts as a service relay between VPLMN 304 and HPLMN 302 for providing a secured connection as well as hiding the network topology.
  • roaming architecture 300 further includes a SEPP 312 in HPLMN 302 (also referred to as hSEPP), and a SEPP 314 in VPLMN 304 (also referred to as a vSEPP), with an N32 interface 316 between SEPP 312 and SEPP 314.
  • FIG. 4 illustrates another roaming architecture 400 of a 5G system.
  • the roaming architecture 400 in FIG. 4 illustrates a home routed scenario in a service-based representation, as is further described in 3GPP TS 23.501.
  • data traffic from VPLMN 304 is routed to data network 108 via HPLMN 302.
  • bearer data is also routed to HPLMN 302.
  • roaming architecture 400 includes a SEPP 312 in HPLMN 302 and a SEPP 314 in VPLMN 304, with an N32 interface 316 between SEPP 312 and SEPP 314.
  • the 5G architecture is based on a Service-Based Architecture (SBA), which is delivered by a set of interconnected Network Functions (NFs), with authorization to access each other's services.
  • SBA Service-Based Architecture
  • NFs Network Functions
  • the roles of NFs with the 5GC may be defined as a service consumer and a service producer.
  • An NF service producer is an NF that exposes a service
  • an NF service consumer is an NF that requests a service.
  • the NRF 226 stores the NF profiles of the NF service producers, and the NF service consumers are able to query the NRF 226 with a discovery function to obtain the NF profiles of the NF service producers.
  • FIG. 5 illustrates inter-PLMN communications between a PLMN 502 and PLMN 504. It is assumed that there is a service agreement or roaming agreement between PLMN 502 and PLMN 504.
  • An NF service producer 522 is shown in a PLMN 502 (e.g., an HPLMN 302), and an NF service consumer 524 is shown in another PLMN 504 (e.g., a VPLMN 304).
  • a SEPP 512 is implemented in PLMN 502 and a SEPP 514 is implemented in PLMN 504.
  • a SEPP is a non-transparent proxy that supports message filtering and policing on inter-PLMN control plane interfaces, and topology hiding.
  • the SEPP protects the connection between NF service consumers and NF service producers from a security perspective.
  • a SEPP applies message filtering and policing to every CP message in inter-PLMN signaling, acting as a service relay between the actual NF service producer and the actual NF service consumer.
  • the N32 interface 532 is used between the SEPPs of a VPLMN and a HPLMN in roaming scenarios, as is described in 3GPP TS 29.573 (v17.1.0).
  • the SEPP that is on the NF service consumer side may be referred to as the c-SEPP, and the SEPP that is on the NF service producer side may be referred to as the p-SEPP.
  • the NF service consumer 524 (or Service Communication Proxy (SCP)) may be configured with the c-SEPP or discover the c-SEPP by querying the NRF 226.
  • the NF service producer 522 (or SCP) may be configured with the p-SEPP or discover the p-SEPP by querying the NRF 226.
  • the N32 interface 532 can be logically considered as two separate interfaces: the N32-c interface 533 and the N32-f interface 534.
  • the N32-c interface 533 is a control plane interface between the SEPPs that provides an initial handshake procedure, and negotiation and parameter exchange for the actual N32 message forwarding.
  • the N32-f interface 534 is used to forward the HTTP/2 messages of the NF service producers and the NF service consumers in different PLMNs, through the SEPPs of the respective PLMNs.
  • the application layer security protection functionality of the N32-f interface 534 is used if the PRotocol for N32 INterconnect Security (PRINS) is negotiated between the SEPPs using the N32-c interface 533.
  • PRINS PRotocol for N32 INterconnect Security
  • the N32-f interface 534 provides message protection of the information exchanged between the NF service consumer and the NF service producer across PLMNs by applying application layer security mechanisms, and forwarding of application layer protected messages from a SEPP in one PLMN to a SEPP in another PLMN.
  • Forwarding application layer protected messages may involve IP Exchange Service (IPX) providers (not shown in FIG. 5 ) on the signaling path. If IPX intermediaries/providers are on the path from SEPP 512 in PLMN 502 to SEPP 514 in PLMN 504, the forwarding on the N32-f interface 534 may involve the insertion of content modification instructions that the receiving SEPP applies after verifying the integrity of such modification instructions.
  • Transport Layer Security TLS is the negotiated security policy between the SEPPs, then the N32-f interface 534 involves only the forwarding of the HTTP/2 messages of the NF service producers and the NF service consumers without any reformatting.
  • the N32 interface 532 uses Transmission Control Protocol (TCP) as the transport protocol as required by HTTP/2.
  • TCP Transmission Control Protocol
  • the scope of the HTTP/2 connection used for the N32-c interface 533 is short-lived. When the initial handshake is completed, the connection is torn down.
  • the HTTP/2 connection used for the N32-c interface 533 is end-to-end between the SEPPs, and does not involve an IPX to intercept the HTTP/2 connection, though an IPX may be involved for IP level routing.
  • the scope of the HTTP/2 connection used for the N32-f interface 534 is long-lived.
  • the HTTP/2 connection used for the N32-f interface 534 may be towards a SEPP of another PLMN without involving any IPX intermediaries, or towards a SEPP of another PLMN via an IPX intermediary.
  • JSON JavaScript Object Notation
  • the procedures on the N32 interface 532 are split into two categories: (1) procedures that happen end-to-end between the SEPPs on the N32-c interface 533, and (2) procedures that are used for forwarding of messages on the service based interface between the NF service consumer 524 and the NF service producer 522 via the SEPP across the N32-f interface 534.
  • a handshake procedure i.e., N32 Handshake Application Programming Interface (API)
  • N32 Handshake Application Programming Interface (API) for the N32-c interface 533 is used between the SEPPs in two PLMNs to mutually authenticate each other and negotiate the security mechanism to use over the N32-f interface 534 along with associated security configuration parameters.
  • An HTTP/2 connection is established between the initiating SEPP and the responding SEPP end-to-end over TLS.
  • the handshake procedure includes a security capability negotiation procedure, a parameter exchange procedure, an N32-f context termination procedure, and an N32-f error reporting procedure.
  • FIG. 6 is a signaling diagram of a security capability negotiation procedure over the N32-c interface 533.
  • the initiating (or sending) SEPP 514 initiates a security capability negotiation procedure towards the responding (or receiving) SEPP 512 to agree on a security mechanism to use for protecting NF service-related signaling over the N32-f interface 534 (as is described in 3GPP TS 29.573).
  • the initiating SEPP 514 issues an HTTP POST request towards the responding SEPP 512 with the request body containing the "SecNegotiateReqData" Information Element (IE).
  • IE "SecNegotiateReqData" Information Element
  • the IE carries the supported security capabilities (i.e., PRINS and/or TLS), whether the 3gpp-Sbi-Target-apiRoot HTTP header is supported (if TLS security is supported), and the sender PLMN ID(s).
  • the responding SEPP 512 responds to the initiating SEPP 514 with a "200 OK" status code and a POST response body that contains the "SecNegotiateRspData" IE.
  • the IE carries the selected security capability (i.e., PRINS or TLS), whether the 3gpp-Sbi-Target-apiRoot HTTP header is supported, and the sender PLMN ID(s).
  • the responding SEPP 512 compares the supported security capabilities of the initiating SEPP 514 to its own supported security capabilities and selects a security mechanism based on a local policy that is supported by both SEPPs. If the selected security capability indicates any other capability other than PRINS, then the HTTP/2 connection initiated between the two SEPPs for the N32 handshake procedures is terminated. If the selected security capability is PRINS, then the two SEPPs may decide to create or maintain HTTP/2 connection(s) where each SEPP acts as a client towards the other (which acts as a server). On failure, the responding SEPP 512 responds to the initiating SEPP 514 with an appropriate 4xx/5xx status code.
  • the parameter exchange procedure is executed if the security capability negotiation procedure selected the security capability as PRINS.
  • the parameter exchange procedure is performed to agree on a cipher suite to use for protecting NF service related signaling over the N32-f interface 534, and optionally exchange the protection policies to use for protecting NF service related signaling.
  • an N32-f context is established between the two SEPPs.
  • a context identifier i.e., "n32fContextId"
  • This context identifier is stored in each SEPP until the N32-f context is explicitly terminated by the N32-f context termination procedure.
  • the N32-f context indicates the PLMN ID(s) of the initiating SEPP 514 (also PLMN ID(s) of NF service consumer 524).
  • a protected message forwarding procedure i.e., Javascript Object Signing and Encryption (JOSE) Protected Message Forwarding API
  • JOSE Javascript Object Signing and Encryption
  • a protected message forwarding procedure is used for forwarding messages across the N32-f interface 534. If the negotiated security capability between the two SEPPs is PRINS as described above for the handshake procedure, one or more HTTP/2 connections between the two SEPPs for the forwarding of JOSE protected messages is established for the N32-f interface 534, which may involve IPX intermediaries/providers on the signaling path.
  • the forwarding of messages over the N32-f interface 534 involves the following steps at the initiating SEPP: (1) identification of the protection policy applicable for the API being invoked (i.e., either a request/response NF service API, a subscribe/unsubscribe service API, or a notification API), (2) message reformatting as per the identified protection policy, and (3) forwarding of the reformatted message over the N32 interface 532.
  • identification of the protection policy applicable for the API being invoked i.e., either a request/response NF service API, a subscribe/unsubscribe service API, or a notification API
  • message reformatting as per the identified protection policy
  • a SEPP on the sending side PLMN applies message reformatting when it receives an HTTP/2 request message from an NF service consumer to an NF service producer in another PLMN, when it receives an HTTP/2 response message from an NF service producer to an NF service consumer in another PLMN, when it receives an HTTP/2 notification request message from an NF service producer to an NF service consumer in another PLMN, or when it receives an HTTP/2 notification response message from an NF service consumer to an NF service producer in another PLMN.
  • the SEPP reformats the HTTP/2 message by encapsulating the whole message into the body of a new HTTP POST message.
  • the body of the HTTP POST request/response message contains the reformatted original HTTP/2 request/response message, respectively.
  • HTTP header and payload are encrypted based on the protection policy exchanged between the SEPPs.
  • FIG. 7 is a signaling diagram of message forwarding over the N32-f interface 534.
  • the initiating SEPP 514 issues an HTTP POST request towards the responding SEPP 512 with the request body containing the reformatted HTTP/2 message.
  • the request message contains the N32 context identifier provided by the responding SEPP 512 to the initiating SEPP 514 earlier during the parameter exchange procedure.
  • the responding SEPP 512 uses the N32 context identifier to locate the agreed cipher suite and protection policy, and processes the request message.
  • the responding SEPP 512 decompresses the HTTP request payload (if it is compressed), reconstructs the HTTP/2 message, and forwards the reconstructed HTTP/2 message to the NF service producer.
  • the responding SEPP 512 waits for a response from the NF service producer, and then responds to the initiating SEPP 514 with a "200 OK" status code and a POST response body that contains the response ("N32ReformattedRspMsg").
  • the response contains the reformatted HTTP response message from the responding PLMN 502.
  • the response message also contains the context identifier provided by the initiating SEPP 514 to the responding SEPP 512 earlier during the parameter exchange procedure.
  • the responding SEPP 512 responds to the initiating SEPP 514 with an appropriate 4xx/5xx status code.
  • Processing of a message received over the N32-f interface 534 at the responding SEPP 512 involves the following steps: (1) identify the N32-f context using the context identifier received in the message, (2) verify the integrity protection (also referred to as integrity verification) of the message using the keying material obtained from the TLS layer during the parameter exchange procedure for the N32-f context, (3) decrypt the ciphertext part of the message and decode the "aad" part of the message, and (4) form the original request/response body from the decrypted ciphertext and the decoded integrity verified "aad” block.
  • integrity protection also referred to as integrity verification
  • the processing further includes the following step: (5) if the reconstructed HTTP message has an "Authorization" header, then the responding SEPP 512 determines whether the PLMN ID of the NF service consumer is present in the Bearer token contained in the Authorization header, and whether the PLMN ID matches the "Remote PLMN ID" of the N32-f context. If the PLMN ID of the NF service consumer is present in the reconstructed HTTP message, then the responding SEPP 512 compares the PLMN ID of the service consumer with the PLMN ID retrieved from the N32-f context. If the PLMN IDs do not match, then the responding SEPP 512 responds to the initiating SEPP 514 with a "403 Forbidden" status code with the application specific cause set as "PLMNID_MISMATCH".
  • the SEPPs of the two PLMNs may communicate directly with one another over the N32 interface 532.
  • MNO Mobile Network Operator
  • PLMN 504 owns or controls PLMN 504 (see FIG. 5 )
  • another MNO owns or controls PLMN 502.
  • PLMN 504 is trusted to PLMN 502, and vice-versa.
  • PLMNs are trusted with a bilateral agreement
  • SEPPs are able to communicate with one another over the N32 interface 532 as discussed above (see FIG. 5 ).
  • An intermediate hub (also referred to as a roaming hub) comprises one or more network nodes or entities, servers, circuitry, logic, hardware, means, etc., implemented in a signaling path between a SEPP of one PLMN or roaming hub and a SEPP of another PLMN or roaming hub, that is configured to relay messages between the SEPPs.
  • the roaming hub is configured to support a secure interconnect between PLMNs that do not have a roaming agreement or that do not have direct N32-c connectivity.
  • the roaming hub is a commercial entity that can be contracted by a network operator to enable quick and efficient access to a wide range of roaming agreements.
  • the roaming hub has a number of roaming agreements and technical interconnections that are already fully negotiated and operational with other network operators and the contracting network operator "buys in" to these agreements (some or all of them).
  • negotiating roaming agreements with the full range of network operators in the world can take a substantial amount of time and resources, some contracting network operators use a roaming hub to get quick access to a wide roaming footprint.
  • Roaming hubs are acting on behalf of the contracting operators from the commercial and technical point of view and have financial liability for roaming agreements enabled through them.
  • the commercial agreements are not directly between the network operators, but between the roaming hub and the home and visited network operator.
  • FIG. 8 illustrates inter-PLMN communications for a roaming scenario in an illustrative embodiment.
  • An NF service producer 522 is shown in a PLMN 802 (e.g., an HPLMN 302), and an NF service consumer 524 is shown in another PLMN 804 (e.g., a VPLMN 304).
  • a SEPP 812 is implemented in PLMN 802 on the service producer side, and a SEPP 814 is implemented in PLMN 804 on the service consumer side.
  • a roaming hub (RHUB) 810 is implemented between SEPP 812 and SEPP 814 (i.e., in the signaling path between SEPP 812 and SEPP 814) to relay messages between SEPP 812 and SEPP 814.
  • Roaming hub 810 is an external entity from SEPP 812 and SEPP 814, and is outside the network domain of PLMN 802 and the network domain of PLMN 804.
  • Roaming hub 810 is illustrated at being part of PLMN 806 in this embodiment, which is an intermediate PLMN between PLMN 802 and PLMN 804.
  • roaming hub 810 may provide an interconnect service outside of a PLMN in other embodiments.
  • one roaming hub 810 is illustrated in the signaling path between SEPP 812 and SEPP 814 in FIG. 8 , more than one roaming hub 810 may be in the signaling path in other embodiments.
  • a roaming agreement 840 between the MNO of PLMN 802 and roaming hub 810 (or a provider of roaming hub 810).
  • an N32 interface 532 may be established between roaming hub 810 and SEPP 812 of PLMN 802.
  • a roaming agreement 840 between the MNO of PLMN 804 and roaming hub 810.
  • an N32 interface 532 may be established between roaming hub 810 and SEPP 814 of PLMN 804.
  • a problem may be encountered when the protected message forwarding procedure (i.e., JOSE Protected Message Forwarding API) is used for forwarding of messages across the N32-f interface 534.
  • JOSE Protected Message Forwarding API i.e., JOSE Protected Message Forwarding API
  • an initiating SEPP on the sending side PLMN receives an HTTP/2 request message from an NF service consumer to an NF service producer in another PLMN.
  • the initiating SEPP reformats the HTTP/2, and forwards the reformatted message over the N32 interface 532 to the receiving SEPP (see FIG. 7 ).
  • the responding SEPP When the responding SEPP receives the message, the responding SEPP identifies the N32-f context using the context identifier received in the message, verifies the integrity protection of the message, decrypts the ciphertext part of the message and decodes the "aad” part of the message, and forms the original request/response body from the decrypted ciphertext and the decoded integrity verified "aad” block. If the reconstructed HTTP message has an "Authorization" header, then the responding SEPP determines whether the PLMN ID of the NF service consumer is present in the Bearer token contained in the Authorization header, and whether the PLMN ID matches the "Remote PLMN ID" of the N32-f context. If the PLMN IDs do not match, then the responding SEPP responds to the initiating SEPP with a "403 Forbidden” status code with the application specific cause set as "PLMNID_MISMATCH".
  • a message may be routed from SEPP 814 to SEPP 812, for example, through roaming hub 810.
  • SEPP 814 is an initiating SEPP
  • SEPP 812 is a responding SEPP for the purpose of N32 procedures.
  • the responding SEPP does not have a PLMN ID for the initiating SEPP (e.g., SEPP 814) or service consumer.
  • the responding SEPP e.g., SEPP 812
  • the responding SEPP would not be able to verify the PLMN ID in the Bearer token of the Authorization header in the message, and would respond with a "403 Forbidden" status code with the application specific cause set as "PLMNID_MISMATCH".
  • FIG. 8 is an illustrative example, and there may be more elaborate configurations.
  • the PLMN hosting the NF service consumer may have an agreement with a first roaming hub
  • the PLMN hosting the NF service producer may have an agreement with a second roaming hub
  • the two roaming hubs may have an agreement.
  • the signaling path may contain the NF service consumer and a SEPP in the consumer PLMN, the first roaming hub, the second roaming hub, and a SEPP and NF service producer in the producer PLMN.
  • HTTP custom headers are defined for HTTP/2 protocol that are supported on the N32 interface 532.
  • An HTTP custom header as defined herein may indicate a PLMN of a sending entity (i.e., provide a PLMN ID of the sending PLMN) that is validated by the roaming hub (e.g., roaming hub 810).
  • the same or another HTTP custom header as defined herein may indicate the roaming hub (e.g., provide a roaming hub ID) that relays or forwards a message.
  • roaming hub 810 When a message is received at roaming hub 810 and needs to be relayed, roaming hub 810 is configured to add the HTTP custom header(s) to the message, and/or modify the HTTP custom header(s) if already present in the message. The roaming hub 810 is further configured to integrity protect the HTTP custom header(s), and forward the message.
  • the responding SEPP may process the HTTP custom header(s) to identify one or more PLMNs that have been validated by a roaming hub (or hubs) between the responding SEPP and the initiating SEPP.
  • the responding SEPP may compare the PLMN ID(s) contained the HTTP custom header(s) with the PLMN ID present in the Bearer token contained in the Authorization header of the message.
  • verification of the Bearer token can be successful when the PLMN ID(s) contained in the HTTP custom header(s) matches the PLMN ID contained in the Bearer token, even though the PLMN ID of the service consumer is not present in an N32-f context of the responding SEPP.
  • the information contained in the HTTP custom header(s) may be used for charging, troubleshooting, or other functions.
  • FIG. 9 is a block diagram of roaming hub 810 in an illustrative embodiment.
  • roaming hub 810 includes the following subsystems: a network interface component 902, and a message forwarding controller 904.
  • Network interface component 902 is a hardware component that exchanges messages, signaling, or packets with other elements, such as a SEPP and/or other systems.
  • network interface component 902 may be configured to communicate over the N32 interface.
  • Message forwarding controller 904 comprises circuitry, logic, hardware, means, etc., configured to relay or forward a message 950 received from a sending entity, to a receiving entity.
  • message forwarding controller 904 is configured to relay a message from a SEPP of one PLMN to a SEPP of another PLMN.
  • message forwarding controller 904 is configured to add or modify one or more HTTP custom headers (e.g., headers 952 and 954) of the message 950.
  • One or more of the subsystems of roaming hub 810 may be implemented on a hardware platform comprised of analog and/or digital circuitry.
  • One or more of the subsystems of roaming hub 810 may be implemented on a processor 930 that executes instructions 934 stored in memory 932.
  • Processor 930 comprises an integrated hardware circuit configured to execute instructions 934, and memory 932 is a non-transitory computer readable storage medium for data, instructions 934, applications, etc., and is accessible by processor 930.
  • roaming hub 810 may comprise or include a SEPP 910 as illustrated in FIG. 9 .
  • Roaming hub 810 may include various other components or sub-systems not specifically illustrated in FIG. 9 .
  • FIG. 10 is a flow chart illustrating a method 1000 of message forwarding in inter-PLMN communications in an illustrative embodiment.
  • the steps of method 1000 will be described with reference to roaming hub 810 in FIG. 9 , but those skilled in the art will appreciate that method 1000 may be performed in other intermediate hubs or systems.
  • the steps of the flow charts described herein are not all inclusive and may include other steps not shown, and the steps may be performed in an alternative order.
  • an NF service consumer 524 in PLMN 804 discovers an NF service producer 522 in PLMN 802, and initiates a message toward NF service producer 522.
  • the message may comprise a service request message, a notification request message, etc.
  • N32-f contexts are established between SEPP 814 and roaming hub 810, and between roaming hub 810 and SEPP 812.
  • SEPP 814 receives the message initiated by NF service consumer 524, and forwards the message to roaming hub 810 over the N32 interface 532.
  • Roaming hub 810 receives the message 950 from a sending entity across the N32 interface 532 (step 1002). It is assumed that a roaming agreement exists between roaming hub 810 and the sending entity so that an N32-f context may be established between roaming hub 810 and the sending entity.
  • the sending entity comprises SEPP 814, which is considered an initiating or sending SEPP.
  • roaming hub 810 may receive the message 950 from another roaming hub in other examples, which is relaying the message 950 between an initiating SEPP and a responding SEPP.
  • Roaming hub 810 determines whether the message 950 includes an HTTP custom header that indicates a PLMN (or multiple PLMNs) that is validated (step 1004).
  • the HTTP custom header may be referred to as a "validated PLMN" custom header, "ValidatedPLMNIDlist” custom header, or the like.
  • HTTP/2 includes HTTP standard headers that are supported on the N32 interface 532, such as defined in 3GPP TS 29.573. HTTP/2 also allows for HTTP custom headers that are supported on the N32 interface 532 (e.g., defined for the JOSE protected message forwarding API on the N32 interface). As described above, one or more HTTP custom headers are defined herein for a message forwarding procedure on the N32 interface 532.
  • a validated PLMN custom header 952 as defined herein indicates one or more PLMNs that are validated between a SEPP 814 on the NF service consumer side and a SEPP 812 on the NF service producer side.
  • the validated PLMN custom header 952 may provide a list of PLMN IDs for one or more PLMNs that are validated in the signaling path between the initiating SEPP 814 and the responding SEPP 812.
  • roaming hub 810 adds or appends a validated PLMN custom header 952 to the message 950 that indicates the PLMN of the sending entity (step 1008) (i.e., the PLMN from which the roaming hub 810 received the message 950).
  • PLMN 804 is trusted to roaming hub 810.
  • roaming hub 810 is able to add the validated PLMN custom header 952 to the message 950 that indicates PLMN 804.
  • Roaming hub 810 also integrity protects the validated PLMN custom header 952 (step 1010).
  • roaming hub 810 signs or applies a signature to the validated PLMN custom header 952 to add or apply integrity protection.
  • Roaming hub 810 may integrity protect the validated PLMN custom header 952 using an integrity algorithm and associated integrity keys (public and/or private keys) that are exchanged during negotiation and parameter exchange over the N32-c interface 533.
  • Roaming hub 810 forwards the message 950 toward a receiving entity (step 1012). It is assumed that a roaming agreement exists between roaming hub 810 and the receiving entity so that an N32-f context may be established between roaming hub 810 and the receiving entity.
  • the receiving entity may comprise SEPP 812, which is considered a responding or receiving SEPP.
  • roaming hub 810 may forward the message 950 to another roaming hub or intermediate proxy in other examples.
  • roaming hub 810 performs integrity verification on the validated PLMN custom header 952 to validate content of the validated PLMN custom header 952 (step 1014). For example, roaming hub 810 may use an integrity algorithm and associated integrity keys (public and/or private keys) that are exchanged with the sending entity during negotiation and parameter exchange over the N32-c interface 533, to verify the integrity of the validated PLMN custom header 952. Roaming hub 810 integrity protects the validated PLMN custom header 952 in the message 950 (step 1018). In other words, roaming hub 810 signs or applies a signature to the validated PLMN custom header 952 to add or apply integrity protection. Roaming hub 810 forwards the message 950 toward the receiving entity (step 1020).
  • an integrity algorithm and associated integrity keys public and/or private keys
  • another HTTP custom header defined for a message forwarding procedure on the N32 interface 532 may indicate one or more roaming hubs that relayed or forwarded the message.
  • this HTTP custom header may provide a list of roaming hubs that relayed the message along the signaling path between the initiating SEPP 814 and the responding SEPP 812.
  • FIG. 11 is a flow chart illustrating another method 1100 of message forwarding in an illustrative embodiment.
  • the steps of method 1100 may be performed in addition to the steps of method 1000, or may be performed separately.
  • roaming hub 810 (through network interface component 902) receives the message 950 from the sending entity across the N32 interface 532 (step 1002).
  • roaming hub 810 determines whether the message 950 includes an HTTP custom header that indicates one or more roaming hubs (or intermediate SEPPs) that relayed the message (step 1104).
  • the HTTP custom header may be referred to as a "Roaming-hub-ID" custom header, "RHUB-ID” custom header, or the like.
  • roaming hub 810 When the message as received does not include a Roaming-hub-ID custom header 954, roaming hub 810 adds or appends a Roaming-hub-ID custom header 954 to the message 950 that indicates a roaming hub ID of roaming hub 810 (step 1106).
  • the roaming hub ID may comprise one or more of a PLMN ID of the PLMN where roaming hub 810 is implemented, a Fully Qualified Domain Name (FQDN) identifier for roaming hub 810, an Internet Protocol (IP) address for roaming hub 810, and an instance ID for roaming hub 810.
  • FQDN Fully Qualified Domain Name
  • IP Internet Protocol
  • Roaming hub 810 also integrity protects the Roaming-hub-ID custom header 954 (step 1108). In other words, roaming hub 810 signs or applies a signature to the Roaming-hub-ID custom header 954 to add or apply integrity protection.
  • Roaming hub 810 may integrity protect the Roaming-hub-ID custom header 954 in the same process as integrity protecting the validated PLMN custom header(s) 952 (see step 1010 or step 1018 of FIG. 10 ). In other words, roaming hub 810 may sign the validated PLMN custom header 952 and the Roaming-hub-ID custom header 954 with an indication (e.g., roaming hub ID) of roaming hub 810. Roaming hub 810 forwards the message 950 toward a receiving entity (step 1012).
  • roaming hub 810 performs integrity verification on the Roaming-hub-ID custom header 954 to validate the content of the Roaming-hub-ID custom header 954 (step 1110).
  • roaming hub 810 may use an integrity algorithm and associated integrity keys (public and/or private keys) that are exchanged with the sending entity during negotiation and parameter exchange over the N32-c interface 533, to verify the integrity of the Roaming-hub-ID custom header 954.
  • Roaming hub 810 adds its roaming hub ID to an instance of the Roaming-hub-ID custom header 954 (step 1112).
  • the Roaming-hub-ID custom header 954 may be defined to indicate a list of multiple roaming hub IDs.
  • the message 950 may include a single occurrence of the Roaming-hub-ID custom header 954.
  • roaming hub 810 may modify the present instance of the Roaming-hub-ID custom header 954 as received in the message 950 to indicate its roaming hub ID in the list (optional step 1130).
  • the Roaming-hub-ID custom header 954 may be defined to indicate a roaming hub ID of a single roaming hub.
  • the message 950 may include multiple instances of the Roaming-hub-ID custom header 954, depending on how many intermediate proxies are in the signaling path.
  • roaming hub 810 may add or append another instance of the Roaming-hub-ID custom header 954 to the message 950 that indicates its roaming hub ID (optional step 1132).
  • Roaming hub 810 integrity protects the Roaming-hub-ID custom header 954 or headers in the message 950 (step 1114).
  • Roaming hub 810 may integrity protect the Roaming-hub-ID custom header(s) 954 in the same process as integrity protecting the validated PLMN custom header(s) 952 (see step 1010 or step 1018 of FIG. 10 ).
  • Roaming hub 810 forwards the message 950 toward the receiving entity (step 1020).
  • the validated PLMN custom header 952 and the Roaming-hub-ID custom header 954 may be combined into a single header.
  • the message 950 will be received at the responding SEPP 812.
  • Responding SEPP 812 is then able to process the HTTP custom headers in the message 950.
  • FIG. 12 is a block diagram of a SEPP 812 in an illustrative embodiment.
  • SEPP 812 includes the following subsystems: a network interface component 1202, and a controller 1204.
  • Network interface component 1202 is a hardware component that exchanges messages, signaling, or packets with other elements.
  • Network interface component 1202 may be configured to communicate over the N32 interface.
  • Controller 1204 comprises circuitry, logic, hardware, means, etc., configured to act as a service relay between PLMNs for providing a secured connection.
  • One or more of the subsystems of SEPP 812 may be implemented on a hardware platform comprised of analog and/or digital circuitry.
  • One or more of the subsystems of SEPP 812 may be implemented on a processor 1230 that executes instructions 1234 stored in memory 1232.
  • Processor 1230 comprises an integrated hardware circuit configured to execute instructions 1234, and memory 1232 is a non-transitory computer readable storage medium for data, instructions 1234, applications, etc., and is accessible by processor 1230.
  • SEPP 812 may include various other components or sub-systems not specifically illustrated in FIG. 12 .
  • FIG. 13 is a flow chart illustrating another method 1300 of message forwarding in inter-PLMN communications in an illustrative embodiment. The steps of method 1300 will be described with reference to SEPP 812 in FIG. 12 , but those skilled in the art will appreciate that method 1300 may be performed in other systems.
  • SEPP 812 (through network interface component 1202) receives a message 950 from a sending entity across the N32 interface (step 1302). It is assumed that a roaming agreement exists between SEPP 812 and the sending entity so that an N32-f context may be established between SEPP 812 and the sending entity.
  • the sending entity comprises roaming hub 810.
  • SEPP 812 may receive the message 950 from another SEPP in other examples.
  • SEPP 812 determines whether the message 950 includes a validated PLMN custom header 952 (step 1304).
  • the validated PLMN custom header 952 as defined herein indicates one or more PLMNs that are validated between a SEPP 814 on the NF service consumer side and a SEPP 812 on the NF service producer side.
  • the validated PLMN custom header 952 may provide a list of PLMN IDs for one or more PLMNs that are validated in the signaling path between the initiating SEPP 814 and the responding SEPP 812.
  • SEPP 812 validates a PLMN of the service consumer based on a token contained in an HTTP standard header 956 of the message 950 and a PLMN ID of the N32-f context (step 1306). If the PLMN IDs match, SEPP 812 determines that the service consumer is validated. If the the PLMN IDs do not match, then access token validation fails and a corresponding error will be reported.
  • SEPP 812 validates a PLMN of the service consumer based on a token contained in an HTTP standard header 956 of the message 950 and a PLMN ID contained in the validated PLMN custom header 952 (step 1308). If the PLMN IDs match, SEPP 812 determines that the service consumer is validated. If the PLMN IDs do not match, then access token validation fails and a corresponding error will be reported
  • FIG. 14 is a flow chart illustrating another method 1400 of message forwarding in an illustrative embodiment.
  • the steps of method 1400 may be performed in addition to the steps of method 1300, or may be performed separately.
  • SEPP 812 (through network interface component 1202) receives message 950 from the sending entity across the N32 interface (step 1302).
  • SEPP 812 determines whether the message 950 includes one or more Roaming-hub-ID custom headers 954 (step 1404).
  • the Roaming-hub-ID custom header 954 indicates one or more roaming hubs that relayed the message.
  • SEPP 812 may perform other message processing (step 1406) that is beyond the scope of this description.
  • SEPP 812 may extract the roaming hub ID(s) from the Roaming-hub-ID custom header(s) 954, and forward the roaming hub ID(s) to another entity in the local PLMN, such as the NF service producer 522 supporting the service requested by the message 950 or a further intermediate entity (step 1408).
  • SEPP 812 may forward or report the roaming hub ID(s) to a Charging Function (CHF) (optional step 1410).
  • CHF Charging Function
  • SEPP 812 may forward or report the roaming hub ID(s) to a tracing function of the 5GC (optional step 1412).
  • this information carried in the Roaming-hub-ID custom header(s) 954 may assist with troubleshooting in the network, such as for invoking a trace action.
  • FIG. 15 is a signaling diagram illustrating message forwarding in an illustrative embodiment.
  • an NF service consumer 524 and a SEPP 814 are shown in PLMN A
  • an NF service producer 522 and a SEPP 812 are shown in PLMN D.
  • Multiple roaming hubs 810-1 and 810-2 are implemented in the signaling path 1502 between SEPP 814 and SEPP 812.
  • Roaming hub 810-1 is shown in PLMN B
  • roaming hub 810-2 is shown in PLMN C.
  • There is a roaming agreement between PLMN A and PLMN B There is a roaming agreement between PLMN A and PLMN B, a roaming agreement between PLMN B and PLMN C, and a roaming agreement between PLMN C and PLMN D.
  • NF service consumer 524 in PLMN A initiates a service request message toward NF service producer 522 in PLMN D.
  • SEPP 814 receives the service request message initiated by NF service consumer 524, and forwards the service request message to roaming hub 810-1 (over the N32 interface 532).
  • Roaming hub 810-1 determines whether the service request message includes a validated PLMN custom header 952. In this example, the service request message does not include a validated PLMN custom header 952, so roaming hub 810-1 adds a validated PLMN custom header 952 to the service request message that indicates the PLMN ID of PLMN A.
  • roaming hub 810-1 Due to the roaming agreement between PLMN A and PLMN B, roaming hub 810-1 knows that PLMN A is a trusted entity. Thus, roaming hub 810-1 adds the validated PLMN custom header 952 to the service request message that indicates the PLMN ID of validated PLMN A. Roaming hub 810-1 then integrity protects the validated PLMN custom header 952.
  • roaming hub 810-1 also determines whether the service request message includes a Roaming-hub-ID custom header 954. In this example, the service request message does not include a Roaming-hub-ID custom header 954, so roaming hub 810-1 adds or appends a Roaming-hub-ID custom header 954 to the service request message that indicates the roaming hub ID of roaming hub 810-1.
  • Roaming hub 810-1 also integrity protects the Roaming-hub-ID custom header 954.
  • Roaming hub 810-1 may integrity protect the Roaming-hub-ID custom header 954 in the same process as integrity protecting the validated PLMN custom headers 952. Roaming hub 810-1 then forwards the service request message to roaming hub 810-2.
  • Roaming hub 810-2 receives the service request message, and determines whether the service request message includes a validated PLMN custom header 952.
  • the service request message includes a validated PLMN custom header 952, so roaming hub 810-2 performs integrity verification on the validated PLMN custom header 952 to verify the content of the validated PLMN custom header 952 (i.e., PLMN ID for PLMN A that is considered a validated PLMN).
  • roaming hub 810-2 also determines whether the service request message includes a Roaming-hub-ID custom header 954.
  • the service request message includes a Roaming-hub-ID custom header 954, so roaming hub 810-2 performs integrity verification on the Roaming-hub-ID custom header 954 to validate the content of the Roaming-hub-ID custom header 954.
  • Roaming hub 810-2 adds another instance of the Roaming-hub-ID custom header 954 to the service request message that indicates its roaming hub ID.
  • Roaming hub 810-2 also integrity protects the validated PLMN custom header 952 and the Roaming-hub-ID custom header 954. Roaming hub 810-2 then forwards the service request message to SEPP 812.
  • SEPP 812 receives the service request message, and determines whether the service request message includes a validated PLMN custom header 952.
  • SEPP 812 validates the PLMN of NF service consumer 524 based on a token contained in an HTTP standard header 956 of the service request message and a PLMN ID contained in the validated PLMN custom header 952.
  • the validated PLMN custom header 952 indicates PLMN A.
  • SEPP 812 determines whether the PLMN ID in the Bearer token contained in the Authorization header of the service request message matches the PLMN ID of PLMN A contained in the validated PLMN custom header 952. In this case, the PLMN IDs will match, and SEPP 812 is able to validate the access token in the service request message.
  • SEPP 812 may also determine whether the service request message includes one or more Roaming-hub-ID custom headers 954. When the service request message includes Roaming-hub-ID custom headers 954 as in this example, SEPP 812 extracts the roaming hub IDs from the Roaming-hub-ID custom headers 954. This data indicates the routing of the service request message over the signaling path 1502. SEPP 812 may forward the roaming hub IDs to NF service producer 522, to a charging function (CHF) 1510 of the 5GC, to a tracing function (TF) 1512 of the 5GC, and/or otherwise use this data. Alternatively, NF service producer 522 may forward the roaming hub IDs to the charging function 1510 and/or the tracing function 1512, and/or otherwise use this data.
  • CHF charging function
  • TF tracing function
  • any of the various elements or modules shown in the figures or described herein may be implemented as hardware, software, firmware, or some combination of these.
  • an element may be implemented as dedicated hardware.
  • Dedicated hardware elements may be referred to as "processors", “controllers”, or some similar terminology.
  • processors When provided by a processor, the functions may be provided by a single dedicated processor, by a single shared processor, or by a plurality of individual processors, some of which may be shared.
  • processor or “controller” should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, a network processor, application specific integrated circuit (ASIC) or other circuitry, field programmable gate array (FPGA), read only memory (ROM) for storing software, random access memory (RAM), non-volatile storage, logic, or some other physical hardware component or module.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • ROM read only memory
  • RAM random access memory
  • non-volatile storage logic, or some other physical hardware component or module.
  • an element may be implemented as instructions executable by a processor or a computer to perform the functions of the element.
  • Some examples of instructions are software, program code, and firmware.
  • the instructions are operational when executed by the processor to direct the processor to perform the functions of the element.
  • the instructions may be stored on storage devices that are readable by the processor. Some examples of the storage devices are digital or solid-state memories, magnetic storage media such as a magnetic disks and magnetic tapes, hard drives, or optically readable digital data storage media.
  • circuitry may refer to one or more or all of the following:
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)

Claims (15)

  1. Verfahren zur Nachrichtenweiterleitung, wobei das Verfahren Folgendes umfasst:
    Empfangen einer Nachricht von einer Sendeentität (814) in einem ersten öffentlichen terrestrischen Mobilfunknetzwerk (804) an einem Roaminghub (810) in einem zwischengeschalteten PLMN (806) über eine N32-Schnittstelle (532) und
    Bestimmen am Roaminghub, ob die Nachricht einen ersten benutzerdefinierten Hypertexttransferprotokoll(HTTP)-Header beinhaltet, der ein PLMN anzeigt, das validiert ist;
    wenn die empfangene Nachricht den ersten benutzerdefinierten HTTP-Header nicht beinhaltet, umfasst das Verfahren ferner Folgendes:
    Hinzufügen eines ersten benutzerdefinierten HTTP-Headers zur Nachricht, der das PLMN (804) der Sendeentität (814) anzeigt;
    Schützen der Integrität des ersten benutzerdefinierten HTTP-Headers und
    Weiterleiten der Nachricht vom Roaminghub (810) im zwischengeschalteten PLMN (806) zu einer Empfangsentität (812) in einem zweiten PLMN (802).
  2. Verfahren nach Anspruch 1, wobei:
    wenn die empfangene Nachricht den ersten benutzerdefinierten HTTP-Header beinhaltet, das Verfahren ferner Folgendes umfasst:
    Durchführen einer Integritätsverifizierung am ersten benutzerdefinierten HTTP-Header, um einen Inhalt des ersten benutzerdefinierten HTTP-Header zu validieren;
    Schützen der Integrität des ersten benutzerdefinierten HTTP-Headers und
    Weiterleiten der Nachricht vom Roaminghub (810) im zwischengeschalteten PLMN (806) zur Empfangsentität (812) in einem zweiten PLMN (802).
  3. Verfahren nach Anspruch 2, wobei:
    der erste benutzerdefinierte HTTP-Header definiert ist, um eine PLMN-Kennung eines Dienstverbrauchers (524) der validierten Nachricht anzuzeigen.
  4. Verfahren nach Anspruch 2, das ferner Folgendes umfasst:
    Empfangen der Nachricht vom Roaminghub (810) an einem Security Edge Protection Proxy, SEPP, (812) über eine N32-Schnittstelle (532) und
    Bestimmen, ob die Nachricht den ersten benutzerdefinierten HTTP-Header beinhaltet;
    wenn die am SEPP empfangene Nachricht den ersten benutzerdefinierten HTTP-Header beinhaltet, umfasst das Verfahren ferner Folgendes:
    Validieren eines PLMN (804) eines Dienstverbrauchers (524) mindestens auf Basis eines Tokens, das in einem HTTP-Standardheader der Nachricht enthalten ist, und einer PLMN-Kennung, die im ersten benutzerdefinierten HTTP-Header enthalten ist.
  5. Verfahren nach Anspruch 1, das ferner Folgendes umfasst:
    Bestimmen am Roaminghub (810), ob die Nachricht einen zweiten benutzerdefinierten HTTP-Header beinhaltet, der einen oder mehrere Roaminghubs anzeigt, die die Nachricht weitergeleitet haben;
    wenn die empfangene Nachricht den zweiten benutzerdefinierten HTTP-Header nicht beinhaltet, umfasst das Verfahren ferner Folgendes:
    Hinzufügen des zweiten benutzerdefinierten HTTP-Headers zur Nachricht, der eine Roaminghubkennung des Roaminghubs anzeigt; und
    Schützen der Integrität des zweiten benutzerdefinierten HTTP-Headers.
  6. Verfahren nach Anspruch 5, wobei:
    wenn die empfangene Nachricht den zweiten benutzerdefinierten HTTP-Header beinhaltet, umfasst das Verfahren ferner Folgendes:
    Durchführen einer Integritätsverifizierung am zweiten benutzerdefinierten HTTP-Header, um einen Inhalt des zweiten benutzerdefinierten HTTP-Headers zu validieren;
    Hinzufügen der Roaminghubkennung zu einer Instanz des zweiten benutzerdefinierten HTTP-Headers und
    Schützen der Integrität des zweiten benutzerdefinierten HTTP-Headers oder der zweiten benutzerdefinierten HTTP-Header.
  7. Verfahren nach Anspruch 6, wobei:
    der zweite benutzerdefinierte HTTP-Header definiert ist, um eine Liste von Roaminghubkennungen anzuzeigen; und
    das Hinzufügen der Roaminghubkennung zu einer Instanz des zweiten benutzerdefinierten HTTP-Headers Folgendes umfasst:
    Modifizieren einer gegenwärtigen Instanz des zweiten benutzerdefinierten HTTP-Headers, der in der Nachricht empfangen wurde, um die Roaminghubkennung in der Liste anzuzeigen.
  8. Verfahren nach Anspruch 6, wobei:
    der zweite benutzerdefinierte HTTP-Header definiert ist, um eine Kennung eines einzelnen Roaminghubs (810) anzuzeigen; und
    das Hinzufügen der Roaminghubkennung zu einer Instanz des zweiten benutzerdefinierten HTTP-Headers Folgendes umfasst:
    Hinzufügen einer weiteren Instanz des zweiten benutzerdefinierten HTTP-Headers zur Nachricht, der die Roaminghubkennung anzeigt.
  9. Einrichtung (810), die Folgendes umfasst:
    mindestens einen Prozessor (930) und
    mindestens einen Speicher (932), der Computerprogrammcode (934) beinhaltet, wobei der mindestens eine Speicher und der Computerprogrammcode dazu ausgelegt sind, die Einrichtung mit dem mindestens einen Prozessor mindestens zu Folgendem zu veranlassen:
    Empfangen einer Nachricht von einer Sendeentität (814) in einem ersten öffentlichen terrestrischen Mobilfunknetzwerk (804) an einer Einrichtung (810), die sich in einem zwischengeschalteten PLMN (806) befindet, über eine N32-Schnittstelle (532) und
    Bestimmen, ob die Nachricht einen ersten benutzerdefinierten Hypertexttransferprotokoll(HTTP)-Header beinhaltet, der ein öffentliches terrestrisches Mobilfunknetzwerk, PLMN, anzeigt, das validiert ist;
    wenn die empfangene Nachricht den ersten benutzerdefinierten HTTP-Header nicht beinhaltet, ist der Computerprogrammcode dazu ausgelegt, die Einrichtung mit dem mindestens einen Prozessor ferner zu Folgendem zu veranlassen:
    Hinzufügen des ersten benutzerdefinierten HTTP-Headers zur Nachricht, der das PLMN (804) der Sendeentität (814) im ersten PLMN (804) anzeigt;
    Schützen der Integrität des ersten benutzerdefinierten HTTP-Headers und
    Weiterleiten der Nachricht von der Einrichtung (810), die sich in einem zwischengeschalteten PLMN (806) befindet, zu einer Empfangsentität (812) in einem zweiten PLMN (802).
  10. Vorrichtung (810) nach Anspruch 9, wobei:
    wenn die empfangene Nachricht den ersten benutzerdefinierten HTTP-Header beinhaltet, der Computerprogrammcode (934) dazu ausgelegt ist, die Einrichtung mit dem mindestens einen Prozessor (930) ferner zu Folgendem zu veranlassen:
    Durchführen einer Integritätsverifizierung am ersten benutzerdefinierten HTTP-Header, um einen Inhalt des ersten benutzerdefinierten HTTP-Headers zu validieren;
    Schützen der Integrität des ersten benutzerdefinierten HTTP-Headers und
    Weiterleiten der Nachricht von der Einrichtung (810), die sich in einem zwischengeschalteten PLMN (806) befindet, zur Empfangsentität (812) in einem zweiten PLMN (802).
  11. Einrichtung (810) nach Anspruch 9, wobei:
    der Computerprogrammcode (934) dazu ausgelegt ist, die Einrichtung mit dem mindestens einen Prozessor (930) ferner zu Folgendem zu veranlassen:
    Bestimmen, ob die Nachricht einen zweiten benutzerdefinierten HTTP-Header beinhaltet, der einen oder mehrere Roaminghubs (810) anzeigt, die die Nachricht weitergeleitet haben;
    wenn die empfangene Nachricht den zweiten benutzerdefinierten HTTP-Header nicht beinhaltet, der Computerprogrammcode dazu ausgelegt ist, die Einrichtung mit dem mindestens einen Prozessor ferner mindestens zu Folgendem zu veranlassen:
    Hinzufügen des zweiten benutzerdefinierten HTTP-Headers zur Nachricht, der eine Roaminghubkennung der Einrichtung anzeigt; und
    Schützen der Integrität des zweiten benutzerdefinierten HTTP-Headers.
  12. Einrichtung (810) nach Anspruch 11, wobei:
    wenn die empfangene Nachricht den zweiten benutzerdefinierten HTTP-Header beinhaltet, der Computerprogrammcode (934) dazu ausgelegt ist, die Einrichtung mit dem mindestens einen Prozessor (930) ferner zu Folgendem zu veranlassen:
    Durchführen einer Integritätsverifizierung am zweiten benutzerdefinierten HTTP-Header, um einen Inhalt des zweiten benutzerdefinierten HTTP-Headers zu validieren;
    Hinzufügen der Roaminghubkennung zu einer Instanz des zweiten benutzerdefinierten HTTP-Headers und
    Schützen der Integrität des zweiten benutzerdefinierten HTTP-Headers oder der zweiten benutzerdefinierten HTTP-Header.
  13. Einrichtung (810) nach Anspruch 12, wobei:
    der zweite benutzerdefinierte HTTP-Header definiert ist, um eine Liste von Roaminghubkennungen anzuzeigen; und
    die Roaminghubkennung zu einer Instanz des zweiten benutzerdefinierten HTTP-Headers hinzuzufügen, der Computerprogrammcode (934) ist dazu ausgelegt, die Einrichtung mit dem mindestens einen Prozessor (930) ferner mindestens zu Folgendem zu veranlassen:
    Modifizieren einer gegenwärtigen Instanz des zweiten benutzerdefinierten HTTP-Headers, der in der Nachricht empfangen wurde, um die Roaminghubkennung in der Liste anzuzeigen.
  14. Einrichtung (810) nach Anspruch 12, wobei:
    der zweite benutzerdefinierte HTTP-Header definiert ist, um eine Kennung eines einzelnen Roaminghubs anzuzeigen; und
    die Roaminghubkennung zu einer Instanz des zweiten benutzerdefinierten HTTP-Headers hinzuzufügen, der Computerprogrammcode ist dazu ausgelegt, die Einrichtung mit dem mindestens einen Prozessor ferner mindestens zu Folgendem zu veranlassen:
    Hinzufügen einer weiteren Instanz des zweiten benutzerdefinierten HTTP-Headers zur Nachricht, der die Roaminghubkennung anzeigt.
  15. Computerlesbares Medium, das darauf gespeicherte Anweisungen umfasst, die, wenn sie von einem Roaminghub (810) in einem zwischengeschalteten öffentlichen terrestrischen Mobilfunknetzwerk, PLMN, (806) ausgeführt werden, den Roaminghub veranlassen, mindestens Folgendes durchzuführen:
    Empfangen einer Nachricht von einer Sendeentität (814) in einem ersten PLMN (804) über eine N32-Schnittstelle (532) und
    Bestimmen, ob die Nachricht einen ersten benutzerdefinierten Hypertexttransferprotokoll(HTTP)-Header beinhaltet, der ein öffentliches terrestrisches Mobilfunknetzwerk, PLMN, anzeigt, das validiert ist;
    wenn die empfangene Nachricht nicht im ersten benutzerdefinierten HTTP-Header beinhaltet ist, den Roaminghub ferner veranlassen, mindestens Folgendes durchzuführen:
    Hinzufügen eines ersten benutzerdefinierten HTTP-Headers zur Nachricht, der das PLMN (804) der Sendeentität (814) anzeigt;
    Schützen der Integrität des ersten benutzerdefinierten HTTP-Headers und
    Weiterleiten der Nachricht vom Roaminghub (810) im zwischengeschalteten PLMN (806) zu einer Empfangsentität (812) in einem zweiten PLMN (802).
EP22196005.7A 2021-09-17 2022-09-16 Roaming-hub zur sicheren verbindung in roaming-szenarien Active EP4152691B1 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US17/477,735 US11533358B1 (en) 2021-09-17 2021-09-17 Roaming hub for secure interconnect in roaming scenarios

Publications (2)

Publication Number Publication Date
EP4152691A1 EP4152691A1 (de) 2023-03-22
EP4152691B1 true EP4152691B1 (de) 2025-10-15

Family

ID=83360947

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22196005.7A Active EP4152691B1 (de) 2021-09-17 2022-09-16 Roaming-hub zur sicheren verbindung in roaming-szenarien

Country Status (3)

Country Link
US (1) US11533358B1 (de)
EP (1) EP4152691B1 (de)
ES (1) ES3053876T3 (de)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12501252B2 (en) * 2022-03-01 2025-12-16 Mavenir Networks, Inc. Roaming hub 5G interconnect for public line mobile networks
US12348955B2 (en) * 2022-11-15 2025-07-01 Oracle International Corporation Methods, systems, and computer readable media for securing sensitive data to be transmitted in 5G and subsequent generation networks
US12355818B2 (en) * 2023-01-19 2025-07-08 Oracle International Corporation Methods, systems, and computer readable media for improving inter-public land mobile network (PLMN) routing across security edge protection proxies (SEPPs) by implementing health checks for remote SEPPs
CN119562303A (zh) * 2023-09-04 2025-03-04 华为技术有限公司 通信方法及相关装置
US12531894B2 (en) 2023-11-29 2026-01-20 Oracle International Corporation Methods, systems, and computer readable media for detecting and mitigating security attacks on producer network functions (NFs) using access token to non-access-token parameter correlation at proxy nf
US12425863B2 (en) 2023-11-29 2025-09-23 Oracle International Corporation Methods, systems, and computer readable media for detecting and mitigating security attacks on producer network functions (NFs) using error response messages
US20250234187A1 (en) * 2024-01-16 2025-07-17 Oracle International Corporation Methods, systems, and computer readable media for detecting and processing inter-public land mobile network (plmn) service-based interface (sbi) messages without 3gpp-sbi-originating-network-id headers
WO2026022397A1 (en) * 2024-07-26 2026-01-29 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for plmn/snpn verification

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4589871B2 (ja) * 2003-09-19 2010-12-01 ソフトバンクモバイル株式会社 国際ローミング対応型移動通信ネットワーク利用システム
JP7050937B2 (ja) * 2018-02-16 2022-04-08 テレフオンアクチーボラゲット エルエム エリクソン（パブル） コアネットワークドメイン間で伝送されるメッセージの保護
US10834571B1 (en) * 2019-08-02 2020-11-10 Syniverse Technologies, Llc Steering of roaming for 5G core roaming in an internet packet exchange network
US11832172B2 (en) * 2020-09-25 2023-11-28 Oracle International Corporation Methods, systems, and computer readable media for mitigating spoofing attacks on security edge protection proxy (SEPP) inter-public land mobile network (inter-PLMN) forwarding interface

Also Published As

Publication number Publication date
EP4152691A1 (de) 2023-03-22
ES3053876T3 (en) 2026-01-27
US11533358B1 (en) 2022-12-20

Similar Documents

Publication Publication Date Title
EP4152691B1 (de) Roaming-hub zur sicheren verbindung in roaming-szenarien
EP3753227B1 (de) Sicherheitsverwaltung in kommunikationssystemen mit sicherheitsbasierter architektur unter verwendung von anwendungsschichtsicherheit
CN113748699B (zh) 用于通信系统中的间接通信的服务授权
US10834571B1 (en) Steering of roaming for 5G core roaming in an internet packet exchange network
EP3847782B1 (de) Automatisierte roamingdienstgütevereinbarungen zwischen netzbetreibern über sicherheits-edge-schutz-proxies in einer kommunikationssystemumgebung
JP7495396B2 (ja) Ｎａｓメッセージのセキュリティ保護のためのシステム及び方法
US12425857B2 (en) Security management between edge proxy and internetwork exchange node in a communication system
EP3528456B1 (de) Sicherheitsverwaltung in kommunikationssystemen mit netzwerkfunktionsassistiertem mechanismus zur sicherung von informationselementen
CN113574829B (zh) 与第三方应用共享通信网络锚定加密密钥
WO2019158817A1 (en) Security management in communication systems with provisioning based mechanism to identify information elements
CN111742529B (zh) 基于服务的架构(sba)中的安全协商
WO2021094349A1 (en) Multi-step service authorization for indirect communication in a communication system
US20260040063A1 (en) Distributed Network Edge Security Architecture
US12192208B2 (en) Apparatus, method, and computer program of protecting communications between networks using predefined security profiles
EP3821562A1 (de) Sicherheitsverwaltung für unautorisierte anfragen in einem kommunikationssystem mit dienstbasierter architektur
US20250031036A1 (en) Protection of application metadata in transport protocol
EP4274283A1 (de) Durch ein heimnetzwerk ausgelöste neuauthentifizierung eines benutzergeräts
US20260006440A1 (en) Establishing a non-access stratum communication link between a user equipment and one of a plurality of network functions or services of a telecommunications network
WO2025168418A1 (en) Method, apparatus and computer program
WO2024033782A1 (en) Sepp support of disaster roaming
CN119562303A (zh) 通信方法及相关装置
WO2025158368A1 (en) Partial user plane protection in mobile networks
WO2025229236A1 (en) Apparatuses and methods for secure communication in a wireless communications system
CN107770067A (zh) 消息发送方法和装置

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20230907

RBV Designated contracting states (corrected)

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20250514

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Ref country code: CH

Ref legal event code: F10

Free format text: ST27 STATUS EVENT CODE: U-0-0-F10-F00 (AS PROVIDED BY THE NATIONAL OFFICE)

Effective date: 20251015

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602022022967

Country of ref document: DE

P01 Opt-out of the competence of the unified patent court (upc) registered

Free format text: CASE NUMBER: UPC_APP_0013294_4152691/2025

Effective date: 20251113

REG Reference to a national code

Ref country code: ES

Ref legal event code: FG2A

Ref document number: 3053876

Country of ref document: ES

Kind code of ref document: T3

Effective date: 20260127