阅读说明：本技术 用于处理可伸缩fqdn的系统和方法 (System and method for processing scalable FQDN ) 是由 杰苏斯-安杰尔·德-格雷格里奥-罗格里格斯 戴维·卡斯特利亚诺斯萨莫拉 尤哈·库亚宁 于 2020-04-07 设计创作，主要内容包括：本文公开了一种由在受访网络(VPLMN)中实现第一NF的第一节点(420)执行的用于与在归属网络(HPLMN)中实现第二NF的第三节点通信的方法。该方法包括：确定(400)应当与其通信的第三节点；向在受访网络中实现安全边缘保护代理(SEPP)的第二节点(440)发送(402)对要由受访网络中的第一节点用于与归属网络中的第三节点通信的归属网络中的第三节点的可伸缩FQDN的请求,该请求包括归属网络中的第三节点的FQDN；从第二节点接收第三节点的可伸缩FQDN,其中归属网络中的第三节点的FQDN被展平为要由第一节点用于与第三节点通信的单个标签。(A method performed by a first node (420) implementing a first NF in a visited network (VPLMN) for communicating with a third node implementing a second NF in a home network (HPLMN) is disclosed. The method comprises the following steps: determining (400) a third node with which to communicate; sending (402) a request to a second node (440) implementing a Security Edge Protection Proxy (SEPP) in the visited network for a scalable FQDN of a third node in the home network to be used by the first node in the visited network for communicating with the third node in the home network, the request comprising the FQDN of the third node in the home network; a scalable FQDN of a third node is received from the second node, wherein the FQDN of the third node in the home network is flattened into a single label to be used by the first node for communication with the third node.)

1. A method performed by a first node (420) implementing a first network function, NF, in a visited network, VPLMN, for communicating with a third node (430) implementing a second NF in a home network (HPLMN), the method comprising:

-determining (400, 500) the third node with which it should communicate;

-sending (402, 502) a request for a scalable fully qualified domain name, FQDN, of the third node in the home network to be used by the first node in the visited network for communicating with the third node in the home network to a second node (440) implementing a security edge protection proxy, SEPP, in the visited network, the request comprising the FQDN of the third node in the home network;

-receiving (406, 506) a scalable FQDN of the third node from the second node, wherein the FQDN of the third node in the home network is flattened to a single label to be used by the first node for communication with the third node.

2. The method of claim 1, further comprising: communicating (408, 508) with the third node in the home network via the second node in the visited network using the received scalable FQDN of the third node, wherein the FQDN of the third node in the home network is flattened to a single label.

3. The method of any of claims 1-2, further comprising: communicating (408) with the third node in the home network by sending a service request comprising the received scalable FQDN of the third node to the second node in the visited network.

4. The method of claim 3, wherein the service request is any one of: a discovery request, an Oauth2 access token request, or a subscription request.

5. The method of any of claims 1-4, wherein one or more of: the first node implements a visited NRF; the second node implements a visited SEPP; and the third node implements a home NRF.

6. The method of any of claims 1-5, wherein requesting the scalable FQDN comprises sending the FQDN of the third node in the home network.

7. The method of any of claims 1-6, wherein receiving the scalable FQDN comprises receiving a flattened FQDN of the third node.

8. The method of any of claims 2-7, further comprising: communicate with the third node by sending a service request to another node (SEPP2) using the scalable FQDN to be used for communicating with the third node.

9. A method performed by a second node (440) implementing a security edge protection proxy, SEPP, in a visited network (VPLMN) for enabling communication with a third node (430) implementing a second network function, NF, in a home network (HPLMN), the method comprising:

-receiving (402), from a first node (420) implementing a first NF in the visited network, a request for a scalable fully qualified domain name, FQDN, of the third node in the home network to be used by the first node in the visited network for communicating with the third node in the home network, the request comprising the FQDN of the third node in the home network; and

-sending (406) a scalable FQDN of the third node to the first node, wherein the FQDN of the third node in the home network is flattened to a single label to be used by the first node for communication with the third node.

10. The method of claim 9, wherein one or more of: the first node implements a visited NRF; the second node implements a visited SEPP; and the third node implements a home NRF.

11. The method of any of claims 9-10, wherein receiving the request for the scalable FQDN comprises receiving an FQDN of the third node in the home network.

12. The method of any of claims 9-11, wherein transmitting the scalable FQDN comprises transmitting a flattened FQDN of the third node.

13. The method of any of claims 9-12, wherein sending the scalable FQDN comprises sending the scalable FQDN of the third node, wherein the FQDN of the third node in the home network is flattened into a single label.

14. The method according to any one of claims 9-13, further comprising: receiving (408) a service request from the first node, the service request comprising the received scalable FQDN for communicating with the third node on behalf of the first node using the scalable FQDN.

15. A first node (420) implementing a first network function, NF, in a visited network (VPLMN) for communicating with a third node (430) implementing a fourth NF in a home network (HPLMN), the first node comprising:

-processing circuitry configured to perform the steps of any of claims 1-8.

16. A second node (440) implementing a security edge protection proxy, SEPP, in a visited network (VPLMN) for enabling communication with a third node (430) implementing a second network function, NF, in a home network (HPLMN), the second node comprising:

-processing circuitry configured to perform the steps of any of claims 9-14.

Background

Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant art unless a different meaning is clearly given and/or implied from the context in which it is used. All references to elements, devices, components, means, steps, etc. are to be interpreted openly as referring to at least one instance of an element, device, component, means, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as being after or before another step and/or where it is implied that a step must be after or before another step. Any feature of any embodiment disclosed herein may be applied to any other embodiment as appropriate. Likewise, any advantage of any embodiment applies to any other embodiment and vice versa. Other objects, features and advantages of the appended embodiments will be apparent from the description that follows.

In 5G systems, for roaming scenarios, the Network Function (NF) in the visited PLMN needs to interact with the network function in the home PLMN. This signaling interaction must go through a border entity called SEPP (security edge protection proxy) located at the edge of the two PLMNs.

The security requirements of the signaling typically require that the signaling between NFs be protected via TLS (transport layer security), even within a given PLMN. Thus, the URI (uniform resource identifier) used by the visited NF to address a given NF in the home PLMN is typically an "https" URI. For example, the amf (vplmn) interacting with udm (hplmn) may use the following URI:

https：//udml.home-operator.com/nudm-sdm/vl/...

at the same time, the SEPP located in the visited PLMN needs to be able to access the content of the message in clear text to apply a specific service logic.

However, using tls (https) requires end-to-end encryption of the message, making it impossible for SEPP to access the message.

To address this problem, the concept of a "scalable Fully Qualified Domain Name (FQDN)" was introduced in TS 33.501, with the aim of terminating TLS connections at the visited SEPP. The example URI above would be transformed to:

https: home-operator.com. SEPP. visited-operator.com (i.e., in this scalable FQDN, the FQDN of the home UDM is cascaded with the FQDN of the visited SEPP.)

The DNS of the visited PLMN is configured in such a way that: such that any address ending with ". erp. visited-operator.com" will be resolved to the IP address of the visited SEPP.

There is also a problem to consider: to terminate a TLS connection, the visited SEPP needs to provide a valid Public Key Infrastructure (PKI) certificate to the visited NF (originator of the TLS connection). A certificate is "valid" when the target URI "matches" one or more FQDNs found in the Subject Alternative Name field (Subject Alternative Name field) in the certificate.

Given that the scalable FQDN is dynamically constructed, and given that the first part is the FQDN of the visited NF, it is not possible to create a certificate with such FQDN within the certificate. The solution is to create a "wildcard certificate". For example, in the above example, the wildcard certificate would contain the following subject alternative names:

*.sepp.visited-operator.com

an important limitation of the wildcard certificate is that ". x" can only represent a single level field in the FQDN. Thus, the above examples will match:

nodel.sepp.visited-operator.com

but the above example will not match the general multi-level form of the scalable FQDN:

udml.home-operator.com.sepp.visited-operator.com

as a result, the scalable FQDN must be transformed again in such a way as to "flatten" the FQDN of the NF in the home PLMN into a single label, for example:

udml.home-operator.com-＞label

the final URI would then be of the form:

https：//label.sepp.visited-operator.com

this will match successfully when the visited SEPP provides the visited NF with a wildcard certificate (SEPP. visited-operator. com) as shown above.

Disclosure of Invention

Certain challenges currently exist. As described above, a "scalable Fully Qualified Domain Name (FQDN)" is introduced in the TS 33.501. However, it is pointed out in TS 33.501 that the algorithm for generating such a single tag from the FQDN of the home NF is left to CT4 for definition.

However, CT4 never does so for the following reasons:

the NF in the visited PLMN typically obtains the FQDN of the NF in the home PLMN via a discovery service request of the NRF. This means that the message of the discovery service request also goes through the SEPP, so the visited SEPP can create a scalable FQDN of the discovered NF of the home PLMN before sending the discovery service response to the visited NF. At this point, the visited SEPP may apply any proprietary algorithm it chooses to generate the "single label" field required by the scalable FQDN.

The visited NF will then use this scalable FQDN built by the visited SEPP in order to send the actual "service" request (e.g., the AMF sends a service request to the discovered UDM).

This request is received by the visited SEPP and it must inverse transform the scalable FQDN to the original FQDN of the home NF. For example: https: v/label. sepp. visual-operator. com- > https: home-operator.com

Whereas SEPP creates a "label" from "home-operator.com", it can always transform it back to the original FQDN "home-operator.com" (applying an algorithmic transformation or by maintaining a mapping table between the label and the FQDN).

The problem with the above assumption is that there are situations where SEPP may not have been previously involved in the signaling path and the visited NF needs to interact with the home NF. Such scenarios are that the so far mentioned "visited NF" and "Home NF" are actually "visited")NRF"and" attributionNRF"is used in the case. Specifically, the method comprises the following steps:

-the visited NRF sending a discovery request to the home NRF

-visited NRF sending Oauth2 access token request to home NRF

-visited NRF sending subscription request to home NRF

In all these cases, the visited NRF learns the FQDN of the home NRF by:

-standardized public address defined in TS 23.003 (based on MCC/MNC construction of home PLMN), or

-being configured in the visited PLMN as part of an SLA/roaming agreement with the home PLMN.

Thus, in these cases, the visited NRF must constitute a scalable FQDN pointing to the home NRF of the visited SEPP. For example:

https：//nrf.home-operator.com.sepp.visited-operator.com

furthermore, this requires a transformation into a single tag domain, for example:

https：//label.sepp.visited-operator.com

thus, whereas the original transformation was done in another entity (visited NRF), there is a need for an improved system and method in which the visited SEPP inverse transforms and converts "label" to "NRF.

Certain aspects of the present disclosure and embodiments thereof may provide solutions to the above and other challenges. The present disclosure presents a new service provided by a SEPP so that other NFs can request the SEPP to generate a scalable FQDN (and flatten the original FQDN into a single label) and also do the reverse mapping, i.e., convert the flattened scalable FQDN to the original FQDN of the NF in the home PLMN.

For example: the visited NRF needs to contact:

https：//nrf.home-operator.com

it therefore sends a GET request to the visited SEPP as follows:

GETHtPS: v/SEPP. found-operator.com/telescomicfqdn ═ NRF. home-operator.com ", where" SEPP. found-operator.com "is the FQDN of the visited SEPP and" NRF. home-operator.com "is the FQDN of the home NRF.

Also, the visited SEPP will answer, for example, using a JSON document, as follows:

{″telescopic″：″0x1273bc89.sepp.visited-operator.com"}

(i.e., in the scalable FQDN "0 x1273bc89.SEPP. found-operator. com", the FQDN of the Home NRF has been flattened to the label "0 x1273bc 89" which is concatenated with the FQDN of the visited SEPP, i.e., "SEPP. found-operator. com")

Reverse services may also be provided:

GEThttps：//sepp.visited-operator.com/telescopiclabel＝"0x1273bc89″

furthermore, the visited SEPP will respond, for example:

{″fqdn"：″nrf.home-operator.com"}

a mechanism and associated services provided by SEPPs that allow other NFs to acquire a scalable FQDN of an NF in another PLMN in such a way that the SEPPs can then reverse map and acquire the FQDN of the alien NF based on the scalable FQDN.

Various embodiments are presented herein that address one or more of the problems disclosed herein. In some embodiments, a method performed by a first node for communicating with a third node comprises: determining a third node with which to communicate; requesting an address from the second node to be used for communication with the third node; receiving, from the second node, an address to be used for communication with the third node; and communicating with the third node using the address.

In some embodiments, one or more of the following: the first node is a node in a visited network, e.g. a visited NRF; the second node is a node in the visited network, e.g. a visited SEPP; and the third node is a node in the home network, e.g. a home NRF.

In some embodiments, requesting an address to be used for communication with the third node comprises: a scalable FQDN of the third node is requested. In some embodiments, receiving the address to be used for communication with the third node comprises: a scalable FQDN of a third node is received. In some embodiments, requesting an address to be used for communication with the third node comprises: and transmitting the FQDN of the third node. In some embodiments, receiving the address to be used for communication with the third node comprises: a flattened FQDN of a third node is received.

In some embodiments, the method further comprises communicating with the third node by sending a service request to the second node using the address to be used for communicating with the third node. In some embodiments, the method further comprises communicating with the third node by sending a service request to the other node using the address to be used for communicating with the third node.

In some embodiments, a method performed by a second node for enabling communication with a third node comprises: receiving, from a first node, a request for an address to be used for communicating with a third node; and sending an address to the first node to be used for communication with the third node.

In some embodiments, one or more of the following: the first node is a node in a visited network, e.g. a visited NRF; the second node is a node in the visited network, e.g. a visited SEPP; and the third node is a node in the home network, e.g. a home NRF. In some embodiments, receiving the request for the address to be used for communicating with the third node comprises: a request for a scalable FQDN for a third node is received. In some embodiments, sending the address to be used for communication with the third node comprises: and sending the scalable FQDN of the third node. In some embodiments, receiving the request for the address to be used for communicating with the third node comprises: the FQDN of the third node is received. In some embodiments, sending the address to be used for communication with the third node comprises: the flattened FQDN of the third node is sent.

In some embodiments, the method further comprises receiving, from the first node, a service request for communicating with the third node using the address to be used for communicating with the third node.

In particular, one embodiment relates to a method performed by a first node implementing a first Network Function (NF) in a visited network (e.g., a visited public land mobile network, VPLMN) for communicating with a third node implementing a second NF in a home network (e.g., a home public land mobile network, HPLMN), the method comprising: determining a third node with which to communicate; sending a request to a second node implementing a Security Edge Protection Proxy (SEPP) in the visited network for a scalable Fully Qualified Domain Name (FQDN) of a third node in the home network to be used by the first node in the visited network to communicate with the third node in the home network, the request including the FQDN of the third node in the home network (e.g., FQDN "nrf. home-operator. com"); a scalable FQDN of a third node is received from the second node, wherein the FQDN of the third node in the home network is flattened into a single label to be used by the first node for communication with the third node. Preferably, the received scalable FQDN comprises a FQDN of a third node flattened into a label concatenated with the FQDN of the second node. For example, the received scalable FQDN may be "0 x1273bc89.SEPP. found-operator. com", wherein the third node is a home NRF having an FQDN "NRF. home-operator. com" that has been flattened to the label "0 x1273bc 89", and wherein the second node is a visited SEPP having an FQDN "SEPP.

Another embodiment relates to a method performed by a second node implementing a Security Edge Protection Proxy (SEPP) in a visited network (e.g., a visited public land mobile network, VPLMN) for enabling communication with a third node implementing a second Network Function (NF) in a home network (e.g., a home public land mobile network, HPLMN), the method comprising: receiving, from a first node implementing a first NF in a visited network, a request for a scalable fully qualified domain name, FQDN, of a third node in a home network to be used by the first node in the visited network for communicating with the third node in the home network, the request including the FQDN of the third node in the home network; and sending the scalable FQDN of the third node to the first node, wherein the FQDN of the third node in the home network is flattened into a single label to be used by the first node for communication with the third node.

Certain embodiments may provide one or more of the following technical advantages. This solution provides a lot of flexibility and simplifies the generation and interoperability in the processing of scalable FQDNs.

Other proposed methods to solve this problem rely on a very basic algorithmic transformation of the original scalable FQDN, for example by replacing "-" in the original FQDN of the visited NF with the symbol "-" to create a single label, such as:

nrf.operator.com-＞nrf-operator-com

thus, the scalable FQDN will be:

nrf-operator-com.sepp.visited-operator.com

this is in fact an aesthetically unpleasing and inflexible solution, because due to the presence of "-" in the original FQDN, such as the example used repeatedly in this disclosure:

nrf.home-operator.com

such an FQDN would not be possible to transform with this algorithm. It should be noted that the only allowed non-alphabetic symbol in the FQDN is the "-" symbol, and therefore cannot be replaced with another symbol.

It has also been proposed to overcome this problem by replacing the "-" itself with multiple "-" symbols, but again this is extremely unsightly and inflexible (e.g. internationalized domain names typically contain two consecutive "-" symbols).

Moreover, another limitation of algorithmic transformations is that the total length of any given label cannot exceed 63 characters, so for long domain names involving multiple domain classes, the upper limit on length may be easily reached.

Another approach mentioned to address this problem is to configure the scalable FQDN of the home NRF at the visited NRF. This is also a very inefficient and cumbersome solution, as the configuration will involve the home NRF in each HPLMN with which a given PLMN has roaming agreements. Furthermore, this configuration is required not only at the visited NRF but also at the visited SEPP, since the visited SEPP needs to be able to map the scalable FQDN of the home NRF to the FQDN of the original home NRF.

Drawings

The proposed solution will now be described, by way of example, with reference to the accompanying drawings, in which:

fig. 1 illustrates one example of a cellular communication network 100 in accordance with some embodiments of the present disclosure;

fig. 2 illustrates a wireless communication system represented as a 5G network architecture;

fig. 3A illustrates a wireless communication system represented as a 5G network architecture;

FIG. 3B illustrates an exemplary roaming 5G reference architecture with a service-based interface in which some embodiments of the present disclosure may be implemented;

FIG. 4 illustrates an example of some embodiments of the present disclosure;

FIG. 5 illustrates an example of some embodiments of the present disclosure;

fig. 6 is a schematic block diagram of a node 600 implementing network functions in accordance with some embodiments of the present disclosure;

fig. 7 is a schematic block diagram illustrating a virtualized embodiment of a node 600 in accordance with some embodiments of the present disclosure;

fig. 8 is a schematic block diagram of a node 600 according to some other embodiments of the present disclosure.

Detailed Description

Some embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. However, other embodiments are included within the scope of the subject matter disclosed herein, and the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

The radio node: as used herein, a "radio node" is a radio access node or wireless device.

A radio access node: as used herein, a "radio access node" or "radio network node" is any node in a radio access network of a cellular communication network that operates to wirelessly transmit and/or receive signals. Some examples of radio access nodes include, but are not limited to, base stations (e.g., NR base stations (gnbs) in third generation partnership project (3GPP) fifth generation (5G) New Radio (NR) networks or enhanced or evolved node bs (enbs) in 3GPP Long Term Evolution (LTE) networks), high power or macro base stations, low power base stations (e.g., micro base stations, pico base stations, home enbs, etc.), and relay nodes.

A core network node: as used herein, a "core network node" is any type of node in a core network. Some examples of core network nodes include, for example, a Mobility Management Entity (MME), a packet data network gateway (P-GW), a Service Capability Exposure Function (SCEF), etc., such as any of the core network nodes shown in fig. 2 and 3A-3B.

The wireless device: as used herein, a "wireless device" is any type of device that accesses (i.e., is served by) a cellular communication network by wirelessly transmitting and/or receiving signals to a radio access node. Some examples of wireless devices include, but are not limited to, User Equipment (UE) and Machine Type Communication (MTC) devices in a 3GPP network.

A network node: as used herein, a "network node" is any node that is part of a radio access network or core network of a cellular communication network/system.

Note that the description given herein focuses on 3GPP cellular communication systems, and thus 3GPP terminology or terminology similar to 3GPP terminology is often used. However, the concepts disclosed herein are not limited to 3GPP systems.

Note that in the description herein, the term "cell" may be referred to; however, particularly with respect to the 5G NR concept, beams may be used instead of cells, and it is therefore important to note that the concepts described herein apply equally to cells and beams.

FIG. 1 shows a schematic view of a

Fig. 1 illustrates one example of a cellular communication network 100 in accordance with some embodiments of the present disclosure. In the embodiment described herein, the cellular communication network 100 is a 5G NR network. In this example, the cellular communication network 100 includes base stations 102-1 and 102-2 (referred to as eNBs in LTE and gNBs in 5G NR) that control corresponding macro cells 104-1 and 104-2. Base stations 102-1 and 102-2 are generally referred to herein collectively as base stations 102 and individually as base stations 102. Likewise, the macro cells 104-1 and 104-2 are generally referred to herein collectively as macro cells 104 and individually as macro cells 104. The cellular communication network 100 may also include a plurality of low power nodes 106-1 to 106-4 controlling corresponding small cells 108-1 to 108-4. The low-power nodes 106-1 to 106-4 may be small base stations (e.g., pico or femto base stations) or Remote Radio Heads (RRHs), etc. It is noted that although not shown, one or more of small cells 108-1 to 108-4 may alternatively be provided by base station 102. Low power nodes 106-1 through 106-4 are generally referred to herein collectively as low power nodes 106 and individually as low power nodes 106. Likewise, small cells 108-1 to 108-4 are generally referred to herein collectively as small cells 108 and individually as small cells 108. The base station 102 (and optionally the low power node 106) is connected to a core network 110.

Base station 102 and low-power node 106 provide service to wireless devices 112-1 through 112-5 in corresponding cells 104 and 108. The wireless devices 112-1 through 112-5 are generally referred to herein collectively as wireless devices 112 and individually as wireless devices 112. The wireless device 112 is also sometimes referred to herein as a UE.

FIG. 2

Fig. 2 illustrates a wireless communication system represented as a 5G network architecture composed of core Network Functions (NFs), where the interaction between any two NFs is represented by a point-to-point reference point/interface. Fig. 2 may be considered as one particular implementation of the system 100 of fig. 1.

The 5G network architecture shown in fig. 2 includes, seen from the access side, a plurality of User Equipments (UEs) connected to a Radio Access Network (RAN) or AN Access Network (AN) and AN access and mobility management function (AMF). Typically, r (an) includes a base station, such as an evolved node b (enb) or a 5G base station (gNB), etc. The 5G core NF shown in fig. 2 includes, as viewed from the core network side, core network nodes such as a Network Slice Selection Function (NSSF), an authentication server function (AUSF), a Unified Data Management (UDM), an AMF, a Session Management Function (SMF), a Policy Control Function (PCF), and an Application Function (AF).

The reference point representation of the 5G network architecture is used to develop detailed call flows in the specification standardization. The N1 reference point is defined to carry signaling between the UE and the AMF. Reference points for connecting AN and AMF and AN and UPF are defined as N2 and N3, respectively. There is a reference point N11 between the AMF and the SMF, which means that the SMF is at least partly controlled by the AMF. N4 is used by the SMF and the UPF so that the UPF can be set using control signals generated by the SMF and can report its status to the SMF. N9 is the reference point for the connection between different UPFs, and N14 is the reference point for the connection between different AMFs, respectively. Since the PCF applies policies to the AMF and SMP, respectively, N15 and N7 are defined. The AMF needs N12 to perform authentication of the UE. Since AMF and SMF require subscription data of the UE, N8 and N10 are defined.

The 5G core network is intended to separate the user plane and the control plane. The user plane carries user traffic and the control plane carries signaling in the network. In fig. 2, the UPF is in the user plane and all other NFs (i.e., AMF, SMF, PCF, AF, AUSF, and UDM) are in the control plane. Separating the user plane and the control plane ensures that each plane resource is scaled independently. It also allows the UPF to be deployed separately from the control plane functions in a distributed manner. In this architecture, the UPF may be deployed very close to the UE to shorten the Round Trip Time (RTT) between the UE and the data network for some applications that require low latency.

The core 5G network architecture consists of modular functions. For example, AMF and SMF are independent functions in the control plane. Separate AMF and SMF allow independent evolution and scaling. Other control plane functions, such as PCF and AUSF, may be separated as shown in fig. 2. The modular functional design enables the 5G core network to flexibly support various services.

Each NF interacts directly with another NF. An intermediate function may be used to route messages from one NF to another NF. In the control plane, the set of interactions between two NFs is defined as a service so that it can be reused. The service can support modularity. The user plane supports interactions such as forwarding operations between different UPFs.

FIG. 3A

Fig. 3A illustrates a 5G network architecture that uses service-based interfaces between NFs in the control plane instead of the point-to-point reference points/interfaces used in the 5G network architecture of fig. 2. However, the NF described above with reference to fig. 2 corresponds to the NF shown in fig. 3A. Services, etc., that the NF provides to other authorized NFs may be exposed to the authorized NFs through a service-based interface. In fig. 3A, the service-based interface is indicated by the name of the letter "N" followed by NF, e.g. Namf denotes a service-based interface of AMF and Nsmf denotes a service-based interface of SMF, etc. The Network Exposure Function (NEF) and the Network Repository Function (NRF) in fig. 3A are not shown in fig. 2 described above. However, it should be clear that all NFs depicted in fig. 2 may interact with NEFs and NRFs of fig. 3A as needed, although not explicitly indicated in fig. 2.

Some of the attributes of the NF shown in fig. 2 and 3A may be described in the following manner. The AMF provides UE-based authentication, authorization, mobility management, etc. Even UEs using multiple access technology are basically connected to a single AMF because the AMF is independent of the access technology. The SMF is responsible for session management and assigns an Internet Protocol (IP) address to the UE. It also selects and controls the UPF for data transmission. If the UE has multiple sessions, each session may be assigned a different SMF to manage them individually and possibly provide different functionality for each session. The AF provides information about the packet flow to the PCF responsible for policy control in order to support quality of service (QoS). Based on this information, the PCF determines policies regarding mobility and session management to make the AMF and SMF operate properly. The AUSF supports authentication functions of the UE or the like and thus stores authentication data of the UE or the like, while the UDM stores subscription data of the UE. A Data Network (DN) (not part of the 5G core network) provides internet access or operator services, etc.

The UDM is similar to the HSS in the LTE/EPC network described above. UDM supports the generation of 3gpp aka authentication credentials, user identification processing, subscription data based access authorization and other subscriber related functions. To provide this functionality, the UDM uses subscription data (including authentication data) stored in a 5GC Unified Data Repository (UDR). In addition to UDM, UDR supports PCF storage and retrieval of policy data and NEF storage and retrieval of application data.

FIG. 3B

Fig. 3B illustrates an exemplary roaming 5G reference architecture with a service-based interface. In this reference architecture, a user roams into a visited Public Land Mobile Network (PLMN), which is different from the user's home PLMN (hplmn). In particular, fig. 3B illustrates a roaming architecture that supports home routed data services, where the administrative domain of the home operator is involved in a user's data session and the UE interfaces with the Data Network (DN) in the HPLMN. From the user's perspective, the various network functions of the HPLMN shown in the non-roaming architecture of fig. 3A are distributed among the HPLMN and VPLMN in the home routing roaming architecture shown in fig. 3B. For example, AMF is in VPLMN, AUSF is in HPLMN, SMF and UPF are present in both VPLMN and HPLMN (e.g., dispersed between VPLMN and HPLMN). To distinguish these functions that exist in the two networks, the prefix "H" or "V" may be used, such as "H-UPF" and "V-UPF".

In roaming and non-roaming scenarios, a user (e.g., a UE) may wish to establish a data session (also referred to as a "PDU session") with a data network (DN, e.g., the internet) via a 5G network. The term "PDU" (shortly, "protocol data unit") is generally used to refer to a data unit specified in the protocol layer and comprising protocol control information and possibly user data. "PDU" is often used interchangeably with "packet". The PDU session establishment may correspond to any one of:

PDU conversation establishment process initiated by UE;

PDU session switching between 3GPP and non-3 GPP networks initiated by UE;

UE initiated PDU session handover from LTE to NR (e.g., EPC to 5 GC); and

network triggered PDU session establishment procedure. In this case, the network sends a device trigger message to the application on the UE side. The payload included in the device trigger request message contains information about which application on the UE side is expected to trigger the PDU session setup request. Based on this information, the application on the UE side triggers the PDU session setup procedure.

For UE-initiated (or UE-requested) PDU session establishment based on home route roaming, the functions in the VPLMN typically need to exchange information about the user with their peers and/or corresponding functions in the HPLMN. For example, V-SMF typically needs to exchange information with H-SMF. However, various problems and/or difficulties may arise due to the VPLMN function (e.g., V-SMF) lacking the necessary information regarding the corresponding HPLMN function (e.g., H-SMF).

The NF may be implemented as a network element on dedicated hardware, as a software instance running on dedicated hardware, or as a virtualized function instantiated on an appropriate platform (e.g., cloud infrastructure). The NF may be an example of NF.

FIG. 4

Fig. 4 illustrates an example of some embodiments of the present disclosure. The visited NRF (e.g., NRF instance) needs to send a message (service request) to the home NRF (e.g., NRF instance) (step 400). The use case may be:

-discovery request

-Oauth2 Access token request

-subscription to the home NRF to be notified of events of NFs registered in the home NRF the FQDN of the home NRF may be determined by the visited NRF as:

standard FQDN constructed from MCC/MNC of home PLMN

Roaming agreements between locally configured, self-visited/home PLMNs

Before sending the service request to the home NRF, the visited NRF sends a request to the visited SEPP to obtain a scalable FQDN of the home NRF (step 402). For example, the visited NRF may send a GET request to the visited SEPP, such as: GET https: v/SEPP. found-operator.com/telescomicfqdn ═ NRF. home-operator.com ", where" SEPP. found-operator.com "is the FQDN of the visited SEPP and" NRF. home-operator.com "is the FQDN of the home NRF. The address/ID of the visited SEPP (e.g. SEPP. visited-operator. com) may be configured locally in the visited NRF unless the visited SEPP providing this new service registers itself as any other NF within the 5GC in the visited NRF, in which case the visited NF may perform service discovery on the visited NRF to discover the service provided by the visited SEPP.

The accessed SEPP creates a scalable FQDN (step 404), for example by generating a random tag (e.g., with only letters, numbers, and possibly a "-" symbol) and appending it to the FQDN of the accessed SEPP, for example in a JSON document, as follows:

{″telescopic″：″0x1273bc89.sepp.visited-operator.com″}

here, an exemplary random label is "0 x1273bc 89". The scalable FQDN of the home NRF is returned to the visited NRF (step 406), where it is flattened into a single label.

The visited NRF sends a service request (step 408) (discovery, token request, subscribe … …) using the flattened scalable FQDN, for example by concatenating the flattened scalable FQDN with the FQDN of the visited SEPP, which effectively points to the IP address of the visited SEPP, so the SEPP can terminate the TLS connection and expose a valid wildcard certificate. In view of the TLS terminating at the visited SEPP, it can decrypt the message (service request) and proceed with the necessary modifications before sending it externally to another PLMN.

Based on the scalable FQDN (flattened to a single label) sent by the visited NRF, the visited SEPP checks the mapping table and obtains the actual FQDN of the home NRF (step 410).

The visited SEPP routes the message to the home PLMN (step 412), i.e. the message is effectively sent to the home SEPP, and possibly through an additional intermediary in the IPX. The remainder of the procedure is outside the scope of this disclosure.

Another embodiment proposes the following possibilities: the visited SEPP disclosing to other NFs the new service generating a scalable FQDN is different from the visited SEPP through which the NF will send the actual service request; that is, the visited SEPPs used in step 402 and step 408 in fig. 4 are different visited SEPP instances. This is shown in fig. 5.

FIG. 5

The visited NRF obtains the scalable FQDN of the home NRF from one of the SEPP instances (visited SEPP1) that disclose the service within the VPLMN, as shown in fig. 4 (steps 400 and 406, corresponding to steps 500 and 506, respectively, in fig. 5).

According to some embodiments of the present disclosure, the visited SEPP1 providing this service may select the actual visited SEPP (e.g., visited SEPP2) that the visited NRF should use to send the actual service request to the HPLMN. To this end, visited SEPP1 may generate a scalable FQDN in the domain of SEPP2 as follows:

{″telescopic″：″label.sepp2.visited-operator.com″}

the visited NRF sends a service request (step 508) (discovery, token request, subscribe … …) to the flattened scalable FQDN, which effectively points to the IP address of the visited SEPP. The NRF selects a different visited SEPP instance (visited SEPP2) than the visited SEPP instance used in step 2 above, e.g. based on local configuration or based on information within the scalable FQDN provided by visited SEPP 1.

If the visited SEPP2 does not recognize a label within the scalable FQDN, the visited SEPP2 obtains the actual FQDN of the home NRF based on the scalable FQDN sent by the visited NRF from the visited SEPP1 (which generates the scalable FQDN) (step 510); i.e., the visited SEPP1 (e.g., "SEPP 1-0x1273bc 89").

In this case, the visited SEPP1 also discloses services to resolve scalable FQDNs (i.e., mapping labels to FQDNs of home NRFs). Flow continues as described in fig. 4, with step 512 being similar to step 412.

FIG. 6

Fig. 6 is a schematic block diagram of a node 600 (e.g., a core network node) implementing network functions in accordance with some embodiments of the present disclosure. The node 600 may for example be a core network node, such as any of NEF, AUSF, UDM, AMF, SMF, PCF, UPF, etc., in particular NSSF or NRF or SEPP, etc. As shown, node 600 includes a control system 602 that includes one or more processors 604 (e.g., a Central Processing Unit (CPU), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA), etc.), a memory 606, and a network interface 608. The one or more processors 604 are also referred to herein as processing circuits. One or more processors 604 are operative to provide one or more functions of node 600 as described herein. In some embodiments, these functions are implemented in software, for example, stored in the memory 606 and executed by the one or more processors 604.

FIG. 7

Fig. 7 is a schematic block diagram illustrating a virtualization embodiment of a node 600 according to some embodiments of the present disclosure. The present discussion is equally applicable to other types of network nodes. In addition, other types of network nodes may have similar virtualization architectures.

As used herein, a "virtualized" node is an embodiment of node 600 in which at least a portion of the functionality of node 600 is implemented as a virtual component (e.g., via a virtual machine executing on a physical processing node in a network). As shown, in this example, node 600 includes a control system 602 that includes one or more processors 604 (e.g., CPUs, ASICs, FPGAs, etc.), memory 606, and a network interface 608. Control system 602 is connected via network interface 608 to one or more processing nodes 700, the one or more processing nodes 700 being coupled to or included as part of network 702. Each processing node 700 includes one or more processors 704 (e.g., CPUs, ASICs, FPGAs, etc.), memory 706, and a network interface 708.

In this example, the functionality 710 of the node 600 described herein is implemented at one or more processing nodes 700 or distributed across the control system 602 and one or more processing nodes 700 in any desired manner. In some particular embodiments, some or all of the functions 710 of node 600 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment hosted by processing node 700. As will be appreciated by those of ordinary skill in the art, additional signaling or communication between the processing node 700 and the control system 602 is used in order to perform at least some of the desired functions 710. It is noted that in some embodiments, control system 602 may not be included, in which case radio unit 610 communicates directly with processing node 700 via an appropriate network interface.

In some embodiments, a computer program is provided comprising instructions which, when executed by at least one processor, cause the at least one processor to perform the functions of node 600 or a node (e.g. processing node 700) according to any of the embodiments described herein that implements one or more functions 710 of node 600 in a virtual environment. In some embodiments, a carrier is provided that includes the computer program product described above. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as a memory).

FIG. 8

Fig. 8 is a schematic block diagram of a node 600 according to some other embodiments of the present disclosure. Node 600 includes one or more modules 800, each implemented in software. Module 800 provides the functionality of node 600 as described herein. The present discussion applies equally to the processing node 700 of fig. 7, where the module 800 may be implemented at one of the processing nodes 700 or distributed across multiple processing nodes 700 and/or across processing nodes 700 and control system 602.

Any suitable steps, methods, features, functions or benefits disclosed herein may be performed by one or more functional units or modules of one or more virtual devices. Each virtual device may include a plurality of such functional units. These functional units may be implemented via processing circuitry (which may include one or more microprocessors or microcontrollers) as well as other digital hardware, which may include a Digital Signal Processor (DSP), dedicated digital logic, or the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or more types of memory, such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, and so forth. Program code stored in the memory includes program instructions for executing one or more telecommunications and/or data communications protocols and instructions for performing one or more of the techniques described herein. In some implementations, the processing circuitry may be configured to cause the respective functional units to perform corresponding functions in accordance with one or more embodiments of the present disclosure.

While the processes in the figures may show a particular order of operations performed by certain embodiments of the disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

Some of the embodiments described above may be summarized in the following manner:

1. a method performed by a first node (420) implementing a first network function, NF, in a visited network (VPLMN) for communicating with a third node (430) implementing a second NF in a home network (HPLMN), the method comprising:

-determining (400) a third node with which communication should be made;

-sending (402) a request to a second node (440) implementing a security edge protection proxy, SEPP, in the visited network for a scalable fully qualified domain name, FQDN, of a third node in the home network to be used by the first node in the visited network for communicating with the third node in the home network, the request comprising the FQDN of the third node in the home network;

-receiving (406) a scalable FQDN of a third node from the second node, wherein the FQDN of the third node in the home network is flattened to a single label to be used by the first node for communication with the third node.

2. The method of embodiment 1, further comprising: communicating (408, 508) with a third node in the home network via a second node in the visited network using the received scalable FQDN of the third node, wherein the FQDN of the third node in the home network is flattened to a single label.

3. The method of any of embodiments 1-2, further comprising: communicating (408) with a third node in the home network by sending a service request comprising the received scalable FQDN of the third node to the second node in the visited network.

4. The method of embodiment 3, wherein the service request is any one of: a discovery request, an Oauth2 access token request, or a subscription request.

5. The method of any of embodiments 1-4, wherein one or more of: the first node implements a visited NRF; the second node implements the visited SEPP; and the third node implements the home NRF.

6. The method according to any of embodiments 1-5, wherein requesting a scalable FQDN comprises sending an FQDN of a third node in a home network.

7. The method of any of embodiments 1-6, wherein receiving a scalable FQDN comprises receiving a flattened FQDN for a third node.

8. The method of any of embodiments 2-7, further comprising: communicating with a third node by sending a service request to another node (SEPP2) using a scalable FQDN to be used for communicating with the third node.

9. A method performed by a second node (440) implementing a security edge protection proxy, SEPP, in a visited network (VPLMN) for enabling communication with a third node (430) implementing a second network function, NF, in a home network (HPLMN), the method comprising:

-receiving (402), from a first node (420) implementing a first NF in the visited network, a request for a scalable fully qualified domain name, FQDN, of a third node in the home network to be used by the first node in the visited network for communicating with the third node in the home network, the request comprising the FQDN of the third node in the home network; and

-sending (406) to the first node the scalable FQDN of the third node, wherein the FQDN of the third node in the home network is flattened to a single label to be used by the first node for communication with the third node.

10. The method of embodiment 9, wherein one or more of: the first node implements a visited NRF; the second node implements the visited SEPP; and the third node implements the home NRF.

11. The method of any of embodiments 9-10, wherein receiving the request for the scalable FQDN comprises: an FQDN of a third node in the home network is received.

12. The method of any of embodiments 9-11, wherein transmitting a scalable FQDN comprises transmitting a flattened FQDN of a third node.

13. The method of any of embodiments 9-12, wherein transmitting a scalable FQDN comprises transmitting a scalable FQDN for a third node, wherein the FQDN for the third node in the home network is flattened into a single label.

14. The method of any of embodiments 9-13, further comprising: a service request is received (408) from the first node, the service request including the received scalable FQDN for communicating with a third node on behalf of the first node using the scalable FQDN.

15. A first node (420) implementing a first network function, NF, in a visited network (VPLMN) for communicating with a third node (430) implementing a second NF in a home network (HPLMN), the first node comprising:

-processing circuitry configured to perform the steps according to any of embodiments 1-8.

16. A second node (440) implementing a security edge protection proxy, SEPP, in a visited network (VPLMN) for enabling communication with a third node (430) implementing a second network function, NF, in a home network (HPLMN), the second node comprising:

-processing circuitry configured to perform the steps according to any of embodiments 9-14.

Some other embodiments described above may be summarized in the following manner:

group A examples

1. A method performed by a first node (420) implementing a first network function, NF, in a visited network (VPLMN) for communicating with a third node (430) implementing a second NF in a home network (HPLMN), the method comprising:

-determining (400) a third node with which communication should be made;

-requesting (402), from a second node (440) implementing a security edge protection proxy, SEPP, in the visited network, a scalable fully qualified domain name, FQDN, of a third node in the home network to be used by the first node in the visited network for communicating with the third node;

-receiving (406), from the second node, a scalable FQDN of a third node to be used by the first node for communication with the third node.

2. The method according to the previous embodiment, further comprising: the received scalable FQDN for the third node is used to communicate (408) with the third node in the home network via the second node in the visited network.

3. The method of any of embodiments 1-2, further comprising: communicating (408) with a third node in the home network by sending a service request comprising the received scalable FQDN of the third node to the second node in the visited network.

4. The method of embodiment 3, wherein the service request is any one of: a discovery request, an Oauth2 access token request, or a subscription request.

5. The method according to any of the preceding embodiments, wherein one or more of: the first node implements a visited NRF; the second node implements the visited SEPP; and the third node implements the home NRF.

6. The method of any preceding embodiment, wherein requesting a scalable FQDN comprises sending an FQDN of a third node in the home network.

7. The method of any preceding embodiment, wherein receiving a scalable FQDN comprises receiving a flattened FQDN for a third node.

8. The method of any preceding embodiment, wherein receiving a scalable FQDN comprises receiving a scalable FQDN, wherein the FQDN of a third node in the home network is flattened into a single label.

9. The method of any of embodiments 2-7, further comprising:

-communicating with the third node by sending a service request to another node (SEPP2) using the scalable FQDN to be used for communicating with the third node.

Group B examples

10. A method performed by a second node (440) implementing a security edge protection proxy, SEPP, in a visited network (VPLMN) for enabling communication with a third node (430) implementing a second network function, NF, in a home network (HPLMN), the method comprising:

-receiving (402), from a first node (420) implementing a first NF in a visited network, a request for a scalable fully qualified domain name, FQDN, for a third node in a home network to be used by the first node in the visited network for communicating with the third node; and

-sending (406) to the first node a scalable FQDN of a third node to be used for communication with a third node in the home network.

11. The method of embodiment 10, wherein one or more of: the first node implements a visited NRF; the second node implements the visited SEPP; and the third node implements the home NRF.

12. The method of any of embodiments 10-11, wherein receiving a request for a scalable FQDN to be used for communication with a third node comprises receiving an FQDN of a third node in a home network.

13. The method of any of embodiments 10-12 wherein sending a scalable FQDN to be used for communication with a third node comprises sending a flattened FQDN for the third node.

14. The method of any of embodiments 10-13, wherein sending a scalable FQDN to be used for communication with a third node comprises sending a scalable FQDN for the third node, wherein the FQDN for the third node in the home network is flattened into a single label.

15. The method of any of embodiments 10-14, further comprising: a service request is received (408) from the first node, the service request including the received scalable FQDN for communicating with a third node on behalf of the first node using the scalable FQDN.

Group C examples

16. A first node (420) implementing a first network function, NF, in a visited network (VPLMN) for communicating with a third node (430) implementing a second NF in a home network (HPLMN), the first node comprising:

-processing circuitry configured to perform any of the steps according to any of group a embodiments.

17. A second node (440) implementing a security edge protection proxy, SEPP, in a visited network (VPLMN) for enabling communication with a third node (430) implementing a second network function, NF, in a home network (HPLMN), the second node comprising:

-processing circuitry configured to perform any of the steps according to any of group B embodiments.

While various embodiments of the present disclosure have been described herein, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments. Moreover, this disclosure encompasses all possible variations of any combination of the above-described elements, unless otherwise indicated herein or otherwise clearly contradicted by context.

Additionally, while the processes or methods described above and shown in the figures are shown as a series of steps, this is done for illustrative purposes only. Thus, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be rearranged, and some steps may be performed in parallel.