WO2023099011A1

WO2023099011A1 - Assigning a network slice to a tenant using tenant information

Info

Publication number: WO2023099011A1
Application number: PCT/EP2021/084170
Authority: WO
Inventors: Patrick Maguire; Mohammed Ziauddin MUJALE
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2021-12-03
Filing date: 2021-12-03
Publication date: 2023-06-08

Abstract

Methods and apparatuses for supporting network slice isolation in a public land mobile network are disclosed. According to an embodiment, a method in a network node is provided for supporting network slice isolation in a public land mobile network (PLMN), the method comprising: receiving a service request from a further network node, the service request comprising tenant information, wherein the tenant information is usable to assign a network slice to a tenant.

Description

ASSIGNING A NETWORK SLICE TO A TENANT USING TENANT INFORMATION

Technical Field

[0001] Embodiments of the disclosure generally relate to methods and apparatuses for network slicing, and, more particularly, to methods and apparatuses for supporting network slice isolation.

Background

[0002] This section introduces aspects that may facilitate better understanding of the present disclosure. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.

[0003] Network slicing is a key capability in 5G to support service isolation and service level agreement, SLA, assurance for various service types. In relation to radio access networks, RAN, many resource sharing scenarios will be supported. Fig. 1 illustrates some of those scenarios. In particular, Fig 1 illustrates Multi Operator RAN (MORAN) 102, Multi Operator Core Network (MOCN) 104 and Gateway Core Network (GWCN) 106. For MORAN 102, as is illustrated in this Figure, the Core Network (CN) 108, Radio Unit (RU) 110, Cell 112 and Public Land Mobile Network (PLMN) 114, have dedicated (non-shared) resources, whereas the Evolved Node B (eNB) 116 has shared resources. For MOCN 104, the CN 118 and PLMN 120 have dedicated resources, whereas the eNB 122, RU 124 and cell 126 each have shared resources, where the cell shares radio resources using slicing. For GWCN 106, the CN 128 and PLMN 130 have dedicated resources, whereas the MME 132, eNB 134, RU 136 and cell 138 each have shared resources. The Mobile Virtual Network Operator, MVNO, which is not illustrated here, uses similar configurations to those shown in Fig. 1.

[0004] As is evident from this Figure, MOCN achieves a higher sharing of the RAN resources, including sharing of the spectrum, compared to MORAN. With MOCN, two or more mobile operators (or enterprises owning spectrum) can pool their respective spectrum allocation and share them over the same RAN infrastructure. This enables the operators sharing the RAN to use the frequency bands owned by the other parties. [0005] It is currently a requirement that operators using MOCN align on the features and configurations applied at a cell level. Furthermore, if one operator uses a large share of the overall cell capacity, this may impact other operators sharing the RAN.

[0006] An RRP (Radio Resource Partitioning) feature can perform reservation of resources and overcome fairness issues to address these issues. The slicing of radio resources can be realized by means of the RRP feature. The RRP feature divides the available radio resources (i.e., the Physical Resource Blocks (PRBs)) on a cell-level into configurable partitions, which ensures an independent and fair sharing of resources. This feature allows for a timely and cost-efficient accommodation of new services over a shared RAN infrastructure. One pre-requisite is the existence of enough radio capacity. When using the RRP feature, the radio resources can be partitioned based on the Service Profile Identifier, SPID, index or the PLMN identifier (PLMN- ID). Different cells can be partitioned differently in terms of parameter (SPID, PLMN-ID) and partition size.

[0007] An RRP may have a static configuration ( i.e. can only use resources within an allocated limit) or may be dynamically configured ( i.e. if an RRP requires additional resources, and there are resources available in the cell which no other RRP requires at that time, the RRP may use them). When multiple partitions compete for the same resources, the system ensures that each partition does not exceed its share.

Summary

[0008] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0009] Tenancy isolation, where a tenant’s data is isolated so that it is not accessible to other tenants, may be required to ensure that the privacy of a tenant’s data is maintained. However, this may create complexities in how to share resources while maintaining tenancy isolation. A problem with existing solutions has been identified by the inventors of the present invention. From a tenancy isolation point of view, currently network sharing will be supported when a tenant is identified by its PLMN id. However, when network, NW, Slicing isolation is required within a PLMN the current solution does not present a way to bind the Service request (e.g. Service) to the correct NW Slice for a tenant. For example, when network slicing isolation is required for mobile virtual network operators, MVNOs, and enterprises in general, the current solution does not present a way to bind the Service request (e.g. Service) to the correct NW Slice.

[0010] Additionally, if tenant isolation is required in the network, at NW Slice deployment time, the Single Network Slice Selection Assistance Information S-NSSAI(s) may need to be associated to the correct RRM Policy. This is not possible unless the RRM policies are created at deployment time, which is unlikely from a radio network robustness point of view.

[0011] One of the objects of the disclosure is to provide an improved solution for network slicing.

[0012] According to an aspect of the disclosure, there is provided a method in a network node for supporting network slice isolation in a public land mobile network, PLMN. The method comprises receiving a service request from a further network node. The service request comprises tenant information. The tenant information is usable to assign a network slice to a tenant.

[0013] In this way, the network node receives tenant information which enables the network node to assign a network slice to a tenant. This is particularly advantageous when isolation of network slices is required in a PLMN.

[0014] According to a further aspect of the disclosure, there is provided a network node for supporting network slice isolation in a public land mobile network, PLMN. The network node comprises a processor and a memory, said memory containing instructions executable by said processor. The network node is operative to receive a service request from a further network node. The service request comprises tenant information. The tenant information is usable to assign a network slice to a tenant.

[0015] According to a further aspect of the disclosure, there is provided a computer readable storage medium comprising instructions which when executed by at least one processor, cause the at least one processor to perform the methods described herein. [0016] According to a further aspect of the disclosure, there is provided a computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out the methods described herein.

[0017] According to a further aspect of the disclosure, there is provided a network comprising the network node.

[0018] According to a further aspect of the disclosure, there is provided a network comprising preconfigured radio resource management, RRM, policies, wherein the preconfigured RRM policies comprise at least one of: an indication of resource sharing; a resource owner identifier which is an identifier of a tenant.

[0019] In this way, the network RRM policies comprise information that enables NW slice deployment when tenancy isolation is required in the network.

[0020] According to a further aspect of the disclosure, there is provided network comprising a service profile, wherein the service profile comprises tenancy information.

[0021] In this way, the network service policy comprises information that enables the service request to be mapped to a network slice when tenancy isolation is required in the network.

[0022] According to a further aspect of the disclosure, there is provided a network comprising a network slice profile, wherein the network slice profile comprises tenancy information.

[0023] In this way, the network slice profile comprises information that enables the service request to be mapped to a network slice when tenancy isolation is required in the network.

Brief Description of the Drawings

[0024] These and other objects, features and advantages of the disclosure will become apparent from the following detailed description of illustrative embodiments thereof, which are to be read in connection with the accompanying drawings.

[0025] FIG. 1 is a diagram illustrating resource sharing; [0026] FIG. 2 is a diagram illustrating the structure of an RRMPolicy Ratio;

[0027] FIG. 3 is a diagram illustrating the relationship between Services, NW Slices, RRP (RRM Policies) and the PLMN (PLMNid of the network);

[0028] FIG. 4 is a diagram illustrating a method in a network node according to an example;

[0029] FIG. 5 is a diagram illustrating a network node according to an example; and

[0030] FIG. 6 is a diagram illustrating a network node according to an example.

Detailed Description

[0031] For the purpose of explanation, details are set forth in the following description in order to provide a thorough understanding of the embodiments disclosed. It is apparent, however, to those skilled in the art that the embodiments may be implemented without these specific details or with an equivalent arrangement.

[0032] As used herein, network node refers to equipment capable, configured, arranged and/or operable to communicate directly or indirectly with a wireless device and/or with other network nodes or equipment in the wireless network to enable and/or provide wireless access to the wireless device and/or to perform other functions (e.g., administration) in the wireless network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs) and NR NodeBs (gNBs)). Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and may then also be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units and/or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS). Yet further examples of network nodes include multi- standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell/multicast coordination entities (MCEs), core network nodes (e.g., MSCs, MMEs), O&M nodes, OSS nodes, SON nodes, positioning nodes (e.g., E-SMLCs), and/or MDTs. As another example, a network node may be a virtual network node as described in more detail below. More generally, however, network nodes may represent any suitable device (or group of devices) capable, configured, arranged, and/or operable to enable and/or provide a wireless device with access to the wireless network or to provide some service to a wireless device that has accessed the wireless network.

[0033] The network may comprise and/or interface with any type of communication, telecommunication, data, cellular, and/or radio network or other similar type of system. In some embodiments, the network may be configured to operate according to specific standards or other types of predefined rules or procedures. Thus, particular embodiments of the wireless network may implement communication standards, such as Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE), and/or other suitable 2G, 3G, 4G, or 5G standards; wireless local area network (WLAN) standards, such as the IEEE 802.11 standards; and/or any other appropriate wireless communication standard, such as the Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave and/or ZigBee standards.

[0034] In 5G networks, service requirements are characterized by a Service Profile. The Service Profile represents the properties of network slice related requirements that should be supported by a Network Slice instance in a 5G network. Table 1 below illustrates an example of the attributes of a Service Profile, where “M” indicates “mandatory”, “O” indicates optional, “T” indicates “true” and “F” indicates “false”. The attributes of the Service Profile comprise pLMNInfoList.

Table 1: Service profile [0035] The service requirements, represented by the Service Profile, may be mapped to a network (NW) Slice instance, either through creation of a new NW slice or mapping to an existing one. A NW Slice is represented by a Service Profile. A new service request represented by a Service Profile is either mapped to a NW Slice which has the same Service profile, or a new NW Slice is created with the Service Profile. A NW Slice subnet is represented by a NW Slice Profile.. An example of the attributes included in a network Slice Profile is shown in Table 2, where “M” indicates “mandatory”, “CM” indicates “conditional mandatory”, “T” indicates “true” and “F” indicates “false”. As is illustrated in Table 2, the attributes of the Slice Profile also comprise pLMNInfoList.

Table 2: Slice Profile

[0036] The pLMNInfoList provides a mapping between the service requirement and the targeted radio infrastructure which may be used to realize the requirement. Multiple PLMNs may be used to fulfill the service requirement and the NW Slice requirement.

[0037] Table 3 outlines the definitions of the pLMNNInfoList in the Service profile and the Slice profile according to the current standard (3GPP TS 28.541, V17.3.0).

Table 3: Definitions of pLMNNInfoList in Service Profile and Slice Profile

[0038] Radio Resource Management policy (RRMPolicy) is currently being standardized as outlined in 3GPP TS 28.541, V 17.3.0. RRMPolicy defines two attributes apart from those inherited from Top level Information Object Class (TOP IOC), the resource type and RRM policy member list. The resourceType attribute defines a type of resource (Physical Resource Block (PRB), RRC (Radio Resource Control) connected users, Dedicated Radio Bearer (DRB) usage etc.) and the rRMPolicyMemberList attribute defines the RRMPolicyMember(s) that is subject to this policy. An RRM resource (defined in resourceType attribute) may be located in NRCellDU, NRCellCU, GNBDUFunction, GNBCUCPFunction or in GNBCUUPFunction. The RRMPolicyRatio IOC is one realization of a RRMPolicy IOC. The RRM policy is illustrated in Table 4 below, where “M” indicates “mandatory”, “T” indicates “true” and “F” indicates “false”.

Table 4: RRM Policy

[0039] It is possible to add new policies to this RRM framework, both standardized or as vendor specific, for example by inheriting from the abstract RRMPolicy_ IOC.

[0040] The RRMPolicyMember represents an RRM Policy member that will be part of a rRMPolicyMemberList. A RRMPolicyMember is defined by its pLMNId and sNSSAI (S- NSSAI). The members in a rRMPolicyMemberList is assigned a specific amount of RRM resources based on settings in RRMPolicy. An example of the attributes of an RRM policy member are illustrated in Table 5 below.

Table 5: RRM policy member

[0041] RRMPolicyRatio is one realization of abstract RRMPolicy_ IOC. RRMPolicyRatio has three attributes, apart from those inherited (Data Network (DN), resourceType, rRMPolicyMemberList). Fig. 2 taken from 3GPP TS 28.541 V16.5.0 (2020-06) illustrates the structure of the RRMPolicyRatio. As is illustrated in this Figure, the RRMPolicyRatio comprises attributes of rRMPolicyMaxRatio 240, rRMPolicyMinRatio 242, and rRMPolicyDedicatedRatio 244, and resource categories of shared resources 246, prioritized resources 248, and dedicated resources 250.

[0042] The following are the definitions for the above mentioned three attributes outlined in 3 GPP TS 28.541 V16.5.0 (2020-06):

The attribute rRMPolicyMaxRatio defines the maximum resource usage quota for the associated rRMPolicyMemberList, including at least one of shared resources, prioritized resources and dedicated resources. The sum of the ‘rRMPolicyMaxRatio’ values assigned to all RRMPolicyRatio(s) name-contained by the same MangedEntity (e.g. DRB, Dedicated Radio Bearer ( i.e. a resource type)) can be greater than 100.

The attribute rRMPolicyMinRatio defines the minimum resource usage quota for the associated RRMPolicyMemberList, including at least one of prioritized resources and dedicated resources, which means the resources quota that need to be guaranteed for use by the associated rRMPolicyMemberList. The sum of the ‘rRMPolicyMinRatio’ values assigned to all RRMPolicyRatio(s) name-contained by the same MangedEntity may be less than or equal to 100.

The attribute rRMPolicyDedicatedRatio defines the dedicated resource usage quota for the RRMPolicyMemberList, including dedicated resources. The sum of the ‘rRMPolicyDedicatedRatio’ values assigned to all RRMPolicyRatio(s) name- contained by same MangedEntity may be less than or equal to 100.

[0043] Table 6 below outlines the three attributes of the RRMPolicy Ratio, where “M” indicates “mandatory”, “O” indicates “optional”, “T” indicates “true” and “F” indicates “false”.

Table 6: RRMPolicy Ratio [0044] The following are the definitions for the above mentioned three resource categories outlined in 3GPP TS 28.541 V16.5.0 (2020-06):

Shared resources are the resources that are shared with other rRMPolicyMemberList(s) (i.e. the rRMPolicyMemberList(s) defined in RRMPolicyRatio(s) name-contained by the same ManagedEntity). The shared resources are not guaranteed for use by the associated rRMPolicyMemberList. The shared resources quota is represented by [rRMPolicyMaxRatio-rRMPolicyMinRatio]. Priortized resources are the resources preferentially used by the associated RRMPolicyMemberList. These resources are guaranteed for use by the associated RRMPolicyMemberList when the RRMPolicyMemberList needs to use them. When not used, these resources may be used by other rRMPolicyMemberList(s) (i.e. the rRMPolicyMemberList(s) defined in RRMPolicyRatio(s) name-contained by the same ManagedEntity). The prioritized resources quota is represented by [rRMPolicyMinRatio-rRMPolicyDedicatedRatio].

Dedicated resources are the resources dedicated for use by the associated RRMPolicyMemberList. These resources cannot be shared even if the associated RRMPolicyMember does not use them. The Dedicated resources quota is represented by [rRMPolicyDedicatedRatio].

[0045] Thus, the resources may be shared by members on the rRMPolicyMemberList(s). The resources shown in Figure 2 may be reserved or allocated for user and bearer related requests, e.g. a user connection, a PDU session, etc., if the user is entitled to use the allocated resources according the ratios defined above.

[0046] As the standard referenced above outlines, an RRM Policy can support many NW Slices across many PLMNs.

[0047] Fig. 3 illustrates the relationship between Services 370, NW Slices 372, RRP (RRM Policies) 374 and the PLMN (PLMNid of the network) 376. In particular, Fig. 3 illustrates that a service may be connected to a number (n) of PLMNs, and a number (n) of Services may be connected to a NW Slice. A NW slice may be connected to a number (n) of services and a number (n) of PLMNs. A number (n) of NW Slices may be connected to an RRP. An RRP may be connected to a number (n) of NW Slices and a number (n) of PLMNs. A number (n) of PLMNs may be connected to a Service, a NW Slice and an RRP may be connected to each of the service, the NW slice, and the RRP. Although Fig. 3 indicates the number as n, in practical implementations the number of the various instances indicated by n may be different than n.

[0048] RRM Policies may be preconfigured across the available PLMNs for various traffic types and at NW Slice deployment time, where each NW Slice is associated with the appropriate RRM Policy based on the PLMNInfoList and 5Qi (5G Quality of Service, QoS, Identifier) data provided in the Service and NW Slice input requirements.

[0049] It has been noted by the inventors of the present invention that a problem with the existing solution is that, from a tenancy isolation point of view, network sharing is supported when a tenant is identified by its PLMN id. However, when network sharing to support NW Slicing isolation is required within a PLMN, for example, support for MVNO’s and enterprises in general, the current solution does not present a way to bind the Service request (Service) to the correct NW Slice.

[0050] Additionally, if tenant isolation is required in the network, at NW Slice deployment time, the slice information, e.g. S-NSSAI(s), may need to be associated to the correct RRM Policy. This is currently not possible unless the RRM policies are created at deployment time which is unlikely, from a radio network robustness point of view.

[0051] In an example, there is provided a method in a network node for supporting network slice isolation in a public land mobile network, PLMN, the method comprising, in a first step, receiving a service request from a further network node, e.g. a node of a Business Support System (BSS), the service request comprising tenant information, wherein the tenant information is usable to assign a network slice to a tenant. This method is illustrated in Fig. 4.

[0052] In particular, Fig. 4 illustrates, in a first step 460, receiving a service request from a further network node, the service request comprising tenant information. The method may further comprise, in a second step 462, determining based on the received tenant information whether the service request corresponds to an existing network slice. Where it is determined that the service request corresponds to an existing network slice (YES), the method may further comprise a step 464 of assigning an existing network slice to the tenant based on the tenant information. Where it is determined that the service request does not correspond to an existing slice (NO), the method may further comprise a step 466 of creating a new network slice based on the tenant information. The method may then comprise a further step 468 of associating network slice information corresponding to the new network slice with preconfigured radio resource management, RRM, policies based on the tenant information. The outcome of the operation in step 468 is that the new network slice is assigned to the tenant based on the tenant information.

[0053] Thus, the network node receives tenant information which enables the network node to assign a network slice to a tenant. This is particularly advantageous when isolation of network slices is required in a PLMN.

[0054] The tenant information may comprise at least one of: a tenant name; a tenant identifier. The tenant name may be, for example, a string, such as the name of the tenant, or a name related to the tenant, and the tenant identifier may be, for example, a number that identifies the tenant. An advantage of using a tenant identifier is that the tenant may be anonymised. The method may be performed by a Management node as the network node. The method may be performed by an end to end, E2E, orchestrator. For example, the network node may be an E2E orchestrator.

[0055] While in the examples herein relate to RAN, it will be appreciated that the examples described herein may be applicable to any appropriate network, such as the Transport network or the CORE network.

[0056] The method may further comprise determining based on the received tenant information whether the service request corresponds to an existing network slice, or a new network slice is to be created. For example, the incoming service request may be fulfilled by an existing deployed NW Slice, for example, one which the tenant owns. Where there does not exist a network slice suitable for a tenant, a new slice may be created. It may be determined based on the received tenant information whether the service request corresponds to an existing network slice belonging to a tenant. The new network slice to be created may be for the service request and a tenant corresponding to the tenant information. The method may further comprise creating the new network slice if it is determined that a new network slice is to be created.

[0057] The orchestration of the new NW Slice and the decision making on whether one is required or not may be performed at the same node (e.g. a Management node, Service Orchestrator, E2E orchestrator). The NW Slice itself which is created in the network by this Management node (Service Orchestrator) may result in the deployment of new network nodes in the network as well as the reconfiguration of existing network nodes.

[0058] If a new network slice is to be created and tenancy isolation is required in the network, the method may further comprise associating network slice information corresponding to the new network slice with preconfigured radio resource management, RRM, policies based on the tenant information. The association may be further based on at least one of: a public land mobile network identifier, PLMNid; traffic characteristic requirements; a tenant identifier. The traffic characteristic requirements may further comprise at last one of: a quality of service, QoS, identifier, and a priority level of the service request, or the traffic priority level. The network slice information may comprise single network slice selection assistance information, S-NSSAI.

[0059] The preconfigured RRM policies may comprise at least one of an indication of resource sharing, and a resource owner identifier which is an identifier of a tenant. The preconfigured RRM policies may be preconfigured based on at least one of: supported public land mobile networks, PLMNs, a supported set of traffic characteristics.

[0060] A network may be provided comprising preconfigured radio resource management, RRM, policies, wherein the preconfigured RRM policies comprise at least one of: an indication of resource sharing; a resource owner identifier which is an identifier of a tenant. The resource owner identifier may correspond to a tenant identifier. For example, RRM policies may be preconfigured in the network with Resource Owner ID (e.g., tenant information). Then subsequently, when a Service request is received by the E2E Orchestrator with specified Tenant information, the E2E Orchestrator may map aspects of the service requirements to the associated preconfigured RRM Policy for the tenant.

[0061] The resource owner identifier may be the same as the tenant identifier or may be different to the tenant identifier. The resource owner identifier and the tenant identifier may be used to identify the same tenant. For example, a resource owner in the network may be a representation of the Tenant in the management/orchestration domain but may not use same string or number to identify the tenant, e.g. Tenant_Id = 12345, ResourceOwner_Id = 12345ABCD for the same tenant.

[0062] A network node may be configured to perform the methods as described herein. The network node may be comprised in a network. The network may comprise a service profile, wherein the service profile comprises tenancy information. The service profile may be usable to map a service request to an existing network slice belonging to a tenant or determine that a new network slice is to be created for the service request and the tenant. The network may comprise a network slice profile, wherein the network slice profile comprises tenancy information.

[0063] Thus, according to an example, the current 3GPP standard may be extended to include Tenancy information in the Service Profile and NW (network) Slice Profile to address isolation in MVNO and Enterprise scenarios. This may support the mapping of tenant service offerings to the correct NW Slice(s).

[0064] In an example, to address tenant isolation in the RAN network for MVNO and Enterprise scenarios, the RRMPolicyMember may be extended to include an indication of resource sharing (resourcesharingindicator [YES/NO]) and a resource owner identifier (resourceownerld). The preconfigured RRM policies may therefore be extended with an indication of resource sharing (resourcesharingindicator [YES/NO]) where NO implies tenancy isolation, and with a resource owner ID resourceownerld ( tenant ID ) to support tenancy isolation in the network. RRMPolicies may also be preconfigured based on supported PLMNs and a supported set of traffic characteristics.

[0065] When a service request is received by a network node, such as the E2E Orchestrator ( see, for example, TMF 641, 3GPP TS 28.531 which provides an example of an interface specification which the received Service Request may be in compliance with), the request may include at least one of a tenant name and a tenant identifier (Tenant Name, Tenant Id). This information, in addition to the service requirements (e.g. the Service Profile) may be used to map the service request to an existing NW Slice, belonging to the Tenant, or a new NW Slice may be created specifically for this service request and tenant.

[0066] The orchestration of the new NW Slice and the decision making on whether one is required or not may be performed in the same node (e.g. the Service Orchestrator). The NW Slice itself which is created in the network by this network node (e.g. a management node, the Service Orchestrator) may result in the deployment of new network nodes in the network as well as the reconfiguration of existing network nodes. [0067] If a new NW Slice is to be deployed and isolation is required in the RAN network then the associated slice information, e.g., S-NSSAI, may be associated with the correct preconfigured RRM Policies, based on provided PLMNid(s), Traffic characteristic requirements ( e.g. 5Qi & Priority Level) and a Tenant identifier.

[0068] Thus, tenancy support in the E2E Orchestration system ensures that incoming service requests are mapped to the correct NW Slice in an automated manner. Furthermore, tenant isolation in the RAN network is supported in an automated manner at a time of NW Slice deployment.

[0069] As illustrated in Fig. 5, in aspects of embodiments the network node 512 comprises network node processing circuitry (or logic) 548 (the second network node can be configured in the same way as the network node). The processing circuitry 548 controls the operation of the network node 512 and can implement the method described herein in respect of the network node 512. The processing circuitry 548 can be configured or programmed to control the network node 512 in the manner described herein. The processing circuitry 548 can comprise one or more hardware components, such as one or more processors, one or more processing units, one or more multi-core processors and/or one or more modules. In particular implementations, each of the one or more hardware components can be configured to perform, or is for performing, individual or multiple steps of the method described herein in respect of the network node 512. In some embodiments, the processing circuitry 548 can be configured to run software to perform the method described herein in respect of the network node 512. The software may be containerised according to some embodiments. Thus, in some embodiments, the processing circuitry 548 may be configured to run a container to perform the method described herein in respect of the network node 512.

[0070] Briefly, the processing circuitry 548 of the network node 512 is configured to receive a service request from a further network node, the service request comprising tenant information, wherein the tenant information is usable to assign a network slice to a tenant.

[0071] As illustrated in Fig. 5, in some embodiments, the network node 512 comprises a network node memory 550. The memory 550 of the network node 512 can comprise a volatile memory or a non-volatile memory. In some embodiments, the memory 550 of the network node 512 may comprise a non-transitory media. Examples of the memory 550 of the network node 512 include, but are not limited to, a random access memory (RAM), a read only memory (ROM), a mass storage media such as a hard disk, a removable storage media such as a compact disk (CD) or a digital video disk (DVD), and/or any other memory.

[0072] The processing circuitry 548 of the network node 512 can be connected to the memory 550 of the network node 512. In some embodiments, the memory 550 of the network node 512 may be for storing program code or instructions which, when executed by the processing circuitry 548 of the network node 512, cause the network node 512 to operate in the manner described herein in respect of the network node 512. For example, in some embodiments, the memory 550 of the network node 512 may be configured to store program code or instructions that can be executed by the processing circuitry 548 of the network node 512 to cause the network node 512 to operate in accordance with the method described herein in respect of the network node 512. Alternatively or in addition, the memory 550 of the network node 512 can be configured to store any information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. The processing circuitry 548 of the network node 512 may be configured to control the memory 550 of the network node 512 to store information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein.

[0073] In some embodiments, as illustrated in Fig. 5, the network node 512 may comprise a network node communications interface 552. The communications interface 552 of the network node 512 can be connected to the processing circuitry 548 of the network node 512 and/or the memory 550 of network node 512. The communications interface 552 of the network node 512 may be operable to allow the processing circuitry 548 of the network node 512 to communicate with the memory 550 of the network node 512 and/or vice versa. Similarly, the communications interface 552 of the network node 512 may be operable to allow the processing circuitry 548 of the network node 512 to communicate with another network node or the network. The communications interface 552 of the network node 512 can be configured to transmit and/or receive information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. In some embodiments, the processing circuitry 548 of the network node 512 may be configured to control the communications interface 552 of the network node 512 to transmit and/or receive information, data, messages, requests, responses, indications, notifications, signals, or similar, that are described herein. The communications interface 552 of the network node may be configured to communicate with another network node or the network.

[0074] Although the network node 512 is illustrated in Fig. 5 as comprising a single memory 550, it will be appreciated that the network node 512 may comprise at least one memory (i.e. a single memory or a plurality of memories) 34 that operate in the manner described herein. Similarly, although the network node 512 is illustrated in Fig. 5 as comprising a single communications interface 552, it will be appreciated that the network node 512 may comprise at least one communications interface (i.e. a single communications interface or a plurality of communications interface) 36 that operate in the manner described herein. It will also be appreciated that Fig. 5 only shows the components required to illustrate an embodiment of the network node 512 and, in practical implementations, the network node 512 may comprise additional or alternative components to those shown.

[0075] Fig. 6 illustrates a network node 612 according to an embodiment, the network node 612 comprising a receiving unit 654 configured to receive a service request from a further network node, the service request comprising tenant information, wherein the tenant information is usable to assign a network slice to a tenant. The network node further comprises a determining unit 656 configured to determine based on the received tenant information whether the service request corresponds to an existing network slice. The network node may further comprise an assigning unit 658, a creating unit 660, and an associating unit 662. Where it is determined that the service request corresponds to an existing network slice (YES), the assigning unit may assign an existing network slice to the tenant based on the tenant information. Where it is determined that the service request does not correspond to an existing slice (NO), the creating unit may be configured to create a new network slice based on the tenant information. The associating unit may be configured to associate network slice information corresponding to the new network slice with preconfigured radio resource management, RRM, policies based on the tenant information.

[0076] In general, the various exemplary embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the disclosure is not limited thereto. While various aspects of the exemplary embodiments of this disclosure may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

[0077] As such, it should be appreciated that at least some aspects of the exemplary embodiments of the disclosure may be practiced in various components such as integrated circuit chips and modules. It should thus be appreciated that the exemplary embodiments of this disclosure may be realized in an apparatus that is embodied as an integrated circuit, where the integrated circuit may comprise circuitry (as well as possibly firmware) for embodying at least one or more of a data processor, a digital signal processor, baseband circuitry and radio frequency circuitry that are configurable so as to operate in accordance with the exemplary embodiments of this disclosure.

[0078] It should be appreciated that at least some aspects of the exemplary embodiments of the disclosure may be embodied in computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device. The computer executable instructions may be stored on a computer readable medium such as a hard disk, optical disk, removable storage media, solid state memory, RAM, etc. As will be appreciated by one of skill in the art, the function of the program modules may be combined or distributed as desired in various embodiments. In addition, the function may be embodied in whole or in part in firmware or hardware equivalents such as integrated circuits, field programmable gate arrays (FPGA), and the like.

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

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

[0081] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the present disclosure. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises”, “comprising”, “has”, “having”, “includes” and/or “including”, when used herein, specify the presence of stated features, elements, and/or components, but do not preclude the presence or addition of one or more other features, elements, components and/ or combinations thereof. The terms “connect”, “connects”, “connecting” and/or “connected” used herein cover the direct and/or indirect connection between two elements.

[0082] The present disclosure includes any novel feature or combination of features disclosed herein either explicitly or any generalization thereof. Various modifications and adaptations to the foregoing exemplary embodiments of this disclosure may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings. However, any and all modifications will still fall within the scope of the non-Limiting and exemplary embodiments of this disclosure.

Claims

1. A method in a network node for supporting network slice isolation in a public land mobile network, PLMN, the method comprising: receiving (460) a service request from a further network node, the service request comprising tenant information, wherein the tenant information is usable to assign (464, 468) a network slice to a tenant.

2. The method as claimed in claim 1, wherein the tenant information comprises at least one of: a tenant name; a tenant identifier.

3. The method as claimed in any preceding claim, the method further comprising determining (462) based on the received tenant information whether: the service request corresponds to an existing network slice; or a new network slice is to be created.

4. The method as claimed in claim 3, wherein it is determined (462) based on the received tenant information whether the service request corresponds to an existing network slice belonging to a tenant.

5. The method as claimed in claim 3 or 4, wherein the new network slice to be created is for the service request and a tenant corresponding to the tenant information.

6. The method as claimed in any of claims 3 to 5, wherein the method further comprises creating (466) the new network slice if it is determined (462-no) that a new network slice is to be created.

7. The method as claimed in any of claims 3 to 6, wherein if a new network slice is to be created and tenancy isolation is required in the network, the method further comprises associating (468) network slice information corresponding to the new network slice with

22 preconfigured radio resource management, RRM, policies based on the tenant information. The method as claimed in claim 7, wherein the association is further based on at least one of: a public land mobile network identifier, PLMNid; traffic characteristic requirements; a tenant identifier. The method as claimed in any of claim 7 or 8, wherein the preconfigured RRM policies comprise at least one of: an indication of resource sharing; a resource owner identifier which is an identifier of a tenant. The method as claimed in any preceding claim, wherein the method is performed by an end to end, E2E, orchestrator. A network node (512, 612) for supporting network slice isolation in a public land mobile network, PLMN, the network node (512, 612) comprising: a processor; and a memory (550), said memory (550) containing instructions executable by said processor, whereby said network node (512, 612) is operative to: receive a service request from a further network node (512, 612), the service request comprising tenant information, wherein the tenant information is usable to assign a network slice to a tenant. The network node (512, 612) as claimed in claim 11, wherein the tenant information comprises at least one of: a tenant name; a tenant identifier. The network node (512, 612) as claimed in claim 11 or 12, the network node (512, 612) being further operative to determine based on the received tenant information whether: the service request corresponds to an existing network slice; or a new network slice is to be created. The network node (512, 612) as claimed in claim 13, wherein it is determined based on the received tenant information whether the service request corresponds to an existing network slice belonging to a tenant. The network node (512, 612) as claimed in claim 13 or 14, wherein the new network slice to be created is for the service request and a tenant corresponding to the tenant information. The network node (512, 612) as claimed in any of claims 13 to 15, wherein the network node (512, 612) is further operable to create the new network slice if it is determined that a new network slice is to be created. The network node (512, 612) as claimed in any of claims 13 to 16, wherein if a new network slice is to be created and tenancy isolation is required in the network, the network node (512, 612) is further operable to associate network slice information corresponding to the new network slice with preconfigured radio resource management, RRM, policies based on the tenant information. The network node (512, 612) as claimed in claim 17, wherein the association is further based on at least one of: a public land mobile network identifier, PLMNid; traffic characteristic requirements; a tenant identifier. The network node (512, 612) as claimed in any of claim 17 or 18, wherein the preconfigured RRM policies comprise at least one of: an indication of resource sharing; a resource owner identifier which is an identifier of a tenant. The network node (512, 612) as claimed in any of claims 13 to 19, wherein the network node (512, 612) is further operable to create tenant information. The network node (512, 612) as claimed in any of claims 11 to 20, wherein the network node (512, 612) is an end to end, E2E, orchestrator. A computer readable storage medium comprising instructions which when executed by at least one processor, cause the at least one processor to perform the method according to any of claims 1 to 10. A computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of any of claims 1 to 10. A network comprising the network node (512, 612) as claimed in any of claims 11 to 21. A network comprising preconfigured radio resource management, RRM, policies, wherein the preconfigured RRM policies comprise at least one of: an indication of resource sharing; a resource owner identifier which is an identifier of a tenant. The network as claimed in claim 25, wherein the resource owner identifier corresponds to a tenant identifier. A network comprising a service profile, wherein the service profile comprises tenancy information. The network as claimed in claim 27, wherein the service profile is usable to map a service request to an existing network slice belonging to a tenant or determine that a new network slice is to be created for the service request and the tenant. A network comprising a network slice profile, wherein the network slice profile comprises tenancy information.

25