WO2020260750A1

WO2020260750A1 - Apparatus, method and computer program

Info

Publication number: WO2020260750A1
Application number: PCT/FI2020/050281
Authority: WO
Inventors: Nagendra S BYKAMPADI; Jani Ekman; Silke Holtmanns
Original assignee: Nokia Technologies Oy
Priority date: 2019-06-24
Filing date: 2020-04-29
Publication date: 2020-12-30

Abstract

An apparatus comprising means for performing: receiving, while connected to a first network, capability information of a second network, the capability information 5 comprising an indication of at least one service related feature supported by the second network.

Description

APPARATUS. METHOD AND COMPUTER PROGRAM

Field

This disclosure relates to communications networks. More particularly, some examples of the present disclosure relates to an apparatus, method and computer program for translating requests and responses from one message format for a communications network to another message format for a different communications network.

Background

In some situations, different networks or different parts of one network may operate using different release versions of telecommunications standards. For example, one network may operate using an older release (legacy version) of a Third Generation Partnership Project (3GPP) than another network. For example, one network may operate using 3GPP Release 16 (Rel-16) (TS 23.501 ) or more recent while another operates using 3GPP Release 15 (Rel-15) or in general terms a legacy version of service and security managing protocol.

Statement of invention

According to a first aspect there is provided an apparatus comprising means for performing: receiving, while connected to a first network, capability information of a second network, the capability information comprising an indication of at least one service related feature supported by the second network.

According to some examples, the capability information comprises an indication of security features used in the second network.

According to some examples, the capability information comprises an indication of a technical standard release version which the second network is operating in accordance with.

According to some examples, the means are further configured to: send capability information of the first network to the second network, the capability information comprising an indication of a technical standard release version the first network is operating in accordance with.

According to some examples, the means are further configured to: send the capability information of the second network to at least one service communication proxy in the first network.

According to some examples, the means are further configured to: receive a message from the second network; append a public land mobile network identifier of the second network to the message; and forward the appended message to at least one service communication proxy in the first network.

According to some examples, the apparatus comprises a security edge protection proxy.

According to a second aspect there is provided an apparatus comprising at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform: receiving, while connected to a first network, capability information of a second network, the capability information comprising an indication of at least one service related feature supported by the second network.

According to some examples, the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to perform: send capability information of the first network to the second network, the capability information comprising an indication of a technical standard release version the first network is operating in accordance with.

According to some examples, the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to perform: send the capability information of the second network to at least one service communication proxy in the first network.

According to some examples, the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to perform: receive a message from the second network; append a public land mobile network identifier of the second network to the message; and forward the appended message to at least one service communication proxy in the first network.

According to a third aspect there is provided an apparatus comprising:

circuitry for receiving, while connected to a first network, capability information of a second network, the capability information comprising an indication of at least one service related feature supported by the second network.

According to a fourth aspect there is provided a method comprising:

receiving, while connected to a first network, capability information of a second network, the capability information comprising an indication of at least one service related feature supported by the second network.

According to some examples, the method comprises: sending capability information of the first network to the second network, the capability information comprising an indication of a technical standard release version the first network is operating in accordance with.

According to some examples, the method comprises: sending the capability information of the second network to at least one service communication proxy in the first network. According to some examples, the method comprises: receiving a message from the second network; appending a public land mobile network identifier of the second network to the message; and forwarding the appended message to at least one service communication proxy in the first network.

According to some examples, the method is performed by a security edge protection proxy.

According to a fifth aspect there is provided a computer program comprising instructions for causing an apparatus to perform at least the following: receiving, while connected to a first network, capability information of a second network, the capability information comprising an indication of at least one service related feature supported by the second network.

According to a sixth aspect there is provided a computer program comprising instructions stored thereon for performing at least the following: receiving, while connected to a first network, capability information of a second network, the capability information comprising an indication of at least one service related feature supported by the second network.

According to a seventh aspect there is provided a non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least the following: receiving, while connected to a first network, capability information of a second network, the capability information comprising an indication of at least one service related feature supported by the second network.

According to an eighth aspect there is provided a non-transitory computer readable medium comprising program instructions stored thereon for performing at least the following: receiving, while connected to a first network, capability information of a second network, the capability information comprising an indication of at least one service related feature supported by the second network.

According to a ninth aspect there is provided an apparatus comprising means for performing: receiving, while connected to a first network, capability information, the capability information comprising an indication of at least one service related feature supported by a second network; receiving a message; converting a format of the message based on the indication to provide a converted message; and sending the converted message; wherein the apparatus comprises an intermediate node between two or more network functions in the first network.

According to some examples, the receiving a message comprises receiving a message from an entity in the first network; wherein the converting a format of the message comprises converting at least one information element in the incoming message to a format supported by the second network; and wherein sending the converted message comprises sending the converted message towards the second network.

According to some examples, the receiving a message comprises receiving a message from a network function in the first network; and wherein the converting a format of the received message comprises converting the format based on the capability information and an application program interface version field in a target universal resource identifier of the received message.

According to some examples, sending the converted message towards the second network comprises sending the converted message via a Security Edge Protection Proxy in the first network.

According to some examples, the receiving a message comprises receiving a message from an entity in the second network; wherein the converting a format of the message comprises converting at least one information element in the incoming message to a format supported by the first network; and wherein sending the converted message comprises sending the converted message to an entity in the first network. According to some examples, the receiving a message sent from an entity in the second networks comprises receiving the message from a security edge protection proxy in the first network.

According to some examples, sending the converted message to an entity in first network comprises sending the converted message to a network resource function; a network function producer or a network function consumer.

According to some examples, the received message and converted message both comprise: an access token request; an access token response; a service request; or a service response.

According to some examples, the first network is a third generation partnership project release 15 network and the second network is a third generation partnership project release 16 network; or the first network is a third generation partnership project release 16 network and the second network is a third generation partnership project release 15 network.

According to some examples, the apparatus is part of a third generation partnership project release 16 network.

According to some examples, the apparatus maintains a mapping of one or more public land mobile network identifiers to capability information and wherein converting a format of the message based on the indication to provide a converted message comprises using a public land mobile network identifier of the message.

According to some examples, the apparatus comprises a service

communication proxy.

According to some examples, the receiving capability information comprises receiving capability information from a security edge protection proxy in the first network.

According to a tenth aspect there is provided an apparatus comprising at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform: receiving, while connected to a first network, capability information, the capability information comprising an indication of at least one service related feature supported by a second network; receiving a message; converting a format of the message based on the indication to provide a converted message; and sending the converted message; wherein the apparatus comprises an intermediate node between two or more network functions in the first network.

According to some examples, sending the converted message to an entity in first network comprises sending the converted message to: a network resource function; a network function producer or a network function consumer.

According to some examples, the apparatus comprises a service

communication proxy.

According to a eleventh aspect there is provided an apparatus comprising: circuitry for: receiving, while connected to a first network, capability information, the capability information comprising an indication of at least one service related feature supported by a second network; circuitry for receiving a message; circuitry for converting a format of the message based on the indication to provide a converted message; and circuitry for sending the converted message; wherein the apparatus comprises an intermediate node between two or more network functions in the first network.

According to a twelfth aspect there is provided a method comprising:

receiving, while connected to a first network, capability information, the capability information comprising an indication of at least one service related feature supported by a second network; receiving a message; converting a format of the message based on the indication to provide a converted message; and sending the converted message; wherein the method is performed at an intermediate node between two or more network functions in the first network.

According to some examples, sending the converted message towards the second network comprises sending the converted message via a Security Edge Protection Proxy in the first network. According to some examples, the receiving a message comprises receiving a message from an entity in the second network; wherein the converting a format of the message comprises converting at least one information element in the incoming message to a format supported by the first network; and wherein sending the converted message comprises sending the converted message to an entity in the first network.

According to some examples, the receiving a message sent from an entity in the second networks comprises receiving the message from a security edge protection proxy in the first network.

According to some examples, the method is performed in a part of a third generation partnership project release 16 network.

According to some examples, the method comprises maintaining a mapping of one or more public land mobile network identifiers to capability information and wherein converting a format of the message based on the indication to provide a converted message comprises using a public land mobile network identifier of the message.

According to some examples, the method is performed by a service communication proxy. According to some examples, the receiving capability information comprises receiving capability information from a security edge protection proxy in the first network.

According to a thirteenth aspect there is provided a computer program comprising instructions for causing an apparatus to perform at least the following: receiving, while connected to a first network, capability information, the capability information comprising an indication of at least one service related feature supported by a second network; receiving a message; converting a format of the message based on the indication to provide a converted message; and sending the converted message; wherein the method is performed at an intermediate node between two or more network functions in the first network.

According to a fourteenth aspect there is provided a computer program comprising instructions stored thereon for performing at least the following:

According to a fifteenth aspect there is provided a non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least the following: receiving, while connected to a first network, capability information, the capability information comprising an indication of at least one service related feature supported by a second network; receiving a message; converting a format of the message based on the indication to provide a converted message; and sending the converted message; wherein the method is performed at an intermediate node between two or more network functions in the first network.

According to an sixteenth aspect there is provided a non-transitory computer readable medium comprising program instructions stored thereon for performing at least the following: receiving, while connected to a first network, capability information, the capability information comprising an indication of at least one service related feature supported by a second network; receiving a message; converting a format of the message based on the indication to provide a converted message; and sending the converted message; wherein the method is performed at an intermediate node between two or more network functions in the first network.

Brief description of Figures

The invention will now be described in further detail, by way of example only, with reference to the following examples and accompanying drawings, in which:

Figure 1 shows a schematic representation of a network;

Figure 2 shows a schematic representation of a message flow;

Figure 3 shows a schematic representation of a network;

Figure 4 shows a schematic representation of a message flow;

Figure 5 shows a schematic representation of an apparatus according to an example;

Figure 6 shows a schematic representation of an apparatus according to an example;

Figure 7 shows a flow diagram of a method according to an example; and

Figure 8 shows a flow diagram of a method according to an example.

Detailed description

The present disclosure relates to translating requests and responses between one or more message formats for communications networks.

Different 3GPP releases for telecommunications networks may use different models for communication.

For example, in 3GPP Release 16 (Rel-16) (TS 23.501 ), an indirect communication model can be used where Network Functions (NFs) communicate via a Service Communication Proxy (SCP). In some examples, an SCP can be considered to be an intermediate function used to help to route Control Plane messages (e.g. Diameter Routing Agents) between two NFs.

In 3GPP Release 15 (Rel-15), networks do not have a SCP and the nodes communicate directly.

3GPP Rel-16 of 5G Service Based Architecture (SBA) describes new architectural models for service communication called Option C” and Option D”. In Option D, the functionalities of target NF discovery and target NF selection, for example, based on load balancing etc. are delegated to an SCP. Option C does not cover delegated target NF discovery like in Option D. In Option C, an SCP is used for delegated routing of NF requests to the selected NF service producer instance. In some examples, an SCP can be considered to be a common NF (i.e. connected to all NFs in a network).

Both Option C and Option D are based on indirect communication between NFs. In other words, the NFs do not directly communicate with each other. This also includes interactions between a NF and a Network Resource Function (NRF) with delegated target NF discovery in Option D. Due to this difference in Rel-16, Rel-15 Open Authorization (OAuth) based service access authorization may be incompatible with Rel-16 networks in some cases.

Release 15 communication for authorization is directly between the network functions, while Release 16 relies on the SCP. In some examples, such as roaming scenarios or even in a single network, there might be a mix of network releases. For example, a Release 15 network may have a roaming partner with a Release 16 network. In some examples, the network setup might be heterogeneous leading to a mix of network releases.

Figure 1 shows an example where a service consumer is in a first network

104 run by Operator 1. Network 104 is a Rel-15 network. In the example of Figure 1 , a service producer is in a second network 102 run by Operator 2. Network 102 is a Rel-16 network.

Rel-16 network 102 comprises Security Edge Protection Proxy (SEPP) 112. In the context of Figure 1 , SEPP 112 may be considered to be a home SEPP (hSEPP) 112. Network 102 also comprises a Network Function provider (NFp) 116, a NRF 118 and a SCP 114. In the context of Figure 1 , NRF 118 may be considered to be a home NRF (hNRF) 118. In some examples, SCP 114 may be referred to as “SCPp” to indicate that the SCP is connected to NFp 116. In some examples, an SCPp can be considered to be an SCP interfacing Rel-16 level (local) NF providers.

Rel-15 network 104 comprises Security Edge Protection Proxy (SEPP) 106. In the context of Figure 1 , SEPP 106 may be considered to be a visiting SEPP (vSEPP) 106. Network 104 also comprises Network Function consumer (NFc) 110 and NRF 108. In the context of Figure 1 , NRF 108 may considered to be a visiting NRF (vNRF) 108.

In some examples, a“home” network entity (e.g. hSEPP, hNRF) may belong to a network comprising a NFp. A“visiting” network entity (e.g. vSEPP, vNRF) may belong to a network comprising a NFc.

Figure 2 shows an example message flow for a situation where a service consumer NFc 210 is in a Rel-15 network and a service provider NFp 216 is in a Rel-16 network.

At 201 , hSEPP 212 and vSEPP 206 mutually authenticate each other as described, for example, in 3GPP TS 33.501.

At 203, hSEPP 212 and vSEPP 206 exchange capability information of their networks. In some examples, this capability information may comprise information on the release and/or feature support of their corresponding networks.

The capability information may be exchanged as part of the N32 interface control plane (N32-c) parameter exchange procedure (3GPP TS 33.501 Clause 13.2.2.2).

In some examples, the capability information can be exchanged using explicit messages. In some examples, the capability information may be instead or additionally appended to message flows used in step 201 for example. In some examples, the capability information may be stored and exchanged based on documents where network operators describe their network set-up (for example, GSMA IR.21 documents).

The capability information is sent from hSEPP 212 to hSCP 214 at step 205. This capability information may be updated such that the capability information at hSCP 214 can be considered to be dynamic. In some examples, SCPs are dynamically updated with release information of peer networks. Release information may be obtained by SEPP local to the SCP. In some examples, hSCP 214 maintains a mapping of capability information against a Public Land Mobile Network identifier (PLMN ID) of the network for which the capability information is for.

In some examples, dynamic learning may be used to obtain capability information of a peer network (peer PLMN). In some examples, dynamic learning may comprise explicit learning whether release information is exchanged between entities (e.g. between vSEPP 206 and hSEPP 212 and between hSEPP 212 and hSCP 214). Dynamic learning may comprise implicit learning of capability information based on information elements received in message flows from a network during NF service profile requests, for example.

During access token request procedures, hSEPP 212 and/or hSCP 214 in the Rel-16 network can confirm the required inworking requirements between PLMNs based on the information elements in the related message flows.

At 207, a Rel-15 NFc (or in general, an NFc operating using an older release version than NFp 216 i.e. operating using a legacy network) tries to set up a service request with NFp 216. NFc 210 sends an access token request to vNRF 208 at 207. At 209, vNRF 208 authenticates NFc 210.

At 211 , 213 and 215 the access token request is forwarded to hSCP 214 via vSEPP 206 and hSEPP 212.

At 215, hSEPP 212 may append a PLMN ID based on where the access token request was received from.

At 217, hSCP 214 recognizes (for example, explicitly based on hSEPP 212 appending the PLMN ID in step 215 or by other means) that the access token request is received from a legacy network on 3GPP Release 15 level. hSCP 214 can then map information elements received in the Rel-15 access token request (or more generally, legacy access token request) to Rel-16 information elements.

At 219, hSCP may validate the access token if it was included in the request at 215. In some examples, where the access token differs for older/newer releases (for example, differs between Rel-16 and Rel-15) the validation step at 215 may use the older type of validation (i.e. validation algorithm of the older release).

At 221 , a Rel-16 access token request is sent to hNRF 218.The Rel-16 access token request may be an information element mapped to a Rel-16 information element at 217. At 223, hNRF 218 authorizes NFc 210. At 225, hNRF 218 generates and signs the access token. At 227, the access token is returned to hSCP 214 to be sent to a target PLMN comprising NFc 210.

At 229, hSCP 214 determines that the target PLMN is in a Rel-15 network based on capability information of the target PLMN. Based on this determination. hSCP 214 maps the information element(s) of the Rel-16 response received at 227 to a Rel-15 access token response message comprising one or more Rel-15 information element(s). At 231 , the response message is sent to NFc 210 via hSEPP 212, vSEPP 206 and vNRF 208.

At 233, NFc issues a Rel-15 service request comprising the access token received at 231. The request is sent to hSCP 214 via vSEPP 206 and hSEPP 212.

At 233, hSEPP 212 may append a PLMN ID to the request based on where the access token request was received from.

At 235, hSCP 214 determines the application program interface (API) version of the request received at 233 based on PLMN ID appended by hSEPP 212 at 233. API from Rel-15 is processed and mapped the by hSCP 214 to Rel-16.

At 237, hSCP 214 authorizes NFc 210 by verifying the access token. A Rel- 16 request is then sent from hSCP 214 to NFp at 239. A Rel-16 service response is received at hSCP 214 at 241. At 243, the service response can by mapped from Rel-16 to Rel-15, for example if it is required to be sent back to NFc 210 in the Rel- 15 network.

Figure 3 shows an example where a service consumer 360 is in a first network 352 run by Operator 1. Network 352 is a Rel-16 network. In the example of Figure 3, a service producer 366 is in a second network 350 run by Operator 2. Network 350 is a Rel-15 network.

Rel-15 network 350 comprises Security Edge Protection Proxy (SEPP) 354. In the context of Figure 3, SEPP 354 may be considered to be a home SEPP (hSEPP) 354. Network 350 also comprises a Network Function provider (NFp) 366 and a NRF 364. In the context of Figure 3, NRF 364 may be considered to be a home NRF (hNRF) 364. In some examples, SCP 114 may be referred to as“SCPp” to indicate that the SCP is connected to NFp 116.

Rel-16 network 352 comprises Security Edge Protection Proxy (SEPP) 356. In the context of Figure 3, SEPP 356 may be considered to be a visiting SEPP (vSEPP) 356. Network 352 also comprises Network Function consumer (NFc) 360, NRF 362 and SCP 358. In the context of Figure 3, NRF 362 may be considered to be a visiting NRF (vNRF) 362. In some examples, SCP 358 may be referred to as “SCPc” to indicate that the SCP is connected to NFc 360. In some examples, an SCPc can be considered to be an SCP interfacing Rel-16 level (local) NF consumers.

In some examples, a hSCP is an SCP in a home PLMN. In some examples, a vSCP is a SCP in a visited PLMN.

Figure 4 shows an example message flow for a situation where a service consumer NFc 460 is in a Rel-16 network using Option C without delegated target NF discovery and a service provider NFp 466 is in a Rel-15 network.

In some examples APIs may be mapped by a higher release SCP. In some examples, this mapping may occur during either an Option C or an Option D of Indirect communication.

At 468, hSEPP 454 and vSEPP 456 mutually authenticate each other as described, for example, in 3GPP TS 33.501.

At 470, hSEPP 454 and vSEPP 456 exchange capability information of their networks. In some examples, this capability information may comprise information on the release and/or feature support of their corresponding networks.

The capability information may be exchanged as part of the N32-c parameter exchange procedure (3GPP TS 33.501 Clause 13.2.2.2).

In some examples, the capability information can be exchanged using explicit messages. In some examples, the capability information may be instead or additionally appended to message flows used in step 468 for example. In some examples, the capability information may be stored and exchanged based on documents where network operators describe their network set-up (for example, GSMA IR.21 documents).

The capability information is sent from vSEPP 456 to vSCP 458 at step 472. In this way, vSCP 458 may receive capability information of the Rel-15 network. This capability information may be updated such that the capability information at vSCP 458 can be considered to be dynamic. In some examples, vSCP 458 maintains a mapping of capability information against a Public Land Mobile Network identifier (PLMN ID) of the network for which the capability information is for.

In some examples, dynamic learning may be used to obtain capability information of a peer network (peer PLMN). In some examples, dynamic learning may comprise explicit learning whether release information is exchanged between entities (e.g. between vSEPP 456 and hSEPP 454 and between vSEPP 456 and vSCP 458). Dynamic learning may comprise implicit learning of capability information based on information elements received in message flows from a network during NF discovery procedures and/or NF service profile requests, for example.

During access token request procedures, vSEPP 456 and/or vSCP 458 in the Rel-16 network can confirm the required inworking requirements between PLMNs based on the information elements in the related message flows.

At 474, a Rel-16 NFc (or in general, an NFc operating using a newer release version than NFp 466 i.e. NFp 466 is operating using a legacy network) tries to set up a service request with NFp 466. NFc 460 sends an access token request to vNRF 462 at 474. At 476, vNRF 462 authenticates NFc 460

At 478, the Rel-16 access token request is sent to vSCP 458. vSCP 458 determines the release version that the target of the access token request is operating with using the capability information dynamically stored at vSCP 458, for example by using PLMN ID information that may be included in the API request. In some examples, vSCP 458 may also, or alternatively, determine the API version of the target based on API version attribute of the target URI that is available in the API Request. Following the determination, at 480 vSCP 458 can map one or more information elements in the Rel-16 request to Rel-15 parameters, if Rel-15 parameters are required at the target of the request.

At 482, 484 and 486 the access token request is forwarded to hNRF 464 via vSEPP 456 and hSEPP 454.

At 490, hNRF 464 verifies an access token if included in the request sent at

486. At 492, hNRF authorizes NFc 460. At 494, hNRF 464 generates a digitally signed access token for NFc 460. At 496, hNRF 464 sends a Rel-15 access token response to vSCP 458 via hSEPP 454 and vSEPP 456. Prior to sending the access token response to vSCP 458, vSEPP 456 may insert a PLMN ID in a custom 3GPP HTTP header field.

At 498, vSCP 458 determines an API and/or release version of the access token response received at 496 (this may be, for example, based on the custom 3GPP header field inserted by vSEPP). vSCP 458 can compare the version in the response with the version used at the target destination. In the example of Figure 4, vSCP 458 determines that Rel-15 parameters are used in the access token response received at 496 and that the target (NFc 460) is in a Rel-16 network. Following the determination, vSCP 458 can map one or more information elements in the Rel-15 response to Rel-16 parameters.

At 451 the converted access token response (which is now a Rel-16 access token response) is sent to NFc 460 via vNRF 462. The response may comprise an access token.

At 453 NF NFc issues a Rel-16 service request comprising the access token received at 451. The request is sent to vSCP 458. At 455, vSCP 458 determines the release version that the target of the service request is operating with by using the capability information dynamically stored at vSCP 458 if the API request includes PLMN ID information. vSCP 458 can also determine the API version of the target based on API version attribute of the target URI that may be available in the API

Request. Following the determination, vSCP 458 can map one or more information elements in the Rel-16 request to Rel-15 parameters, if Rel-15 parameters are required at the target of the request.

The converted Rel-15 service request is then sent from vSCP 458 to vSEPP 456 at 457. At 459 the Rel-15 service request is sent from vSEPP 456 to hSEPP

454. At 461 the Rel-15 service request is sent from hSEPP 461 to NFp 466.

At 463, NFp 466 authorises NFc 460. This step may comprise verifying an access token received at 461.

At 465, a Rel-15 service response is sent to vSCP 458 via hSEPP 454 and vSEPP 456. Prior to sending the access token response, vSEPP 212 may insert the PLMN ID in a custom 3GPP HTTP header field.

At 467 vSCP 458 can determine whether the received response (based on the custom 3GPP header field inserted by vSEPP) needs to be converted to a different release version to be forwarded to NFc 460. The Rel-15 response is then mapped to Rel-16 and at 469 may be sent to NFc 460.

In Figures 2 and 4 an SCP in a Rel-16 network is used to identify whether a target destination is operating using a different release version to an incoming message. If so, the vSCP can convert (translate) the parameters in the incoming message such that the message can be forwarded with parameters that are used at the target destination.

Although a dual operator scenario is discussed above, the conversion functions of the SCP can also be deployed in a single operator scenario. This may be used, for example, in a situation where an operator has a NFp/NFc with different capabilities (in terms of release version and feature support, for example).

A possible wireless communication device will now be described in more detail with reference to Figure 5 showing a schematic, partially sectioned view of a communication device 500. Such a communication device is often referred to as user equipment (UE) or terminal. An appropriate mobile communication device may be provided by any device capable of sending and receiving radio signals. Non limiting examples comprise a mobile station (MS) or mobile device such as a mobile phone or what is known as a’smart phone’, a computer provided with a wireless interface card or other wireless interface facility (e.g., USB dongle), personal data assistant (PDA) or a tablet provided with wireless communication capabilities, or any combinations of these or the like. A mobile communication device may provide, for example, communication of data for carrying communications such as voice, electronic mail (email), text message, multimedia and so on. Users may thus be offered and provided numerous services via their communication devices. Non- limiting examples of these services comprise two-way or multi-way calls, data communication or multimedia services or simply an access to a data communications network system, such as the Internet. Users may also be provided broadcast or multicast data. Non-limiting examples of the content comprise downloads, television and radio programs, videos, advertisements, various alerts and other information.

A wireless communication device may be for example a mobile device, that is, a device not fixed to a particular location, or it may be a stationary device. The wireless device may need human interaction for communication, or may not need human interaction for communication. In the present teachings the terms UE or “user” are used to refer to any type of wireless communication device.

The wireless device 500 may receive signals over an air or radio interface 507 via appropriate apparatus for receiving and may transmit signals via appropriate apparatus for transmitting radio signals. In Figure 5 transceiver apparatus is designated schematically by block 506. The transceiver apparatus 506 may be provided for example by means of a radio part and associated antenna arrangement. The antenna arrangement may be arranged internally or externally to the wireless device.

A wireless device is typically provided with at least one data processing entity

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

Figure 6 shows an example of a control apparatus 600 for a communication system, for example to be coupled to and/or for controlling a station of an access system, such as a RAN node, e.g. a base station, gNB, a central unit of a cloud architecture or a node of a core network such as an MME or S-GW, a scheduling entity such as a spectrum management entity, or a server or host, or an IAB or relay node. The apparatus 600 may be coupled to an NG-RAN node, or to a part of a UPF. The control apparatus may be integrated with or external to a node or module of a core network or RAN. In some example embodiments, base stations comprise a separate control apparatus unit or module. In other example embodiments, the control apparatus can be another network element such as a radio network controller or a spectrum controller. In some example embodiments, each base station may have such a control apparatus as well as a control apparatus being provided in a radio network controller. The control apparatus 600 can be arranged to provide control on communications in the service area of the system. The control apparatus 600 comprises at least one memory 601 , at least one data processing unit 602, 603 and an input/output interface 604. Via the interface the control apparatus can be coupled to a receiver and a transmitter of the base station. The receiver and/or the transmitter may be implemented as a radio front end or a remote radio head. For example the control apparatus 600 or processor 601 can be configured to execute an appropriate software code to provide the control functions.

Figure 7 is a flow chart of a method according to an example. The flow chart of Figure 7 is viewed from the perspective of an apparatus such as hSEPP 212, hSEPP 454, vSEPP 206 or vSEPP 456, for example. S701 comprises receiving, while connected to a first network, capability information of a second network, the capability information comprising an indication of at least one service related feature supported by the second network.

Figure 8 is a flow chart of a method according to an example. The flow chart of Figure 7 is viewed from the perspective of an apparatus such as vSCP 458 or hSCP 214, for example.

S801 comprises receiving, while connected to a first network, capability information, the capability information comprising an indication of at least one service related feature supported by a second network

5802 comprises receiving a message.

5803 comprises converting a format of the message based on the indication to provide a converted message.

5804 comprises sending the converted message.

The method of Figure 8 may be performed by an apparatus comprising an intermediate node between two or more network functions in the first network.

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

As used in this application, the term“circuitry” may refer to one or more or all of the following: (a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry) and(b) combinations of hardware circuits and software, such as (as applicable): (i) a combination of analog and/or digital hardware circuit(s) with software/firmware and (ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and (c) hardware circuit(s) and or processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation. This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

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

Further in this regard it should be noted that any blocks of the logic flow as in the Figures may represent program steps, or interconnected logic circuits, blocks and functions, or a combination of program steps and logic circuits, blocks and functions. The software may be stored on such physical media as memory chips, or memory blocks implemented within the processor, magnetic media such as hard disk or floppy disks, and optical media such as for example DVD and the data variants thereof, CD. The physical media is a non-transitory media.

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

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

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

Claims

I/We Claim:

1. An apparatus comprising means for performing: receiving, while connected to a first network, capability information of a second network, the capability information comprising an indication of at least one service related feature supported by the second network.

2. An apparatus according to claim 1 , wherein the capability information comprises an indication of security features used in the second network.

3. An apparatus according to claim 1 or claim 2, wherein the capability information comprises an indication of a technical standard release version which the second network is operating in accordance with.

4. An apparatus according to any preceding claim, wherein the means are further configured to: send capability information of the first network to the second network, the capability information comprising an indication of a technical standard release version the first network is operating in accordance with.

5. An apparatus according to any preceding claim, wherein the means are further configured to: send the capability information of the second network to at least one service communication proxy in the first network.

6. An apparatus according to any preceding claim, wherein the means are further configured to: receive a message from the second network; append a public land mobile network identifier of the second network to the message; and forward the appended message to at least one service communication proxy in the first network.

7. An apparatus according to any preceding claim, wherein the apparatus comprises a security edge protection proxy.

8. An apparatus according to any preceding claim, wherein the means comprises: at least one processor; and at least one memory including computer program code, the at least one memory and computer program code configured to, with the at least one processor, cause the performances of the apparatus.

9. An apparatus comprising means for performing: receiving, while connected to a first network, capability information, the capability information comprising an indication of at least one service related feature supported by a second network; receiving a message; converting a format of the message based on the indication to provide a converted message; and sending the converted message; wherein the apparatus comprises an intermediate node between two or more network functions in the first network.

10. An apparatus according to claim 9, wherein the capability information comprises an indication of security features used in the second network,

11. An apparatus according to claim 9 or claim 10, wherein the capability information comprises an indication of a technical standard release version which the second network is operating in accordance with.

12. An apparatus according to any of claims 9 to 11 , wherein receiving a message comprises receiving a message from an entity in the first network; wherein the converting a format of the message comprises converting at least one information element in the incoming message to a format supported by the second network; and wherein sending the converted message comprises sending the converted message towards the second network.

13. An apparatus according to claim 12, wherein the receiving a message comprises receiving a message from a network function in the first network; and wherein the converting a format of the received message comprises converting the format based on the capability information and an application program interface version field in a target universal resource identifier of the received message.

14. An apparatus according to any of claims 9 to 13, wherein the receiving a message comprises receiving a message from an entity in the second network; wherein the converting a format of the message comprises converting at least one information element in the incoming message to a format supported by the first network; and wherein sending the converted message comprises sending the converted message to an entity in the first network.

15. An apparatus according to any of claims 9 to 14, wherein the received message and converted message both comprise: an access token request; an access token response; a service request; or a service response.

16. An apparatus according to any of claims 9 to 15, wherein the first network is a third generation partnership project release 15 network and the second network is a third generation partnership project release 16 network; or the first network is a third generation partnership project release 16 network and the second network is a third generation partnership project release 15 network.

17. An apparatus according to any of claims 9 to 16, wherein the apparatus is part of a third generation partnership project release 16 network.

18. An apparatus according to any of claims 9 to 17, wherein the apparatus maintains a mapping of one or more public land mobile network identifiers to capability information and wherein converting a format of the message based on the indication to provide a converted message comprises using a public land mobile network identifier of the message.

19. An apparatus according to any of claims 9 to 18, wherein the apparatus comprises a service communication proxy.

20. An apparatus according to any of claims 9 to 19, wherein the means comprises: at least one processor; and at least one memory including computer program code, the at least one memory and computer program code configured to, with the at least one processor, cause the performances of the apparatus.

21 . A method comprising: receiving, while connected to a first network, capability information of a second network, the capability information comprising an indication of at least one service related feature supported by the second network.

22. A method comprising: receiving, while connected to a first network, capability information, the capability information comprising an indication of at least one service related feature supported by a second network; receiving a message; converting a format of the message based on the indication to provide a converted message; and sending the converted message; wherein the method is performed at an intermediate node between two or more network functions in the first network.

23. A computer program comprising instructions for causing an apparatus to perform at least the following: receiving, while connected to a first network, capability information of a second network, the capability information comprising an indication of at least one service related feature supported by the second network.

24. A computer program comprising instructions for causing an apparatus to perform at least the following: receiving, while connected to a first network, capability information, the capability information comprising an indication of at least one service related feature supported by a second network; receiving a message; converting a format of the message based on the indication to provide a converted message; and sending the converted message; wherein the apparatus comprises an intermediate node between two or more network functions in the first network.