WO2025231876A1

WO2025231876A1 - Public land mobile network protection

Info

Publication number: WO2025231876A1
Application number: PCT/CN2024/092444
Authority: WO
Inventors: Bo Holm BJERRUM; Saurabh Khare; Jing PING
Original assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy; Nokia Technologies Oy
Current assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy; Nokia Technologies Oy
Priority date: 2024-05-10
Filing date: 2024-05-10
Publication date: 2025-11-13
Anticipated expiration: 2026-11-10

Abstract

Example embodiments of the present disclosure relate to a solution for protecting public land mobile network. In the proposed solution, a first network device receives, from a second network device, a first message for a network service. The first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to a second domain, and the first message comprises a domain name indicating the second domain. Based on the first message, the first network device transmits, to a third network device, a second message comprising the domain name.

Description

PUBLIC LAND MOBILE NETWORK PROTECTION

FIELD

Various example embodiments of the present disclosure generally relate to the field of telecommunication and in particular, to methods, devices, apparatuses and computer readable storage medium for protecting public land mobile network.

BACKGROUND

With developments in the integration of Public Network Integrated Non Public Network (PNI-NPN) , protecting public land mobile networks (PLMN) from security vulnerabilities has become increasingly crucial. The main challenge is ensuring secure communication and safeguarding sensitive information, facilitated by the service communication proxy (SCP) . Therefore, it is worth studying the enhancements for SCP security measures to protect PLMN from PNI-NPN, ensuring reliable and secure network operations.

SUMMARY

In a first aspect of the present disclosure, there is provided a first network device. The first apparatus comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the first network device at least to: receive, from a second network device, a first message for a network service, wherein the first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to a second domain, and the first message comprises a domain name indicating the second domain; and transmit, to a third network device, a second message based on the first message, the second message comprising the domain name.

In a second aspect of the present disclosure, there is provided a second network device. The second apparatus comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the second network device at least to: transmit, to a first network device, a first message for a network service, wherein the first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to a second domain, and the first message comprises a domain name indicating the second domain.

In a third aspect of the present disclosure, there is provided a third network device. The third apparatus comprises at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the third network device at least to: receive, from a first network device, a second message comprising a domain name indicating a second domain, wherein the second message is transmitted from the first network device based on a first message for a network service, wherein the first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to the second domain, and the first message comprises the domain name indicating the second domain.

In a fourth aspect of the present disclosure, there is provided a method. The method comprises: receiving, from a second network device, a first message for a network service, wherein the first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to a second domain, and the first message comprises a domain name indicating the second domain; and transmitting, to a third network device, a second message based on the first message, the second message comprising the domain name.

In a fifth aspect of the present disclosure, there is provided a method. The method comprises: transmitting, to a first network device, a first message for a network service, wherein the first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to a second domain, and the first message comprises a domain name indicating the second domain.

In a sixth aspect of the present disclosure, there is provided a method. The method comprises: receiving, from a first network device, a second message comprising a domain name indicating a second domain, wherein the second message is transmitted from the first network device based on a first message for a network service, wherein the first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to the second domain, and the first message comprises the domain name indicating the second domain.

In a seventh aspect of the present disclosure, there is provided a first network device. The first apparatus comprises means for receiving, from a second network device, a first message for a network service, wherein the first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to a second domain, and the first message comprises a domain name indicating the second domain; and means for transmitting, to a third network device, a second message based on the first message, the second message comprising the domain name.

In an eighth aspect of the present disclosure, there is provided a second network device. The second apparatus comprises means for transmitting, to a first network device, a first message for a network service, wherein the first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to a second domain, and the first message comprises a domain name indicating the second domain.

In a ninth aspect of the present disclosure, there is provided a third network device. The third apparatus comprises means for receiving, from a first network device, a second message comprising a domain name indicating a second domain, wherein the second message is transmitted from the first network device based on a first message for a network service, wherein the first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to the second domain, and the first message comprises the domain name indicating the second domain.

In a tenth aspect of the present disclosure, there is provided a computer readable medium. The computer readable medium comprises instructions stored thereon for causing an apparatus to perform at least the method according to the fourth aspect.

In an eleventh aspect of the present disclosure, there is provided a computer readable medium. The computer readable medium comprises instructions stored thereon for causing an apparatus to perform at least the method according to the fifth aspect.

In a twelfth aspect of the present disclosure, there is provided a computer readable medium. The computer readable medium comprises instructions stored thereon for causing an apparatus to perform at least the method according to the sixth aspect.

It is to be understood that the Summary section is not intended to identify key or essential features of embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become easily comprehensible through the following description.

BRIEF DESCRIPTION OF THE DRAWINGS

Some example embodiments will now be described with reference to the accompanying drawings, where:

FIG. 1 illustrates an example block of main RF requirements for in-band and out-of-band;

FIG. 2A and FIG. 2B illustrate schematic diagrams of scenarios proposed in technical solutions;

FIG. 3A illustrates an example workflow diagram of NPN network function (NF) subscribing notification from NF of PLMN in accordance with some embodiments of the present disclosure;

FIG. 3B illustrates an example workflow diagram of PLMN NF subscribing notification from NF of NPN in accordance with some embodiments of the present disclosure;

FIG. 4 illustrates a signaling flow of communication between first network device, second network device and third network device in accordance with some embodiments of the present disclosure;

FIG. 5A illustrates an example workflow diagram of registration and consumer NF services of PLMN in accordance with some embodiments of the present disclosure;

FIG. 5B illustrates an example workflow diagram of subscribing for notification from PLMN in accordance with some embodiments of the present disclosure;

FIG. 5C illustrates an example workflow diagram of subscribing for notification from NPN by PLMN NF in accordance with some embodiments of the present disclosure;

FIG. 5D illustrates an example workflow diagram of subscribing for notification from NPN by NPN NF in accordance with some embodiments of the present disclosure;

FIG. 6 illustrates a flowchart of a communication method implemented at a first network device according to some example embodiments of the present disclosure;

FIG. 7 illustrates a flowchart of a communication method implemented at a second network device according to some example embodiments of the present disclosure;

FIG. 8 illustrates a flowchart of a communication method implemented at a third network device according to some example embodiments of the present disclosure;

FIG. 9 illustrates a simplified block diagram of a device that is suitable for implementing example embodiments of the present disclosure; and

FIG. 10 illustrates a block diagram of an example computer readable medium in accordance with some example embodiments of the present disclosure.

Throughout the drawings, the same or similar reference numerals represent the same or similar element.

DETAILED DESCRIPTION

Principle of the present disclosure will now be described with reference to some example embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. Embodiments described herein can be implemented in various manners other than the ones described below.

In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

References in the present disclosure to “one embodiment, ” “an embodiment, ” “an example embodiment, ” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

It shall be understood that although the terms “first, ” “second” and the like may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and/or” includes any and all combinations of one or more of the listed terms.

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

As used herein, unless stated explicitly, performing a step “in response to A” does not indicate that the step is performed immediately after “A” occurs and one or more intervening steps may be included.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and/or “including” , when used herein, specify the presence of stated features, elements, and/or components etc., but do not preclude the presence or addition of one or more other features, elements, components and/or combinations 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.

As used herein, the term “communication network” refers to a network following any suitable communication standards, such as New Radio (NR) , Long Term Evolution (LTE) , LTE-Advanced (LTE-A) , Wideband Code Division Multiple Access (WCDMA) , High-Speed Packet Access (HSPA) , Narrow Band Internet of Things (NB-IoT) and so on. Furthermore, the communications between a terminal device and a network device in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the fourth generation (4G) , 4.5G, the fifth generation (5G) and the sixth generation (6G) communication protocols, and/or any other protocols either currently known or to be developed in the future. Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will of course also be future type communication technologies and systems with which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system.

As used herein, the term “network device” refers to a node in a communication network via which a terminal device accesses the network and receives services therefrom. The network device may refer to a base station (BS) or an access point (AP) , for example, a node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , an NR NB (also referred to as a gNB) , a Remote Radio Unit (RRU) , a radio header (RH) , a remote radio head (RRH) , a relay, an Integrated Access and Backhaul (IAB) node, a low power node such as a femto, a pico, a non-terrestrial network (NTN) or non-ground network device such as a satellite network device, a low earth orbit (LEO) satellite and a geosynchronous earth orbit (GEO) satellite, an aircraft network device, and so forth, depending on the applied terminology and technology. In some example embodiments, radio access network (RAN) split architecture comprises a Centralized Unit (CU) and a Distributed Unit (DU) at an IAB donor node. An IAB node comprises a Mobile Terminal (IAB-MT) part that behaves like a UE toward the parent node, and a DU part of an IAB node behaves like a base station toward the next-hop IAB node.

The term “terminal device” refers to any end device that may be capable of wireless communication. By way of example rather than limitation, a terminal device may also be referred to as a communication device, user equipment (UE) , a Subscriber Station (SS) , a Portable Subscriber Station, a Mobile Station (MS) , or an Access Terminal (AT) . The terminal device may include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA) , portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , USB dongles, smart devices, wireless customer-premises equipment (CPE) , an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD) , a vehicle, a drone, a medical device and applications (e.g., remote surgery) , an industrial device and applications (e.g., a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts) , a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. The terminal device may also correspond to a Mobile Termination (MT) part of an IAB node (e.g., a relay node) . In the following description, the terms “terminal device” , “communication device” , “terminal” , “user equipment” and “UE” may be used interchangeably.

As used herein, the term “resource, ” “transmission resource, ” “resource block, ” “physical resource block” (PRB) , “uplink resource, ” or “downlink resource” may refer to any resource for performing a communication, for example, a communication between a terminal device and a network device, such as a resource in time domain, a resource in frequency domain, a resource in space domain, a resource in code domain, or any other resource enabling a communication, and the like.

As used herein, the term "NPN" refers to Non-Public Network, a concept within the realm of telecommunications, particularly in the context of 5G networks. An NPN is designed to provide network services that are not available to the general public, catering instead to specific users or entities such as enterprises, factories, campuses, or government facilities.

As used herein, the term "PNI-NPN" refers to Public Network Integrated Non-Public Network, a concept within cellular network technology, particularly in the context of 5G networks. PNI-NPN is designed to provide a seamless integration between a public land mobile network (PLMN) and non-public networks (NPNs) , which are typically private networks that serve specific entities or locations such as factories, campuses, or specific business premises.

As used herein, the term "PLMN" refers to Public Land Mobile Network, a standard term used in the telecommunications industry to describe any wireless communications system intended for use by terrestrial subscribers in vehicles or on foot. This term is widely used to specify networks that provide various mobile services such as voice and data communications to the general public.

As used herein, the term "SCP" refers to Service Communication Proxy, a functional entity in telecommunications, particularly within the 5G architecture. SCP plays a crucial role in the service-based architecture (SBA) of 5G networks by acting as a mediator and facilitator for service interactions between network functions.

As used herein, the term "NRF" refers to Network Repository Function, a component within the 5G network's Service-Based Architecture (SBA) . The NRF plays a pivotal role in managing the discovery and registration of network functions in a 5G system.

As used herein, the term "CCA" refers to Client Credentials Assertion, which is a security mechanism often used for the authorization of server-to-server interactions. The client credentials grant type enables a client application to directly obtain an access token from the authorization server using its own credentials, rather than acting on behalf of a specific user.

As used herein, the term "URI" refers to Uniform Resource Identifier, a compact sequence of characters that identifies an abstract or physical resource. A URI can be used for various purposes, ranging from locating resources on the internet to identifying resources in more abstract data processing systems.

Example Environment

FIG. 1 illustrates an example communication environment 100 in which example embodiments of the present disclosure can be implemented.

In the specific example of FIG. 1, communication environment 100 comprises a plurality of communication network devices, a first network device 110, a second network device 120, and a third network device 130. The first network device 110, the second network device 120 and the third network device 130 can communicate with each other. In some embodiments, communication environment 100 also comprise the fourth network device 140 and other network devices.

In the following, for the purpose of illustration, some example embodiments are described with the first network device 110 comprises a Service Communication Proxy (SCP) in the first network; the second network device 120 a network function (NF) consumer in the second network or a network function (NF) service consumer in the first network; the third network device 130 comprises a Network Repository Function (NRF) node in the first network or a NF service producer in the second network; and the fourth network device 140 operating as AMF.

In some example embodiments, the network function consumer may be the AMF, and the network function producer may be UDM.

Alternatively, in some other example embodiments, the network function consumer may be the NWDAF, and the network function producer may be AMF.

Alternatively, in some further example embodiments, the network function consumer may be the SMF, and the network function producer may be AMF.

It is to be understood that the number of network devices and their connections shown in FIG. 1 are only for the purpose of illustration without suggesting any limitation. In the other example embodiments, the communication environment 100 may include any suitable number of devices configured to implementing example embodiments of the present disclosure.

Communications in the communication environment 100 may be implemented according to any proper communication protocol (s) , comprising, but not limited to, cellular communication protocols of the first generation (1G) , the second generation (2G) , the third generation (3G) , the fourth generation (4G) , the fifth generation (5G) , the sixth generation (6G) , and the like, wireless local network communication protocols such as Institute for Electrical and Electronics Engineers (IEEE) 802.11 and the like, and/or any other protocols currently known or to be developed in the future. Moreover, the communication may utilize any proper wireless communication technology, comprising but not limited to: Code Division Multiple Access (CDMA) , Frequency Division Multiple Access (FDMA) , Time Division Multiple Access (TDMA) , Frequency Division Duplex (FDD) , Time Division Duplex (TDD) , Multiple-Input Multiple-Output (MIMO) , Orthogonal Frequency Division Multiple (OFDM) , Discrete Fourier Transform spread OFDM (DFT-s-OFDM) and/or any other technologies currently known or to be developed in the future.

Both scpdomain and nfdomain has been defined. ScpDomain is an optional attribute of NF Profile. An NF (other than a SCP) can register at most one SCP domain in NF profile, i.e. the NF can belong to only one SCP domain. If an NF (other than a SCP) includes this information in its profile, this indicates that the services produced by this NF should be accessed preferably via an SCP from the SCP domain the NF belongs to. A SCP can belong to a list of scp domains, accordingly, scpinfo includes a list of scpDomainInfo, and definition of type scpDomainInfo is shown in below Table 1.

Table 1 Definition of type ScpDomainInfo

NfDomain is one of the properties of the NF-Service-Consumer, which is part of FQDN of the NF-Service-Consumer in the Network Repository Function (NRF) /NF service request. When a NF-Service-Consumer discovers a NF service from NRF or requests an access-token from NRF, the NRF matches the properties of the NF-Service-Consumer against these rules in decreasing order of priority, and 1 is the highest. The properties of the NF-Service-Consumer include for example, PLMN, Standalone Non-Public Network (SNPN) , nfType, NfDomain, Single Network Slice Selection Assistance Information (S-NSSAIs) , NF-Instance Id and son on. If a match is found, search stops, and the matching rule is applied to determine the scope to be granted. The definition of type NFProfile is shown in the following Table 2.

Table 2 Definition of type NFProfile

Communications in the communication environment 400 may be implemented according to any proper communication protocol (s) , comprising, but not limited to, cellular communication protocols of the first generation (1G) , the second generation (2G) , the third generation (3G) , the fourth generation (4G) , the fifth generation (5G) , the sixth generation (6G) , and the like, wireless local network communication protocols such as Institute for Electrical and Electronics Engineers (IEEE) 802.11 and the like, and/or any other protocols currently known or to be developed in the future. Moreover, the communication may utilize any proper wireless communication technology, comprising but not limited to: Code Division Multiple Access (CDMA) , Frequency Division Multiple Access (FDMA) , Time Division Multiple Access (TDMA) , Frequency Division Duplex (FDD) , Time Division Duplex (TDD) , Multiple-Input Multiple-Output (MIMO) , Orthogonal Frequency Division Multiple (OFDM) , Discrete Fourier Transform spread OFDM (DFT-s-OFDM) and/or any other technologies currently known or to be developed in the future.

Work Principle and Example Signalling for Communication

The New R19 Study on security for PLMN hosting a NPN include justification and objectives as the following. A predefined standard TS 22.261 documented the scenario where dedicated network entities of NPN can be deployed in customer premises that are outside the control of the PLMN operator. TS 22.261 also proposed the requirement that the 5G system shall enable a PLMN to host an NPN without compromising the security of the PLMN. In some scenarios, the interface between customer premises and operator premises is non-service-based architecture (SBA) interface (i.e. N4) . In other scenarios, the interface between customer premises and operator premises is SBA interface. These two kinds of scenarios are described in more details below referring to FIG. 2A and FIG. 2B. Dedicated NFs deployed in customer premises may be compromised due to several reasons, for example, weaker physical perimeters, misconfiguration and so on. In some technical solutions, Network Domain Security for Internet Protocol (NDS/IP) and SBA security can provide authentication, authorization, confidentiality, integrity and anti-replay protection. However, if attackers exploit compromised dedicated NFs to launch, such as Distributed Denial of Service (DDoS) , malformed signaling messages, topology information exposure and so on, the NDS/IP or SBA security cannot protect PLMN from attacks. Therefore, it is proposed to study how to guarantee the security level of PLMN considering the potential attacks from the compromised dedicated NFs.

Based on the above justification, the following objectives will be studied. The objectives include identifying which dedicated NFs are likely to be hosted by NPN in customer premises, identifying key issues and potential security requirements for the scenarios of PLMN hosting a NPN with dedicated NFs deployed in customer premises, and developing solutions to address the identified requirements if necessary.

Reference is made to FIG. 2A and FIG. 2B, which illustrate the forgoing described scenarios proposed in new R19 Study. New R19 Study on security for PLMN hosting a NPN was approved in last SA3 and SA meeting.

As shown in FIG. 2A, in scenario 1, dedicated User Plane Function (UPF) is deployed in customer premises, and all Control Plane (CP) functions rely on NFs are deployed in the operator premises. The interface between customer premises and operator premises is N4, which is non-SBA interface. According to predefined standards 33.501 and 33.210, mutual authentication, confidentiality, integrity and anti-replay protection, as well as limited traffic flow analysis are required on Security Gateway (SEG) . Internet Protocol Security (IPSEC) can also help to hide network topology. In addition, some SEG products support malformed packet filter and flow control (rate-limiting) already although without explicitly requirements in 3GPP spec. Therefore, looks potential attacks mentioned in the Security Identifier (SID) proposal, including DoS, malformed signaling messages, topology information exposure, on external N4 can be addressed already with SEG in the technical solutions, probably with additional features specified in 3GPP on SEG.

As shown in FIG. 2B, in scenario 2, dedicated UPF and other control plane functions including such as Session Management Function (SMF) and Access and Mobility Management Function (AMF) are deployed in customer premises. The interface between customer premises and operator premises is SBA interface. The challenge lies in that Service Based Interface (SBI) of 5G Core Network (5GC) is extended to cross two security domains, but still in the same PLMN. This implies that existing SEG may not work for SBI as it was designed to protect non-SBI interfaces, and existing Security Edge Protection Proxy (SEPP) may not work as the NPN has same PLMN ID without addition NPN Id in the case of PNI-NPN. It also means that existing SCP may not work as SCP acting as Transport Layer Security (TLS) proxy cannot support malformed signaling messages discard, topology hiding, and rate-limiting.

Malformed signaling messages discard and rate-limiting may be realized with enhancement of policies in the technical solutions, but topology hiding is still not possible.

Communication mode D may be used to hide real address of NFService producers in PLMN on the interactions of request and response between NFService consumer and NFService producer, but there’ re still issues on the interactions of subscribe and notify between NFService consumer and NFService producer as mentioned in the followings.

For better understanding, reference is now made to FIG. 3A, which illustrates an example workflow diagram of NPN Network Function subscribing notification from Network Function of PLMN. In order to hide address of Unified Data Management (UDM) 1 for AMF2, it is supposed that the notification from UDM1 of PLMN to AMF2 of NPN will be proxied by service communication proxy gateway (SCPgw) at the edge of the PLMN. The challenge lies in the way of UDM1 and SCPgw getting this knowledge, as well as whether and how UDM1 should send notification to SCPgw, or whether and how SCPgw should perform address translation.

Reference is made to FIG. 3B, which illustrates an example workflow diagram of PLMN NF subscribing notification from NF of NPN. In order to hide address of Network Data Analytics Function (NWDAF) 1 from AMF2, it is supposed that SCPgw at the edge of the PLMN should proxy the subscription and notification request. The challenge lies in the way of NWDAF1 determining that the subscription request should be sent to SCPgw for which notification, as well as whether and how SCPgw should translate callback Uniform Resource Identifier (URI) and target address of notification.

For both workflows in FIG. 3A and FIG. 3B, whether SCP map the NF instance address to SCP instance address for NF instance status change notification or not is to be solved, especially for the workflow shown in FIG. 3A.

In order to solve at least part of the above problems or other potential problems, a solution to protect PLMN from PNI-NPN is proposed. The solution leverages SCP to hide network topology of PLMN. NF profile, CCA, Token, and discovery request are extended to include new information element to distinguish PNI-NPN domain. In order to distinguish PNI-NPN domain, in some options, new PNI-NPN element is introduced to represent PNI-NPN domain. In other options, PNI-NPN concept is generalized to common domain, and use source DN to represent domain the service consumer belong to, and target domain the producer belong to. In other options, existing SCP domain is reused to represent domain of service producer, and FQDN to derive domain of service consumer.

Example embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings.

FIG. 4 illustrates a signaling flow 400 of communication between first network device, second network device and third network device in accordance with some embodiments of the present disclosure. For the purposes of discussion, the signaling flow 400 will be discussed with reference to FIG. 1, for example, by using the first network device 110, the second network device 120 and the third network device 130.

In operation, the second network device 120 transmits (410-1) a first message for a network service, and the first network device 110 receives (410-2) the first message from the second network device 120 accordingly.

In some example embodiments, the first network device 110 may be located in a first network corresponding to a first domain and the second network device 120 may be located in a second network corresponding to a second domain. Further, the first message includes a domain name (DN) indicating the second domain. The domain name may be also referred to as domain identity (ID) , domain identification, or other suitable term in example embodiments of the present disclosure. It is to be understood that they are interchangeable, rather than suggesting any limitations.

It is also to be noted that there is no limitation about the number of DNs in the first message. For instance, the first message may include two or more DNs. In an example, the first message (e.g., a discovery request) may include a source DN indicating a source domain, such as PLMN, as well as a target DN indicating target domain, such as PNINPN1. In this respect, more details with be discussed with reference to the following figures, for example, FIG. 5C.

Then, the second network device 120 transmits (420-1) a second message based on the first message to the third network device 130, and the third network device 130 receives (420-2) the second message from the first network device 110 accordingly. In particular, the second message includes the domain name.

More example embodiments will be further discussed with reference to FIGS. 5A to 5D.

In some example embodiments, the first network device 110 may include a Service Communication Proxy (SCP) in the first network. In some example embodiment (for example, the example embodiments shown in FIG. 5A) , the first network device 110 may receive, from a further SCP in the second network, a registration request for registering a NF service producer, the registration request including the domain name indicating the second domain. Then the first network device 110 may transmit, to a NF Repository Function (NRF) node in the first network, a further registration request for registering a fourth network device in the second network as the NF service producer, the further registration request including the domain name.

In some example embodiments, at least one of the registration request or the further registration request may include client credentials assertion (CCA) , where the CCA includes the domain name.

In some example embodiments, the first network device 110 may receive, from a further SCP in the second network, at least one of a discovery request including the domain name or a token request including the domain name, the discovery request and the token request being associated with a registration request from a fourth network device (for example, AMF in FIG. 5A) in the second network (such as Step 3A and 4A in FIG. 5A, from SCP in NPN to SCP in PLMN) . Then the first network device 110 may transmit, to a NF Repository Function (NRF) node in the first network, the at least one of the discovery request or the token request (such as Step 3A and 4A in FIG. 5A, from SCP in PLMN to NRF) . In response to receiving, from the NRF node, a token response including a token for the registration request, the first network device 110 may transmit, to the further SCP, a further token response including the token (such as Step 4B in FIG. 5A) .

In some example embodiments, the second network device 120 may include a network function (NF) consumer in the second network (for example, the example embodiments shown in FIG. 5B) . In some example embodiments, the first message includes a service request (such as Step 1 in FIG. 5B) for the network service. The third network device 130 comprises a Network Repository Function (NRF) node in the first network, and the second message includes at least one of: a discovery request (such as Step 2 in FIG. 5B) including at least one of the domain name or an identifier of the second network device, or a token request (such as Step 4 in FIG. 5B) including at least one of the domain name or an identifier of the second network device.

In some example embodiments, at least one of the service request, the discovery request, or the token request may include client credentials assertion (CCA) , where the CCA includes the domain name.

In some example embodiments, the second message may include the token request including the domain name, and the first network device 110 may receive, from the third network device 130, a token response including a token indicating that the first network device 110 is allowed to access the network service. Then the first network device 110 may change a callback Uniform Resource Identifier (URI) or IP address of the second network device 120 in the service request based on an address of the first network device 110; and then the first network device 110 may transmit a further service request for the network service to a network function (NF) service producer, the further service request including at least one of the changed callback URI or IP address, the token or routing binding information (such as Step 5 to Step 7 in FIG. 5B) .

In some example embodiments, the token may include the domain name. In some other embodiments, the token response including the token that includes the domain name is transmitted from the third network device 130 by checking (such as Step 5 in FIG. 5B) the DN comprised in client credentials assertion (CCA) in the token request.

In some example embodiments, the token comprised in the further service request may include the domain name, which is checked by the NF service producer (such as Step 8 in FIG. 5B) .

In some example embodiments, the second network device 120 may include a network function (NF) service consumer in the first network (for example, the example embodiments shown in FIG. 5C) .

In some example embodiments, the first message may include a service request (such as Step 5 in FIG. 5C) for the network service. In some example embodiments, the third network device 130 may include a NF service producer in the second network, and the second message may include a further service request (such as Step 7 in FIG. 5C) for the network service. In some example embodiments, the first network and the second network may be different.

In some example embodiments, the second network device 120 may transmit to a NF Repository Function (NRF) node in the first network at least one of: a discovery request (such as Step 1 in FIG. 5C) including a domain name of the NF service producer, or a token request (such as Step 3 in FIG. 5C) including a domain name of the NF service producer.

In some example embodiments, the first network device 110 may receive, from the second network device 120, the service request (such as Step 7 in FIG. 5C) including a callback Uniform Resource Identifier (URI) of the second network device 120 and a token indicating that the second network device 120 is allowed to access the network service provided by the NF service producer in the second network. The first network device 110 may change the callback URI of the second network device 120 based on an address of the first network device 110, then the first network device 110 may transmit, to the third network device 130, the further service request (such as Step 7 in FIG. 5C) including at least one of the changed callback URI, the token or routing binding information.

In some example embodiments, the token may include the domain name. In some example embodiments, the service request may include a service subscription request containing subscription information (such as Step 9 to Step 12 in FIG. 5B, and Step 8 to Step 9 in FIG. 5C) . In some example embodiments, the first network device 110 may receive, from the NF service producer, a notification of the network service associated with the subscription information, the notification including a changed callback URI. The first network device 110 may determine a callback URI of the second network device based on the changed callback URI, then the first network device 110 may transmit, to the second network device 120, the notification of the network service based on the callback URI of the second network device 120.

In some example embodiments, the second network device 120 may include a network function (NF) service consumer in the second network (for example, the example embodiments shown in FIG. 5D) . In some example embodiments, the first message may include a service request (such as Step 1 in FIG. 5D) for the network service. In some example embodiments, the third network device 130 may include a NF service producer in the second network, and the second message may include a further service request (such as Step 6 in FIG. 5D) for the network service. In some example embodiments, the first network and the second network are the same.

In some example embodiments, the first network device 110 may receive, from the third network device 130, a registration request for registering a NF service producer, and then the first network device 110 may transmit, to a NF Repository Function (NRF) node in the first network, a further registration request for registering the third network device 130 as the NF service producer (such as Registration in FIG. 5C and FIG. 5D) .

In some example embodiments, at least one of the registration request and the further registration request may include client credentials assertion (CCA) , where the CCA include the domain name.

In some example embodiments, the first network device 110 may transmit to a NF Repository Function (NRF) node in the first network, at least one of: a discovery request (such as Step 2 in FIG. 5D) including the domain name, or a token request (such as Step 4 in FIG. 5D) including the domain name.

In some example embodiments, at least one of the service request, the discovery request, or the token request may include client credentials assertion (CCA) , where the CCA include the domain name.

In some example embodiments, the service request may include a service subscription request containing subscription information. In some example embodiments, the first network device 110 may receive, from the NRF node, a token response including a token indicating that the second network device 120 is allowed to access the network service provided by the NF service producer in the second network, and then the first network device 110 may transmit, to the third network device 130, the further service request including at least one of a callback URI of the second network device 120 in the service request, the token or routing binding information.

In some example embodiments, the token may include the domain name.

In some example embodiments, the domain name may indicate at least one of: a domain to which a network function (NF) consumer belongs, a domain to which a NF producer belongs, a domain corresponding to a non-public network (NPN) , or a domain corresponding to a Public Network Integrated Non Public Network (PNI-NPN) .

In some example embodiments, the first network may be a public network, and the second network may be a non-public network. In some other example embodiments, the service request includes a service subscription request.

In some example embodiments, the second network device 120 may receive, from the first network device 110, a notification of the network service based on a callback URI of the second network device 120, the callback URI of the second network device 120 being determined based on a changed callback URI comprised in a further notification received from a NF service producer, the further notification being associated with the subscription information.

In some example embodiments, the third network device 130 may transmit, to the first network device 110, a notification of the network service associated with the subscription information, the notification including a changed callback URI of the second network device 120.

In some example embodiments, the first network device 110 may receive, from the first network device 110, the further service request including at least one of a changed callback Uniform Resource Identifier (URI) , a token or routing binding information. Herein, the changed callback URI is determined based on a callback URI of the second network device 120 comprised in the service request from the first network device 110, and the token is comprised in the service request and indicates that the second network device 120 is allowed to access the network service provided by the NF service producer in the second network.

In some example embodiments, the first network device 110 may receive, from the first network device 110, the further service request comprising at least one of a changed callback Uniform Resource Identifier (URI) , a token or routing binding information. Herein, the token may be comprised in a token response from a NF Repository Function (NRF) node in the first network and the token indicates that the second network device 120 is allowed to access the network service provided by the NF service producer in the second network. In addition, the changed callback URI may be determined based on a callback URI of the second network device 120 in the service request and an address of the first network device 110.

More example embodiments will be discussed. For better understanding, reference is now made to FIG. 5A to FIG. 5D. FIG. 5A to FIG. 5D illustrate example embodiment workflow diagrams of different scenarios. It should be noted that the steps in the following example embodiments are optional, not necessary.

In FIG. 5A, the workflow shows registration and consumer NF services of PLMN. This scenario includes new PNI-NPN Id in registration and other service request from NF in NPN. In this scenario, AMF is consumer. In this case, it is similar to SNPN having the option to extend NF profile and token to include PNI-NPN Information Element (IE) .

As shown in FIG. 5A, at Step 1, SCPgw works as topology hiding gateway for NPN network accessing PLMN, and SCPgw is configured with new policy to hide PLMN from NPN (Session Initiation Protocol (SIP) ) . NRF and NFp are configured with new policy to reject the service request if NPN request is not coming from SCPgw. (SIP) .

At Step 2, When AMF from NPN network sends the registration request to the NRF available in the PLMN, the request is routed via SCPgw by indirect model d communications. AMF also include enhanced CCA that includes PNI-NPN indication. Once request is received at the NRF, the NRF validates whether the request is coming from SCPgw or not. Additionally, the NRF check whether the entity signing the CCA is privileged to access the NF producer through SCP GW. If the entity signing the CCA is not privileged to access the NF producer through SCP GW, the NRF rejects the request. Otherwise, NRF allows the request. With the help of CCA content, the NRF understand the request is originated from PNINPN network that has to be routed via SCPgw. Alternatively, the NRF is configured with local policy to understand the NFc instance id and corresponding PNINPN network. And accordingly apply the policy to accept or reject the request if not coming from SCPgw. It is noted that SCPgw in PNINPN is optional.

At Step 3, When AMF sends a registration request to UDM, the SCP in PNINPN sends a discovery request to discover the UDM. Once request is received at the NRF, the NRF validates whether request is coming from SCPgw or not. If the request is not coming from SCPgw, NRF rejects the request. If the request is coming from SCPgw, the NRF allows the request and provides the UDM NFprofile. In this step, SCPgw replaces the IP address or fqdns available in the NFprofile to hide the topology of the PLMN. And then put its own address so that further request to UDM must go via SCPgw.

At Step 4, AMF or SCP in NPN network sends the access token request. In this access token request, new IE is introduced to inform the NRF that request is coming from PNINPN =NPN1 network. Once request is received at the NRF, the NRF grant or reject the token based on the local policy and NFp profile information. The NFp profile may also contains allowed PNINPN list which can be used to grant the access token.

At Step 5, AMF or SCP sends the service request to NFp or UDM with enhanced access token and enhanced CCA. NFp or UDM uses the enhanced access token to authorize or reject the service request. If service response contains URI, SCPgw modifies the same to hide the topology. Then at Step 6, once NFp sends the notification, SCPgw performs the topology hiding again and changes the URI. It is noted that all service requests or service responses in the workflow are modified by the SCP to hide the topology.

In FIG. 5B, the workflow shows subscribing for notification from PLMN. In this scenario, AMF is consumer. This scenario reuses requester FQDN for NF in NPN to subscribe notification from PLMN.

The preconditions of this scenario are described in the followings. Communication mode D is adopted, and SCP in PLMN called SCP GW is utilized to hide network topology of PLMN. Policies are preconfigured in NRF and other NFs in PLMN to restrict direct access from the NPN, but the NFs in NPN may be allowed to indirectly access the NFs in the PLMN with proxy by SCP in the PLMN. The NF Service Producers in PLMN such as UDM are registered to NRF. SCP-domain and nfdomain or FQDN defined in predefined standard 29.510 are utilized to support communication between NFs in PNI-NPN and PLMN. And only protection of PLMN is considered in the solution.

As shown in FIG. 5B, at Step 1, AMF in NPN subscribes notification from UDM in PLMN, besides existing parameter in the subscription request in technical solutions. And in the present disclosure, especially for SCP domain of the target UDM and requester FQDN or DN of the AMF, the AMF also include FQDN or DN of the AMF in CCA. AMF sends the request to SCP GW of PLMN which is preconfigured in the AMF. It is noted that, in the present disclosure, the FQDN or DN can be added in CCA and/or certificate used to sign CCA.

At Step 2, After receiving request, SCP GW triggers discovery request to NRF to find a corresponding UDM. In the present disclosure, SCP GW includes enhanced CCA and requester FQDN or DN in the discovery request, and also saves information of the request.

At Step 3, NRF authenticates and authorizes the request based on enhanced CCA and local policies, selects and returns NF profile of selected UDM instances to SCP GW according to requester FQDN, target SCP domain, and local policies.

At Step 4, after receiving discovery response, the SCP GW sends request to NRF for access token to subscribe notification of the UDM. In the present disclosure, SCP GW includes the enhanced CCA and requester FQDN or DN in the token request.

At Step 5, NRF authenticates and authorizes the request based on the enhanced CCA and local policies, generated token which including additional requester DN, and returns to SCP GW.

It is noted that at Step 3 and step 5, in the present disclosure, NRF only accepts the request proxied by the SCP GW if the requester FQDN or DN of the NF consumer is not in the domain from which the NF can access the NRF directly. This can also be verified by linking the key used to sign the CCA to a given domain.

At Step 6, in the present disclosure, after receiving token, the SCP GW replaces callback URI in subscription request from the NF in the NPN with its own address, stores the mapping. The SCP GW may include binding information in the request which will assist SCP to distribute notification received from UDM to corresponding NF consumer.

At Step 7, the SCP GW sends subscription request to UDM discovered at Step 4. The request includes token got at Step 5 and callback URI. In the present disclosure, SCP GW decide whether put the original URI or mapped URI in the callback URI based on requester FQDN or DN of the NF service consumer and scp domain of the NF service producer and local policies.

At Step 8, the UDM validates the token and responds to the SCP GW, and SCP GW responds to the AMF in NPN. It is noted that, in the present disclosure, UDM only accepts the request proxied by the SCP GW if the requester FQDN or DN of the NF consumer in token is not in the domain from which the NF can access the UDM directly.

At Step 9, the UDM sends notifications to SCP GW according to subscription information, which may include routing binding information copied from corresponding subscription request.

At Step 10, the SCP GW forwards the notification to corresponding consumer, for example, AMF in NPN, according to callback URI in subscription request from the AMF and information in the notification.

Reference is made to FIG. 5C, the workflow shows subscribing for notification from NPN by PLMN NF. In this scenario, AMF is producer. This scenario include new source or target domain for NF in PLMN to subscribe for notification from NPN.

The preconditions of this scenario are described in the followings. Communication mode C is adopted, and SCP in PLMN called SCP GW is utilized to hide network topology of PLMN. Policies are preconfigured in NRF and other NFs in PLMN to restrict direct access from the NPN, but the NFs in NPN may be allowed to indirectly access the NFs in the PLMN with proxy by SCP in the PLMN. Only protection of PLMN is considered in the solution. And AMF registers to NRF in PLMN as NF service producer through SCP GW in PLMN, including domain name or ID of AMF such as PNINPN1, in NF profile and CCA. NRF validates the CCA and decide to accept or reject the registration request according to validation result, DN of the AMF and local polices. If the registration is accepted, NRF stores the NF profile including DN of the AMF. It is noted that another option, besides domain name or ID, domain type such as PLMN edge, PNINPN, PLMN central, and so on, can be added to allow defining policies based on type of domain the NF belongs to.

As shown in FIG. 5C, at Step 1, NWDAF in PLMN sends request to NRF in the PLMN to discovery subscription service in NPN for notification of AMF in NPN, besides existing parameter, and in the present disclosure, the NWDAF also includes source DN such as PLMN1, and target DN such as PNINPN1 in the discovery request.

At Step 2, after receiving request, NRF authenticates and authorizes the request based on source and target DNs in the request and local policies, selects and returns NF profile of selected AMF instances to NWDAF based on source and target DNs in the request and local policies.

At Step 3, NWDAF sends request to NRF for access token to subscribe notification of the AMF. In the present disclosure, NWDAF also includes the source and target DNs in the token request.

At Step 4, NRF authenticates and authorizes the request based on source and target DNs and local policies, generated token including additional source and target DNs, and returns to NWDAF.

It is noted that in the present disclosure, at Step 4, NRF only accepts the request proxied by the SCP GW if the requester FQDN or DN of the NF consumer is not in the domain from which the NF can access the NRF directly.

At Step 5, NWDAF sends subscription request to SCP GW according to target DN and local configuration. The enhanced token, target DN, and optionally source DN, are included in the request. The callback URI is set to URI of NWDAF.

At Step 6, After receiving the request, the SCP GW replaces the callback URI with URI of SCP GW according to target and/or source DN and local policies, and forwards subscription request to AMF in NPN based on target DN. SCP GW stores the subscription and mapping information.

At Step 7, AMF in NPN validates the token in the request, and matches the source and target DN in the token, and accepts the request based on local policies, then sends response to SCP GW. And then SCP GW forwards the response to the NWDAF.

At Step 8, the AMF sends notifications to SCP GW according to subscription information. Then at Step 9, the SCP GW gets NWDAF address from local mapping table created at Step 6, and forwards the notification to NWDAF. There is an open issue in this scenario of the way to distinguish by SCPgw to which NF in PLMN the notification target. In this case, routing binding information can be included in subscription request from SCP GW to the AMF, which could be copied in the notification from the AMF to SCP GW, then SCP GW can distribute the notification according to the routing binding information.

Reference is made to FIG. 5D, the workflow shows subscribing for notification from NPN by NPN NF. In this scenario, AMF is producer and SMF is consumer. This scenario include new source or target domain for NF in NPN to subscribe for notification from NPN.

The preconditions of this scenario are described in the followings. Communication mode D is adopted, and SCP in PLMN called SCP GW is utilized to hide network topology of PLMN. Policies are preconfigured in NRF and other NFs in PLMN to restrict direct access from the NPN, but the NFs in NPN may be allowed to indirectly access the NFs in the PLMN with proxy by SCP in the PLMN. Only protection of PLMN is considered in the solution. And AMF registers to NRF in PLMN as NF service producer through SCP GW in PLMN, including domain name or ID of AMF such as PNINPN1, in NF profile and CCA. NRF validates the CCA and decide to accept or reject the registration request according to validation result, DN of the AMF and local polices. If the registration is accepted, NRF stores the NF profile including DN of the AMF. It is noted that another option, besides domain name or ID, domain type such as PLMN edge, PNINPN, PLMN central, and so on, can be added to allow defining policies based on type of domain the NF belongs to.

As shown in FIG. 5D, at Step 1, SMF in NPN subscribes notification from AMF in the same NPN, besides existing parameter, and in the present disclosure, it also includes source DN such as PNINPN1, and target DN such as PNINPN1 in the request. SMF sends the request to SCP GW of PLMN which is preconfigured in the SMF. The source DN is also included in CCA.

In the present disclosure, it is noted that as AMF is registered in NRF of PLMN, unless SMF is preconfigured with AMF information locally, it needs to discover AMF instance or set from NRF in PLMN although the SMF and AMF are in the same domain.

At Step 2, after receiving request, SCP GW triggers discovery request to NRF to find a corresponding AMF. SCP GW includes enhanced CCA, source DN and target DN in the discovery request, and also saves information of the request.

At Step 3, NRF authenticates and authorizes the request based on enhanced CCA and local policies, selects and returns NF profile of selected AMF instances to SCP GW according to source DN and target DN, and local policies.

At Step 4, after receiving discovery response, the SCP GW sends request to NRF for access token to subscribe notification of the AMF. The SCP GW includes the enhanced CCA, source DN and target DN in the token request.

At Step 5, NRF authenticates and authorizes the request based on the enhanced CCA and local policies, generated token including additional source DN and target DN, and returns to SCP GW.

It is noted that, in the present disclosure, at Step 3 and 5, NRF only accepts the request proxied by the SCP GW if the source DN of the NF consumer is not in the domain from which the NF can access the NRF directly.

At Step 6, after receiving token, the SCP GW sends subscription request to the target AMF. The callback URI is set to URI of SMF according to source and target DN, and callback URI included in the subscription request from the SMF in the step 1.

At Step 7, the AMF validates the token and responds to the SCP GW, and SCP GW responds to the SMF in NPN. Then at Step 8, the AMF sends notifications to the SMF in the same domain according to callback URI in subscription request at Step 6.

Example method

FIG. 6 shows a flowchart of an example method 600 implemented at a first network device in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 600 will be described from the perspective of the first network device 110 in FIG. 1.

At block 610, the first network device 110 receives, from a second network device, a first message for a network service, wherein the first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to a second domain, and the first message comprises a domain name indicating the second domain.

At block 620, the first network device 110 transmits, to a third network device, a second message based on the first message, the second message comprising the domain name.

In some example embodiments, the second network device comprises a network function (NF) consumer in the second network, and the first message comprises a service request for the network service. The third network device comprises a Network Repository Function (NRF) node in the first network, and the second message comprises at least one of: a discovery request comprising at least one of the domain name or an identifier of the second network device, or a token request comprising at least one of the domain name or an identifier of the second network device.

In some example embodiments, at least one of the service request, the discovery request, or the token request comprises client credentials assertion (CCA) , and the CCA comprises the domain name.

In some example embodiments, the second message comprises the token request comprising the domain name, and the first network device may receive, from the third network device, a token response comprising a token indicating that the first network device is allowed to access the network service; change a callback Uniform Resource Identifier (URI) or IP address of the second network device in the service request based on an address of the first network device; and transmit a further service request for the network service to a network function (NF) service producer, the further service request comprising at least one of the changed callback URI or IP address, the token or routing binding information.

In some example embodiments, the token comprises the domain name, or the token response comprising the token that comprises the domain name is transmitted from the third network device by checking the DN comprised in client credentials assertion (CCA) in the token request.

In some example embodiments, the token comprised in the further service request comprises the domain name, which is checked by the NF service producer.

In some example embodiments, the second network device comprises a network function (NF) service consumer in the first network, and the first message comprises a service request for the network service. The third network device comprises a NF service producer in the second network, and the second message comprises a further service request for the network service, and the first network and the second network are different.

In some example embodiments, the second network device transmits to a Network Repository Function (NRF) node in the first network at least one of: a discovery request comprising a domain name of the NF service producer, or a token request comprising a domain name of the NF service producer.

In some example embodiments, the first network device may receive, from the second network device, the service request comprising a callback Uniform Resource Identifier (URI) of the second network device and a token indicating that the second network device is allowed to access the network service provided by the NF service producer in the second network; change the callback URI of the second network device based on an address of the first network device; and transmit, to the third network device, the further service request comprising at least one of the changed callback URI, the token or routing binding information.

In some example embodiments, the token comprises the domain name.

In some example embodiments, the service request comprises a service subscription request containing subscription information, and the first network device may receive, from the NF service producer, a notification of the network service associated with the subscription information, the notification comprising a changed callback URI; determine a callback URI of the second network device based on the changed callback URI; and transmit, to the second network device, the notification of the network service based on the callback URI of the second network device.

In some example embodiments, the second network device comprises a network function (NF) service consumer in the second network, and the first message comprises a service request for the network service, and the third network device comprises a NF service producer in the second network, and the second message comprises a further service request for the network service, and the first network and the second network are the same.

In some example embodiments, the first network device may receive, from the third network device, a registration request for registering a NF service producer; and transmit, to a Network Repository Function (NRF) node in the first network, a further registration request for registering the third network device as the NF service producer.

In some example embodiments, at least one of the registration request, and the further registration request comprises client credentials assertion (CCA) , and the CCA comprises the domain name.

In some example embodiments, the first network device may transmit, to a Network Repository Function (NRF) node in the first network, at least one of: a discovery request comprising the domain name, or a token request comprising the domain name.

In some example embodiments, the service request comprises a service subscription request containing subscription information, and the first network device may receive, from the NRF node, a token response comprising a token indicating that the second network device is allowed to access the network service provided by the NF service producer in the second network; and transmit, to the third network device, the further service request comprising at least one of a callback URI of the second network device in the service request, the token or routing binding information.

In some example embodiments, the token comprises the domain name.

In some example embodiments, the first network device comprises a Service Communication Proxy (SCP) in the first network, and the first network device may receive, from a further SCP in the second network, a registration request for registering a NF service producer, the registration request comprising the domain name indicating the second domain; and transmit, to a Network Repository Function (NRF) node in the first network, a further registration request for registering a fourth network device in the second network as the NF service producer, the further registration request comprising the domain name.

In some example embodiments, at least one of the registration request or the further registration request comprises client credentials assertion (CCA) , and the CCA comprises the domain name.

In some example embodiments, the first network device comprises a Service Communication Proxy (SCP) in the first network, and the first network device may receive, from a further SCP in the second network, at least one of a discovery request comprising the domain name or a token request comprising the domain name, the discovery request and the token request being associated with a registration request from a fourth network device in the second network; transmit, to a Network Repository Function (NRF) node in the first network, the at least one of the discovery request or the token request; and in response to receiving, from the NRF node, a token response comprising a token for the registration request, transmit, to the further SCP, a further token response comprising the token.

In some example embodiments, the token comprises the domain name.

In some example embodiments, the domain name indicates at least one of: a domain to which a network function (NF) consumer belongs, a domain to which a NF producer belongs, a domain corresponding to a non-public network (NPN) , or a domain corresponding to a Public Network Integrated Non Public Network (PNI-NPN) .

In some example embodiments, the first network is a public network and the second network is a non-public network, or the service request comprises a service subscription request.

FIG. 7 shows a flowchart of an example method 700 implemented at a second network device in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 700 will be described from the perspective of the second network device 120 in FIG. 1.

At block 710, the second network device 120 transmits, to a first network device, a first message for a network service, wherein the first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to a second domain, and the first message comprises a domain name indicating the second domain.

In some example embodiments, the second network device comprises a network function (NF) consumer in the second network, and the first message comprises a service request for the network service, and the third network device comprises a Network Repository Function (NRF) node in the first network, and the second message comprises at least one of: a discovery request comprising at least one of the domain name or an identifier of the second network device, or a token request comprising at least one of the domain name or an identifier of the second network device.

In some example embodiments, the second network device comprises a network function (NF) service consumer in the first network, and the first message comprises a service request for the network service, and the third network device comprises a NF service producer in the second network, and the second message comprises a further service request for the network service, and the first network and the second network are different.

In some example embodiments, the second network device may transmit, to a Network Repository Function (NRF) node in the first network, at least one of: a discovery request comprising a domain name of the NF service producer, or a token request comprising a domain name of the NF service producer.

In some example embodiments, the second network device may transmit, to the first network device, the service request comprising a callback Uniform Resource Identifier (URI) of the second network device and a token indicating that the second network device is allowed to access the network service provided by the NF service producer in the second network.

In some example embodiments, the token comprises the domain name.

In some example embodiments, the service request comprises a service subscription request containing subscription information, and the second network device may receive, from the first network device, a notification of the network service based on a callback URI of the second network device, the callback URI of the second network device being determined based on a changed callback URI comprised in a further notification received from a NF service producer, the further notification being associated with the subscription information.

FIG. 8 shows a flowchart of an example method 800 implemented at a third network device in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 800 will be described from the perspective of the third network device 130 in FIG. 1.

At block 810, the third network device 130 receives, from a first network device, a second message comprising a domain name indicating a second domain, the second message is transmitted from the first network device based on a first message for a network service, the first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to the second domain, and the first message comprises the domain name indicating the second domain.

In some example embodiments, the service request comprises a service subscription request containing subscription information, and the third network device may transmit, to the first network device, a notification of the network service associated with the subscription information, the notification comprising a changed callback URI of the second network device.

In some example embodiments, the first network device may receive, from the first network device, the further service request comprising at least one of a changed callback Uniform Resource Identifier (URI) , a token or routing binding information, the changed callback URI is determined based on a callback URI of the second network device comprised in the service request from the first network device, and the token is comprised in the service request and indicates that the second network device is allowed to access the network service provided by the NF service producer in the second network.

In some example embodiments, the second network device comprises a network function (NF) service consumer in the first network, and the first message comprises a service request for the network service, and the third network device comprises a NF service producer in the second network, and the second message comprises a further service request for the network service, and the first network and the second network are the same.

In some example embodiments, the third network device may transmit, to the first network device, a registration request for registering a NF service producer.

In some example embodiments, the registration request comprises client credentials assertion (CCA) , and the CCA comprises the domain name.

In some example embodiments, the service request comprises a service subscription request containing subscription information, and the third network device may receive, from the first network device, the further service request comprising at least one of a changed callback Uniform Resource Identifier (URI) , a token or routing binding information, the token is comprised in a token response from a Network Repository Function (NRF) node in the first network and the token indicates that the second network device is allowed to access the network service provided by the NF service producer in the second network, and the changed callback URI is determined based on a callback URI of the second network device in the service request and an address of the first network device.

In some example embodiments, the token comprises the domain name.

Example Apparatus, Device and Medium

In some example embodiments, a first apparatus capable of performing any of the method 600 (for example, the first network device 110 in FIG. 1) may comprise means for performing the respective operations of the method 600. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The first apparatus may be implemented as or included in the first network device 110 in FIG. 1.

In some example embodiments, the first apparatus comprises means for receiving, from a second network device, a first message for a network service, the first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to a second domain, and the first message comprises a domain name indicating the second domain; and means for transmitting, to a third network device, a second message based on the first message, the second message comprising the domain name.

In some example embodiments, the second message comprises the token request comprising the domain name, and the first apparatus further comprises: means for receiving, from the third network device, a token response comprising a token indicating that the first network device is allowed to access the network service; means for changing a callback Uniform Resource Identifier (URI) or IP address of the second network device in the service request based on an address of the first network device; and means for transmitting a further service request for the network service to a network function (NF) service producer, the further service request comprising at least one of the changed callback URI or IP address, the token or routing binding information.

In some example embodiments, the first apparatus further comprises: means for receiving, from the second network device, the service request comprising a callback Uniform Resource Identifier (URI) of the second network device and a token indicating that the second network device is allowed to access the network service provided by the NF service producer in the second network; means for changing the callback URI of the second network device based on an address of the first network device; and means for transmitting, to the third network device, the further service request comprising at least one of the changed callback URI, the token or routing binding information.

In some example embodiments, the token comprises the domain name.

In some example embodiments, the service request comprises a service subscription request containing subscription information, and the first apparatus further comprises: means for receiving, from the NF service producer, a notification of the network service associated with the subscription information, the notification comprising a changed callback URI; means for determining a callback URI of the second network device based on the changed callback URI; and means for transmitting, to the second network device, the notification of the network service based on the callback URI of the second network device.

In some example embodiments, the first apparatus further comprises: means for receiving, from the third network device, a registration request for registering a NF service producer; and means for transmitting, to a Network Repository Function (NRF) node in the first network, a further registration request for registering the third network device as the NF service producer.

In some example embodiments, the first apparatus further comprises: means for transmitting, to a Network Repository Function (NRF) node in the first network, at least one of: a discovery request comprising the domain name, or a token request comprising the domain name.

In some example embodiments, the service request comprises a service subscription request containing subscription information, and the first apparatus further comprises: means for receiving, from the NRF node, a token response comprising a token indicating that the second network device is allowed to access the network service provided by the NF service producer in the second network; and means for transmitting, to the third network device, the further service request comprising at least one of a callback URI of the second network device in the service request, the token or routing binding information.

In some example embodiments, the token comprises the domain name.

In some example embodiments, the first network device comprises a Service Communication Proxy (SCP) in the first network, and the first apparatus further comprises: means for receiving, from a further SCP in the second network, a registration request for registering a NF service producer, the registration request comprising the domain name indicating the second domain; and means for transmitting, to a Network Repository Function (NRF) node in the first network, a further registration request for registering a fourth network device in the second network as the NF service producer, the further registration request comprising the domain name.

In some example embodiments, the first network device comprises a Service Communication Proxy (SCP) in the first network, and the first apparatus further comprises: means for receiving, from a further SCP in the second network, at least one of a discovery request comprising the domain name or a token request comprising the domain name, the discovery request and the token request being associated with a registration request from a fourth network device in the second network; means for transmitting, to a Network Repository Function (NRF) node in the first network, the at least one of the discovery request or the token request; and means for in response to receiving, from the NRF node, a token response comprising a token for the registration request, transmitting, to the further SCP, a further token response comprising the token.

In some example embodiments, the token comprises the domain name.

In some example embodiments, a second apparatus capable of performing any of the method 700 (for example, the second network device 120 in FIG. 1) may comprise means for performing the respective operations of the method 700. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The second apparatus may be implemented as or included in the second network device 120 in FIG. 1.

In some example embodiments, the second apparatus comprises means for transmitting, to a first network device, a first message for a network service, the first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to a second domain, and the first message comprises a domain name indicating the second domain.

In some example embodiments, the second apparatus further comprises: means for transmitting, to a Network Repository Function (NRF) node in the first network, at least one of: a discovery request comprising a domain name of the NF service producer, or a token request comprising a domain name of the NF service producer.

In some example embodiments, the second apparatus further comprises: means for transmitting, to the first network device, the service request comprising a callback Uniform Resource Identifier (URI) of the second network device and a token indicating that the second network device is allowed to access the network service provided by the NF service producer in the second network.

In some example embodiments, the token comprises the domain name.

In some example embodiments, the service request comprises a service subscription request containing subscription information, and the second apparatus further comprises: means for receiving, from the first network device, a notification of the network service based on a callback URI of the second network device, the callback URI of the second network device being determined based on a changed callback URI comprised in a further notification received from a NF service producer, the further notification being associated with the subscription information.

In some example embodiments, a third apparatus capable of performing any of the method 800 (for example, the third network device 130 in FIG. 1) may comprise means for performing the respective operations of the method 800. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. The third apparatus may be implemented as or included in the third network device 130 in FIG. 1.

In some example embodiments, the third apparatus comprises means for receiving, from a first network device, a second message comprising a domain name indicating a second domain, the second message is transmitted from the first network device based on a first message for a network service, the first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to the second domain, and the first message comprises the domain name indicating the second domain.

In some example embodiments, the service request comprises a service subscription request containing subscription information, and the third apparatus further comprises: means for transmitting, to the first network device, a notification of the network service associated with the subscription information, the notification comprising a changed callback URI of the second network device.

In some example embodiments, the third apparatus further comprises: means for receiving, from the first network device, the further service request comprising at least one of a changed callback Uniform Resource Identifier (URI) , a token or routing binding information, the changed callback URI is determined based on a callback URI of the second network device comprised in the service request from the first network device, and the token is comprised in the service request and indicates that the second network device is allowed to access the network service provided by the NF service producer in the second network.

In some example embodiments, the third apparatus further comprises: means for transmitting, to the first network device, a registration request for registering a NF service producer.

In some example embodiments, the service request comprises a service subscription request containing subscription information, and the third apparatus further comprises: means for receiving, from the first network device, the further service request comprising at least one of a changed callback Uniform Resource Identifier (URI) , a token or routing binding information, the token is comprised in a token response from a Network Repository Function (NRF) node in the first network and the token indicates that the second network device is allowed to access the network service provided by the NF service producer in the second network, and the changed callback URI is determined based on a callback URI of the second network device in the service request and an address of the first network device.

In some example embodiments, the token comprises the domain name.

FIG. 9 is a simplified block diagram of a device 900 that is suitable for implementing example embodiments of the present disclosure. The device 900 may be provided to implement a communication device, for example, the first network device 110, the second network device 120 or the third network device 130 as shown in FIG. 1. As shown, the device 900 includes one or more processors 910, one or more memories 920 coupled to the processor 910, and one or more communication modules 940 coupled to the processor 910.

The communication module 940 is for bidirectional communications. The communication module 940 has one or more communication interfaces to facilitate communication with one or more other modules or devices. The communication interfaces may represent any interface that is necessary for communication with other network elements. In some example embodiments, the communication module 940 may include at least one antenna.

The processor 910 may be of any type suitable to the local technical network and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The device 900 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.

The memory 920 may include one or more non-volatile memories and one or more volatile memories. Examples of the non-volatile memories include, but are not limited to, a Read Only Memory (ROM) 924, an electrically programmable read only memory (EPROM) , a flash memory, a hard disk, a compact disc (CD) , a digital video disk (DVD) , an optical disk, a laser disk, and other magnetic storage and/or optical storage. Examples of the volatile memories include, but are not limited to, a random-access memory (RAM) 922 and other volatile memories that will not last in the power-down duration.

A computer program 930 includes computer executable instructions that are executed by the associated processor 910. The instructions of the program 930 may include instructions for performing operations/acts of some example embodiments of the present disclosure. The program 930 may be stored in the memory, e.g., the ROM 924. The processor 910 may perform any suitable actions and processing by loading the program 930 into the RAM 922.

The example embodiments of the present disclosure may be implemented by means of the program 930 so that the device 900 may perform any process of the disclosure as discussed with reference to FIG. 2 to FIG. 8. The example embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.

In some example embodiments, the program 930 may be tangibly contained in a computer readable medium which may be included in the device 900 (such as in the memory 920) or other storage devices that are accessible by the device 900. The device 900 may load the program 930 from the computer readable medium to the RAM 922 for execution. In some example embodiments, the computer readable medium may include any types of non-transitory storage medium, such as ROM, EPROM, a flash memory, a hard disk, CD, DVD, and the like. The term “non-transitory, ” as used herein, is a limitation of the medium itself (i.e., tangible, not a signal) as opposed to a limitation on data storage persistency (e.g., RAM vs. ROM) .

FIG. 10 shows an example of the computer readable medium 1000 which may be in form of CD, DVD or other optical storage disk. The computer readable medium 1000 has the program 930 stored thereon.

Generally, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, and other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. Although various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representations, it is to be understood that the block, apparatus, system, technique or method 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.

Some example embodiments of the present disclosure also provide at least one computer program product tangibly stored on a computer readable medium, such as a non-transitory computer readable medium. The computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target physical or virtual processor, to carry out any of the methods as described above. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. The program code may be provided to a processor or controller of a general-purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program code, when executed by the processor or controller, cause the functions/operations specified in the flowcharts and/or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of the present disclosure, the computer program code or related data may be carried by any suitable carrier to enable the device, apparatus or processor to perform various processes and operations as described above. Examples of the carrier include a signal, computer readable medium, and the like.

The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random-access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

Further, although operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, although several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Unless explicitly stated, certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, unless explicitly stated, various features that are described in the context of a single embodiment may also be implemented in a plurality of embodiments separately or in any suitable sub-combination.

Although the present disclosure has been described in languages specific to structural features and/or methodological acts, it is to be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

A first network device comprising:

at least one processor; and

at least one memory storing instructions that, when executed by the at least one processor, cause the first network device at least to:

receive, from a second network device, a first message for a network service, wherein the first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to a second domain, and the first message comprises a domain name indicating the second domain; and

transmit, to a third network device, a second message based on the first message, the second message comprising the domain name.
The first network device of claim 1, wherein the second network device comprises a network function (NF) consumer in the second network, and the first message comprises a service request for the network service, and

wherein the third network device comprises a Network Repository Function (NRF) node in the first network, and the second message comprises at least one of:

a discovery request comprising at least one of the domain name or an identifier of the second network device, or

a token request comprising at least one of the domain name or an identifier of the second network device.
The first network device of claim 2, wherein at least one of the service request, the discovery request, or the token request comprises client credentials assertion (CCA) , and wherein the CCA comprises the domain name.
The first network device of claim 2 or 3, wherein the second message comprises the token request comprising the domain name, and the first network device is caused to:

receive, from the third network device, a token response comprising a token indicating that the first network device is allowed to access the network service;

change a callback Uniform Resource Identifier (URI) or IP address of the second network device in the service request based on an address of the first network device; and

transmit a further service request for the network service to a network function (NF) service producer, the further service request comprising at least one of the changed callback URI or IP address, the token or routing binding information.
The first network device of claim 4, wherein the token comprises the domain name, or

wherein the token response comprising the token that comprises the domain name is transmitted from the third network device by checking the DN comprised in client credentials assertion (CCA) in the token request.
The first network device of claim 4, wherein the token comprised in the further service request comprises the domain name, which is checked by the NF service producer.
The first network device of claim 1, wherein the second network device comprises a network function (NF) service consumer in the first network, and the first message comprises a service request for the network service, and

wherein the third network device comprises a NF service producer in the second network, and the second message comprises a further service request for the network service, and

wherein the first network and the second network are different.
The first network device of claim 7, wherein the second network device transmits to a Network Repository Function (NRF) node in the first network at least one of:

a discovery request comprising a domain name of the NF service producer, or

a token request comprising a domain name of the NF service producer.
The first network device of claim 7, wherein the first network device is caused to:

receive, from the second network device, the service request comprising a callback Uniform Resource Identifier (URI) of the second network device and a token indicating that the second network device is allowed to access the network service provided by the NF service producer in the second network;

change the callback URI of the second network device based on an address of the first network device; and

transmit, to the third network device, the further service request comprising at least one of the changed callback URI, the token or routing binding information.
The first network device of claim 9, wherein the token comprises the domain name.
The first network device of claim 4 or 9, wherein the service request comprises a service subscription request containing subscription information, and wherein the first network device is caused to:

receive, from the NF service producer, a notification of the network service associated with the subscription information, the notification comprising a changed callback URI;

determine a callback URI of the second network device based on the changed callback URI; and

transmit, to the second network device, the notification of the network service based on the callback URI of the second network device.
The first network device of claim 1, wherein the second network device comprises a network function (NF) service consumer in the second network, and the first message comprises a service request for the network service, and

wherein the third network device comprises a NF service producer in the second network, and the second message comprises a further service request for the network service, and

wherein the first network and the second network are the same.
The first network device of claim 7 or 12, wherein the first network device is caused to:

receive, from the third network device, a registration request for registering a NF service producer; and

transmit, to a Network Repository Function (NRF) node in the first network, a further registration request for registering the third network device as the NF service producer.
The first network device of claim 13, wherein at least one of the registration request, and the further registration request comprises client credentials assertion (CCA) , and wherein the CCA comprises the domain name.
The first network device of claim 12, wherein the first network device is caused to:

transmit, to a Network Repository Function (NRF) node in the first network, at least one of:

a discovery request comprising the domain name, or

a token request comprising the domain name.
The first network device of claim 15, wherein at least one of the service request, the discovery request, or the token request comprises client credentials assertion (CCA) , and wherein the CCA comprises the domain name.
The first network device of claim 15, wherein the service request comprises a service subscription request containing subscription information, and wherein the first network device is caused to:

receive, from the NRF node, a token response comprising a token indicating that the second network device is allowed to access the network service provided by the NF service producer in the second network; and

transmit, to the third network device, the further service request comprising at least one of a callback URI of the second network device in the service request, the token or routing binding information.
The first network device of claim 17, wherein the token comprises the domain name.
The first network device of any of claims 1 to 18, wherein the first network device comprises a Service Communication Proxy (SCP) in the first network, and wherein the first network device is caused to:

receive, from a further SCP in the second network, a registration request for registering a NF service producer, the registration request comprising the domain name indicating the second domain; and

transmit, to a Network Repository Function (NRF) node in the first network, a further registration request for registering a fourth network device in the second network as the NF service producer, the further registration request comprising the domain name.
The first network device of claim 19, wherein at least one of the registration request or the further registration request comprises client credentials assertion (CCA) , and wherein the CCA comprises the domain name.
The first network device of any of claims 1 to 20, wherein the first network device comprises a Service Communication Proxy (SCP) in the first network, and wherein the first network device is caused to:

receive, from a further SCP in the second network, at least one of a discovery request comprising the domain name or a token request comprising the domain name, the discovery request and the token request being associated with a registration request from a fourth network device in the second network;

transmit, to a Network Repository Function (NRF) node in the first network, the at least one of the discovery request or the token request; and

in response to receiving, from the NRF node, a token response comprising a token for the registration request, transmit, to the further SCP, a further token response comprising the token.
The first network device of claim 21, wherein the token comprises the domain name.
The first network device of any of claims 1 to 22, wherein the domain name indicating at least one of:

a domain to which a network function (NF) consumer belongs,

a domain to which a NF producer belongs,

a domain corresponding to a non-public network (NPN) , or

a domain corresponding to a Public Network Integrated Non Public Network (PNI-NPN) .
The first network device of any of claims 1 to 23, wherein the first network is a public network and the second network is a non-public network, or

wherein the service request comprises a service subscription request.
A second network device comprising:

at least one processor; and

at least one memory storing instructions that, when executed by the at least one processor, cause the second network device at least to:

transmit, to a first network device, a first message for a network service, wherein the first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to a second domain, and the first message comprises a domain name indicating the second domain.
The second network device of claim 25, wherein the second network device comprises a network function (NF) consumer in the second network, and the first message comprises a service request for the network service, and

wherein the third network device comprises a Network Repository Function (NRF) node in the first network, and the second message comprises at least one of:

a discovery request comprising at least one of the domain name or an identifier of the second network device, or

a token request comprising at least one of the domain name or an identifier of the second network device.
The second network device of claim 26, wherein at least one of the service request, the discovery request, or the token request comprises client credentials assertion (CCA) , and wherein the CCA comprises the domain name.
The second network device of claim 25, wherein the second network device comprises a network function (NF) service consumer in the first network, and the first message comprises a service request for the network service, and

wherein the third network device comprises a NF service producer in the second network, and the second message comprises a further service request for the network service, and

wherein the first network and the second network are different.
The second network device of claim 28, wherein the second network device is caused to:

transmit, to a Network Repository Function (NRF) node in the first network, at least one of:

a discovery request comprising a domain name of the NF service producer, or

a token request comprising a domain name of the NF service producer.
The second network device of claim 28, wherein the second network device is caused to:

transmit, to the first network device, the service request comprising a callback Uniform Resource Identifier (URI) of the second network device and a token indicating that the second network device is allowed to access the network service provided by the NF service producer in the second network.
The second network device of claim 30, wherein the token comprises the domain name.
The second network device of claim 30, wherein the service request comprises a service subscription request containing subscription information, and wherein the second network device is caused to:

receive, from the first network device, a notification of the network service based on a callback URI of the second network device, the callback URI of the second network device being determined based on a changed callback URI comprised in a further notification received from a NF service producer, the further notification being associated with the subscription information.
The second network device of claim 25, wherein the second network device comprises a network function (NF) service consumer in the second network, and the first message comprises a service request for the network service, and

wherein the third network device comprises a NF service producer in the second network, and the second message comprises a further service request for the network service, and

wherein the first network and the second network are the same.
The second network device of any of claims 25 to 33, wherein the domain name indicating at least one of:

a domain to which a network function (NF) consumer belongs,

a domain to which a NF producer belongs,

a domain corresponding to a non-public network (NPN) , or

a domain corresponding to a Public Network Integrated Non Public Network (PNI-NPN) .
The second network device of any of claims 25 to 34, wherein the first network is a public network and the second network is a non-public network, or

wherein the service request comprises a service subscription request.
A third network device comprising:

at least one processor; and

at least one memory storing instructions that, when executed by the at least one processor, cause the third network device at least to:

receive, from a first network device, a second message comprising a domain name indicating a second domain,

wherein the second message is transmitted from the first network device based on a first message for a network service,

wherein the first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to the second domain, and the first message comprises the domain name indicating the second domain.
The third network device of claim 36, wherein the second network device comprises a network function (NF) consumer in the second network, and the first message comprises a service request for the network service, and

wherein the third network device comprises a Network Repository Function (NRF) node in the first network, and the second message comprises at least one of:

a discovery request comprising at least one of the domain name or an identifier of the second network device, or

a token request comprising at least one of the domain name or an identifier of the second network device.
The third network device of claim 37, wherein at least one of the service request, the discovery request, or the token request comprises client credentials assertion (CCA) , and wherein the CCA comprises the domain name.
The third network device of claim 36, wherein the second network device comprises a network function (NF) service consumer in the first network, and the first message comprises a service request for the network service, and

wherein the third network device comprises a NF service producer in the second network, and the second message comprises a further service request for the network service, and

wherein the first network and the second network are different.
The third network device of claim 39, wherein the service request comprises a service subscription request containing subscription information, and the third network device is caused to:

transmit, to the first network device, a notification of the network service associated with the subscription information, the notification comprising a changed callback URI of the second network device.
The third network device of claim 39, wherein the second network device transmits to a Network Repository Function (NRF) node in the first network at least one of:

a discovery request comprising a domain name of the NF service producer, or

a token request comprising a domain name of the NF service producer.
The third network device of claim 39, wherein the first network device is caused to:

receive, from the first network device, the further service request comprising at least one of a changed callback Uniform Resource Identifier (URI) , a token or routing binding information,

wherein the changed callback URI is determined based on a callback URI of the second network device comprised in the service request from the first network device, and the token is comprised in the service request and indicates that the second network device is allowed to access the network service provided by the NF service producer in the second network.
The third network device of claim 36, wherein the second network device comprises a network function (NF) service consumer in the first network, and the first message comprises a service request for the network service, and

wherein the third network device comprises a NF service producer in the second network, and the second message comprises a further service request for the network service, and

wherein the first network and the second network are the same.
The third network device of claim 39 or 43, wherein the third network device is caused to:

transmit, to the first network device, a registration request for registering a NF service producer.
The first network device of claim 44, wherein the registration request comprises client credentials assertion (CCA) , and wherein the CCA comprises the domain name.
The third network device of any of claims 43 to 45, wherein the service request comprises a service subscription request containing subscription information, and wherein the third network device is caused to:

receive, from the first network device, the further service request comprising at least one of a changed callback Uniform Resource Identifier (URI) , a token or routing binding information,

wherein the token is comprised in a token response from a Network Repository Function (NRF) node in the first network and the token indicates that the second network device is allowed to access the network service provided by the NF service producer in the second network, and

wherein the changed callback URI is determined based on a callback URI of the second network device in the service request and an address of the first network device.
The first network device of claim 46, wherein the token comprises the domain name.
The third network device of any of claims 36 to 47, wherein the domain name indicating at least one of:

a domain to which a network function (NF) consumer belongs,

a domain to which a NF producer belongs,

a domain corresponding to a non-public network (NPN) , or

a domain corresponding to a Public Network Integrated Non Public Network (PNI-NPN) .
The third network device of any of claims 36 to 48, wherein the first network is a public network and the second network is a non-public network, or

wherein the service request comprises a service subscription request.
A method comprising:

receiving, from a second network device, a first message for a network service, wherein the first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to a second domain, and the first message comprises a domain name indicating the second domain;

transmitting, to a third network device, a second message based on the first message, the second message comprising the domain name.
A method comprising:

transmitting, to a first network device, a first message for a network service, wherein the first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to a second domain, and the first message comprises a domain name indicating the second domain.
A method comprising:

receiving, from a first network device, a second message comprising a domain name indicating a second domain,

wherein the second message is transmitted from the first network device based on a first message for a network service,

wherein the first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to the second domain, and the first message comprises the domain name indicating the second domain.
A first apparatus comprising:

means for receiving, from a second network device, a first message for a network service, wherein the first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to a second domain, and the first message comprises a domain name indicating the second domain; and

means for transmitting, to a third network device, a second message based on the first message, the second message comprising the domain name.
A second apparatus comprising:

means for transmitting, to a first network device, a first message for a network service, wherein the first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to a second domain, and the first message comprises a domain name indicating the second domain.
A third apparatus comprising:

means for receiving, from a first network device, a second message comprising a domain name indicating a second domain,

wherein the second message is transmitted from the first network device based on a first message for a network service,

wherein the first network device is located in a first network corresponding to a first domain and the second network device is located in a second network corresponding to the second domain, and the first message comprises the domain name indicating the second domain.
A computer readable medium comprising instructions stored thereon for causing an apparatus at least to perform the method of any of claims 50 to 52.