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

Abstract

The application relates to a communication method for a first core network (111) and a network entity for operating a local network slice (NSI-1) in the first core network for communication 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 application relates generally to the field of telecommunications. More particularly, the present application relates to an apparatus, system, and method for cross-regional end-to-end network slicing 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 services and connections between various devices (e.g., automobiles, wearable devices, sensors, and actuators) in private and industrial environments. New services and connections often imply distinct service requirements in terms of latency, data rate, etc., which naturally require different processing, thereby posing challenges to the control of the 5G network.

In particular, supporting various new services has a profound impact on the architecture of the core network. In today's mobile networks, services mainly refer to access by portable devices in the hands of people 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 how to respond can be pre-programmed. However, with various new service requests, the service modes will become very diverse. Therefore, it is difficult to predict a service request for a 5G network. An appropriate way to meet the requirements is to flexibly respond to any incoming service in a dynamic way.

It is not easy to respond efficiently to different and unpredictable service requests. The administrative pre-planning approach using static network deployment does not work. Recently, software-defined networking (SDN) and network function virtualization (network function virtualization, NFV) have been proposed as two key contributors to implementing a flexible and programmable network infrastructure. The idea behind SDN is to abstract all content into flows and move the complexity of flow processing onto a logical centralized unit called an SDN controller (SDNC). Thus, an SDN view (SDN view) reduces all network elements to "dumb" flow processing devices that are responsible for flow processing only. With these concepts, SDN merges all Control Plane (CP) wisdom at the SDNC. Whereas the generic abstraction and locally available data in turn simplifies the development of network control and management applications. NFV further converts existing network functions (previously implemented primarily by dedicated and specific hardware) into virtual function modules that can be easily deployed or removed as needed.

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

In the upcoming 5G age, services provided through mobile networks will not be limited to just person-to-person communications and basic internet connections. But are expected to provide more and more vertical industry services over wireless mobile networks. However, conventional best effort quality of service (QoS) cannot support diversified services. For example, if a medical robot must accurately operate tele-surgery in real time, the eHealth service requires an ultra-low latency connection. Another example is that in order to provide an immersive entertainment experience, a Virtual Reality (VR) live broadcast requires high throughput bandwidth while requiring low latency interactions. Thus, for different customers, a 5G network would have to guarantee various service level agreements (SERVICE LEVEL AGREEMENT, SLAs), but share the same physical infrastructure.

One way to meet these different requirements is to first virtualize the physical infrastructure into a cloud using the SDN and NFV technologies mentioned above, converting the physical infrastructure to be fully programmable. Second, resource isolation is emphasized to provide performance guarantees. These two proposals create 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 one tenant is a virtualized logical network housed in a shared infrastructure, referred to as a Network Slice Instance (NSI). NSI is an end-to-end (E2E) network capability for providing services according to the current 3gpp SA2 definition.

Emphasis on E2E feature capability in 5G networks has attracted increasing interest in the vertical industry. Unlike previous generations of mobile network systems (e.g., 3G and 4G), 5G networks will facilitate machine-type connections (machinery-type connectivity, MTC) in which communications will occur between objects/devices, rather than from person to person. For example, in future intelligent plants, robots need to communicate locally not only in one plant, but also to co-operate with robots in another plant located in a different place at the time of production. Another example is a networked car scenario where cars on the road will be controlled by a car company for automatic driving or driving assistance, or where communication between cars may also occur. In this case, the car is spread throughout so as to cover different areas. Obviously, a certain level of QoS must be guaranteed in both cases.

To guarantee an SLA (e.g., latency) for a service, a service provider in the vertical industry may utilize E2ENSI across multiple areas. Implementing such an E2E system is a problem of resource provisioning and isolation if such NSIs are deployed in a single domain, just like local communication in one factory. In reality, if area-to-area guaranteed SLA communication is required, creating such NSI for E2E systems becomes complex 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 that has its local gateway within a geographic area. Furthermore, the allocation of addresses allocated at the gateway is globally planned and area-based, where local addresses in one area are private and trans-regional communication is through NAT (NATed). Thus, an infrastructure that is partitioned into multiple domains naturally breaks the E2E system.

End-to-end traffic follows the infrastructure hierarchy due to the absence of network slices. In particular, an identifier (e.g., an IP address) is assigned by the access control entity to a User Entity (UE) node of any access network. For example, such network functions are referred to in 3GPP as access management functions (ACCESS MANAGEMENT functions, AMFs). Thereafter, a bearer connection (i.e. tunnel path) will be established from the UE to the gateway node of the management area and the identifier of the UE is converted to a public identifier by means of network address translation (network address translation, NAT), wherein a mapping rule is created and the source address in the packet header will be modified to the public identifier of the gateway node if the UE sends a packet to the other area. Conversely, if a packet is sent from another area to the gateway node, matching the transformation rules of the gateway node (e.g., ip_addr: port), the destination field of the packet header will be modified and forwarded further to the inner area, and the packet eventually reaches the UE node.

Because communication mainly occurs between the UE and the server, and the communication from the UE to the UE is little and is mainly relayed through the central server, the address allocation problem is solved for network management through the NAT mode, and meanwhile, the service requirement of the current mobile network system is met. In brief, the client-server model is suitable for current service models because communications are between north and south. However, such a solution is hardly suitable for upcoming 5G scenes, in particular for things interconnection scenes such as interconnected cars, remote operations, etc. In these cases, a trans-regional E2E network (slice) must be created so that UEs located in different regions can communicate seamlessly as in the same home network. Clearly, there is still a gap to implement a true E2E system (i.e., cross-regional E2E network slicing) based on current solutions. How the 3GPP standardization specifications solve the problem of cross-regional E2E network slicing is not clear.

In view of the virtualized environment settings, it is naturally considered whether existing solutions from cloud computing can be used. The proposed virtual private cloud (virtual private cloud, VPC) peering for interconnecting two virtual data centers appears to be a suitable option. The cloud resource provider supplies computing resources in the cloud data center based on the tenant's request. The resources offered are logically dedicated to that particular tenant and guaranteed according to the orders submitted by the tenant, similar to the network slicing scenario. Such a part of the supplied resources is called VPC. In a cloud infrastructure, a tenant may have multiple VPC instances, which may be deployed at the same data center or geographically across different data centers. In either case, the tenant may wish that its VPCs 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, known as VPC peering. However, as will be explained in more detail below, VPC peering cannot simply be used as a solution for inter-slice sharing across regions.

First, the VPC excludes the UE from VPC consideration. 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 regarded as an end user and will be assigned an external identifier.

Second, even though the UE may initially be included as part of the VPC, the VPC peering does not support addresses that overlap in the peering's VPC. Address overlap may be avoided in planning, but when two NSIs are requested, it may not be possible to plan for peer two NSIs. In other words, it is possible that initially two NSIs are independently planned (and thus there may be overlapping private addresses on each NSI), and we have to peer two NSIs due to the later requirements. In this case, it is difficult to completely reassign the address because it may be possible to hang up 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 data center layer. After the VPC is created, it 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 routed internally. When VPC pairing is required, the routing policy will be modified at both gateway nodes so that traffic from either VPC can pass. A direct path may also be established if necessary. However, in current cloud platforms only one such connection can be established, and this simple peer-to-peer scheme would not help if it were desired to include multiple UEs from different areas in different E2E network slices.

Furthermore, trans-regional communication typically involves external traffic transport consumption. This is also evident by the pricing policies offered 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 $ 0.52/Gb if transmitted over the NATed scheme. In other words, trans-regional communication is more expensive. Funds aspects are also key factors affecting tenant policy selection when tenants deploy their services in the cloud. Obviously, when deploying a trans-regional service, the tenant is more inclined to lease the provisioned line, so that traffic does not traverse the public network as NATed traffic, but rather is like intra-domain traffic. This may be limited by two factors. First, the connection of the rental supply is economical but not free. Taking VPC pricing of a well known company as an example, the connection cost provided between the united states and the european union country is $ 0.3/hour and $ 0.02/Gb. Second, whether a tenant can lease to such provisioned lines 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 areas, the individual must himself want to build a connection to the offer. One possible solution is to seek assistance from telecom operators whose network coverage is at least greater than current cloud providers. Existing mobile network systems are not ready to provide such E2E systems.

Accordingly, there remains a need for devices, systems, and methods for providing cross-regional end-to-end network slice peering in communication networks, particularly in 5G core networks.

Disclosure of Invention

Embodiments of the application 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 application are based on an extended set of operations performed on related components that manage and implement cross-regional network slice peering for User Equipment (UE). Embodiments of the present application provide several functional extensions and corresponding new interfaces to accommodate network systems to establish cross-regional E2E network slice peering for User Equipment (UE).

According to an embodiment of the application, a Network Slice Instance (NSI) is used to perceive a cross-regional network slice, wherein a direct intra-slice path to a gateway node would be provided for an access UE if cross-regional E2E communication is required. This process includes the management and allocation of cross-region identifiers. Furthermore, the gateway node of a region is adapted to establish a direct path to the gateway node of another region. In order to form a complete trans-regional E2E path for a direct UE connection, the created direct paths (including intra-slice paths and trans-regional paths) will be concatenated.

The embodiment of the application also provides a network slice management entity, which is suitable for indicating the managed component to complete the operations introduced above. Transregional E2E network slicing peering may involve multiple management entities. In these management entities, the cross-regional SLA requirements will be coordinated through a new interface between the involved regions. At the same time, to dynamically guarantee SLAs across multiple regions, performance monitoring loops may also be provided.

More particularly, according to a first aspect, the application relates to a network entity for a first core network, wherein the network entity is arranged to operate a local network slice in the first core network for communication 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 allowing cross-regional end-to-end network slicing peering, i.e. providing virtual global slicing 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 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 a 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 a local network slice, wherein to provide the first local communication path, the network entity is further operable to provide a port at the first access point and a first port at a sub-gateway of the local network slice.

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

In a further possible implementation manner of the first aspect, in order to provide the first local communication path, the network entity is further configured to: a forwarding rule is provided at the first access point for forwarding the data packet 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 manner 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 the data packet 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 manner 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 manner 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 manner of the first aspect, the network entity is further configured to: encapsulating the data packets and providing the data packets 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 a further possible implementation form 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 manner of the first aspect, the network entity is further configured to provide a 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 a local network slice, and the network entity is further configured to, in order to provide a first bridged communication path: a second port is provided at a sub-gateway of the local network slice and a second port is provided at a main gateway of the first core network.

In a further possible implementation manner of the first aspect, in order to provide the first bridged communication path, the network entity is further configured to: forwarding rules are provided at the local network-sliced sub-gateway for forwarding data packets between the first port and the second port of the local network-sliced sub-gateway.

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

In a further 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 in the event that the performance of the local network slice does not meet one or more service layer requirements.

According to a second aspect, the application 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 method is provided that allows for implementation of trans-regional 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 application are described in more detail below with reference to the attached drawing figures, wherein:

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

FIG. 2 is a block diagram illustrating a network architecture for implementing a cross-regional sharing concept in accordance with an embodiment of the present application;

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 application;

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

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

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

Like reference numerals below denote like or at least functionally equivalent features.

Detailed Description

The following description refers to the accompanying drawings, which form a part hereof, and which show by way of illustration specific aspects of embodiments of the application or in which the embodiments of the application may be practiced. It is to be understood that embodiments of the application may be used in other respects and may include structural or logical changes not depicted in the drawings. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present application is defined by the appended claims.

For example, it should be understood that disclosure relating to the described method may also be true 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 units (e.g., functional units) to perform the one or more described method steps (e.g., one unit performing one or more steps, or each of the plurality of units performing one or more of the plurality of steps), even if such one or more units are not explicitly described or shown in the figures. On the other hand, if a particular apparatus is described based on one or more units (e.g., functional units), for example, the corresponding method may include steps to perform the function of the one or more units (e.g., one step to perform the function of the one or more units, or each of the plurality of steps to perform the function of the one or more units), even if such one or more steps are not explicitly described or shown in the drawings. 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 indicated otherwise.

As will be described in more detail below, embodiments of the present application provide a series of functional extensions to components of a single or distributed network entity to implement and manage Network Slice Instances (NSIs) so that a trans-regional E2E network slice peering for User Equipment (UE) can be established.

Fig. 1 depicts a high-level block diagram of a network architecture showing the cross-regional sharing concept implemented by embodiments of the present application, wherein a first user equipment (UE 1) 101 located at a first local core network (RE-1) 111 and a second user equipment (UE 2) 151 located at a second local core network (RE-2) 161 want to communicate "directly" with each other from two areas of the two core networks, wherein each UE accesses the network through a local network slice created in each area (i.e., NSI-1 113 and NSI-2 163, also referred to herein as network slice instance NSI), i.e., UE 1 101 is attached to the first local network slice NSI-1 113 and UE2 151 is attached to the second local network slice NSI-2 163. These two areas (i.e. the first local core network RE-1 and the second local core network RE-2) belong to two separate operating domains, possibly owned by different operators, so only gateway interconnections are available.

As will be described in more detail below, embodiments of the present application provide a network entity for a first core network RE-1 111, wherein the network entity is configured to operate a local network slice NSI-1 113 in the first core network RE-1 111 to communicate with a second network slice (i.e., a remote network slice NSI-2 163) in a second core network RE-2 161. The second core network RE-2 161 may also provide the same network entity according to an embodiment of the application, in which case the local network slice NSI-1 113 in the first core network RE-1 111 will be a remote network slice.

In an embodiment, the components implementing NSI in each zone will be tuned to support cross-zone E2E network slice peering requirements. The extensions here include: first, the access management entity may assign a special identifier for cross-regional communication. Second, session management of the NSI may establish a direct path (e.g., bearer tunnel) from the UE to the gateway node of the NSI. Notably, such paths still do not enable trans-regional connections because traffic is still NAT through the gateway nodes of the NSI (i.e., gw'115, 165 in fig. 1). Third, the intra-slice SLA should currently be guaranteed by considering the SLA requirements of the cross-zone 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 from fig. 1, wherein each of the plurality of local network slices 113 of the first sub-network 111 comprises a sub-gateway 115, the sub-gateway 115 being connected to the primary gateway 121 of the first core network 111, each of the plurality of local network slices 163 of the second core network 161 comprising a sub-gateway 165, the sub-gateway 165 being connected to the primary gateway 171 of the second core network 161.

In another embodiment, the gateway node may be extended to handle cross-regional E2E requirements, where a direct path may be established and concatenated with a previously created intra-slice direct path (i.e., gw node). Thus, the two paths that are connected together merge different regions that reach further regions. Thus, with the path established on both sides, a complete path for cross-regional E2E network slice peering can be formed. In particular, creating a direct path between two gateway nodes in two areas will result in a new interface (referred to herein as a trans-regional gateway interface) for exchanging or coordinating E2E SLA requirements, as will be explained in detail below.

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

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

According to an embodiment, network programmability of the infrastructure (e.g., openvSwitch node capabilities) may facilitate implementing cross-regional E2E communications. As shown in fig. 2, two NSIs (i.e., NSI-1 113 and NSI-2 163) are deployed in the network but in different areas or core networks (i.e., RE-1 and RE-2), wherein communications across different areas must pass through transport network 140. Since there may be multiple NSIs in each area or core network owned by different tenants, 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 communications outside the local area are 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, because NSI-1 113 and NSI-2 163 are originally in different areas, the addresses are fully automatically assigned, NSI-1 113 and NSI-2 163 may have the same private network address field. This shows a key distinction from the VPC peering scenario where the peering VPC should not have overlapping addresses and therefore needs to be pre-programmed. Nevertheless, VPC peer-to-peer solutions cannot be applied to this, as there is a potential for address reassignment to deployed NSIs, introducing significant maintenance costs and suspending running services.

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

With further reference to fig. 3-6, how cross-regional 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 in each regional network for identifier assignment 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 of the NSI and configure the gateway node between the two involved areas, wherein a direct path will be established across the two areas, while SLA requirements of the trans-regional peering will be coordinated. The third step is to concatenate the local direct path with the cross-regional path and the performance monitoring loop back will be associated with the network slice management layer.

To prepare a regional direct path from a UE node (e.g., UE-1 in fig. 3) to a gateway node 115 of a local network slice NSI 113, a cross-regional identifier is assigned to the UE node 101 by a network entity (particularly 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 the identifier. Such a cross-region identifier may be a new identifier for the UE node 101 that is different from the initial identifier that would be obtained when the UE 101 was added to the NSI 113 as usual. In an embodiment, the UE is preferably assigned a dedicated identifier for distinguishing from the local traffic identity, although it belongs to the same NSI.

As shown in fig. 3, after completing the allocation of the cross-region identifier, 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_a103 a and Gw ': p_a'115 a) are created on the gateway node 115 of the access point 103 and the local network slice NSI 113, respectively, as two endpoints of the regional path.

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

A path belonging to 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-1 113 over the provisioned path. When the packet of UE node 101 arrives at access point 103, the created port encapsulates the packet and forwards it over the tunnel path to port 115a on gateway 115 of local network slice NSI-1 113. In this way, the port 115a on the gateway node 115 of the local network slice NSI-1 113 may obtain data packets from UEs 101 with cross-region identifiers.

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

More specifically, in one embodiment, a first tunnel path is provided between port 103a of the first access point 103 and the first port 115a of the sub-gateway 115 of the local network slice NSI-1 113. 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-2 163. Furthermore, forwarding rules for forwarding data packets to UE1 101 and forwarding data packets from UE1 101 may be provided at the first access point 103, and forwarding rules for forwarding data packets to UE2 151 and forwarding data packets from UE2 151 may also be provided at the second access point 153.

In another embodiment, UE1 101 and UE2 151 may be assigned cross-slice identifiers (i.e., global identifiers). Embodiments of the present application may configure the first access point 103 based on the cross-slice identifier of UE1 101 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 the local network slice NSI-1 113, and configure the second access point 153 based on the global identifier of UE2 151 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 the remote network slice NSI-2 163.

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

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

More specifically, each of the plurality of local network slices 113 of the first core network 111 includes a sub-gateway 115 connected to the primary gateway 121 of the first core network 111, and each of the plurality of local network slices 163 of the second core network 161 includes a sub-gateway 165 connected to the primary gateway 171 of the second core network 161. In order 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, a first port 121a is provided at the primary gateway 121 of the first core network 111 and a first port 171a is provided at the primary gateway 171 of the second core network 161.

In addition, a tunnel path is provided 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 application may encapsulate and forward data packets to 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. 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 application also allow taking into account one or more service layer requirements between the first core network 111 and the second core network 161.

For the second case, the transmission network between two gateway nodes of two areas or two core networks is not fully administered by either of the two operators, as it involves multiple operators. Thus, either of the two operators may cooperate to establish a path, or may involve a third party operator in possession of the transport network. For the former case, the path setup request may be exchanged over an interface between management entities of two different operators, which request triggers port creation on gateway nodes on each side. SLA requirements across regional E2E network slices can also be exchanged thereafter so that each management entity can provision paths within its respective management domain. In the latter case, both operators will talk to possible third party operators. When the operator of the transport network receives a request and SLA requirements of the E2E network slice, both gateway nodes can be informed how new ports should be created and how to connect with the trans-regional tunnel paths offered by the operator of the transport network. This is shown in fig. 5.

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

However, the complete E2E path has not yet been completed because the gap between the gateway node of the NSI and the gateway node of the regional network infrastructure has not yet bridged (i.e., gw' through Gw in fig. 4-6). In addition, no performance monitoring loop was introduced.

In an embodiment, the gap between the gateway node of the NSI and the gateway node of the area network infrastructure may be bridged: the trans-regional traffic sent from the UE will 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 be aware of SLA requirements. Thus, similar to the case of a trans-regional gateway node, there is an interface between the two gateway nodes to exchange the necessary parameter data.

Referring to fig. 6, a specific procedure includes creating new ports and configuring forwarding rules on two gateway nodes (i.e., between a gateway node of an NSI and a gateway node of a regional network infrastructure). For the gateway node of the NSI a new port will be created as an interface/endpoint of the path to the gateway node of the area network. Correspondingly, another new port will also be created as an interface/endpoint 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, forwarding rules are to be 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-1 113 and the primary 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-2 163 and the primary gateway 171 of the second core network 161, embodiments of the present application may provide: a second port 115b at the sub-gateway 115 of the local network slice NSI-1 113 and a second port 121b at the primary gateway 121 of the first core network 111; and/or the remote network slices the second port 165b at the sub-gateway 165 of NSI-2 163 and the second port 171b at the primary gateway 171 of the second core network 161.

Further, in order to provide a first bridged communication path and/or a second bridged communication path, forwarding rules may be provided at the sub-gateway 115 of the local network slice NSI-1 113 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-1 113; and/or forwarding rules may also be provided 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-2 163.

Similarly, forwarding rules may be provided 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 and/or forwarding rules may also be provided at the primary gateway 171 of the second core network 161 for forwarding data packets between the first port 171a and the second port 171b of the primary 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 rules may direct the packet to the interface of the direct path to the new port created on the gateway node of the regional network. On the other hand, if the packet is received at a port created on the gateway node of the NSI, the forwarding rules 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 network nodes with the direct path between the trans-regional gateway nodes, forwarding rules 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 the cross-regional direct path, the forwarding rules may direct the packet to an interface/port of the path to the gateway node of the NSI.

Transregional E2E network slicing for UE nodes may not be static because E2E SLAs may be important. Thus, the performance of each direct path can 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 slicing peering in the communication network (especially the 5G core network). The local management entity also supplies the path according to the exchanged information.

Those skilled in the art will appreciate that the "blocks" ("units") in the various figures (methods and apparatus) represent or describe the functions of the embodiments of the application (and not necessarily a single "unit" in hardware or software) so as to describe equivalently the functions or features of the embodiments of the apparatus and method (units = steps).

In several embodiments provided by the present application, it should be understood that the disclosed systems, devices, and methods may be implemented in other ways. For example, the described apparatus embodiments are merely exemplary. For example, the cell division is merely a logical function division, and other divisions may be possible in actual implementations. For example, multiple units or components may be combined or integrated into another system, or certain features may be omitted or not performed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed may be implemented using some interfaces. The indirect coupling or communication connection between devices or units may be implemented in electronic, mechanical, or other forms.

The 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 may be selected according to actual needs to achieve the objectives of the embodiment.

In addition, functional units in embodiments of the application may be integrated into one processing unit, or each unit may physically reside in a single unit, or two or more units may be integrated into one unit.

Claims (17)

1. A communication method for a first core network (111), comprising:

A network entity 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), comprising:

The network entity allocates a cross-region identifier for a first UE (101), the cross-region identifier being a dedicated identifier, the cross-region identifier being different from an initial identifier obtained when the first UE (101) joins a local network slice (113), the first UE (101) being attached to a first access point (103) of the local network slice (113);

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

The network entity provides 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);

The network entity configures the first access point (103) based on the cross-zone identifier of the first UE (101) to encapsulate a data packet of the first UE (101) and forward the data packet to the first tunnel path, causing the first tunnel path to forward the data packet to the cross-slice communication path, the data packet carrying the cross-zone identifier.

2. A communication method according to claim 1, comprising:

The network entity obtaining data from the remote network slice (163) within the local network slice (113); and/or

The network entity provides data to the remote network slice (163) within the local network slice (113).

3. A communication method according to claim 2, comprising:

the network entity obtains 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

The network entity obtains data from a second UE (151) from the remote network slice (163) within the local network slice (113).

4. A communication method according to claim 3, characterized in that, in order to provide a first local communication path, the communication method comprises:

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

5. The communication method according to claim 4, wherein to provide the first local communication path, the communication method comprises:

The network entity provides forwarding rules at the first access point (103) for forwarding data packets to the first UE (101) and/or forwarding data packets from the first UE (101).

6. The communication method according to claim 5, comprising:

The network entity assigns a cross-slice identifier to the first UE (101).

7. The communication method according to claim 6, comprising:

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

8. The method according to claim 7, comprising:

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

9. The communication method according to claim 8, comprising:

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

10. A method of communicating according to claim 9, comprising:

the network entity considers one or more service layer requirements between the first core network (111) and the second core network (161).

11. The communication method according to claim 10, wherein the local network slice (113) comprises a sub-gateway (115) connected to a main gateway (121) of the first core network (111), the communication method comprising:

the network entity provides 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).

12. The communication method according to claim 11, characterized in that the first UE (101) is attached to a first access point (103) of the local network slice (113), and the communication method comprises:

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

13. The communication method according to claim 12, wherein to provide the first bridged communication path, the communication method comprises:

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

14. The communication method according to claim 13, wherein to provide the first bridged communication path, the communication method comprises:

the network entity provides forwarding rules at the primary gateway (121) of the first core network (111), the forwarding rules being used for forwarding data packets between the first port (121 a) and the second port (121 b) of the primary gateway (121) of the first core network (111).

15. The communication method according to any one of claims 1 to 14, characterized by comprising:

the network entity monitors performance of the local network slice (113).

16. A method of communicating according to claim 15, comprising:

The network entity adjusts the local network slice (113) in case the performance does not meet one or more service layer requirements.

17. A network entity, characterized in that it comprises means for performing the method of any of claims 1 to 16.