CN113170530A - Cross-regional network slice peering for 5G networks - Google Patents

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 for communicating with a remote network slice (NSI-2) in a second core network (161).

Description

Cross-regional network slice peering for 5G networks

Technical Field

The present invention generally relates to the field of telecommunications. More particularly, the present invention relates to an apparatus, system, and method for cross-regional end-to-end network slice peering in a communication network, particularly in a 5G core network.

Background

Next generation mobile networks (i.e., 5G networks) are expected to support many new types of services and connections between various devices (e.g., automobiles, wearable devices, sensors, and actuators) in both private and industrial environments. New types of services and connections often imply distinct service requirements in terms of latency, data rate, etc., which naturally require different processing, thereby presenting challenges to the control of the 5G network.

In particular, supporting various new types of services has a profound impact on the architecture of the core network. In today's mobile networks, services mainly refer to the access of portable devices in one's hands only for data services and voice services. The core network may apply substantially the same processing to the portable device following best-effort (best-effort) principles. Thus, these services are predictable, and it can be planned how to respond to them. However, with various new service requests, the service patterns will become very diverse. Therefore, it is difficult to predict a service request for the 5G network. The appropriate way to meet the requirements is to flexibly respond to any incoming service in a dynamic way.

It is not trivial to efficiently respond to different and unpredictable service requests. Administrative pre-planning methods using static network deployment do not work. Software-defined networking (SDN) and Network Function Virtualization (NFV) have recently been proposed as two key contributors to the implementation of flexible and programmable network infrastructures. The idea behind SDN is to abstract all content into flows and move the complexity of flow processing onto a logically centralized unit called SDN controller (SDNC). Thus, the SDN view (SDN view) simplifies all network elements to "dumb" stream processing devices that are only responsible for stream processing. With these concepts, SDN merges all management and Control Plane (CP) intelligence at SDNC. The generic abstraction and locally available data in turn simplify the development of network control and management applications. NFV further turns existing network functions (previously implemented primarily by dedicated and specific hardware) into virtual functional modules that can be easily deployed or removed as needed.

Given that any Network Function (NF) can be deployed/allocated on demand (a feature of NFV) and the forwarding behavior of NFs can be programmed remotely (a feature of SDN), with both enabling technologies, the response to new service requests becomes much easier than before, just like installing and running computer programs.

In the upcoming 5G era, services provided over mobile networks will not be limited to only person-to-person communications and basic internet connectivity. But rather anticipates providing more and more industry-vertical services over wireless mobile networks. However, the conventional best-effort quality-of-service (QoS) cannot support diversified services. For example, if a medical robot must operate telesurgery accurately in real time, the eHealth service requires ultra-low latency connections. Another example is that to provide an immersive entertainment experience, Virtual Reality (VR) live broadcasts require high throughput bandwidth while requiring low latency interactions. Thus, for different customers, the 5G network will have to guarantee various Service Level Agreements (SLAs), but share the same physical infrastructure.

The approach to meet these different requirements is to first virtualize the physical infrastructure as a cloud using the SDN and NFV techniques mentioned above, thereby converting the physical infrastructure to be fully programmable. Second, resource isolation is emphasized to provide performance guarantees. These two proposals lead to a new technical concept called network slicing, where multiple network tenants have their own network resources that are isolated from each other and guarantee SLAs. This isolated network resource portion for a tenant is a virtualized logical network housed in a shared infrastructure, called Network Slice Instance (NSI). According to current 3GPP SA2 definitions, NSI is end-to-end (E2E) network capability for providing services.

The emphasis on the capability of the E2E feature in the 5G network has attracted increasing interest in vertical industries. Unlike previous generations of mobile network systems (e.g., 3G and 4G), 5G networks will facilitate machine-type connectivity (MTC) where communication will occur between objects/devices rather than between people. For example, in future intelligent plants, robots need to communicate not only locally in one plant, but also to cooperate in production with robots located in another plant at a different location. Another example is a networked car scenario, where cars on the road will be controlled by a car company for autonomous driving or driving assistance, or communication may also occur between cars. In this case, the car is distributed throughout, covering different areas. Obviously, in both cases a certain level of QoS must be guaranteed.

To guarantee the SLA (e.g., latency) for the service, service providers in the industry vertical may utilize E2ENSI across multiple zones. Implementing such an E2E system is a resource provisioning and isolation issue if such NSIs are deployed in a single domain, just like local communication in one plant. In reality, if communication of region-to-region guaranteed SLAs is required, creating such an NSI for the E2E system becomes complicated due to the geographically distributed nature of the network infrastructure. The key reason is that the network infrastructure typically contains multiple areas, where each area is a subsystem with its local gateway within a geographic area. Further, the address assignment assigned at the gateway is globally planned and region-based, where local addresses in one region are private and cross-region communication is NAT-enabled (NATed). Thus, an infrastructure partitioned into multiple domains naturally destroys the E2E system.

Due to the lack of network slices, end-to-end traffic follows the infrastructure level. In particular, an identifier (e.g., an IP address) is assigned by the access control entity to any User Entity (UE) node accessing the network. For example, such a network function is called an Access Management Function (AMF) in 3 GPP. Thereafter, a bearer connection (i.e., a tunnel path) from the UE to a gateway node of the management area will be established, and an identifier of the UE is converted into a public identifier through Network Address Translation (NAT), wherein a mapping rule is created, and if the UE transmits a packet to other areas, a source address in a header of the packet will be modified into the public identifier of the gateway node. Conversely, if a packet is sent from another region to the gateway node, matching the conversion rules of the gateway node (e.g., ip _ addr: port), the destination field of the packet header will be modified and further forwarded to the inner region, with the packet eventually reaching the UE node.

Since communication mainly occurs between the UE and the server, and communication from the UE to the UE is rare and is mainly relayed through the central server, such a way through NAT solves the address allocation problem for network management, and also meets the service requirements of the current mobile network system. In short, the client-server model fits into the current service model, since communication is between north and south. However, such a scheme is hardly suitable for an upcoming 5G scenario, in particular an interconnection scenario of things such as interconnecting automobiles, remote operations, etc. In these cases, it is necessary to create an E2E network (slice) that spans the area so that UEs located in different areas can communicate seamlessly as if they were in the same local network. Clearly, there is still a gap to achieve a true E2E system (i.e., cross-regional E2E network slices) based on current solutions. It is still unclear how the 3GPP standardized specifications address the cross-regional E2E network slicing problem.

Given the environment settings of virtualization, it is natural to consider whether existing solutions from cloud computing can be used. Virtual Private Cloud (VPC) peering proposed for interconnecting two virtual data centers seems to be a suitable choice. A cloud resource provider provisions computing resources in a cloud data center based on a tenant's request. The provisioned resources are logically dedicated to that particular tenant and are guaranteed against orders submitted by the tenant, similar to a network slicing scenario. Such a portion of the provisioned resources is referred to as a VPC. In a cloud infrastructure, a tenant may have multiple VPC instances, which may be deployed in the same data center or geographically across different data centers. In either case, the tenant may want its VPCs to form a complete private network that can communicate with each other (e.g., private IP addressing). Thus, the cloud infrastructure must be able to establish such an interconnection, called VPC peering. However, as will be explained in more detail below, VPC peering cannot simply be used as a solution for cross-region inter-slice sharing.

First, the VPC excludes UEs from consideration at the VPC. Although VPC peering can logically merge two VPCs across different regions, the UE is still outside the merged VPC (consisting of two independent VPCs) and its address allocation still follows the policy of each cloud region. In principle, the UE will be treated as an end user and will be assigned an external identifier.

Second, VPC peers do not support overlapping addresses in the peer's VPC, even though the UE may be initially included as part of the VPC. Address overlap may be avoided in planning, but when two NSIs are requested, it may not be possible to plan for two NSIs to be peers. In other words, it is possible that initially two NSIs are planned independently (and thus there may be overlapping private addresses on each NSI), and we must peer the two NSIs due to later requirements. In this case, it is difficult to fully reassign the address, since it may be suspended and the running service must be stopped.

Third, only one peer-to-peer connection is supported between the two VPCs. VPC peering is more like routing table modification at the cloud datacenter layer. After creation, the VPC is always connected to a physical or virtual gateway router. If the VPC needs to access the outside, the gateway is configured to act as a NAT, otherwise all traffic is internally routed. When a VPC pair is required, the routing policy will be modified at both gateway nodes so that traffic from either VPC can pass through. A direct path may also be established if necessary. However, only one such connection can be established in current cloud platforms, and this simple peer-to-peer scheme would not help if one wants to include multiple UEs from different areas in different E2E network slices.

Furthermore, cross-regional communication typically involves external traffic transport consumption. This is also reflected by the pricing policies given by the hot cloud providers. Taking the VPC pricing of a well-known company as an example, the internal traffic cost is only $ 0.01/Gb if transmitted over a VPN connection, but the cost is $ 0.52/Gb if transmitted over a NATed scheme. In other words, cross-region communication is more expensive. The funding aspect is also a key factor that affects tenant policy selection when the tenant deploys its services in the cloud. Clearly, when deploying cross-regional services, tenants prefer to lease provisioned lines so that traffic does not traverse the public network like NATed traffic, but rather intra-domain traffic. This may be limited by the following two factors. First, leased supplied connections, while economical, are not free. Taking the VPC pricing of a well-known company as an example, the cost of providing a connection between the United states and the countries of the European Union is $ 0.3/hour and $ 0.02/Gb. Second, whether a tenant can lease a line to such a offer depends on the availability of the infrastructure of a particular cloud provider. For example, cloud infrastructure may be provided in only a few major countries and cities. If the cloud provider does not provide this functionality between regions, the individual must then think himself or herself to build the connection of the offer. One possible solution is to seek assistance to telecom operators whose network coverage is at least larger than current cloud providers. However, existing mobile network systems are not yet ready to provide such an E2E system.

Accordingly, there remains a need for an apparatus, system, and method for providing cross-regional end-to-end network slice peering in a communication network, particularly in a 5G core network.

Disclosure of Invention

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

In general, embodiments of the present invention are based on an extended set of operations performed on a related component that manages and implements cross-regional network slice peering for User Equipment (UE). The embodiment of the invention provides several functional extensions and corresponding new interfaces to adapt to a network system, so as to establish cross-regional E2E network slice peer-to-peer for User Equipment (UE).

According to an embodiment of the invention, a Network Slice Instance (NSI) is used to perceive a cross-regional network slice, where an access UE would be provided with a direct intra-slice path to the gateway node if cross-regional E2E communication is required. This process includes the management and assignment of cross-regional identifiers. Furthermore, the gateway node of a zone is adapted to establish a direct path to the gateway node of another zone. To form a complete cross-regional E2E path for direct UE connections, the created direct paths (including intra-slice paths and cross-regional paths) will be concatenated.

Embodiments of the present invention further provide a network slice management entity, which is adapted to instruct a managed component to complete the above introduced operations. Cross-regional E2E network slice peering may involve multiple management entities. In these management entities, cross-regional SLA requirements will be coordinated through a new interface between the involved regions. Meanwhile, in order to dynamically guarantee SLAs across multiple zones, performance monitoring loops may also be provided.

More particularly, according to a first aspect, the present 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 for communicating with a remote network slice in a second core network.

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

Thus, an improved network entity is provided that allows for cross-regional end-to-end network slice peering, i.e. that provides a virtual global slice in a communication network, in particular in a 5G core network.

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

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

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

The first sub-gateway may be a virtual switch.

In another possible implementation of the first aspect, the first UE is attached to a first access point of the local network slice, wherein, to provide the first local communication path, the network entity is further operable to provide the port at the first access point and provide the first port at a sub-gateway of the local network slice.

In another possible implementation of the first aspect, to provide the first local communication path, the network entity is further configured to: a first tunnel path is provided between a port of the first access point and a first port of a sub-gateway of the local network slice.

In another possible implementation of the first aspect, to provide the first local communication path, the network entity is further configured to: forwarding rules are provided at the first access point for forwarding data packets to and/or from the first UE.

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

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

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

In another possible implementation of the first aspect, the network entity is further configured to: a first port is provided at a primary gateway of a first core network.

In another possible implementation of the first aspect, the network entity is further configured to: a tunnel path is provided between a first port of a primary gateway of a first core network and a first port of a primary gateway of a second core network.

In another possible implementation of the first aspect, the network entity is further configured to: the data packets are encapsulated and provided to a tunnel path between the first port of the primary gateway of the first core network and the first port of the primary gateway of the second core network.

In another possible implementation of the first aspect, the network entity is configured to take into account one or more service layer requirements between the first core network and the second core network in order to provide a tunnel path between the first port of the primary gateway of the first core network and the first port of the primary gateway of the second core network.

In another possible implementation of the first aspect, the network entity is further configured to provide the first bridged communication path between the sub-gateway of the local network slice and the primary gateway of the first core network.

In another possible implementation of the first aspect, the first UE is attached to a first access point of the local network slice, and to provide the first bridged communication path, the network entity is further configured to: the second port is provided at a sub-gateway of the local network slice and at a main gateway of the first core network.

In another possible implementation of the first aspect, to provide the first bridged communication path, the network entity is further configured to: forwarding rules are provided at the sub-gateways of the local network slice for forwarding data packets between the first port and the second port of the sub-gateways of the local network slice.

In another possible implementation of the first aspect, to provide the first bridged communication path, the network entity is further configured to: forwarding rules are provided at the primary gateway of the first core network for forwarding data packets between the first port and the second port of the primary gateway of the first core network.

In another possible implementation of the first aspect, the network entity is further configured to monitor the performance of the local network slice, in particular based on a feedback loop. The network entity may also be configured to adjust the local network slice if 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 comprising 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 approach is provided that allows cross-area end-to-end network slice peering in a communication network, in particular in a 5G core network.

The 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 and drawings, and from the claims.

Drawings

Embodiments of the invention are described in more detail below with reference to the accompanying drawings, in which:

FIG. 1 is a high-level block diagram of a network architecture illustrating a cross-region sharing concept implemented by an embodiment of the present invention;

FIG. 2 is a block diagram illustrating a network architecture for implementing a cross-region sharing concept according to an embodiment of the present invention;

FIG. 3 is a block diagram illustrating the network architecture of FIG. 2 further including interfaces and tunnel paths implementing the area sharing concept in accordance with an embodiment of the present invention;

FIG. 4 is a block diagram illustrating the network architecture of FIG. 2 further including intra-operator interfaces and tunnel paths implementing the cross-region sharing concept in accordance with an embodiment of the present invention;

FIG. 5 is a block diagram illustrating the network architecture of FIG. 2 further including interfaces and tunnel paths within multiple operators implementing a cross-region sharing concept in accordance with an embodiment of the present invention; and

fig. 6 is a block diagram illustrating the network architecture of fig. 4 further including interfaces and bridge paths implementing the concept of region and inter-slice sharing according to an embodiment of the present invention.

In the following, the same reference numerals indicate identical or at least functionally equivalent features.

Detailed Description

The following description refers to the accompanying drawings, which form a part of this disclosure and show by way of illustration, specific aspects of embodiments of the invention or which may be used. It should be understood that embodiments of the invention may be used in other respects, and may include 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 example, it should be understood that disclosure relating to the described method may also hold for a corresponding device or system configured to perform the method, and vice versa. For example, if one or more particular method steps are described, the corresponding apparatus may include one or more elements (e.g., functional elements) to perform the one or more method steps described (e.g., one element performs one or more steps, or each of the plurality of elements performs one or more of the steps), even if such one or more elements are not explicitly described or shown in the figures. On the other hand, for example, if a particular apparatus is described based on one or more units (e.g., functional units), the corresponding method may include steps to perform the functions of the one or more units (e.g., one step performs the functions of one or more units, or each of multiple steps performs the functions of one or more units of the multiple units), even if such one or more steps are not explicitly described or illustrated in the figures. Furthermore, it is to be understood that 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 greater detail below, embodiments of the present invention provide a series of functional extensions to the components of a single or distributed network entity to implement and manage Network Slice Instances (NSIs) so that cross-regional E2E network slice peering for User Equipment (UE) can be established.

Fig. 1 depicts a high-level block diagram of a network architecture illustrating a cross-area sharing concept implemented by an embodiment of the present invention, wherein a first user equipment (UE 1)101 located at a first local core network (RE-1)111 and a second user equipment (UE2)151 located at a second local core network (RE-2)161 want to communicate with each other "directly" from both areas of the two core networks, wherein each UE accesses the network through local network slices (i.e., NSI-1113 and NSI-2163, also referred to herein as network slice instances NSI) created at each area, respectively, i.e., UE 1101 is attached to the first local network slice NSI-1113 and UE 2151 is attached to the second local network slice NSI-2163. These two areas (i.e. the first local core network RE-1 and the second local core network RE-2) belong to two separate operational domains, possibly owned by different operators, so only gateway interconnections are available.

As will be described in more detail below, embodiments of the present invention provide a network entity for a first core network RE-1111, wherein the network entity is configured to operate a local network slice NSI-1113 in the first core network RE-1111 to communicate with a second network slice (i.e., a far-end network slice NSI-2163) in a second core network RE-2161. The second core network RE-2161 may also provide the same network entities, in which case the local network slice NSI-1113 in the first core network RE-1111 would be a far-end network slice, according to an embodiment of the present invention.

In an embodiment, the components that implement the NSI in each region will be tailored to support cross-region E2E network slice peering requirements. The extension here includes: first, the access management entity may assign a special identifier for cross-region communication. Second, session management for the NSI may establish a direct path (e.g., a bearer tunnel) from the UE to a gateway node for the NSI. Notably, such paths still cannot achieve cross-regional connectivity because traffic is still NAT through the gateway nodes of the NSI (i.e., Gw' 115, 165 in fig. 1). Third, the intra-slice SLAs should currently be guaranteed by considering SLA requirements across area E2E.

In an embodiment, NSI-1 is one of the plurality of local network slices 113 of the first core network 111 and NSI-2 is one of the plurality of local network slices 163 of the second core network 161, as can be seen in fig. 1, wherein each of the plurality of local network slices 113 of the first core network 111 comprises a sub-gateway 115, the sub-gateway 115 being connected with the main gateway 121 of the first core network 111, and each of the plurality of local network slices 163 of the second core network 161 comprises a sub-gateway 165, the sub-gateway 165 being connected with the main gateway 171 of the second core network 161.

In another embodiment, the gateway node may be extended to handle cross-region E2E requirements, where a direct path may be established and concatenated with the previously created intra-slice direct path (i.e., Gw node). Thus, the two paths that are joined together merge different regions, which further reach other regions. Thus, with the paths established on both sides, a complete path for network slicing peering across area E2E may be formed. In particular, creating a direct path between two gateway nodes of two zones will result in a new interface (referred to herein as a cross-zone gateway interface) that is used to exchange or coordinate E2E SLA requirements, as will be explained in more detail below.

Furthermore, all of the operations introduced above may be dependent on the commands of the network slice management logic. Additionally, performance or status monitoring loops may be provided to dynamically adjust the configuration of the deployment of network slice peers across the area E2E. This may be implemented as a distributed or centralized system.

Since Software Defined Networking (SDN) and Network Function Virtualization (NFV) technologies are key contributors to programmable network infrastructure, embodiments of the present invention may be based on a virtualized environment in which infrastructure resources (e.g., computing, storage, and networks) are abstracted and may be dynamically provisioned, adjusted, and/or reallocated as needed.

According to an embodiment, network programmability of the infrastructure (e.g., OpenvSwitch node capability) may facilitate cross-regional E2E communication. As shown in fig. 2, the two NSIs (i.e., NSI-1113 and NSI-2163) are deployed in the network but in different areas or core networks (i.e., RE-1 and RE-2), where communication across the different areas must pass through transport network 140. Since there may be multiple NSIs owned by different tenants in each area or core network, each NSI will have its own gateway node Gw' to access the local infrastructure. In addition, multiple NSIs may share a common gateway node when external communication outside the local area is required. In fig. 2, Gw '115 and Gw' 165 are used to represent gateway nodes of NSI 113 and NSI 163, respectively, and Gw 121 and Gw 171 represent gateway nodes of core network 111 and core network 161, respectively.

Notably, since NSI-1113 and NSI-2163 are originally in different areas and addresses are fully automatically assigned, NSI-1113 and NSI-2163 may have the same private network address realm. This shows a key difference from the VPC peering scenario where the peering VPCs should not have overlapping addresses, thus requiring pre-planning. However, VPC peer-to-peer solutions cannot be applied because they can cause address reallocation for deployed NSIs, can introduce significant maintenance costs and suspend running services.

The UE node accesses the NSI through an access point (i.e., AP 103, 153 in fig. 2) of the regional network. According to an embodiment, two UE nodes from different areas having access to their own NSI want to communicate with each other as in the same local network. Meanwhile, the requirement of ensuring SLA can be met. Also, the VPC peering solution does not address how the UE nodes should peer.

With further reference to fig. 3-6, how cross-region E2E network slice peering is implemented will be discussed in detail below. The complete process comprises the following steps: the first step is to configure the NSI for identifier assignment in each area network and to establish a direct path from the UE node to the gateway node of the NSI. The second step is to retrieve the SLA requirements of the UE for the NSI and configure the gateway node between the two involved areas, where a direct path will be established across the two areas, while the SLA requirements across area peering will be coordinated. The third step is to concatenate the local direct path with the cross-regional path and the performance monitoring loopback will be associated with the network slice management layer.

To prepare an area direct path from a UE node (e.g., UE-1 in fig. 3) to the gateway node 115 of the local network slice NSI 113, a cross-area identifier is assigned to the UE node 101 by a network entity (in particular, an access management entity, i.e., UE-1: IPc). In 3GPP systems, this is defined as the main work of the Access Management Function (AMF). Such functionality may be located somewhere in the core network or integrated with the Access Point (AP) 103. In the former case, the access point 103 forwards the join request from the UE 101 to the address bound to the AMF. In the latter case, the access point 103 will immediately assign an identifier. Such a cross-region identifier may be a new identifier for the UE node 101 that is different from the initial identifier that the UE 101 would have obtained when it joined the NSI 113 on a regular basis. In an embodiment, although the UEs belong to the same NSI, a dedicated identifier is preferably assigned for differentiation from local traffic identification.

As shown in fig. 3, after the allocation of the cross-area identifier is completed, the access point 103 prepares to establish a path to the gateway node 115 of the local network slice NSI 113. This process includes port creation, path provisioning, and forwarding rule set configuration: two ports (ap: p _ a 103a and Gw ': p _ a' 115a) are created on the access point 103 and the gateway node 115 of the local network slice NSI 113, respectively, as two end points of the area path.

More specifically, to provide the first local communication path and the second local communication path, port 103a is provided at the first access point 103, the first port 115a is provided at the sub-gateway 115 of the local network slice NSI-1113, and port 153a is provided at the second access point 153, and the first port 165a is provided at the sub-gateway 165 of NSI-2163.

A path belonging to the NSI will then be provisioned as a tunnel path between the two ports 103a and 115a according to the SLA requirements of the UE node 101. These two ports will be used to transport traffic between the UE node 101 and the gateway node 115 of the local network slice NSI-1113 over the provisioned path. When a data packet for the UE node 101 arrives at the access point 103, the created port encapsulates and forwards the data packet through a tunneled path to port 115a on the gateway 115 of the local network slice NSI-1113. In this way, port 115a on gateway node 115 of local network slice NSI-1113 may get a packet from UE 101 with a cross-region identifier.

On the other hand, a packet arriving at port 115a of the gateway node 115 will be encapsulated and routed to port 103a on the access point 103, and then de-encapsulated and eventually sent to the UE node 101. All forwarding actions are directed by forwarding rules configured on the access point to handle incoming and outgoing packets.

More specifically, in one embodiment, a first tunneling path is provided between port 103a of the first access point 103 and a first port 115a of the sub-gateway 115 of the local network slice NSI-1113. Similarly, a second tunnel path may be provided between port 153a of the second access point 153 and the first port 165a of the sub-gateway 165 of the remote network slice NSI-2163. Further, forwarding rules for forwarding packets to and from UE 1101 may be provided at the first access point 103, and forwarding rules for forwarding packets to and from UE 2151 may also be provided at the second access point 153.

In another embodiment, UE 1101 and UE 2151 may be assigned a cross-slice identifier (i.e., a global identifier). Embodiments of the present invention may configure the first access point 103 based on the cross-slice identifier of UE 1101 to encapsulate and forward data packets to the tunnel path between port 103a of the first access point 103 and the first port 115a of the sub-gateway 115 of local network slice NSI-1113, and configure the second access point 153 based on the global identifier of UE 2151 to encapsulate and forward data packets to the tunnel path between port 153a of the second access point 153 and the first port 165a of the sub-gateway 165 of far-end network slice NSI-2163.

In another embodiment, a direct path across the region may be constructed, wherein the path also takes into account the SLA requirements across region E2E. This requirement can be coordinated by a new interface between two gateway nodes of two different areas. There are two possible situations when a path is established between two regions. The first case is where the two areas belong to the same operator, and the second case is where the two areas belong to different operators.

For the first case, similar to the process of creating the regional direct path, a new port is prepared for each gateway node of the regional network to handle the cross-regional traffic, where the encapsulation/decapsulation of the data packets is done on the port. The network operator may provide a tunnel path between the two newly created ports. Since this path is a cross-regional tunnel path that requires SLA guarantees, SLA requirements across the regional E2E network slice can be exchanged between the two management entities responsible for the respective management regions when provisioning the path. Thus, as shown in fig. 4, a new interface may be created between the two management entities to exchange the required information.

More specifically, each local network slice of the plurality of local network slices 113 of the first core network 111 comprises a sub-gateway 115 connected to the main gateway 121 of the first core network 111, 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 the main gateway 171 of the second core network 161. To provide a global communication path between the primary gateway 121 of the first core network 111 and the primary gateway 171 of the second core network 161, the first port 121a is provided at the primary gateway 121 of the first core network 111 and the first port 171a is provided at the primary gateway 171 of the second core network 161.

Further, a tunnel path is provided between the first port 121a of the main gateway 121 of the first core network 111 and the first port 171a of the main gateway 171 of the second core network 161. The embodiment of the present invention may encapsulate and forward the data packet to the tunnel path between the first port 121a of the main gateway 121 of the first core network 111 and the first port 171a of the main gateway 171 of the second core network 161. In order to provide a tunnel path between the first port 121a of the primary gateway 121 of the first core network 111 and the first port 171a of the primary gateway 171 of the second core network 161, embodiments of the present invention also allow for one or more service layer requirements between the first core network 111 and the second core network 161 to be taken into account.

For the second case, since multiple operators are involved, the transport network between two gateway nodes of two regions or two core networks is not fully policed by either of the two operators. Thus, either of the two operators may cooperate to establish the path, or may involve a third party operator owning the transport network. For the former case, the path setup request may be exchanged over an interface between the management entities of two different operators, which triggers port creation on the gateway node on each side. SLA requirements across the area E2E network slice may also be exchanged afterwards, so that each management entity can provision paths within its respective management domain. For the latter case, both operators will talk to a possible third party operator. When the operator of the transport network receives the request and the SLA requirements of the E2E network slice, both gateway nodes can be informed how new ports should be created and connected with the operator-supplied cross-area tunnel path of the transport network. This is shown in fig. 5.

As discussed above, two types of direct paths may be created through the previous steps. The first type is the regional direct path between the UE and the gateway node of the NSI; the second type is a cross-regional direct path between gateway nodes of two different regions, which may be administrative domains of different operators.

However, since the gap between the gateway node of the NSI and the gateway node of the regional network infrastructure has not yet been bridged (i.e., Gw' to Gw in fig. 4-6), the full E2E path has not yet been completed. In addition, no performance monitoring loopback is introduced.

In an embodiment, the gap between the gateway node of the NSI and the gateway node of the regional network infrastructure may be bridged: cross-regional traffic sent from the UE may reach the gateway node of the NSI and need to be forwarded to the gateway node of the regional network. To guarantee E2E performance across NSI, the path between gateway nodes must also learn SLA requirements. Thus, there is an interface between two gateway nodes to exchange the necessary parameter data, similar to the case of a cross-regional gateway node.

Referring to fig. 6, a specific process involves creating a new port and configuring forwarding rules on two gateway nodes (i.e., between the gateway node of the NSI and the gateway node of the regional network infrastructure). For the gateway node of the NSI a new port will be created as an interface/end point of the path to the gateway node of the area network. Correspondingly another new port will be created as an interface/end point of the path to the gateway node of the NSI. In order to concatenate the direct path connecting the UE node and the gateway node of the NSI with the direct path between the gateway node of the NSI and the gateway node of the regional network, a forwarding rule is added on the gateway node of the NSI.

More specifically, in order to provide a first bridged communication path between the sub-gateway 115 of the local network slice NSI-1113 and the main gateway 121 of the first core network 111, and/or a second bridged communication path between the sub-gateway 165 of the remote network slice NSI-2163 and the main gateway 171 of the second core network 161, embodiments of the present invention may provide: a second port 115b at the sub-gateway 115 of the local network slice NSI-1113 and a second port 121b at the main gateway 121 of the first core network 111; and/or the second port 165b at the sub-gateway 165 of the far-end network slice NSI-2163 and the second port 171b at the main gateway 171 of the second core network 161.

Furthermore, in order to provide the first bridged communication path and/or the second bridged communication path, a forwarding rule may be provided at the sub-gateway 115 of the local network slice NSI-1113 for forwarding data packets between the first port 115a and the second port 115b of the sub-gateway 115 of the local network slice NSI-1113; and/or may also provide forwarding rules at the sub-gateway 165 of the remote network slice NSI-2163 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-2163.

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

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

In order to concatenate the direct path between two local gateway nodes with the direct path between the cross-regional gateway nodes, a forwarding rule may also be added on the gateway nodes of the regional network. In particular, if a packet is received from a created port (label), the forwarding rules may direct the packet to a direct path to other gateway nodes across the region. On the other hand, if a packet is received from an interface of a cross-regional direct path, the forwarding rule may direct the packet to an interface/port of the path to the gateway node of the NSI.

The cross-regional E2E network slice for UE nodes may not be static, as E2E SLAs may be important. Thus, the performance of each direct path may be monitored and real-time status provided to the management layer. The management layer may adjust the configuration (including path provisioning) as necessary.

After configuring all forwarding rules, the entire path completes E2E, providing cross-regional E2E network slice peering in a communication network (especially a 5G core network). The local management entity also provisions the path according to the exchanged information.

Those skilled in the art will appreciate that "blocks" ("elements") in the various figures (methods and apparatus) represent or describe the functionality of embodiments of the present invention (rather than individual "elements" in hardware or software), and thus, equally describe the functionality or features (elements or steps) of apparatus embodiments and method embodiments.

In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods may be implemented in other ways. For example, the described apparatus embodiments are merely exemplary. For example, the cell division is only a logical functional division, and may be other divisions in an actual implementation. For example, various elements or components may be combined or integrated in another system or certain features may be omitted, or not implemented. Further, the mutual coupling or direct coupling or communication connections shown or discussed may be realized by using some interfaces. An indirect coupling or communicative connection between devices or units may be achieved electronically, mechanically, or otherwise.

Elements described as separate parts may or may not be physically separate and parts shown as elements may or may not be physical elements, may be located in one position or may be distributed over a plurality of network elements. Some or all of the units can be selected according to actual needs to achieve the purposes of the embodiment schemes.

In addition, the functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist separately physically, or two or more units are integrated into one unit.

Claims (20)

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

-operating a local network slice (113) in the first core network (111) to communicate with a remote network slice (163) in a second core network (161).

2. The network entity of the preceding claim, configured to:

-obtaining data from the far-end network slice (163) within the local network slice (113); and/or

-providing data to the far-end network slice (163) within the local network slice (113).

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

-acquiring data from a first UE (101) within the local network slice (113), the first UE (101) being attached to a RAN of the first core network (111); and/or

-obtaining data from a second UE (151) from the far-end network slice (163) within the local network slice (113).

4. The network entity of the preceding claim, wherein the network entity is configured to provide a first local communication path between the first UE (101) and a sub-gateway (115) of the local network slice (113).

5. The network entity of claim 4, wherein the first UE (101) is attached to a first access point (103) of the local network slice (113), and wherein, in particular, to provide the first local communication path, the network entity is further configured to:

providing a port (103a) at the first access point (103) and providing a first port (115a) at the sub-gateway (115) of the local network slice (113).

6. The network entity of claim 5, wherein to provide the first local communication path, the network entity is further to:

providing a first tunnel path between the port (103a) of the first access point (103) and the first port (115a) of the sub-gateway (115) of the local network slice (113).

7. The network entity of claim 5 or 6, wherein to provide the first local communication path, the network entity is further to:

providing, at the first access point (103), a forwarding rule for forwarding data packets to the first UE (101) and/or forwarding data packets from the first UE (101).

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

9. The network entity of claim 8, wherein the network entity is further configured to:

configuring the first access point (103) based on the cross-slice identifier of the first UE (101) to encapsulate and forward data packets to the tunnel path between the port (103a) of the first access point (103) and the first port (115a) of the sub-gateway (115) of the local network slice (113).

10. The network entity of any preceding claim, wherein the network entity is further configured to provide a cross-slice communication path between a primary gateway (121) of the first core network (111) and a primary gateway (171) of the second core network (161).

11. The network entity of claim 10, wherein the network entity is further configured to:

providing a first port (121a) at the primary gateway (121) of the first core network (111).

12. The network entity of claim 11, further configured to:

providing a tunnel path between the first port (121a) of the primary gateway (121) of the first core network (111) and a first port (171a) of the primary gateway (171) of the second core network (161).

13. The network entity of claim 12, wherein the network entity is further configured to:

encapsulating a data packet and providing the data packet to the tunnel path between the first port (121a) of the primary gateway (121) of the first core network (111) and the first port (171a) of the primary gateway (171) of the second core network (161).

14. The network entity of claim 12 or 13, configured to consider one or more service layer requirements between the first core network (111) and the second core network (161).

15. The network entity of any one of the preceding claims, wherein the local network slice (113) comprises a sub-gateway (115) connected to a main gateway (121) of the first core network (111), wherein the network entity is further configured to provide a first bridged communication path between the sub-gateway (115) of the local network slice (113) and the main gateway (121) of the first core network (111).

16. The network entity of claim 15, wherein the first UE (101) is attached to a first access point (103) of the local network slice (113), and the network entity is further configured to:

providing a second port (115b) at the sub-gateway (115) of the local network slice (113) and providing a second port (121b) at the main gateway (121) of the first core network (111).

17. The network entity of claim 16, wherein to provide the first bridged communication path, the network entity is further to:

providing, at the sub-gateway (115) of the local network slice (113), a forwarding rule for forwarding data packets between the first port (115a) and the second port (115b) of the sub-gateway (115) of the local network slice (113).

18. The network entity of claim 16 or 17, wherein to provide the first bridged communication path, the network entity is further to:

providing a forwarding rule at the primary gateway (121) of the first core network (111) for forwarding data packets between the first port (121a) and the second port (121b) of the primary gateway (121) of the first core network (111).

19. The network entity of any one of the preceding claims, wherein the network entity is further configured to monitor a performance of the local network slice (113) and to adapt the local network slice (113), in particular if the performance does not meet one or more service layer requirements.

20. A method comprising the steps of:

a local network slice (113) in a first core network (111) is operated to communicate with a remote network slice (163) in a second core network (161).

Images