WO2020108772A1

WO2020108772A1 - Cross-region network slicing peering for 5g networks

Info

Publication number: WO2020108772A1
Application number: PCT/EP2018/083151
Authority: WO
Inventors: Chenghui Peng; Xun XIAO; Xueli AN; Jianjun Wu
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2018-11-30
Filing date: 2018-11-30
Publication date: 2020-06-04
Also published as: CN113170530A

Abstract

The invention relates to a network entity for a first core network (111), wherein the network entity is configured to operate a local network slice (NSI-1) in the first core network to communicate with a remote network slice (NSI-2) in a second core network (161).

Description

DESCRIPTION

CROSS-REGION NETWORK SLICING PEERING FOR 5G NETWORKS

TECHNICAL FIELD

Generally, the present invention relates to the field of telecommunications. More specifically, the present invention relates to devices, systems and methods for cross region end-to-end network slicing peering in communication networks, in particular 5G core networks.

BACKGROUND

The next generation of mobile networks, i.e. 5G networks, is expected to support many new types of services and connections between various devices such as cars, wearables, sensors and actuators from both private and industrial environments. The new types of services and connections usually imply very distinct service requests on latency, data rate and so on, which naturally ask for different treatments and thereby pose challenges to the control of 5G networks.

In particular, supporting various new types of services has a deep impact on the core network architecture. In today’s mobile networks, services mainly refer to the access of portable devices in human hands for data and voice services only. Core networks can apply basically the same treatment to portable devices following the best-effort principle. Hence, those services are predictable and how to respond them can be well preplanned. With various new service requests, however, service patterns will become quite heterogeneous. Consequently, service requests to a 5G network are difficult to predict. A proper way to meet the requirements is to agilely respond to any incoming services in a dynamic way.

Efficiently responding to distinct and unpredictable service requests is not an easy task. Administratively pre-planning approaches with static network deployment do not work. Recently, Software-Defined Networking (SDN) and Network Function Virtualization (NFV) have been proposed as the two key enablers to realize a flexible and programmable network infrastructure. The idea behind SDN is to abstract everything as a flow and to move the complexity of flow treatment to a logically centralized element called SDN Controller (SDNC). Hence, the SDN view reduces all network elements to "dumb" flow treatment devices, which are only responsible for flow processing. With these concepts, SDN fuses all management and control plane (CP) intelligence at the SDNC. In return, the common abstraction and the locally available data simplify the development of network control and management applications. NFV further turns existing network functions, which were mainly implemented by dedicated and specialized hardware before, into virtualized function modules that can be easily deployed or removed as needed.

With this two enabling technologies, responding to new service requests becomes much easier than before given that any network functions (NFs) can be deployed/allocated on- demand (NFV’s features) and forwarding behaviors of them can be remotely programmed (SDN’s features), just like installing and running a computer program.

In the upcoming 5G era, services provided via mobile networks will not be limited to human communications and basic internet connections. Rather, it is expected that there will be an increasingly large number of services of vertical industries that will be provided through the wireless mobile network. The legacy best-effort quality-of-service (QoS) is however incapable of supporting heterogeneous services. For example, an ultra-low latency connectivity is required by eHealth services if a medical robot has to be precisely operated in real time for remote surgery. Another example is that a virtual reality (VR) live broadcast will need high throughput bandwidth and meanwhile low latency interactions in order to provide immersive entertainment experiences. Hence, 5G networks will have to guarantee various service level agreements (SLAs) for different customers but share the same physical infrastructure.

An approach to meet these different requirements is, firstly, a virtualization of the physical infrastructure as clouds using the SDN and NFV technologies mentioned above, whereby the physical infrastructure is converted to be fully programmable. Secondly, resource isolations are emphasized in order to provide performance guarantees. These two proposals generate a new technical concept, called network slicing, where multiple network tenants will have their own network resources that are isolated from each other and SLA-guaranteed. Such a portion of isolated network resources for one tenant is a virtualized logical network accommodated in the shared infrastructure, called a network slice instance (NSI). According to the current 3GPP SA2 definitions, an NSI is an end-to- end (E2E) networking capability for providing services. The emphasis on E2E-featured capability in 5G networks attracts increasing interests of vertical industries. Different from the previous generations of mobile network systems (e.g. 3G and 4G), 5G networks will boost machinery-type connectivity (MTC) where

communications will happen between objects/devices, instead of between humans. In the future smart factory, for example, robots will not only need local communication in one factory, but also have to collaborate with robots in another factory at a different place when manufacturing. Another example is a connected-car scenario where cars on the roads will be controlled by a car company for auto-piloting or driving assistance, or communications may happen among cars. In this case, cars are pervasive and

everywhere, thereby with coverage in different regions. Obviously, a certain level of QoS has to be guaranteed in both cases.

In order to guarantee the SLAs (e.g. latency) of services, service providers of the vertical industry will utilize an E2E NSI across multiple regions. If such an NSI is deployed in a single domain, realizing such an E2E system is a problem of resource provisioning and isolation, like the local communication in one factory. In reality, if region-to-region SLA- guaranteed communication is required, creating such an NSI for an E2E system becomes complicated due to the geographically distributed nature of the network infrastructure. The key reasons are that the network infrastructure usually consists of multiple regions where each region is a sub-system that has its local gateway at a geographical area.

Furthermore, the address assignment is globally planned and region-based allocated at gateways where local addresses in one region are private and cross region

communications is NATed. Consequently, the infrastructure which is split into multiple domains naturally breaks the E2E system.

Due to the lack of network slicing, end-to-end traffics follow the infrastructure hierarchy. Specifically, any user entity (UE) node accessing the network will be assigned an identifier, e.g. an IP address, by an access control entity. For instance, such a network function in 3GPP is called access management function (AMF). After that, a bearer connection (i.e. a tunneling path) will be established from the UE to the gateway node of an administrative area and the identifier of the UE will be translated to a public identifier via a NAT, where a mapping rule is created and the source address in packet header will be modified to the public identifier of the gateway node if the UE sends packets to another region. Oppositely, if a packet from another region is sent to the gateway node, matching against the translation rules at the gateway node (e.g. ip_addr:port), the destination field of the packet header will be modified and further forwarded to the internal region, and the packet eventually arrives at the UE node.

Such a NATed way resolves address assignment issues for the network management and also fulfills service requirements of current mobile network systems, because

communications mostly happen between UEs and servers as well as UE-to-UE communication is rare and mostly relayed via central servers. Simply put, the client-server model fits the current service model since communications are between north and south. However, such a scheme hardly fits the coming 5G scenarios, especially the connected thing scenarios such as connected cars, remote operation, and so on. In these cases, a cross-region E2E network (slice) has to be created so that UEs at different regions can seamlessly communicate as if they are in the same local network. Clearly, there is a gap based on the current solution to realize a real E2E system, i.e. for cross-region E2E network slicing. It is still unclear how the 3GPP standardized specifications solve the cross-region E2E network slicing problem.

Given a virtualized environment settings, it is natural to think whether existing solutions from cloud computing can be used. Virtual private cloud (VPC) peering proposed for interconnecting two virtual data centers seems to be an appropriate choice. A cloud resource provider provision computing resource in the cloud datacenter based on the request of a tenant. The provisioned resource is logically dedicated for that particular tenant and it is guaranteed according to the submitted order from the tenant, which is similar to network slicing scenario. Such a portion of provisioned resource is called as a VPC. In cloud infrastructure, one tenant may have multiple VPC instances, where they may be deployed in the same datacenter or geographically across different datacenters.

In either case, the tenant may want its VPCs can form a whole private network that communicate with each other (e.g. private IP addressing). Therefore, the cloud infrastructure has to be able to establish such kind of interconnections, which is called VPC peering. However, as will be explained in more detail below, VPC peering cannot be trivially used as a solution for cross-region slice sharing.

First of all, a VPC excludes UEs as part of the VPC consideration. Although VPC peering can logically merge two VPCs across different regions, UEs are still outside of the merged VPC (consisting of two individual VPCs) and their address allocations still follow the policy in each cloud region. In principle, UEs will be treated as end users who will be assigned external identifiers. Secondly, VPC peering does not support overlapped addresses in the peered VPCs even if UEs can initially be included as part of a VPC. Overlapped addresses can be avoided when planning, but peering two NSIs may not be able to plan when requesting the two NSIs. In other words, it is possible that initially the two NSIs were planned individually (thus possibly having overlapped private addresses on individual NSIs), and due to later on requirement, we have to peer the two NSIs. In this case, completely re-allocating addresses will be difficult because this may suspend and will have to stop the running services.

Thirdly, between two VPCs, only one peering connection is supported. VPC peering is more like a routing table modification at the cloud datacenter layer. When a VPC is created, it is always connected to a gateway router that is either physical or virtual. If a VPC needs to access external, the gateway is configured to behave as a NAT, otherwise all traffics are internally routable. When VPC peering is needed, on the two gateway nodes, routing policies will be modified so that the traffic from either VPC can get through. If necessary, a direct path can be established as well. However, in current cloud platforms, only one such a connection can be established, and if multiple UEs from different regions want to be included in different E2E network slices, such a simple peering scheme does not help.

Moreover, cross-region communication usually involves external traffic transmission consumptions. This is also reflected in the pricing strategies given by the popular cloud providers. Take VPC pricing of a known company as example, internal traffics cost only 0.01 $/Gb if transmission happens over a VPN connection, but 0.52$/Gb if transmission happens via a NATed scheme. In other words, cross-region communication is more expensive. The captical aspect is also a critical factor that influences strategy selection of tenants when they deploy their services in the clouds. Obviously, when deploying cross region services, tenants prefer to rent provisioned lines so that traffics will not go over public networks as NATed traffics but intra-domain traffics. This can be limited by the following two factors. First of all, renting a provisioned connection is also not free, though it is economical. Take VPC pricing of a known company as example, a provided connection between US and EU countries costs 0.3$/h and 0.02$/Gb. Secondly, whether a tenant can rent such a provisioned line depends on the availability of the infrastructure from a specific cloud provider. For example, a cloud infrastructure may be only provided in several major countries and cities. If the cloud provider does not offer such a capability between regions, one has to figure out how to build the provisioned connections by himself. One possible solution is to ask for help from telecom operators whose network coverage is at least larger than current cloud providers. Unfortunately, existing mobile network systems are not ready to provide such an E2E system yet.

Thus, there is still a need for devices, systems and methods for providing cross-region end-to-end network slicing peering in communication networks, in particular 5G core networks.

SUMMARY

Embodiments of the invention are defined by the features of the independent claims, and further advantageous implementations of the embodiments by the features of the dependent claims.

Generally, embodiments of the invention are based on a set of extended operations executed on relevant components that manage and implement the cross-region network slicing peering for user equipments (UEs). Embodiments of the invention provide several functional extensions and corresponding new interfaces to adapt a network system so as to establish a cross-region E2E network slice peering for user equipments (UEs).

According to embodiments of the invention, a network slice instance (NSI) is adapted to be aware of cross-region network slicing where accessing UEs will be given a direct intra slice path to a gateway node if cross-region E2E communication is required. This includes cross-region identifier management and assignment. Furthermore, the gateway node of a region is adapted to be able to establish direct paths to a gateway node of another region. Created direct paths including the intra-slice and cross-region region paths will be concatenated in order to form a full cross-region E2E path for direct UE connections.

Embodiments of the invention also provide a network slicing management entity adapted to instruct the managed components to finish the operations introduced above. Cross region E2E network slicing peering may involve multiple management entities. Among the management entities, cross-region SLA requirement will be aligned through a new interface between the involved regions. Meanwhile, performance monitoring loopback can also be provided in order to dynamically guarantee the SLA cross multiple regions. More specifically, according to a first aspect the invention relates to a network entity for a first core network, wherein the network entity is configured to operate a local network slice in the first core network to communicate with a remote network slice in a second core network.

The network entity can be a single or distributed physical entity and can comprise one or more network functions implemented on one or more physical devices.

Thus, an improved network entity is provided, allowing for cross-region end-to-end network slicing peering, i.e. providing a virtual global slice in communication networks, in particular 5G core networks.

In a further possible implementation form of the first aspect, the network entity is configured to obtain, within the local network slice, data from the remote network slice and/or to provide, within the local network slice, data to the remote network slice.

In a further possible implementation form of the first aspect, the network entity is configured to obtain, within the local network slice, data from a first user equipment, UE, attached to a RAN of the first core network and/or to obtain, within the local network slice, data from a second UE from the remote network slice.

In a further possible implementation form of the first aspect, the network entity is configured to provide a first local communication path between the first UE and a sub gateway of the local network slice.

The first sub-gateway can be a virtual switch.

In a further possible implementation form of the first aspect, the first UE is attached to a first access point of the local network slice, wherein for providing the first local communication path the network entity may be further configured to provide a port at the first access point and a first port at the sub-gateway of the local network slice.

In a further possible implementation form of the first aspect, for providing the first local communication path, the network entity is further configured to: provide a first tunneling path between the port of the first access point and the first port of the sub-gateway of the local network slice. In a further possible implementation form of the first aspect, for providing the first local communication path, the network entity is further configured to: provide forwarding rules at the first access point for forwarding data packets to and/or from the first UE.

In a further possible implementation form of the first aspect, the network entity is further configured to allocate a cross-slice identifier, i.e. a global identifier to the first UE.

In a further possible implementation form of the first aspect, the network entity is further configured to: configure the first access point on the basis of the cross-slice identifier of the first UE to encapsulate and forward data packets to the tunneling path between the port of the first access point and the first port of the sub-gateway of the local network slice.

In a further possible implementation form of the first aspect, the network entity is further configured to provide a cross-slice, i.e. global communication path between a main gateway of the first core network and a main gateway of the second core network.

In a further possible implementation form of the first aspect, the network entity is further configured to: provide a first port at the main gateway of the first core network.

In a further possible implementation form of the first aspect, the network entity is further configured to: provide a tunneling path between the first port of the main gateway of the first core network and a first port of the main gateway of the second core network.

In a further possible implementation form of the first aspect, the network entity is further configured to: encapsulate and provide data packets to the tunneling path between the first port of the main gateway of the first core network and the first port of the main gateway of the second core network.

In a further possible implementation form of the first aspect, for providing the tunneling path between the first port of the main gateway of the first core network and the first port of the main gateway of the second core network, the network entity is configured to take one or more service layer requirements between the first core network and the second core network into account. In a further possible implementation form of the first aspect, the network entity is further configured to provide a first bridging communication path between the sub-gateway of the local network slice and the main gateway of the first core network.

In a further possible implementation form of the first aspect, the first UE is attached to a first access point of the local network slice and for providing the first bridging

communication path the network entity is further configured to: provide a second port at the sub-gateway of the local network slice and a second port at the main gateway of the first core network.

In a further possible implementation form of the first aspect, for providing the first bridging communication path the network entity is further configured to: provide forwarding rules at the sub-gateway of the local network slice for forwarding data packets between the first port and the second port of the sub-gateway of the local network slice.

In a further possible implementation form of the first aspect, for providing the first bridging communication path the network entity is further configured to: provide forwarding rules at the main gateway of the first core network for forwarding data packets between the first port and the second port of the main gateway of the first core network.

In a further possible implementation form of the first aspect, the network entity is further configured to monitor the performance of the local network slice in particular on the basis of a feedback loop. The network entity can be further configured to adjust the local network slice, in case the performance of the local network slice does not meet one or more service layer requirements.

According to a second aspect the invention relates to a method which comprises the step of operating a local network slice in a first core network to communicate with a remote network slice in a second core network.

Thus, an improved method is provided, allowing for cross-region end-to-end network slicing peering in communication networks, in particular 5G core networks.

Details of one or more embodiments are set forth in the accompanying drawings and the description below. Other features, objects, and advantages will be apparent from the description, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

In the following embodiments of the invention are described in more detail with reference to the attached figures and drawings, in which:

Fig. 1 is a high-level block diagram of a network architecture illustrating cross-region sharing concepts implemented by embodiments of the invention;

Fig. 2 is a block diagram showing a network architecture for implementing cross-region sharing concepts according to embodiments of the invention;

Fig. 3 is a block diagram showing the network architecture of figure 2 further including interfaces and a tunneling path implementing regional sharing concepts according to embodiments of the invention;

Fig. 4 is a block diagram showing the network architecture of figure 2 further including interfaces and a tunneling path implementing cross-region sharing concepts within one operator according to embodiments of the invention;

Fig. 5 is a block diagram showing the network architecture of figure 2 further including interfaces and a tunneling path implementing cross-region sharing concepts within multiple operators according to embodiments of the invention; and

Fig. 6 is a block diagram showing the network architecture of figure 4 further including interfaces and bridging paths implementing regional and inter-slice sharing concepts according to embodiments of the invention.

In the following identical reference signs refer to identical or at least functionally equivalent features.

DETAILED DESCRIPTION OF THE EMBODIMENTS

In the following description, reference is made to the accompanying figures, which form part of the disclosure, and which show, by way of illustration, specific aspects of embodiments of the invention or specific aspects in which embodiments of the present invention may be used. It is understood that embodiments of the invention may be used in other aspects and comprise structural or logical changes not depicted in the figures. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present invention is defined by the appended claims.

For instance, it is understood that a disclosure in connection with a described method may also hold true for a corresponding device or system configured to perform the method and vice versa. For example, if one or a plurality of specific method steps are described, a corresponding device may include one or a plurality of units, e.g. functional units, to perform the described one or plurality of method steps (e.g. one unit performing the one or plurality of steps, or a plurality of units each performing one or more of the plurality of steps), even if such one or more units are not explicitly described or illustrated in the figures. On the other hand, for example, if a specific apparatus is described based on one or a plurality of units, e.g. functional units, a corresponding method may include one step to perform the functionality of the one or plurality of units (e.g. one step performing the functionality of the one or plurality of units, or a plurality of steps each performing the functionality of one or more of the plurality of units), even if such one or plurality of steps are not explicitly described or illustrated in the figures. Further, it is understood that the features of the various exemplary embodiments and/or aspects described herein may be combined with each other, unless specifically noted otherwise.

As will be described in more detail in the following, embodiments of the invention provide a series of functional extensions on the components of a single or distributed network entity to realize and manage network slice instances (NSIs) so that cross-region E2E network slice peering for user equipments (UEs) can be established.

Figure 1 shows a high-level block diagram of a network architecture illustrating cross region sharing concepts implemented by embodiments of the invention, wherein a first user equipment (UE 1 ) 101 at a first local core network (RE-1 ) 1 1 1 and a second user equipment (UE 2) 151 at a second local core network (RE-2) 161 would like to "directly" communicate with each other from two regions of these two core networks, wherein each UE respectively accesses the network through a local network slice (herein also referred to as a network slice instance, NSI), i.e. NSI-1 1 13 and NSI-2 163, created at each region, i.e. the UE 1 101 is attached to the first local network slice, NSI-1 , 1 13 and the UE 2 151 is attached to the second local network slice, NSI-2, 163. The two regions i.e. the first local core network RE-1 and the second local core network RE-2, belong to two separated operational domains, which might be owned by different operators, thus only gateway interconnectivity is available.

As will be described in more detail below, embodiments of the invention provide a network entity for the first core network RE-1 1 1 1 , wherein the network entity is configured to operate the local network slice NSI-1 1 13 in the first core network RE-1 1 1 1 to

communicate with the second network slice, i.e. the remote network slice NSI-2 163 in the second core network RE-2 161. According to embodiments of the invention, the same network entity can be provided in the second core network RE-2 161 as well, in which case the local network slice NSI-1 1 13 in the first core network RE-1 1 1 1 would be the remote network slice.

In an embodiment, components realizing NSIs in each region will be adapted to support the cross-region E2E network slicing peering requirements. Extensions here include: first, an access management entity can assign an identifier that is special for the cross-region communication. Secondly, a session management of the NSI can establish a direct path (like a bearer tunnel) from the UE to a gateway node of the NSI. It is worth noting that such a path still does not enable the cross region connectivity because traffic is still NATed by the gateway node of the NSI (i.e. Gw’ 1 15, 165 in figure 1 ). Thirdly, intra-slice SLA should be guaranteed at the moment by taking cross-region E2E SLA requirements into considerations.

In an embodiment, NSI-1 is one of a plurality of local network slices 1 13 of the first core network 1 1 1 and NSI-2 is one of a plurality of local network slices 163 of the second core network 161 , wherein each local network slice of the plurality of local network slices 1 13 of the first sub-network 1 1 1 comprises a sub-gateway 1 15 connected to a main gateway 121 of the first core network 1 1 1 and each local network slice of the plurality of local network slices 163 of the second core network 161 comprises a sub-gateway 165 connected to a main gateway 171 of the second core network 161 , as can be taken from figure 1 .

In a further embodiment, the gateway nodes can be extended to handle the cross-region E2E requirement where a direct path can be established and concatenated with the intra slice direct path created before (i.e. Gw nodes). Therefore, two paths linked together merge the different regions, which further reach the other region. As a result, with the paths established on both sides, a full path for cross-region E2E network slicing peering can be formed. In particular, creating the direct path between two gateway nodes of the two regions leads to a new interface (herein referred to as a cross-region gateway interface) that is used to exchange or align the E2E SLA requirements, which will be elaborated in more details in the following.

Furthermore, all the operations introduced above can rely on the commands of network slicing management logic. In addition, performance or state monitoring loopback can be provided in order to dynamically adjust configurations of the deployment of cross-region E2E network slicing peering. This can be implemented as a distributed or centralized system.

Since Software-Defined Networking (SDN) and Network Function Virtualization (NFV) technologies are the key enablers of a programmable network infrastructure,

embodiments of the invention can be based on a virtualized environment, wherein infrastructure resources (e.g. compute, storage and networking) are abstracted and can be dynamically provisioned, adjusted and/or re-allocated as needed.

According to an embodiment, networking programmability from the infrastructure, e.g. OpenvSwitch node capability, can facilitate to realize cross-region E2E communications. As shown in figure 2, the two NSIs, i.e. NSI-1 1 13 and NSI-2 163, are deployed in the network but in different regions or core networks, i.e. RE-1 and RE-2, where

communications across different regions certainly go over the transport networks 140. In each region or core network, since there could be multiple NSIs owned by different tenants, each NSI will have its own gateway node, Gw’, to access the local infrastructure. In addition, multiple NSIs can share a common gateway node when external

communication outside the local region is needed. In figure 2, Gw’ 1 15, 165 is used to denote a gateway node of a NSI 1 13, 163 and Gw 121 , 171 a gateway node of the core networks 1 1 1 , 161 , respectively.

It is worth noting that NSI-1 1 13 and NSI-2 163 can have the same private network address domain, because they are originally at different regions where an address assignment is completely autonomous. This shows the key difference to the VPC peering scenario where the peered VPCs should have not overlapped addresses, thus pre planning is needed. Nevertheless, VPC peering solution cannot be applied here because it causes address re-allocation for the deployed NSIs, which may introduce huge maintenance costs and suspend running services. UE nodes access an NSI through an access point (i.e. AP 103, 153 in figure 2) of a regional network. According to an embodiment, two UE nodes accessing their own NSIs from different regions would like to communicate with each other as in the same local network. Meanwhile, SLA-guaranteed requirements can be satisfied. Again, VPC peering solution does not handle how UE node should be peering.

In the following, details about how a cross-region E2E network slicing peering can be realized will be discussed under further reference to figures 3 to 6. The whole procedure includes the following steps: The first step is to configure the NSI in each regional network for the identifier allocation and to establish direct path from the UE node to the gateway node of the NSI. The second step is to retrieve the SLA requirement of the UE of the NSI and configure the gateway nodes between the two involved regions where a direct path will be established across the two regions, meanwhile SLA requirements of cross-region peering will be aligned. The third step is to concatenate the local direct path to the cross region path and performance monitoring loopback will be associated with the network slicing management layer.

In order to prepare the regional direct path from the UE node (e.g. UE-1 in figure 3) to a gateway node 1 15 of the local network slice NSI 1 13, a cross-region identifier for the UE node 101 is allocated by the network entity, in particular an access management entity (i.e. UE-1 :IPc). In 3GPP systems, this is defined as the main job of an access

management function (AMF). Such a function could be located in a certain place in the core network or be integrated with the access point (AP) 103. In the former case, the access point 103 forwards the joining request from the UE 101 to an address where AMF is bound. In the latter case, the identifier will be immediately assigned by the access point 103. Such a cross-region identifier can be a new identifier of the UE node 101 , which is different from the initial identifier the UE 101 gets when it joins in the NSI 1 13 as usual. In an embodiment, it is preferred to assign a dedicated identifier in order to differentiate with local traffic identification, though the UE belongs to the same NSI.

After the cross-region identifier assignment is done, the access point 103 is prepared to establish the path to the gateway node 1 15 of the local network slice NSI 1 13, which is shown in figure 3. This includes port creations, path provisioning and a set of forwarding rule configurations: the two ports, ap:p_a 103a and Gw’:p_a’ 1 15a, as the two endpoints of the regional path, are created on the access point 103 and the gateway node 1 15 of the local network slice NSI 1 13 respectively. More specifically, for providing the first local communication path and the second local communication path, a port 103a is provided at the first access point 103 and a first port 1 15a at the sub-gateway 1 15 of the local network slice NSI-1 1 13, and a port 153a is provided at the second access point 153 and a first port 165a at the sub-gateway 165 of NSI-2 163.

After that, a path belonging to the NSI will be provisioned between the two ports 103a,

1 15a as a tunnelling path according to the SLA requirements of the UE node 101. The two ports will be used to transmit the traffic between the UE node 101 and the gateway node 1 15 of the local network slice NSI-1 1 13 over the provisioned path. When the packets of the UE node 101 arrive at the access point 103, the created port encapsulates and forwards them through the tunnelling path to the port 1 15a on the gateway 1 15 of the local network slice NSI-1 1 13. In this way, the port 1 15a on the gateway node 1 15 of the local network slice NSI-1 1 13 can get the packets from UE 101 with the cross-region identifier.

On the other hand, packets arriving at the port 1 15a of the gateway node 1 15 will be encapsulated and sent over the path to the port 103a on the access point 103, then will be decapsulated and eventually sent to the UE node 101. All of the forwarding actions are instructed by the forwarding rules configured on the access point in order to handle packets coming and going.

More specifically, in an embodiment, a first tunneling path is provided between the port 103a of the first access point 103 and the first port 1 15a of the sub-gateway 1 15 of the local network slice NSI-1 1 13.Likeweise, a second tunneling path can be provided between the port 153a of the second access point 153 and the first port 165a of the sub gateway 165 of the remote network slice NSI-2 163. Furthermore, forwarding rules can be provided at the first access point 103 for forwarding data packets to and from UE1 101 , and forwarding rules can also be provided at the second access point 153 for forwarding data packets to and from UE2 151 .

In a further embodiment, a cross-slice, i.e. global identifier can be allocated to UE1 101 and to UE2 151 . Embodiments of the invention can configure the first access point 103 on the basis of the cross-slice identifier of UE1 101 to encapsulate and forward data packets to the tunneling path between the port 103a of the first access point 103 and the first port second access point 153 on the basis of the global identifier of UE2 151 to encapsulate and forward data packets to the tunneling path between the port 153a of the second access point 153 and the first port 165a of the sub-gateway 165 of the remote network slice NSI-2 163.

In a further embodiment, a direct path across regions can be built, wherein this path considers the cross-region E2E SLA requirements as well. The requirement may be aligned over a new interface where the interface is between the two gateway nodes of two different regions. There are two possible cases when establishing the path between the two regions. The first case is that the two regions belong to the same operator while the second case is that two regions belong to different operators.

For the first case, similar to the procedures creating the regional direct path, each gateway node of the regional network is prepared with a new port to handle the cross region traffics where packet en-/decapsulation will be done on the ports. Between the two ports newly created, the network operator may provision a tunneling path between them. Since it is a cross-region tunneling path that requires SLA guarantees, between the management entities responsible for their own administrative regions, the cross-region E2E network slicing SLA requirements can be exchanged when provisioning the path. Therefore, a new interface can be created between the two management entities in order to exchange the required information, as illustrated in figure 4.

More specifically, each local network slice of the plurality of local network slices 1 13 of the first core network 1 1 1 comprises a sub-gateway 1 15 connected to a main gateway 121 of the first core network 1 1 1 , and each local network slice of the plurality of local network slices 163 of the second core network 161 comprises a sub-gateway 165 connected to a main gateway 171 of the second core network 161 . For providing the global

communication path between the main gateway 121 of the first core network 1 1 1 and the main gateway 171 of the second core network 161 , a first port 121 a is provided at the main gateway 121 of the first core network 1 1 1 , and a first port 171 a is provided at the main gateway 171 of the second core network 161.

Furthermore, a tunneling path is provided between the first port 121 a of the main gateway 121 of the first core network 1 1 1 and the first port 171 a of the main gateway 171 of the second core network 161. Embodiments of the invention can encapsulate and forward data packets to the tunneling path between the first port 121 a of the main gateway 121 of the first core network 1 1 1 and the first port 171 a of the main gateway 171 of the second core network 161. Embodiments of the invention also allow to take one or more service layer requirements between the first core network 1 1 1 and the second core network 161 into account, for providing the tunneling path between the first port 121 a of the main gateway 121 of the first core network 1 1 1 and the first port 171 a of the main gateway 171 of the second core network 161.

For the second case, since it involves multiple operators, the transport network between the two gateway nodes of the two regions or the two core networks is governed by neither of the two operators completely. As a result, either of the two operators can cooperatively establish the path or it can involve either a third-party operator who owns the transport network. For the former case, over the interface between the management entities of the two different operators, a path establishment request can be exchanged, which triggers the port creation on the gateway node of individual sides. After that, cross-region E2E network slice SLA requirements can also be exchanged so that each management entity can provision the path in their own administrative domain. For the latter case, two operators will talk to the possible third-party operator. When the operator of the transport network receives requests as well as the E2E network slice SLA requirements, it can inform the two gateway nodes about how they should create the new port and connect to the cross-region tunnelling path the transport network operator is provisioning. This is illustrated in figure 5.

As discussed above, two types of direct paths can be created by the previous steps. The first type is the regional direct path between the UE and the gateway node of the NS I; the second type is the cross-region direct path between the gateway nodes of two different regions, which could be of administrative domains of different operators.

The whole E2E path is however not completed because the gap between the gateway node of an NSI and the gateway node of the regional network infrastructure is not bridged yet (i.e. Gw’ to Gw in figures 4 to 6). In addition, the performance monitoring loopback is not introduced.

In an embodiment, the gap between the gateway node of an NSI and the gateway node of the regional network infrastructure can be bridged: cross-region traffics sent from the UE will arrive at the gateway node of the NSI, and need to be forwarded to the gateway node of the regional network. In order to guarantee the E2E performance across NSIs, the path between the gateway nodes has also to be aware of the SLA requirements. Therefore, there is an interface between the two gateway nodes, which is similar to the case of cross region gateway nodes, to exchange necessary parameter data.

Under reference to figure 6, the concrete procedures include new port creations and forwarding rule configurations on both gateway nodes, i.e. between the gateway node of an NSI and the gateway node of the regional network infrastructure. For the gateway node of the NSI, a new port will be created as the interface/endpoint of the path to the gateway node of the regional network. Accordingly, another new port will also be created as the interface/endpoint of the path to the gateway node of the NSI. On the gateway node of the NSI, forwarding rules will be added in order to concatenate the direct path connecting the UE node and the gateway node of the NSI as well as the direct path between the gateway node of the NSI and the gateway node of the regional network.

More specifically, for providing a first bridging communication path between the sub gateway 1 15 of the local network slice NSI-1 1 13 and the main gateway 121 of the first core network 1 1 1 and/or a second bridging communication path between the sub-gateway 165 of the remote network slice NSI-2 163 and the main gateway 171 of the second core network 161 , embodiments of the invention can provide: a second port 1 15b at the sub gateway 1 15 of the local network slice NSI-1 1 13 and a second port 121 b at the main gateway 121 of the first core network 1 1 1 ; and/or a second port 165b at the sub-gateway 165 of the remote network slice NSI-2 163 and a second port 171 b at the main gateway 171 of the second core network 161 .

Furthermore, for providing the first bridging communication path and/or the second bridging communication path, forwarding rules can be provided at the sub-gateway 1 15 of the local network slice NSI-1 1 13 for forwarding data packets between the first port 1 15a and the second port 1 15b of the sub-gateway 1 15 of the local network slice NSI-1 1 13; and/or forwarding rules can also be provided at the sub-gateway 165 of the remote network slice NSI-2 163 for forwarding data packets between the first port 165a and the second port 165b of the sub-gateway 165 of the remote network slice NSI-2 163.

Similarly, forwarding rules can be provided at the main gateway 121 of the first core network 1 1 1 for forwarding data packets between the first port 121 a and the second port 121 b of the main gateway 121 of the first core network 1 1 1 , and/or forwarding rules can also be provided at the main gateway 171 of the second core network 161 for forwarding data packets between the first port 171 a and the second port 171 b of the main gateway 171 of the second core network 161.

In an embodiment, if a packet is received from the interface of the direct path inside the NSI, the forwarding rule can guide the packet to the interface of the direct path through to the new port created on the gateway node of the regional network. On the other hand, if a packet is received at the port created on the gateway node of the NSI, the forwarding rule can guide the packet to the interface of the direct path inside the NSI through to the UE node.

On the gateway node of the regional network, forwarding rules can also be added in order to concatenate the direct path between the two local gateway nodes and the direct path between the cross-region gateway nodes. Specifically, if a packet is received from the port created (notation), the forwarding rule can guide the packet to the direct path through to the other gateway node across regions. On the other hand, if a packet is received from the interface of the direct path across regions, the forwarding rule can guide the packet to the interface/port of the path through to the gateway node of the NSI.

The cross-region E2E network slicing for UE nodes may not be static, as the E2E SLA can matter. As a result, the performance of every direct path can be monitored and a real time status can be provided to the management layer. The management layer can adjust the configurations including path provisioning if necessary.

After all forwarding rules are configured, the whole path is E2E completed, providing cross-region E2E network slicing peering in communication networks, in particular 5G core networks. The path is also provisioned according to the exchanged information by the local management entity.

The person skilled in the art will understand that the "blocks" ("units") of the various figures (method and apparatus) represent or describe functionalities of embodiments of the invention (rather than necessarily individual "units" in hardware or software) and thus describe equally functions or features of apparatus embodiments as well as method embodiments (unit = step).

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus, and method may be implemented in other manners. For example, the described apparatus embodiment is merely exemplary. For example, the unit division is merely logical function division and may be other division in actual implementation. For example, a plurality of units or components may be combined or integrated into another system, or some features may be ignored or not performed. In addition, the displayed or discussed mutual couplings or direct couplings or

communication connections may be implemented by using some interfaces. The indirect couplings or communication connections between the apparatuses or units may be implemented in electronic, mechanical, or other forms. The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one position, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the objectives of the solutions of the embodiments. In addition, functional units in the embodiments of the present invention may be integrated into one processing unit, or each of the units may exist alone physically, or two or more units are integrated into one unit.

Claims

1. A network entity for a first core network (1 1 1 ), wherein the network entity is configured to:

- operate a local network slice (1 13) in the first core network (1 1 1 ) to communicate with a remote network slice (163) in a second core network (161 ).

2. Network entity according to the previous claim configured to:

- obtain, within the local network slice (1 13), data from the remote network slice (163); and/or

- provide, within the local network slice (1 13), data to the remote network slice (163).

3. Network entity according to one of the previous claims configured to:

- obtain, within the local network slice (1 13), data from a first UE (101 ) attached to a RAN of the first core network (1 1 1 ); and/or

- obtain, within the local network slice (1 13), data from a second UE (151 ) from the remote network slice (163).

4. Network entity according to the previous claim, wherein the network entity is configured to provide a first local communication path between the first UE (101 ) and a sub-gateway (1 15) of the local network slice (1 13).

5. Network entity of claim 4, wherein the first UE (101 ) is attached to a first access point (103) of the local network slice (1 13) and in particular wherein for providing the first local communication path the network entity is further configured to: provide a port (103a) at the first access point (103) and a first port (1 15a) at the sub gateway (1 15) of the local network slice (1 13).

6. Network entity of claim 5, wherein for providing the first local communication path the network entity is further configured to: provide a first tunneling path between the port (103a) of the first access point (103) and the first port (1 15a) of the sub-gateway (1 15) of the local network slice (1 13).

7. Network entity of claims 5 or 6, wherein for providing the first local communication path the network entity is further configured to: provide forwarding rules at the first access point (103) for forwarding data packets to and/or from the first UE (101 ).

8. Network entity of claim 7, wherein the network entity is further configured to allocate a cross-slice identifier to the first UE (101 ).

9. Network entity of claim 8, wherein the network entity is further configured to: configure the first access point (103) on the basis of the cross-slice identifier of the first UE (101 ) to encapsulate and forward data packets to the tunneling path between the port (103a) of the first access point (103) and the first port (1 15a) of the sub-gateway (1 15) of the local network slice (1 13).

10. Network entity of any one of the preceding claims, wherein the network entity is further configured to provide a cross-slice communication path between a main gateway (121 ) of the first core network (1 1 1 ) and a main gateway (171 ) of the second core network (161 ).

1 1. Network entity of claim 10, wherein the network entity is further configured to: provide a first port (121 a) at the main gateway (121 ) of the first core network (1 1 1 ).

12. Network entity of claim 1 1 , further configured to: provide a tunneling path between the first port (121 a) of the main gateway (121 ) of the first core network (1 1 1 ) and a first port (171 a) of the main gateway (171 ) of the second core network (161 ).

13. Network entity of claim 12, wherein the network entity is further configured to: encapsulate and provide data packets to the tunneling path between the first port (121 a) of the main gateway (121 ) of the first core network (1 1 1 ) and the first port (171 a) of the main gateway (171 ) of the second core network (161 ).

14. Network entity of claim 12 or 13, configured to take one or more service layer requirements between the first core network (1 1 1 ) and the second core network (161 ) into account.

15. Network entity of any one of the preceding claims, wherein the local network slice (1 13) comprises a sub-gateway (1 15) connected to a main gateway (121 ) of the first core network (1 1 1 ), wherein the network entity is further configured to provide a first bridging communication path between the sub-gateway (1 15) of the local network slice (1 13) and the main gateway (121 ) of the first core network (1 1 1 ).

16. Network entity of claim 15, wherein the first UE (101 ) is attached to a first access point (103) of the local network slice (1 13) and the network entity is further configured to: provide a second port (1 15b) at the sub-gateway (1 15) of the local network slice (1 13) and a second port (121 b) at the main gateway (121 ) of the first core network (1 1 1 ).

17. Network entity of claim 16, wherein for providing the first bridging communication path the network entity is further configured to: provide forwarding rules at the sub-gateway (1 15) of the local network slice (1 13) for forwarding data packets between the first port (1 15a) and the second port (1 15b) of the sub-gateway (1 15) of the local network slice (1 13).

18. Network entity of claim 16 or 17, wherein for providing the first bridging

communication path the network entity is further configured to: provide forwarding rules at the main gateway (121 ) of the first core network (1 1 1 ) for forwarding data packets between the first port (121 a) and the second port (121 b) of the main gateway (121 ) of the first core network (1 1 1 ).

19. Network entity of any one of the preceding claims, wherein the network entity is further configured to monitor the performance of the local network slice (1 13) and in particular adjust the local network slice (1 13), in case the performance does not meet one or more service layer requirements.

20. A method comprising the step of:

operating a local network slice (1 13) in a first core network (1 1 1 ) to communicate with a remote network slice (163) in a second core network (161 ).