WO2022033662A1

WO2022033662A1 - Service traffic across network domain boundaries

Info

Publication number: WO2022033662A1
Application number: PCT/EP2020/072530
Authority: WO
Inventors: Qing Wei; Wint Yi POE
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2020-08-11
Filing date: 2020-08-11
Publication date: 2022-02-17

Abstract

The present disclosure relates to entities for a mobile or cellular communication system, in particular, to support service traffic communication across boundaries of different network domains. The present disclosure provides, to this end, a first boundary entity for arrangement at a first network domain boundary, a network registration function, and a network entity for sending and receiving service traffic. The first boundary entity is configured to provide registration information to the network registration entity, the registration information including a profile of the first boundary entity. The profile of the first boundary entity comprises a list of one or more services provided by one or more service provider entities in one or more second network domains and supported by the first boundary entity.

Description

SERVICE TRAFFIC ACROSS NETWORK DOMAIN BOUNDARIES

TECHNICAL FIELD

The present disclosure relates to entities for a mobile network system, in particular, for a 5^th generation mobile or cellular communication system (5G system). The proposed entities and corresponding methods, according to embodiments of the disclosure, are configured to support the communication of service traffic across boundaries of different network domains. The present disclosure provides, to this end, a boundary entity arranged at a network domain boundary of a first network domain, a network registration function for the first network domain, and a network entity for the first network domain for consuming the service traffic provided by a service provider entity in a second network domain.

In the present disclosure, different network domains may comprise different logical domains of the same network, or may comprise different networks.

BACKGROUND

The 3^rd Generation Partnership Project (3GPP) Release 16, in particular, 3GPP standard TS 23.501 in version 16.4.0 titled "System Architecture for the 5G System; Stage 2", provides definitions with respect to different network domains. In particular, aNon-Public Network (NPN) enables deployment of the 5G System for private use. An NPN may be deployed as a Stand-alone Non-Public Network (SNPN), operated by an NPN operator and not relying on network functions provided by a Public Land Mobile Network (PLMN), or a Public network integrated NPN (PNI-NPN), a non-public network deployed with the support of a PLMN.

In a SNPN deployment scenario, the SNPN Network Functions (NF) need to interact with the PLMN NFs. For instance, the access to SNPN services may be based on PLMN credentials, as in the specific scenario defined in 3GPP standard TR23.700-07 in version 0.3 "Study on enhanced support of non-public networks”. This means that an Access and Mobility Management Function (AMF) in the SNPN needs to interact with a Unified Data Manager Function resp. Authentication Server Function (UDM/AUSF) in the PLMN, in order to get User Equipment (UE) credentials, so that the UE can access the SNPN. When the UE moves between SNPN and PLMN coverage, the SNPN NFs (e.g., a Policy Control Function (PCF)) and the PLMN NFs (e.g., a Session Management Function (SMF)) need to coordinate with each other the network policies based on a Service Level Agreement (SLA) between SNPN and PLMN.

In a PNI-NPN deployment scenario, the NPN NFs also need to interact with the PLMN NFs. For instance, in a particular NPN, which provides a deployment scenario with a shared Radio Access Network (RAN) and Control Plane (CP), the PLMN CP NFs control the NPN User Plane (UP) NFs.

In the 3GPP Release 16, there is further an explicit support of a communication between two NFs within one network. For instance, the communication between the SMF and a User Plane Function (UPF) is done via the N4 interface, which is a bridge between the CP and the UP. For the PNI-NPN deployment scenario, there is no distinction between the case where the UPF is deployed in the PLMN domain and the case where it is deployed in the NPN domain. However, since the NPN NFs and the PLMN NFs may be deployed by different parties over the infrastructure that is owned by different entities, there need to be certain security control and accounting measures between the different network domains.

The 3GPP Release 16 further supports the interaction between NFs in serving and visiting PLMNs, in particular via pre-defined Security Edge Protection Proxy (SEPP) pairs. However, the PLMN and the SNPN have very different network sizes and business relationships. Moreover, the SNPN is a specified network, which may deploy only a few dedicated UPFs and some of the 5GC NFs in a small area (e.g., in a university campus or a factory). In contrast, the PLMN normally needs to deploy various UPFs and 5GC NFs for covering country-wide areas and different operator businesses. Further, one PLMN may need to interact with thousands of SNPNs from different verticals in different areas.

Thus, there is a need for a secure and scalable service communication between different networks domains, i.e. across network domain boundaries. SUMMARY

Embodiments of the present disclosure are based on the following considerations of the inventors.

According to 3GPP standard TS 23.501 in version 16.4.0 titled "System Architecture for the 5G System; Stage 2", service traffic between a visiting PLMN and a home PLMN is communicated via a visit SEPP (vSEPP) and a home SEPP (hSEPP) pair, respectively, using the N32 interface. The N32 is an interface between the control plane of the visiting PLMN and the control plane of the home PLMN. SEPPs forward the service traffic between a NF service consumer and a NF service producer in two different networks after applying message filtering, policing, and security check.

3GPP standard TS 33.501 in version 16.2.0 titled "Security architecture and procedures for 5G system ' specifies details of the SEPP but focuses only on security perspectives. The SEPP pair is always pre-defined in the network, i.e., a NF knows the SEPP it should send service traffic to, and the SEPP knows the paring SEPP, which it should relay the service traffic to. Before a NF sends the service traffic to a NF in another network domain via a pre-defined SEPP, it finds the address of that NF in the other network domain by an inquiry to the Network Repository Function (NRF) in its own network domain, as in a roaming scenario.

For instance, as shown in FIG. 16, when a NF in a visitor network, which is referred to as NF service consumer in FIG. 16, wants to communicate with a NF in a home network, which is referred to as NRF in Home PLMN in FIG. 16, the NF in the visitor network performs a service discovery procedure as shown in FIG. 16, if it does not have the address of the other NF. More specifically, in step 1, the NF service consumer sends a discovery request to a NRF in the visitor network, which is referred to as NRF in serving PLMN in FIG 16. In step 2, the NRF in the visitor network, i.e. NRF in serving PLMN, sends the discovery request to NRF in Home PLMN, and gets the address or the profile of the NF in the home network in response to the discovery request. In step 3, the NRF in serving PLMN responds to the NF service consumer with the discovered NF address or profile in the home PLMN. After the NF in the visitor network thus discovers the address or profile of the other NF in the home network, it sends the service traffic to the predefined vSEPP putting its own address as a source address and the address of the discovered other NF in the home network as a destination address. The vSEPP relays the service traffic to the pairing hSEPP, and the hSEPP relays the service traffic to the NF in the home network according to the discovered address.

The disadvantages of these conventional solutions are as follows:

• No similar SEPP roles are defined for a PNI-NPN deployment scenario between a NPN domain and a PLMN domain (e.g., no security protection for the service traffic communication between different network domains is provided).

• The SEPPs are all pre-defined in the network domain, and the configuration of all related NFs needs to be updated whenever a SEPP is added, deleted, activated, or deactivated in the network domain.

• There is no way for performing congestion control or load balancing for the service traffic communication between network domains using the SEPP pairs (e.g., a huge non-critical service traffic may block some critical service traffic in the peak time).

• No hiding of the network architecture from the other network domain is possible. The NF knows exactly the NF instance (i.e. , the address of that NF) in the other network domain, which it needs to interact with.

• The service discovery is inefficient. In particular, there is a lack of pre-defined NRF pairs between different network domains in addition to the predefined SEPP pairs. Further, there is also a lack of additional service discovery traffic via the SEPP pairs, before the actual service traffic communication between the consumer NFs and provider NFs in the different network domains, which goes again via SEPP pairs.

In view of the above-mentioned disadvantages, embodiments of the present invention aim to improve the conventional solutions. An objective is to enable an improved, e.g., secure and scalable, service traffic communication between different network domains. Another goal is to allow the coordination of the service traffic, e.g., congestion control or load balancing, exchanged between the different network domains. Further, embodiments of the invention should support a more dynamic and flexible deployment of service interaction points between the different network domains. In addition, it should be possible to hide internal architectures of different network domains from each other.

One or more of the objectives mentioned above is achieved by the embodiments of the invention as described in the enclosed independent claims. Advantageous implementations of the embodiments of the invention are further defined in the dependent claims.

A first aspect of the disclosure provides a first boundary entity for arrangement at a boundary of a first network domain and for communicating service traffic with one or more second boundary entities arranged at a boundary of one or more second network domains, the first boundary entity being configured to: provide registration information to a network registration entity of the first network domain, the registration information including a profile of the first boundary entity, wherein the profile of the first boundary entity comprises a list of one or more services provided by one or more service provider entities in the one or more second network domains and supported by the first boundary entity.

As mentioned above, in this disclosure, different network domains may be different logical domains of the same network or may be different networks. Accordingly, the first network domain and the second network domain may, respectively, also be a first network and second network, for example, a non-public network and a public network.

The first boundary entity of the first aspect enables an improved service traffic communication between different network domains. For instance, a service consumer entity in the first network domain can discover the first boundary entity through interacting with the network registration entity. Then, it can request the first boundary entity to consume a service provided by a service provider entity in the second network domain, and can communicate the service traffic via the first boundary entity. Notably, service traffic may include a service request (for a service) and a service response (for the service). The first boundary entity thereby enables the coordination of the service traffic (e.g., congestion control or load balancing) exchanged between the different network domains, as described further below. Further, the first boundary entity can hide the internal architecture of the first network domain from the one or more second network domains, in particular the service provider entity. Using one or more first boundary entities for the first network domain enables a dynamic and flexible deployment of service interaction points between the different network domains. Further, providing one or more first boundary entities for communicating service traffic to and from one or more second network domains, enables scalability.

In an implementation form of the first aspect, the profile of the first boundary entity further comprises at least one of: one or more services traffic types of the one or more services provided by the one or more service provider entities in the one or more second network domains, wherein each service traffic type comprises at least one of a service name, a service provider entity identifier (ID), and a second network domain ID; a service area; load information indicating an allowed throughput of service traffic between the first boundary entity and each of the one or more second boundary entities; support information indicating a supported number of concurrent service traffic connections between the first boundary entity and each of the one or more second boundary entities; and processing information indicating one or more service traffic processing capabilities of the first boundary entity.

Such a profile of one or more first boundary entities can be exposed or made accessible by the network registration entity in the first network domain, and/or it can be discovered by network entities (e.g., service consumer entities, i.e. entities that want to consume a service can send discovery requests) in the first network domain. Based on the profile of the one or more first boundary entities, the network entities in the first network domain may select the first boundary entity, in order to request and then receive a desired service response from the second network domain, in particular from a service provider entity in the second network domain. The information in the profile further allows the network entities in the first network domain to consider congestion of one or more first boundary entities or a load of these first boundary entities, e.g., allowing the network entity may implement load balancing.

In an implementation form of the first aspect, the first boundary entity is further configured to: receive a first request for a first service from a service consumer entity in the first network domain; provide a second request for the first service to a second boundary entity supporting the first service; receive a first service response of the first service from the second boundary entity supporting the first service; and provide a second service response of the first service to the service consumer entity.

In this way, the first boundary entity allows the service consumer entity in the first network domain to consume the service response received from the second boundary entity (and, e.g., stemming from a service provider entity in the second network domain). Notably, the service response received from the second boundary entity (the first service response of the first service) may be modified by the first boundary entity before providing it to the service consumer entity (thus, the second service response of the first service), but may also be the same (in this case, the first and the second service response of the first service are the same).

Further, the first boundary entity allows the service consumer entity in the first network domain to send the service request to the service provider entity in the second network domain via the second boundary entity. Notably, the service request received from the service consumer in the first network domain (the first service request of the first service) may be modified by the first boundary entity before providing it to the second boundary entity (thus, the second service request of the first service), but may also be the same (in this case, the first and the second service request of the first service are the same).

In an implementation form of the first aspect, the first boundary entity is further configured to: receive a first request for a second service from a second boundary entity; provide a second request for the second service to a service provider entity in the first network domain providing the second service; receive a first service response of the second service from the service provider entity providing the second service; and provide a second service response of the second service to the second boundary entity.

In this way, the first boundary entity allows the service consumer entity in the second network domain to consume service the response stemming from the service provider entity in the first network domain. Service traffic across domain boundaries is thus enabled in an improved manner. Notably, the service response received from the service provider entity (the first service response of the second service) may be modified by the first boundary entity before providing it to the second boundary entity (thus, the second service response of the second service), but may also be the same (in this case, the first and the second service response of the second service are the same). Further, the first boundary entity allows the service consumer entity in the second network domain to send the service request to the service provider entity in the first network domain. Notably, the service request received from the service consumer in the second network domain (the first service request of the second service) may be modified by the second boundary entity before providing it to the first boundary entity (thus, the second service request of the second service), but may also be the same (in this case, the first and the second service request of the second service are the same).

In an implementation form of the first aspect, the first boundary entity is further configured to: maintain a Quality of Service (QoS) profile for each supported service traffic type, wherein the QoS profile comprises at least one of: a priority of the service traffic; and a latency requirement of the service traffic.

Thus, the first boundary entity may be configured to priorities one service traffic over the other, or may be configured to ensure a certain latency of the service traffic, in order to maintain a certain QoS profile.

In an implementation form of the first aspect, the first boundary entity is further configured to: maintain information comprising one or more service consumer entities in the first network domain and/or in the one or more second network domains, and/or comprising one or more service provider entities in the first network domain and/or in the one or more second network domains; wherein each service consumer entity and each service provider entity is associated with one or more services.

For instance, the first boundary entity may be configured to learn information related to a service consumer entity or of a service provider entity, after receiving service traffic from that entity directly or via the second boundary entity, or the first boundary entity may discover such information using the network registration entity, or may be locally configured with such information. The information maintained by the first boundary entity allows the first boundary entity to contact the relevant second boundary entities, and likewise enables second boundary entities to contact it as relevant first boundary entity for requesting or providing certain service traffic. In an implementation form of the first aspect, the information further comprises a correlation between a service consumer entity in one of the first network domain and the one or more second network domains associated with a certain service, and a service provider entity in the other one of the first network domain and the one or more second network domains associated with the certain service.

The correlation may be built by the first boundary entity by getting and/or aggregating one or more services from different service consumer entities and service provider entities. In this way, the first boundary entity may more efficiently communicate the service traffic.

In an implementation form of the first aspect, the first boundary entity is further configured to: add at least one of the service consumer entity providing the request for the first service and the service provider entity providing the second service to the maintained information, if the at least one of the service consumer entity and the service provider entity is not already included.

Notably, this implementation form includes adding a new service consumer entity or service provider entity associated with a new service, but also adding a new service consumer entity or service provider entity associated with an already known service.

In an implementation form of the first aspect, the first boundary entity is further configured to: convert one or more service parameters of the service traffic communicated with the one or more second boundary entities from service parameters valid in one of the first and the second network domains to service parameters valid in the other one of the first and the second network domains.

The conversion of the service parameters may be done according to a pre-configuration or locally maintained information. Further, converting service parameters may include an address translation. The maintained information may comprise address information.

In an implementation form of the first aspect, the first boundary entity is further configured to: process the service traffic communicated with the one or more second boundary entities. In this way, the first boundary entity can influence the communication of the service traffic across network domain boundaries, and thus can improve the communication of service traffic.

In an implementation form of the first aspect, processing the service traffic comprises at least one of aggregating the service traffic of one or more services, traffic shaping of the service traffic of one or more services, policing or scheduling the service traffic of one or more services, and analysing the service traffic based on QoS profile of the service traffic type.

The first boundary entity may monitor incoming and outgoing service traffic (i. e. , service traffic received from or provided to the one or more second boundary entities). Analyzing the service traffic may include calculating, whether service traffic aggregation (e.g., if a supported number of concurrent service traffic connections between the first boundary entity and each of the one or more second boundary entities or service traffic is exceeded) or service traffic shaping (e.g., if an allowed throughput of service traffic between the first boundary entity and each of the one or more second boundary entities is exceeded) is necessary.

In particular, the first boundary entity may perform at least one of aggregating service requests for one or more services, traffic shaping service requests for one or more services, policing or scheduling service requests of one or more services. Further, the the first boundary entity may perform at least one of aggregating service responses for one or more services, traffic shaping service responses for one or more services, policing or scheduling service response of one or more services, and analysing the service response based on a QoS profile of the service traffic type.

In an implementation form of the first aspect, the first boundary entity comprises at least one of a SEPP and a Network Exposure Function (NEF). Further, the network registration entity may comprise a NRF.

In an implementation form of the first aspect, the first network domain is a domain of a non-public network and the one or more second network domains include a domain of a public network. For instance, the public network may be a PLMN of VPLMN, and/or the non-pubhc network may be a SNPN or a PNI-NPN or HPLMN.

A second aspect of the present disclosure provides a network registration entity for a first network domain, the network registration entity being configured to: receive a profile from one or more first boundary entities, wherein each first boundary entity is arranged at a boundary of the first network domain; store the profile of the one or more first boundary entities, wherein the profile comprises a list of one or more services provided by one or more service provider entities in one or more second network domains and supported by the one or more first boundary entities; and provide at least one of an address and the profile of one or more determined first boundary entities to a network entity in the first network domain.

Generally, the network registration entity may expose or make accessible the received profile of the one or more first boundary entities in the first network domain. It may, for example, provide the profile of the determined one or more first boundary entities (some or all of the first boundary entities, from which a profile is received) or information derived from the profile (e.g., the address), for example, upon request. The network registration entity may be or may comprise a NRF. The network entity, to which the network registration entity provides the profile(s), may be a service consumer entity in the first network domain. This service consumer entity can then request and consume a service of a service provider entity in the second network domain, based on the profile of the first boundary entity, as described above. Thus, the network registration entity providing the address or the profile of the one or more determined first boundary entities enables an improved service traffic communication across network domain boundaries.

In an implementation form of the second aspect, the network registration entity is further configured to: receive a discovery request from the network entity in the first network domain, the discovery request comprising a desired service; and determine the one or more determined first boundary entities based on the desired service and the stored profiles. That is, the network registration entity can make a selection or a pre-selection of some appropriate determined first boundary entities, and may provide the address or profile of these determined one or more first boundary entities to the network entity.

In an implementation form of the second aspect, the network registration entity is further configured to: determine the one or more determined first boundary entities based on at least one of QoS requirements of the desired service and a service traffic type of the desired service.

In an implementation form of the second aspect, the profile of the first boundary entity further comprises at least one of: one or more service traffic types of the one or more services provided by the one or more service provider entities in the one or more second network domains, wherein each service traffic type comprises at least one of a service name, a service provider entity ID, and a second network domain ID; a service area; load information indicating an allowed throughput of service traffic between the first boundary entity and each of the one or more second boundary entities; support information indicating a supported number of concurrent service traffic connections between the first boundary entity and each of the one or more second boundary entities; processing information indicating one or more service traffic processing capabilities of the first boundary entity, and wherein the network registration entity is further configured to determine the one or more determined first boundary entities based on at least one of the one or more service traffic types, the service area, the load information, the support information, and the processing information included in the profiles of the one or more first boundary entities.

A third aspect of the present disclosure provides a network entity for a first network domain, the network entity being configured to: receive at least one of an address and a profile of one or more first boundary entities from a network registration entity of the first network domain, wherein the profile of the one or more first boundary entities comprises a list of one or more services provided by one or more service provider entities in one or more second network domains and supported by the one or more first boundary entities; select at least one first boundary entity from the one or more first boundary entities, based on at least one of a desired service and the at least one of the address and the profile of the one or more first boundary entities; and send a request for the desired service to the selected at least one first boundary entity. The network entity may be a service consumer entity in the first network domain. The network entity can select an appropriate first boundary entity based on the profile(s) of the one of more first boundary entities, which it received form the network registration entity. These may be the determined (e.g. pre-selected) first boundary entities mentioned above with respect to the second aspect. The network entity may then send the request for the desired service, and may receive corresponding service response from the selected first boundary entity. This service response may stem from a service provider entity in one or more second network domains. Thus, an improved service traffic communication over network domain boundaries is achieved.

In an implementation form of the third aspect, the network entity is further configured to: send a discovery request to the network registration entity, the discovery request comprising the desired service; and receive the at least one of the address and the profile of the one or more first boundary entities supporting the desired service, in response to the discovery request.

In an implementation form of the third aspect, the discovery request includes at least one of a service traffic type of the desired service and QoS requirements for the desired service.

In an implementation form of the third aspect, the network entity is further configured to: select the at least one first boundary entity from the one or more first boundary entities based on at least one of QoS requirements of the desired service and a service traffic type of the desired service.

In an implementation form of the third aspect, the profile of each first boundary entity further comprises at least one of: one or more service traffic types of the one or more services provided by the one or more service provider entities in the one or more second network domains, wherein each service traffic type comprises at least one of a service name, a service provider entity ID, and a second network domain ID; a service area; load information indicating an allowed throughput of service traffic between the first boundary entity and each of the one or more second boundary entities; support information indicating a supported number of concurrent service traffic connections between the first boundary entity and each of the one or more second boundary entities; processing information indicating one or more service traffic processing capabilities of the first boundary entity, and wherein the network entity is further configured to select the at least one first boundary entity from the one or more first boundary entities based on at least one of the one or more service traffic types, the service area, the load information, the support information, and the processing information included in the profile of the one or more first boundary entities.

A fourth aspect of the present disclosure provides a method performed by a first boundary entity arranged at a boundary of a first network domain and communicating service traffic with one or more second boundary entities arranged at a boundary of one or more second network domains, the method comprising: providing registration information to a network registration entity of the first network domain, the registration information including a profile of the first boundary entity, wherein the profile of the first boundary entity comprises a list of one or more services provided by one or more service provider entities in the one or more second network domains and supported by the first boundary entity.

In an implementation form of the fourth aspect, the profile of the first boundary entity further comprises at least one of: one or more service traffic types of the one or more services provided by the one or more service provider entities in the one or more second network domains, wherein each service traffic type comprises at least one of a service name, a service provider entity ID), and a second network domain ID; a service area; load information indicating an allowed throughput of service traffic between the first boundary entity and each of the one or more second boundary entities; support information indicating a supported number of concurrent service traffic connections between the first boundary entity and each of the one or more second boundary entities; and processing information indicating one or more service traffic processing capabilities of the first boundary entity.

In an implementation form of the fourth aspect, the method further comprises: receiving a first request for a first service from a service consumer entity in the first network domain; providing a second request for the first service to a second boundary entity supporting the first service; receiving a first service response of the first service from the second boundary entity supporting the first service; and providing a second service response of the first service to the service consumer entity. In an implementation form of the fourth aspect, the method further comprises: receiving a first request for a second service from a second boundary entity; providing a second request for the second service to a service provider entity in the first network domain providing the second service; receiving a first service response of the second service from the service provider entity providing the second service; and providing a second service response of the second service to the second boundary entity.

In an implementation form of the fourth aspect, the method further comprises: maintaining a QoS profile for each supported service traffic type, wherein the QoS profile comprises at least one of: a priority of the service traffic; and a latency requirement of the service traffic.

In an implementation form of the fourth aspect, the method further comprises maintaining information comprising one or more service consumer entities in the first network domain and/or in the one or more second network domains, and/or comprising one or more service provider entities in the first network domain and/or in the one or more second network domains; wherein each service consumer entity and each service provider entity is associated with one or more services.

In an implementation form of the fourth aspect, the information further comprises a correlation between a service consumer entity in one of the first network domain and the one or more second network domains associated with a certain service, and a service provider entity in the other one of the first network domain and the one or more second network domains associated with the certain service.

In an implementation form of the fourth aspect, the method further comprises adding at least one of the service consumer entity providing the request for the first service and the service provider entity providing the second service to the maintained information, if the at least one of the service consumer entity and the service provider entity is not already included.

In an implementation form of the fourth aspect, the method further comprises converting one or more service parameters of the service traffic communicated with the one or more second boundary entities from service parameters valid in one of the first and the second network domains to service parameters valid in the other one of the first and the second network domains.

In an implementation form of the fourth aspect, the method further comprises processing the service traffic communicated with the one or more second boundary entities.

In an implementation form of the fourth aspect, processing the service traffic comprises at least one of aggregating the service traffic of one or more services, traffic shaping of the service traffic of one or more services, policing or scheduling the service traffic of one or more services, and analysing the service traffic based on QoS profile of the service traffic type.

In an implementation form of the fourth aspect, the first boundary entity comprises at least one of a SEPP and a NEF.

In an implementation form of the fourth aspect, the first network domain is a domain of a non-public network and the one or more second network domains include a domain of a public network.

The method of the fourth aspect and its implementation forms achieve all advantages and effects of the first boundary entity of the first aspect and its respective implementation forms.

A fifth aspect of the present disclosure provides a method performed by a network registration entity of a first network domain, the method comprising: receiving a profile from one or more first boundary entities, wherein each first boundary entity is arranged at a boundary of the first network domain; storing the profile of the one or more first boundary entities, wherein the profile comprises a list of one or more services provided by one or more service provider entities in one or more second network domains and supported by the one or more first boundary entities; and providing at least one of an address and the profile of one or more determined first boundary entities to a network entity in the first network domain. In an implementation form of the fifth aspect, the method further comprises receiving a discovery request from the network entity in the first network domain, the discovery request comprising a desired service; and determining the one or more determined first boundary entities based on the desired service and the stored profiles.

In an implementation form of the fifth aspect, the method further comprises determining the one or more determined first boundary entities based on at least one of QoS requirements of the desired service and a service traffic type of the desired service.

In an implementation form of the fifth aspect, the profile of the first boundary entity further comprises at least one of: one or more service traffic types of the one or more services provided by the one or more service provider entities in the one or more second network domains, wherein each service traffic type comprises at least one of a service name, a service provider entity ID, and a second network domain ID; a service area; load information indicating an allowed throughput of service traffic between the first boundary entity and each of the one or more second boundary entities; support information indicating a supported number of concurrent service traffic connections between the first boundary entity and each of the one or more second boundary entities; processing information indicating one or more service traffic processing capabilities of the first boundary entity, and wherein the network registration entity is further configured to determine the one or more determined first boundary entities based on at least one of the one or more service traffic types, the service area, the load information, the support information, and the processing information included in the profiles of the one or more first boundary entities.

The method of the fifth aspect and its implementation forms achieve all advantages and effects of the network registration entity of the second aspect and its respective implementation forms.

A sixth aspect of the present disclosure provides a method performed by a network entity of a first network domain, the method comprising: receiving at least one of an address and a profile of one or more first boundary entities from a network registration entity in the first network domain, wherein each profile comprises a list of one or more services provided by one or more service providers in one or more second network domains and supported by the one or more first boundary entities; selecting at least one first boundary entity from the one or more first boundary entities, based on a desired service and based on the at least one of the address and/or the profile of the one or more first boundary entities; and sending a request for the desired service to the selected at least one first boundary entity.

In an implementation form of the sixth aspect, the method further comprises: sending a discovery request to the network registration entity, the discovery request comprising the desired service; and receiving the at least one of the address and the profile of the one or more first boundary entities supporting the desired service, in response to the discovery request.

In an implementation form of the sixth aspect, the discovery request includes at least one of a service traffic type of the desired service and QoS requirements for the desired service.

In an implementation form of the sixth aspect, the method further comprises selecting the at least one first boundary entity from the one or more first boundary entities based on at least one of QoS requirements of the desired service and a service traffic type of the desired service.

In an implementation form of the sixth aspect, the profile of each first boundary entity further comprises at least one of: one or more service traffic types of the one or more services provided by the one or more service provider entities in the one or more second network domains, wherein each service traffic type comprises at least one of a service name, a service provider entity ID, and a second network domain ID; a service area; load information indicating an allowed throughput of service traffic between the first boundary entity and each of the one or more second boundary entities; support information indicating a supported number of concurrent service traffic connections between the first boundary entity and each of the one or more second boundary entities; processing information indicating one or more service traffic processing capabilities of the first boundary entity, and wherein the network entity is further configured to select the at least one first boundary entity from the one or more first boundary entities based on at least one of the one or more service traffic types, the service area, the load information, the support information, and the processing information included in the profile of the one or more first boundary entities. The method of the sixth aspect and its implementation forms achieve all advantages and effects of the network entity of the third aspect and its respective implementation forms.

A seventh aspect of the present disclosure provides a computer program comprising program code for performing the method according to one of the fourth to sixths aspects, or any of their implementation forms, when executed on a processor.

An eight aspect of the present disclosure provides a non-transitory storage medium storing executable program code which, when executed by a processor, causes the method according to one of the fourth to sixths aspects or any of their implementation forms to be performed.

It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.

BRIEF DESCRIPTION OF THE DRAWINGS

The above described aspects and implementation forms will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which:

FIG. 1 shows an overview of several entities according to embodiments of the invention, for service traffic communication across a network domain;

FIG. 2 shows schematically different network domains with their boundary entities and NFs; FIG. 3 illustrates an architecture of a first boundary entity according to an embodiment of the invention;

FIG. 4 illustrates a profile of a first boundary entity according to an embodiment of the invention;

FIG. 5 shows a service registration and discovery procedure involving entities according to embodiments of the invention;

FIG. 6 shows a service traffic processing procedure involving entities according to embodiments of the invention;

FIG. 7 shows boundary entities according to embodiments of the invention implemented as enhanced SEPPs;

FIG. 8 shows boundary entities according to embodiments of the invention implemented as enhanced SEPPs attached to NEFs;

FIG. 9 shows boundary entities according to embodiments of the invention implemented as enhanced SEPPs for a scenario of a service consumer entity receiving a same type of service from multiple service provider entities;

FIG. 10 shows a procedure of aggregation and coordination of monitoring data by boundary entities according to embodiments of the invention implemented as enhanced SEPPs in a PLMN and aNPN, respectively;

FIG. 11 shows a boundary entity according to an embodiment of the invention implemented as an enhanced SEPP in a PLMN for a scenario of receiving a same type of service from two or more enhanced SEPPs in NPNs;

FIG. 12 shows a procedure of aggregation and coordination of a subscription service by boundary entities according to embodiments of the invention implemented as enhanced SEPPs in a PLMN and a NPN; FIG. 13 shows a method performed by a first boundary entity according to an embodiment of the invention;

FIG. 14 shows a method performed by a network registration entity according to an embodiment of the invention;

FIG. 15 shows a method performed by a network entity according to an embodiment of the invention; and

FIG. 16 shows a conventional service discovery procedure, wherein a NF service consumer in a visiting network discovers an address or profile of a NF in a home network.

DETAILED DESCRIPTION OF EMBODIMENTS

FIG. 1 shows several entities according to embodiments of the invention, and particularly illustrates a basic scheme proposed by the present disclosure. FIG. 1 shows a first boundary entity 100 according to an embodiment of the invention, a network registration entity 104 according to an embodiment of the invention, and a network entity 106 according to an embodiment of the invention, a second boundary entity 110 according to an embodiment of the invention, and a service provider entity 112 according to an embodiment of the invention. The first boundary entity 100, the network registration entity 104, and the network entity 106 are arranged in a first network domain 101, wherein the first boundary entity 100 is specifically arranged at a boundary of the first network domain 101. The second boundary entity 110 and the service provider entity 112 are arranged in a second network domain 111, wherein the second boundary entity 110 is specifically arranged at the boundary of the second network domain 111. The second boundary entity 110 may be configured like the first boundary entity 100, according to an embodiment of the invention, and the first boundary entity 100 and the second boundary entity 110 may communicate service traffic 120 across the network domain boundaries of the first network domain 101 and the second network domain 111.

Notably, there may generally be more than one first boundary entity 100 arranged at the boundary of the first network domain 101, and likewise there may be more than one second boundary entity 110 arranged at the boundary of the second network domain 111. Moreover, there may generally be more than one network entity 106 (in particular, one or more service consumer entities 106) in the first network domain 101, and more than one service provider entity 112 in the second network domain 111. There may also be one or more service provider entities 102 in the first network domain 101 (not shown) and one or more service consumer entities 116 in the second network domain 111 (not shown). Thereby, a service provider entity 112 in the second network domain 111 and a service provider entity 102 in the first network domain 101 may be configured likewise. Also, a service consumer entity 106 in the first network domain 101 and a service consumer entity 116 in the second network domain 111 may be configured and function likewise. Further a service provider entity 102 or 112 may at the same time be a service consumer entity 106 or 116 (e.g., for different services), i.e. a service provider/consumer entity 102/106 or 112/116. In addition, there may also be more than one second network domain 111, wherein each second network domain 111 may comprise one or more second boundary entities 110 and one or more service provider entities 112. FIG. 1 is simplified with respect to the above general case, and shows only one entity of each type.

The first boundary entity 100 and the second boundary entity 110 may each be, or may each comprise, at least one of a SEPP and a NEF. That is, either boundary entity 100, 110 may comprise a SEPP, or a NEF, or a SEPP and a NEF. The network entity 106 and/or the service provider entity 112 may each be, or may comprise, a NF, wherein the NF may be one of a SMF, an AF, a PCF, an UPF, or the like. The network registration entity 104 may be, or may comprise, aNRF.

The first boundary entity 100 shown in FIG. 1 is generally configured to communicate, e.g., provide, or receive, or exchange service traffic 120 with one or more second boundary entities 110 of one or more second network domains 111. FIG. 1 shows specifically that the first boundary entity 100 can communicate service traffic 120 with the shown second boundary entity 110.

The first boundary entity 100 is further configured to provide registration information 103 to the network registration entity 104 in the first network domain 101. The registration information 103 includes a profile 105 of the first boundary entity 100. The profile 105 of the first boundary entity 100 comprises at least a list of one or more services, which are provided by one or more service provider entities 112 in the one or more second network domains 111, and which is supported by the first boundary entity 100. For instance, the list may comprise one or more services provided by the shown service provider entity 112.

The network registration entity 104 is accordingly configured to receive the profile 105 from the first boundary entity 100, as shown in FIG. 1. Likewise, the network registration entity 104 may receive a similar profile 105 from one or more further first boundary entities 105 of the first network domain. The network registration entity 104 is thus generally configured to receive the profile 105 of one or more first boundary entities 100, and is configured to store the profile 105 of the one or more first boundary entities 100. Notably, the profile 105 of each first boundary entity 110 thereby comprises a list of services as described above.

The network registration entity 104 is further configured to provide at least one of an address 105a or the profile 105 of one or more determined first boundary entities 100 (i.e., determined from all of the one or more first boundary entities 110, from which the network registration entity 104 received the profile 105) to the network entity 106. For example, the network registration entity 104 may receive a discovery request from the network entity 106, wherein the discovery request comprises a desired service, and may then determine the one or more determined first boundary entities 100 based on the desired service and the stored profiles 105 (i.e., the profile 105 of each first boundary entity). Additionally, or alternatively, the network registration entity 104 could be configured to determine the one or more determined first boundary entities 100 based on at least one of QoS requirements of the desired service and a service traffic type of the desired service.

The network entity 106 is accordingly configured to receive at least one of the address 105 a and the profile 105 of the one or more determined first boundary entities 100 from the network registration entity 104. Further, the network entity 106 is configured to select at least one first boundary entity 100 from the one or more determined first boundary entities 100, based on a desired service (that is, a service it desires to consume) and the at least one of the address 105a and the profile 105 of the one or more determined first boundary entities 100. Then, the network entity 106 is configured to send a request 107 for the desired service to the selected at least one first boundary entity 100. In FIG. 1, it is illustrated that the network entity 106 selects the shown first boundary entity 100 and sends the request 107 to it.

The selected first boundary entity 100 (in this case, the shown first boundary entity 100) may accordingly receive the request 107 for the desired service from the network entity 106, and may provide the request 107 (or a second request derived based on the request

107), for the desired service to the second boundary entity 110 that supports that service. In response, it may receive a service response 108 for the desired service from the second boundary entity 110. Notably, the service response 108 may stem from one or more service provider entities 112 in the second network domain 111 as shown, and may be provided via the second boundary entity 110 and the first boundary entity 100 to the network entity 106 in the first network domain 101 (each entity may thereby modify the service response

108). That is, the first boundary entity 100 may further provide the service response 108 of the desired service to the network entity 106. In this way, the network entity 106 in the first network domain 101 is able to consume the desired service, which is provided by the service provider entity 112 in the second network domain. The service traffic 120 communicated between the first boundary entity 100 and the second boundary entity 110 comprises the service request 107 and the service response 108.

The entities 100, 104, 106, 110 and 112 shown in FIG. 1 may each comprise a processor or processing circuitry (not shown) configured to perform, conduct or initiate the various operations of the respective entity described herein. The processing circuitry may comprise hardware and/or the processing circuitry may be controlled by software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multipurpose processors.

The entities 100, 104, 106, 110 and 112 shown in FIG. 1 may each further comprise memory circuitry, which stores one or more instruction(s) that can be executed by the processor or by the processing circuitry, in particular under control of the software. For instance, the memory circuitry may comprise a non-transitory storage medium storing executable software code which, when executed by the processor or the processing circuitry, causes the various operations of the respective entity to be performed. In one embodiment, the processing circuitry comprises one or more processors and a non- transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the respective entity to perform, conduct or initiate the operations or methods described herein.

FIG. 2 shows a general overview of an exemplary implementation of the scheme described above with respect to FIG. 1. In particular, the first network domain 101 is specifically an NPN (“NPN1”) in this example, and the second network domain 111 is a PLMN in this example. The first boundary entity 100 arranged at the boundary of the first network domain 101 is configured to communicate service traffic 120 with at least two second boundary entities 110 arranged at the boundary of the second network domain 111. That is, embodiments of the invention generally propose boundary entity pairs between two network domains. FIG. 2 further illustrates that there may be another network domain 201, e.g., another NPN (“NPN2”), which comprises at least one further boundary entity 200 that is configured to communicate service traffic 120 with at least one second boundary entity 110 of the second network domain 111. The boundary entity 200 may be configured like the first boundary entity 100, according to an embodiment of the invention. FIG. 2 also illustrates that each network domain 101, 111, 201 may comprise NFs, like a SMF, an AF, a UPF, a PCF, a UDR, and/or an NRF.

The first boundary entity 100 may be able to monitor the service traffic 120 going out/in the first network domain 101, and may further process the service traffic 120. For example, the first boundary entity 100 may aggregate service traffic 120, and/or shape service traffic 120. That is, the first boundary entity 100 may aggregate multiple service requests 107, and/or may aggregate multiple service responses 108. Further, the first boundary entity 100 may shape one or more service requests 107, and/or may shape one or more service response 108. For instance, this may be necessary due to a too high number of service traffic connections (i. e. , service traffic 120 of different services may be aggregated) or too high overall traffic load (i. e. , service traffic may be shape, e.g. throttled, by reducing the service traffic throughput). This can accordingly help to reduce congestions due to service traffic 120 between the network domains 101 and 111, and/or to avoid overloading a service provider entity 112 (shown in FIG. 1) that needs to serve multiple service consumer entities (as e.g. the network entity 106 shown in FIG. 1).

In addition, first boundary entity 100 may be able to perform a conversion of service parameters between the different networks domains 101 and 111, i.e., to convert one or more service parameters of the service traffic 120 communicated with the one or more second boundary entities 110 from service parameters valid in one of the first network domain 101 and the one or more second network domains 111 to service parameters valid in the other one of the first network domain 101 and the one or more second network domains 111 (depending on the direction of the service traffic 120, e.g., whether the service traffic 120 is a service request 107 or a service response 108). The first boundary entity 100 may also change the source/destination service address, and may apply service constraints.

The first boundary entity 100 may adopt at least one service based interface (SBI) and may support a registration and discovery mechanism as defined in 3GPP Release 15. This enables a dynamic deployment of one or more first boundary entities 100 at the boundary of the first network domain 101, without the efforts to configure it also at each entity (e.g., at each NF in the first network domain 101), which needs to provide or needs to receive service traffic 120 via the first boundary entity 100. Meanwhile, the appropriated first boundary entity 100 for that service traffic 120 can be flexibly selected (e.g., by the network entity 106 or by the network registration entity 104, or by both wherein the network registration entity 104 determines one or more determined first boundary entities 100 and then the network entity 106 selects one or more first boundary entities 100 from the one or more determined first boundary entities 100, as described above), based on at least one of a service traffic load and a service traffic requirements (e.g., a type of the service traffic). Thus, overloading one or more first boundary entities 100 may be avoided.

FIG. 2 particularly illustrates a scheme of multiple boundary entities 100 and 110. In particular, one or more boundary entity pairs can be deployed between two networks domains 101, 111. For instance, with respect to FIG. 2, the first boundary entity 100 of the first network domain 101 may be connected to multiple second boundary entities 110 of the second network domain 111, wherein one second boundary entity 110 may, for example, be deployed in a central cloud for a UDM service interaction, and one other second boundary entity 110 may be deployed in an edge cloud for SMF service interaction. At least one second boundary entity 110 may be connected to multiple first boundary entities 100 located in different network domains 101, 201 or different network domain areas. Generally, one boundary entity in a network domain can be paired with multiple boundary entities in one or more other network domains.

FIG. 3 shows an exemplary architecture of a first boundary entity 100 for a first network domain 101, according to an embodiment of the invention, which may build on the first boundary entity 100 shown in FIG. 1 or FIG. 2. The first boundary entity 100 may use at least one SBI as described above, for instance, one or more intra-domain SBIs 302 (into the first network domain 101) and one or more inter-domain SBIs 303 (to one or more second network domains 111). The first boundary entity 100 may further maintain information 300 comprising one or more service consumer entities 106 in the first network domain 101 and/or one or more service consumer entities 116 in the one or more second network domains 111, and/or comprising one or more service provider entities 102 in the first network domain 101 and/or one or more service provider entities 112 in the one or more second network domains 111. Thereby, each service consumer entity 106/116 and each service provider entity 102/112 may be associated with one or more services.

The first boundary entity 100 may be configured with the following components:

• A service traffic processor 301, which is able to modify the service traffic 120 passing by/through it (e.g., it may change service parameters, may merge multiple service requests 107 and/or may merge multiple service responses 108, etc.). Further, the service traffic processor 301 may schedule the service traffic 120, e.g., may be able to decide on a forwarding operation of the service traffic 120 (e.g., a holding time of a service request 107 and/or a service response 108, before forwarding).

• The information 300 may include a list of the service consumer entities 106 in its own first network domain 101, mapped to correspondent service provider entities 112 in one or more second network domains 111. Optionally, the information 300 may also include service information for each service associated with the service consumer entities 106 and service provider entities 112.

• The information 300 may further include a list of the service provider entities 102 in its own first network domain 101 mapped to correspondent service consumer entities 116 in one or more second network domains 111. Optionally, the information 300 may also include service information for each service associated with the service consumer entities 116 and service provider entities 102.

• In the information 300, each service consumer entity 106/116 and/or service provider entity 112 can be identified by the following parameters:

■ Network domain ID (e.g., PLMN ID + NID)

■ Network slice ID (e.g., Network Slice Selection Assistance Information (NSSAI))

■ NF type (e.g., AMF, SMF etc.)

■ Fully-Qualified Domain Name (FQDN) or Internet Protocol (IP) address of a NF (discovered with the help of the NRF)

• The service information may include:

■ Service type (e.g., the name of the service traffic 120)

■ QoS for the service traffic 120 (e.g., a priority, a latency requirement of the service traffic 120).

FIG. 4 illustrates schematically a profile 105 of a first boundary entity 100 according to an embodiment of the invention, wherein the profile 105 may be provided by the first boundary entity 100 to the network registration entity 104, as described above. The profile 105 of the first boundary entity 100 may include the following information (the information described below may be provided in addition to other NF profiles defined in 3GPPP):

• A list of one or more supported external network domain services, and for each service:

■ Network domain ID;

■ Supported NF type (optional);

■ Supported service type (optional);

■ Additional parameters, e.g., Tracking Area identifier (TAI), UE group, etc. (optional);

• A serving area (e.g., in the form of list of TAI(s) and/or cell(s)); • Load information, e.g., an allowed throughput of the service traffic 120 between the first boundary entity 110 and each of the one or more second boundary entities, (e.g., allowed throughput per service traffic type, and/or per network domain pair);

• Support information, e.g., an allowed number of concurrent service connections between the first boundary entity 100 and each of the one or more second boundary entities 110, (e.g., support information per service traffic type, and/or per network domain pair);

• Capability information, e.g., indicating one or more supported service traffic coordination/processing capabilities of the first boundary entity 100 (e.g., none, traffic shaping, traffic/service aggregation, etc.);

• The first boundary entity 100 adopts SBI and has e.g. two types of SBI;

■ intra-domain SBI(s) 303 towards NFs in the first network domain 101;

■ Inter-domain SBI(s) 302 towards the one or more second network domains 111.

FIG. 5 shows an exemplary procedure for registration and discovery of the first boundary entity 110 according to an embodiment of the invention. In particular, FIG. 5 shows the following steps:

• Step 1 : The pairing second boundary 110 can be pre-configured at the first boundary entity 110, or it can be discovered via the network registration entity 104 (as example, via the NRF 104). Optionally also a cross-domain registration method may be performed. That is the second boundary entity 110 in the second network domain 111 (as example a PLMN 111) may register itself via the first boundary entity 100 of the first network domains 101 (as example aNPN 101) at the network registration entity 104 of the NPN, so that first boundary entity 100 could discover more easily the pairing second boundary entity 110.

• Steps 2a, 2b: The profile 105 of the first boundary entity 100 is configured or registered in the network registration entity 104 in the firs) network domain 101, e.g., following a similar procedure as specified in the 3GPP Release 16 NRF service procedure (see Release 16, figure 4)

• Step 3: The first boundary entity 100 can be discovered via the NRF 104, e.g. by the network entity 106 (as example a service consumer NF 106) or may be preconfigured at the service consumer NF 106. For instance, the service consumer NF 106 may send a discovery request to the NRF 104 as described above.

• Steps 4, 5, and 6: The consumer NF 106 may then send a service request 107 for a desired service to the first boundary entity 100 in step 4, and the first boundary entity 100 will provide the service request 107 further to the second network domain via the second boundary entity 110 in step 5. The second boundary entity 110 will then provide the service request 107 to the Provider NF 112 in step 6.

FIG. 5 further illustrates the service provider entity 112 in the second network domain 111 (as example a service provider NF 112), and shows that the second network domain 111 may also have a network registration entity 114 (for example, a NRF 114), which may register the second boundary entity 110 like the NRF 104 registers the first boundary entity 100. That is, the second boundary entity 110 may function (within its second network domain 111) like the first boundary entity 100 (in its first network domain 101), according to an embodiment of the invention.

FIG. 6 shows an exemplary procedure of service traffic 120 processing using the first boundary entity 100. Knowing, for instance, the corresponding address of the first boundary entity 100, the network entity 106 (for example, a service consumer/provider NF 102/106) may be able to communicate service traffic 120 with the service provider entity 112 in the second network domain 111 (for example, a service provider/consumer NF 112/116) as shown in FIG. 6:

• Step 0: The boundary entity service registration and discovery (via network registration entity 104, e.g., NRF, or pre-configured) takes place as shown in FIG. 5.

• Step 1 : The service consumer entity 106 sends a service request 107 to the discovered (selected, see above) first boundary entity 100. Step 2: The first boundary entity 100 generates an entry into the information 300 maintained by the first boundary entity 100 (see e.g. FIG. 3), for instance, a table entry for the service consumer/provider NF 102/106 and the external service provider/ consumer NF 112/116, if these entities do not yet exist in the information 300 maintained by the first boundary entity 100 (otherwise it may extend the service provider list included in the information 300). Further, the first boundary entity 100 may perform service request aggregation and/or coordination.

Step 3: The first boundary entity 100 sends the (potentially modified) service request 107 to the second boundary entity 110.

Step 4: The second boundary entity 110 generates an entry into information 300 maintained by the second boundary entity 110 (similar to that of the first boundary entity 100 shown in and described with respect to FIG. 3), e.g., a table entry for the service provider/consumer NF 112/116 and external service consumer/provider NF 106, if these entities do not yet exist in the information 300 maintained by the second boundary entity (otherwise it may extend a service consumer list in its information 300). The second boundary entity 110 may further perform a service discovery, or a service request aggregation and/or coordination.

Steps 5-6: The second boundary entity 110 sends service request 107 (potentially modified by the second boundary entity 110) and receives service response 108 (i.e., a response to the service request 107 in the form of service traffic 120) in the second network domain 111 (PLMN).

Step 7 : The second boundary entity 110 fills in the table with the discovered provider service parameters, performs service parameter conversion, and dispatches the service traffic 120 to the external service consumer/provider NF 102/106 via the correspondent first boundary entity 100.

Step 8: The first boundary entity 100 fills in its information 300 with provider service parameters, performs service parameter conversion, and dispatch the service traffic 120 to the service consumer/provider entity 102/106. In the following, different exemplary implementations of the first boundary entity 100 and the second boundary entity 110, according to embodiments of the invention, are described, wherein the first boundary entity 100 and second boundary entity 110 in each case build on the boundary entities 100 and 110 shown in the previous figures. FIG. 7 shows the first boundary entity 100 and second boundary entity 110 being implemented as an enhanced SEPP. FIG. 8 shows the first boundary entity 100 and second boundary entity 110 being each implemented as an integrated NEF and SEPP. FIG. 9 and 10 illustrate the use case of the first boundary entity 100 and the second boundary entity 110 for the aggregation and coordination of monitored data. FIG. 11 and 12 illustrate the use case of the first boundary entity 100 and the second boundary entity 110 for the aggregation and coordination of a subscription service.

FIG. 7 shows, as an exemplary implementation, that the fist boundary entity 100 and the second boundary entity 110 can each be implemented as a SEPP. The first boundary entity 100 is implemented as a vSEPP, and the second boundary entity 110 is implemented as a hSEPP in this example. Compared to a conventional SEPP, each SEPP may be enhanced with a SEPP service profile, which is similar or includes the profile 105 described above. The SEPP service profile could, in particular, include the profile 105 to support a registry and discovery of supported services in both intra-domain SBI 302 and inter-domain SBI 303, as described with respect to the steps shown in FIG. 5. By enabling the first boundary entity 100 and the second boundary entity 110 as such enhanced SEPPs, a flexible and dynamic deployment may be supported.

Using the network registration entities 104 and 114, for example, the NRF 104 in the first network domain 101 and the NRF 114 in the second network domain 114 (as shown in FIG. 7), network entities, such as, for example, various NFs, including PCF AMF, SMF, AF, etc., can select a local SEPP in their respective network domain 101, 111 and may also select the pairing SEPP in the other network domain 111, 101. For instance, the selection can be based on a load situation of the SEPPs of one or both network domains 101, 111, and/or requirements of the service traffic 120. Via the SEPPs, network entities in one network domain 101 may be able to receive/send service traffic 120 from/to a network entity in the other network domain, for example, according to the steps described with respect to FIG. 6. FIG. 8 shows that, in another exemplary implementation, the first boundary entity 100 and the second boundary entity 110 (vSEPP and hSEPP, respectively) can each be associated with or attached to a NEF. The NEF of the respective SEPP could, for example, perform at least one of the service traffic aggregation, coordination, address translation, and service discovery for selected service traffic 120, before forwarding the service traffic 120 via the N32 interface to the other SEPP. Each SEPP may still be used as it is defined now in 3GPP, in particular, for security checks and message filtering or pricing.

FIG. 9 and 10 show that, in another exemplary implementation, the first boundary entity 100 and the second boundary entity 110 may be used for aggregation and coordination of monitoring data, respectively. In particular, in FIG. 9, the first boundary entity 100 in a first network domain 101 (here in a NPN) may interact with the second boundary entity 110 in a second network domain 111 (here in a PLMN). For example, the boundary entities may interact based on the procedure for boundary entity registration and discovery presented in FIG. 5.

Notably, the scenario of this exemplary implementation may be a PNI-NPN deployment scenario including a shared RAN and CP. In such a shared RAN and CP scenario, the NPN may have dedicated UPFs, which can be controlled by the PLMN Control Plane (CP) NFs.

Further, the first boundary entity 100 and the second boundary entity 110 may interact to perform a session management procedure. For example, a SMF of the PLMN, the SMF A shown in FIG. 9, which is a service consumer entity 116 in the second network domain 111 in this case, may collect monitoring data from one or more UPFs located in the NPN network, for instance the UPF #1 and the UPF#2 shown in FIG. 9, which are service provider entities 102 in the first network domain 101 in this case. The first boundary entity 100 and the second boundary entity 110 may thereby perform service aggregation and coordination based on the service requests 107 from the SMF A for the monitoring data of the UPFs #1 and #2. By providing service aggregation and coordination of the monitoring data, the overall data transfer between the two boundary entities 100 and 110 can be minimized effectively.

FIG. 10 shows steps that may be performed for such a procedure: Step 1.1 : The SMF A sends a service request 107 to the second boundary entity 110 for the monitoring data from the UPF #1 in the NPN.

Step 1.2: The SMF A sends a service request 107 to the second boundary entity 110 for the monitoring data from the UPF #2 in the NPN.

Step 2: Based on the service requests 107 from steps 1.1 and 1.2, the second boundary entity 110 may add the requests into its information 900 (e.g., into a consumer list) with corresponding external service provider entity information. Since both service requests 107 are for UPFs in the same network domain (the NPN), the second boundary entity 110 can determine to aggregate the two service requests 107 from the SMF A to the UPF #1 and the UPF #2 in the NPN network, respectively, and may form an aggregated service request 107a. Further, the second boundary entity 110 may check the corresponding first boundary entity 100 in the NPN of the UPF # 1 and #2.

Step 3: The second boundary entity 110 may send the aggregated service request 107a to the first boundary entity 100 in the NPN.

Step 4: Based on the received aggregated service request 107a, the first boundary entity 100 may add the received service requests 107 into its information 300 (e.g., a provider list), and may check if there is already a same request 107 to a service provider entity 102 using the information 300. If the same request 107 to the same service provider entity 102 does not exist, the first boundary entity 100 will send the service requests 107 to the UPF #1 and UPF #2. It may perform service discovery e.g., using NRF, service request aggregation and coordination when needed.

Step 5: The first boundary entity 100 sends the service requests 107b to UPF#1 and UPF#2 of NPN network.

Step 6: The first boundary entity 100 receives service responses 108 from UPF #1 and UPF #2 inside the NPN network, e.g., including the monitoring data.

Step 7: The first boundary entity 100 may perform aggregation and coordination of service responses 108 from the UPF #1 and UPF #2 to the SMF A, for example, by checking the mapping of provider entity lists and based on internal capabilities used for the traffic control, e.g., bandwidth, buffer size, number of concurrent connections, and service requirements, e.g., delay budget. Thereby, the first boundary entity 100 may generate an aggregated service response 108a.

• Step 8: The first boundary entity 100 sends the aggregated service response 108a to the second boundary entity 110 in the PLMN, for instance, based on internal capabilities used for the traffic control defined in step 7. For example, if the number of concurrent connections is already at the limit and there is no strict delay budget, the aggregated service response 108a may be expected with some delays.

• Step 9: Upon receiving the aggregated service response 108a from the first boundary entity 100, the second boundary entity 110 performs service dispatch, address translation for the service response 108 to the SMF A, e.g., based on the consumer entity list.

• Steps 10.1 and 10.2: The second boundary entity 110 sends the aggregated service response 108a or the individual service responses 108b from UPF #1 and UPF #2, including the individual monitoring data from the UPF#1 and the UPF#2, respectively, to the SMF A.

FIG. 11 and FIG. 12 show, in another exemplary implementation, aggregation and coordination functionalities supported by the first boundary entity 100 and the second boundary entity 110 (e.g., again implemented as enhanced SEPPs), this time for a subscription service. In this scenario, the second boundary entity 110 in the second network domain 111 (here in a PLMN) may interact with the first boundary entity 100 in the first network domain 101 (here a NPN #1), and may further interact with another boundary entity 200 in another network domain 201 (here aNPN#2). The boundary entities 100, 110, 200 may interact by performing the procedure for boundary entity registration and discovery presented in Fig. 5.

Notably, the scenario of this exemplary implementation is an S-NPN deployment scenario. In this scenario, the PLMN supports SNPN along with credentials owned by the PLMN, which is separated from the SNPN (i.e., NPN#1 andNPN#2). In this case, the PLMN owns 5GC including at least an AUSF and a UDM.

Further, the boundary entities 100, 110, 200 may interact to perform an admission control procedure (e.g., a registration procedure), where an AMF A of the NPN#1 (which is a service consumer entity 106 in the first network domain 101 in this case) and an AMF C of the NPN#2 (which is a service consumer entity 206 in the other network domain 201 in this case) need a subscription service from UDM#1 of the PLMN (which is a service provider entity 112 in the second network domain 111 in this case). The first boundary entity 100 in the NPN# 1 and the other boundary entity 200 in the NPN#2 may send requests 107 for a subscription service (received from the AMFs A and C) to the second boundary entity 110 in the PLMN. By providing service aggregation and coordination functionalities, the second boundary entity 110 may minimize unnecessary signaling inside the PLMN network effectively. It may be assumed that the subscription requests 107 from the boundary entities 100, 200 of multiple NPNs may be received by the second boundary entity 110. Hence, the aggregation and coordination for subscription service would be required.

FIG. 12 shows steps that may be performed for such a procedure:

• Step la: The AMF A 106 sends a service request 107 to the first boundary entity A 100 of NPN #1 for the subscription service from the UDM #1 of the PLMN.

• Step lb: The AMF C 206 sends a service request 107 to the first boundary entity C 200 of the NPN #2 for the subscription service from UDM #1 of the PLMN.

• Steps 2a - 2b: Upon receiving the subscription requests 107 to the UDM#1 of the PLMN, the first boundary entity A 100 may add the requests 107 into its information 300 (e.g., into a consumer list) with corresponding external service provider entity information in a step 2a. The first boundary entity C 200 may add the requests 107 into its information 600 (e.g., into a consumer list) with corresponding external service provider entity information in a step 2b.

• Step 3: The boundary entity A 100 of NPN# 1 sends the service request 107 to the second boundary entity B 110 in the PLMN network. The first boundary entity C 200 of NPN#2 sends the service request 107 to the second boundary entity B 110 in the PLMN network.

Step 4: Upon receiving the subscription service requests 107, the second boundary entity B 110 creates and adds the received requests 107 into its information 900 (e.g., into a provider entity list).

Step 5: If the same request 107 is received to the same service provider entity, based on an internal capability used for the traffic control, e.g., bandwidth, buffer size, the second boundary entity B 110 coordinates the two requests 107 to the UDM #1. It can thereby create an aggregated service request 107a. It may also perform service discovery, when needed.

Step 6: The aggregated service request 107a is sent from the second boundary entity B 110 to the UDM # 1 inside the PLMN network.

Step 7: The service response 108 to the aggregated service request 107a is sent from UDM #1 to the second boundary entity B 110 inside the PLMN network.

Step 8: Based on the received service response 108, the second boundary entity B 110 performs service dispatch, address translation for the service response 108 to the first boundary entity A 100 and the first boundary entity C 200 of NPN# 1 and NPN#2, accordingly.

Step 9: The second boundary entity B 110 sends the service response 108a to the first boundary entity A 100 and the first boundary entity C 200 of NPN# 1 and NPN#2, respectively.

Step 10: The first boundary entity A 100 of NPN# 1 and the first boundary entity C 200 of the NPN#2 send the service response 108a to the AMF A and AMF C, respectively. FIG. 13 shows a method 1300 according to an embodiment of the invention. The method 1300 may be performed by any first boundary entity 100 according to an embodiment of the invention. The first boundary entity 100 is arranged at a boundary of a first network domain 101 and can communicate service traffic 120 with one or more second boundary entities 110 arranged at a boundary of one or more second network domains 111.

The method comprising a step 1301 of providing registration information 120 to a network registration entity 104 of the first network domain 101, the registration information 120 including a profile 105 of the first boundary entity 100. Thereby, as shown in box 1301a, the profile 105 of the first boundary entity 100 comprises a list of one or more services provided by one or more service provider entities 112 in the one or more second network domains 111 and supported by the first boundary entity 100.

FIG. 14 shows a method 1400 according to an embodiment of the invention. The method 1400 may be performed by any network registration entity 104 of a first network domain 101 according to an embodiment of the invention.

The method 1400 comprises a step 1401 of receiving a profile 105 from one or more first boundary entities 100, wherein each first boundary entity 100 is arranged at a boundary of the first network domain 101. Further, the method 1400 comprises a step 1402 of storing the profile 105 of the one or more first boundary entities 100, wherein each profile 105 comprises a list of one or more services provided by one or more service provider entities 112 in one or more second network domains 111 and supported by the one or more first boundary entities 100. Further, the method 1400 comprises a step 1403 of providing at least one of an address 105a and the profile 105 of one or more determined first boundary entities 100 to a network entity 106 in the first network domain 101.

FIG. 15 shows a method 1500 according to an embodiment of the invention. The method 1500 may be performed by any network entity 106 of a first network domain 101 according to an embodiment of the invention, in particular by a service consumer entity 106.

The method 1500 comprises a step 1501 of receiving at least one of an address 105a and a profile 105 of one or more first boundary entities 100 from a network registration entity 104 in the first network domain 101, wherein the profile 105 of the one or more first boundary entities 100 comprises a list of one or more services provided by one or more service provider entities in one or more second network domains 111 and supported by the one or more first boundary entities 100. Further, the method 1500 comprises a step 1502 of selecting at least one first boundary entity 100 from the one or more first boundary entities 100, based on a desired service and the at least one of the address 105a and the profile 105 of the one or more first boundary entities 100. Further, the method 1500 comprises a step 1503 of sending a request for the desired service to the selected at least one first boundary entity 100.

In summary, the proposed embodiments of the present disclosure may exhibit the following advantages:

• A first boundary entity 100 may adopt SBI for intra-domain communication and inter-domain communication. This enables flexible boundary entity deployment, for instance, by re-using NRF services. Load can be balanced between multiple first boundary entities 100 and second boundary entities 110 using the profile 105 of the first boundary entity 100. Still, changes for the service provider/service consumer cross-networks can be minimized.

• The first boundary entity 100 can integrate service traffic routing with service address discovery, which may reduce intra-domain signaling (i.e., the steps of service discovery inquiry and response in the same network, see steps 1, 3 in FIG. 18) Meanwhile, a service consumer entity 106 does not need to know the exact service address of the service provider entity 112, so that the internal architecture can be hidden from both network domains 101, 111.

• The first boundary entity 100 can perform cross-domain service aggregation, coordination, and it can reuse the discovered service address by other consumer entities. This may further reduce the cross-domain signaling, as well as the peak cross-domain signaling

The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed embodiments of the invention, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

1. A first boundary entity (100) for arrangement at a boundary of a first network domain (101) and for communicating service traffic (120) with one or more second boundary entities (110) arranged at a boundary of one or more second network domains (111), the first boundary entity (100) being configured to: provide registration information (103) to a network registration entity (104) of the first network domain (101), the registration information (103) including a profile (105) of the first boundary entity (100), wherein the profile (105) of the first boundary entity (100) comprises a list of one or more services provided by one or more service provider entities (112) in the one or more second network domains (111) and supported by the first boundary entity (100).

2. The first boundary entity (100) according to claim 1, wherein the profile (105) of the first boundary entity (100) further comprises at least one of: one or more service traffic types of the one or more services provided by the one or more service provider entities (112) in the one or more second network domains (111), wherein each service traffic type comprises at least one of a service name, a service provider entity identifier, and a second network domain identifier; a service area; load information indicating an allowed throughput of service traffic between the first boundary entity (100) and each of the one or more second boundary entities (110); support information indicating a supported number of concurrent service traffic connections between the first boundary entity (100) and each of the one or more second boundary entities (110); and processing information indicating one or more service traffic processing capabilities of the first boundary entity (100).

3. The first boundary entity (100) according to claim 1 or 2, further configured to: receive a first request (107) for a first service from a service consumer entity

(106) in the first network domain (101); provide a second request (107) for the first service to a second boundary entity (110) supporting the first service; receive a first service response (108) of the first service from the second boundary entity (110) supporting the first service; and provide a second service response (108) of the first service to the service consumer entity (106).

4. The first boundary entity (100) according to any one of the claims 1 to 3, further configured to: receive a first request (107) for a second service from a second boundary entity (HO); provide a second request (107) for the second service to a service provider entity (112) in the first network domain (101) providing the second service; receive a first service response (108) of the second service from the service provider entity (112) providing the second service; and provide a second service response (108) of the second service to the second boundary entity (100).

5. The first boundary (100) entity according to any one of the claims 1 to 4, further configured to maintain a Quality of Service, QoS, profile for each supported service traffic type, wherein the QoS profile comprises at least one of: a priority of the service traffic (120); and a latency requirement of the service traffic (120).

6. The first boundary entity (100) according to any one of the claims 1 to 5, further configured to maintain information (300) comprising one or more service consumer entities (106) in the first network domain (101) and/or in the one or more second network domains (111), and/or comprising one or more service provider entities (112) in the first network domain (101) and/or in the one or more second network domains (111), wherein each service consumer entity (106) and each service provider entity (112) is associated with one or more services.

7. The first boundary entity (100) according to claim 6, wherein the information (300) further comprises a correlation between a service consumer entity (106) in one of the first network domain (101) and the one or more second network domains (111) associated with a certain service, and a service provider entity (112) in the other one of the first network domain (101) and the one or more second network domains (111) associated with the certain service.

8. The first boundary entity (100) according to claim 3 and/or 4 and according to claim 6 or 7, further configured to add at least one of the service consumer entity (106) providing the request for the first service and the service provider entity (112) providing the second service to the maintained information (300), if at least one of the service consumer entity (106) and the service provider entity (112) is not already included.

9. The first boundary entity (100) according to any one of the claims 1 to 8, further configured to convert one or more service parameters of the service traffic (120) communicated with the one or more second boundary entities (110) from service parameters valid in one of the first network domain (101) and the one or more second network domains (111) to service parameters valid in the other one of the first network domain (101) and the one or more second network domains (111).

10. The first boundary entity (100) according to any one of the claims 1 to 9, further configured to process the service traffic (120) communicated with the one or more second boundary entities (110).

11. The first boundary entity (100) according to claim 10, wherein processing the service traffic (120) comprises at least one of aggregating the service traffic (120) of one or more services, traffic shaping of the service traffic (120) of one or more services, policing or scheduling the service traffic (120) of one or more services, and analysing the service traffic (120) based on a Quality of Service, QoS, profile of the service traffic type.

12. The first boundary entity (100) according to any one of the claims 1 to 11, wherein the first boundary entity (100) comprises at least one of a security edge protection proxy and a network exposure function.

13. The first boundary entity (100) according to any one of the claims 1 to 12, wherein the first network domain (101) is a domain of a non-public network and the one or more second network domains (111) include a domain of a public network.

14. A network registration entity (104) for a first network domain, the network registration entity (104) being configured to: receive a profile (105) from one or more first boundary entities (100), wherein each first boundary entity (100) is arranged at a boundary (101) of the first network domain (101); store the profile (105) of the one or more first boundary entities (100), wherein the profile (105) comprises a list of one or more services provided by one or more service provider entities (112) in one or more second network domains (111) and supported by the one or more first boundary entities (100); and provide at least one of an address (105a) and the profile (105) of one or more determined first boundary entities (100) to a network entity (106) in the first network domain (101).

15. The network registration entity (104) according to claim 14, further configured to: receive a discovery request from the network entity (106) in the first network domain (101), the discovery request comprising a desired service; and determine the one or more determined first boundary entities (100) based on the desired service and the stored profile (105).

16. The network registration entity (104) according to claim 14 or 15, further configured to determine the one or more determined first boundary entities (100) based on at least one of Quality of Service, QoS, requirements of the desired service and a service traffic type of the desired service.

17. The network registration entity (104) according to any one of the claims 14 to 16, wherein the profile (105) of the first boundary entity (100) further comprises at least one of: one or more service traffic types of the one or more services provided by the one or more service provider entities (112) in the one or more second network domains (111), wherein each service traffic type comprises at least one of a service name, a service provider entity identifier, and a second network domain identifier; a service area; load information indicating an allowed throughput of service traffic between the first boundary entity (100) and each of the one or more second boundary entities (110); support information indicating a supported number of concurrent service traffic connections between the first boundary entity (100) and each of the one or more second boundary entities (110); processing information indicating one or more service traffic processing capabilities of the first boundary entity (110), and wherein the network registration entity (104) is further configured to determine the one or more determined first boundary entities (100) based on at least one of the one or more service traffic types, the service area, the load information, the support information, and the processing information included in the profile (105) of the one or more first boundary entities (100).

18. A network entity (106) for a first network domain, the network entity (106) being configured to: receive at least one of an address (105a) and a profile (105) of one or more first boundary entities (100) from a network registration entity (104) of the first network domain (101), wherein the profile (105) of the one or more first boundary entities (100) comprises a list of one or more services provided by one or more service provider entities (112) in one or more second network domains (111) and supported by the one or more first boundary entities (100); select at least one first boundary entity (100) from the one or more first boundary entities (100), based on a desired service and the at least one of the address (105a) and the profile (105) of the one or more first boundary entities (100); and send a request (107) for the desired service to the selected at least one first boundary entity (100).

19. The network entity (106) according to claim 18, further configured to: send a discovery request to the network registration entity (104), the discovery request comprising the desired service; and receive the at least one of the address (105a) and the profile (105) of the one or more first boundary entities (110) supporting the desired service in response to the discovery request.

20. The network entity (106) according to claim 18 or 19, wherein the discovery request includes at least one of a service traffic type of the desired service and Quality of Service, QoS, requirements for the desired service.

21. The network entity (106) according to any one of the claims 18 to 20, further configured to select the at least one first boundary entity (100) from the one or more first boundary entities (100) based on at least one of the QoS requirements for the desired service and a service traffic type of the desired service.

22. The network entity (106) according to any one of the claims 18 to 21, wherein the profile (105) of each first boundary entity (100) further comprises at least one of: one or more service traffic types of the one or more services provided by the one or more service provider entities (112) in the one or more second network domains (111), wherein each service traffic type comprises at least one of a service name, a service provider entity identifier, and a second network domain identifier; a service area; load information indicating an allowed throughput of service traffic between the first boundary entity (100) and each of the one or more second boundary entities (110); support information indicating a supported number of concurrent service traffic connections between the first boundary entity (100) and each of the one or more second boundary entities (110); processing information indicating one or more service traffic processing capabilities of the first boundary entity (100), and wherein the network entity (106) is further configured to select the at least one first boundary entity (100) from the one or more first boundary entities (100) based on at least one of the one or more service traffic types, the service area, the load information, the support information, and the processing information included in the profile (105) of the one or more first boundary entities (100).

23. A method (1300) performed by a first boundary entity (100) arranged at a boundary of a first network domain (101) and communicating service traffic (120) with one or more second boundary entities (110) arranged at a boundary of one or more second network domains (111), the method (1300) comprising: providing (1301) registration information (103) to a network registration entity (104) of the first network domain (101), the registration information (103) including a profile (105) of the first boundary entity (110), wherein the profile (105) of the first boundary entity (110) comprises a list of one or more services provided by one or more service provider entities (112) in the one or more second network domains (111) and supported by the first boundary entity (100).

24. A method (1400) performed by a network registration entity (104) of a first network domain (101), the method (1400) comprising: receiving (1401) a profile (105) from one or more first boundary entities (100), wherein each first boundary entity (100) is arranged at a boundary of the first network domain (101); storing (1402) the profile (105) of the one or more first boundary entities (100), wherein the profile (105) comprises a list of one or more services provided by one or more service provider entities (112) in one or more second network domains (111) and supported by the one or more first boundary entities (100); and providing (1403) at least one of an address (105a) and the profile (105) of one or more determined first boundary entities (100) to a network entity (106) in the first network domain (101).

25. A method (1500) performed by a network entity (106) of a first network domain (101), the method (1500) comprising: receiving (1501) at least one of an address (105a) and a profile (105) of one or more first boundary entities (100) from a network registration entity (104) in the first network domain (101), wherein the profile (105) of the one or more first boundary entities (110) comprises a list of one or more services provided by one or more service provider entities (112) in one or more second network domains (111) and supported by the one or more first boundary entities (110); selecting (1502) at least one first boundary entity (100) from the one or more first boundary entities (100), based on a desired service and the at least one of the address (105a) and the profile (105) of the one or more first boundary entities (100); and sending (1503) a request (107) for the desired service to the selected at least one first boundary entity (100).

26. A computer program comprising program code for performing the method (1300, 1400, 1500) according to any one of the claims 23 to 25, when executed on a processor.