Radio access network node and method

Abstract

To provide a communication system in which a communication device constitutes part of the communication system.SOLUTION: A mobile telecommunications system 1 supports a network slice and allows at least one tenant to communicate using at least one slice type associated with the tenant. Communication devices 3-1 to 3-3 receive network slicing-related information from a base station 5-2. The network slicing-related information includes information identifying support for tenants whose communication is supported via the base station and at least one communication parameter associated with a particular tenant or a slice type of the particular tenant. The communication device uses a slice having the slice type of the tenant with which the communication device is associated based on the network slicing-related information.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates to radio access networks in cellular or wireless communication networks, particularly but not exclusively to sharing radio access networks between multiple operators. The present invention relates particularly but not exclusively to wireless telecommunications networks implemented according to various standards defined by the 3rd Generation Partnership Project (3GPP). The present invention relates, for example, to Long Term Evolution (LTE) networks, LTE-Advanced (LTE-A) networks, enhancements and developments related to LTE / LTE-A, and developments beyond LTE / LTE-A to more recent so-called "5G" or "New Radio (NR)" technologies. [Background technology]

[0002] Radio Access Network (RAN) sharing deployment scenarios are known, and methods and capabilities to facilitate the implementation of these scenarios have been introduced in 3GPP (3rd Generation Partnership Project) standards from Release 5 onwards.

[0003] Traditionally, RAN sharing provides a way for network operators (service providers) to reduce their capital expenditure requirements when setting up wireless communication networks and / or to expand the areas covered by cellular communication services. Rather than each operator having to provide its own base stations and associated equipment for each cell of the network, an operator can share another operator's RAN and provide service to areas served by other operators without having to invest in its own base stations.

[0004] Furthermore, by reducing the number of base stations that they must provide and operate, operators in a shared relationship can reduce their ongoing operational costs: in fact, each base station may utilize a large amount of power during operation, therefore reducing the number of base stations in operation can significantly reduce power requirements and therefore may also be considered more environmentally friendly.

[0005] Typically, operator RAN sharing involves fixed, long-term contracts where each operator obtains access to the other operator's RAN. RAN sharing is particularly advantageous in areas where operators have underutilized cellular capacity, because this capacity can be shared without affecting the ongoing service provision of the original operator. Furthermore, RAN sharing may be useful to ensure that the services offered by the operators can reach a certain percentage of the population, specified by the license conditions in a particular country, without requiring each operator to provide expensive capacity in remote locations where capacity is likely to be underutilized.

[0006] The terms "5G" and "New Radio (NR)" refer to evolving communications technologies that are expected to support a variety of applications and services, such as Machine Type Communications (MTC), Internet of Things (IoT) communications, vehicular communications and autonomous vehicles, high definition video streaming, and smart city services. 5G / NR technologies are therefore expected to enable network access to vertical markets and support network (RAN) sharing to provide network services to third parties and create new business opportunities. Although base stations in 5G / NR communications systems are typically referred to as New Radio Base Stations (NR-BSs) or "gNBs," they may also be referred to using the term eNB (or 5G / NReNB), which is typically associated with LTE base stations.

[0007] Recently, it has been proposed to split the functions of a gNB (herein referred to as a "distributed" gNB) between one or more distributed units (DUs) and a central unit (CU), where the CU typically performs high level functions and communication with the next generation core, and the DU typically performs low level functions and communication over the air interface with nearby user equipment (UE) (i.e. in the cell operated by the gNB).

[0008] To support such diverse applications and services, mobile network operators need to satisfy the diverse and often conflicting requirements of these applications and handle large amounts of data traffic. For example, some of these applications have relatively loose QoS / QoE (Quality of Service / Quality of Experience) requirements, while some other applications have relatively strict QoS / QoE requirements (e.g., high bandwidth and / or low latency).

[0009] Deploying a dedicated network infrastructure for each type of service or application is expensive and impractical. Therefore, network virtualization and "network slicing" are considered as a flexible and cost-effective way to support and accommodate heterogeneous applications with diverse requirements on a common network infrastructure. Such network slicing is described, for example, in the "NGMN 5G White Paper" V1.0 by the NGMN (Next Generation Mobile Networks) agreement, available at https: / / www.ngmn.org / 5g-white-paper.html. In fact, a network slice is a logical network, usually for a specific Service Level Agreement (SLA) for a specific tenant. A tenant of a network (e.g., a Public Land Mobile Network (PLMN)) is a wholesale customer of the network. For example, a tenant may be a large enterprise or an intermediary that requires the PLMN to provide access to a predefined set of resources or a specific policy in handling sliced ​​subscribers during congestion. An example of a tenant is a public safety agency. A tenant may have application specific requirements. For example, in an enterprise deployment, the enterprise may have a set of equipment in the field and equipment that is not related to the field operation. The enterprise may have a policy to allocate at least 60% of the resources (whether in the RAN or in the core) to the field operation during congestion, but not to segregate the resources all the time.

[0010] More specifically, a network slice (e.g., a "5G slice") may support a communication service of a particular connection type using a particular way of handling the control plane and user plane for that service. In practice, a slice may include multiple network functions and a particular radio access technology (RAT) configuration that are combined for a particular use case, technology, and / or business model. Not all slices need to include the same functions, and one or more slices may lack functions that are considered important today. In essence, a slice provides only the traffic processing required for a given use case, thereby avoiding other unnecessary functions.

[0011] As an example, multiple slices operating simultaneously on the same infrastructure may include a slice for a typical smartphone, configured by setting up full-fledged smartphone-specific functionality distributed over the network. A slice may be provided to support an automotive use case, where security, reliability, and latency are critical and all necessary (and potentially specialized) functionality can be instantiated at the cloud edge nodes, including virtual applications that are required as a result of latency constraints. Other slices supporting large-scale machine-type (IoT) devices (e.g., sensors) may have basic control plane functionality configured, for example omitting any mobility functionality, with contention-based resources for access. There may be other specialized slices operating in parallel, as well as potentially generic slices providing basic best-effort connectivity to address unknown use cases and traffic.

[0012] It is currently believed that a number of key principles will need to be applied for the support of network slicing in the RAN. First, for example, the RAN will need to be slice aware. In particular, the RAN will support different treatment of different network slices pre-configured by the operator. The RAN will also likely support selection of the RAN part of the network slice by an identifier such as a "slice ID" provided by the user equipment (UE) that clearly identifies one of the network slices pre-configured in the public land mobile network (PLMN). Similarly, the RAN will likely support resource management between slices (e.g., enforcement of inter-slice policies via service level agreements), QoS differentiation within slices, and / or resource isolation between slices. The RAN will also likely support RAN selection of a Core Network (CN) entity for initial routing of uplink messages, for example, based on the received slice ID and a mapping in the RAN node (CN entity, supported slice). If no slice ID is received, the RAN may select a CN entity based on a function such as the Non Access Stratum (NAS) Node Selection Function (NNSF), for example, based on a temporary ID of the UE. Summary of the Invention [Problem to be solved by the invention]

[0013] However, currently, there is no consistent view or decision on a number of important issues. For example, currently, there is no firm view on whether some basic slices will be standardized together with their corresponding network features (e.g., enhanced Mobile Broadband (eMBB), massive machine-type communication (MTC), etc.). Similarly, it is not clear how the UE obtains an unambiguous slice ID. For example, the ID may be sent to the UE by the CN after the CN selects a slice (e.g., similar to the enhanced dedicated core (eDECOR) feature), or may be preconfigured in the UE. Also, it is unclear whether resource separation means that multiple slices cannot share control plane (respective user plane) resources or common processing resources, and / or whether resource separation should implement some form of cryptographic function to separate control plane (CP) and user plane (UP) traffic between slices.

[0014] Furthermore, there are several RAN specific issues that need to be addressed, such as: how does the RAN verify that a particular UE is authorized to select a slice and when does this verification occur; whether the RAN may also select a slice based on the particular resources accessed by the UE; whether the RAN, or some other entity or group of entities, handles requirements arising from service level agreements; and whether the RAN should additionally support QoS enforcement independently on a per slice basis.

[0015] There are many other issues that have not yet been considered or recognized and that need to be addressed to provide a functional slicing mechanism.

[0016] It is believed, therefore, that there are a number of issues that need to be addressed for significant progress to be made towards providing a fully functional and efficient slicing mechanism.

[0017] The present invention aims to provide an apparatus, and associated methods, that will at least partially address one or more of these problems, thereby contributing to the provision of a practical slicing mechanism.

[0018] Despite these recognized problems, the inventors have discovered that progress toward a practical slicing mechanism can be made by addressing several issues that have not yet been considered. [Means for solving the problem]

[0019] Accordingly, to provide such a mechanism, the example methods and apparatus described herein are intended to address, and contribute at least in part to, one or more of the following: -Allowing a particular UE to know as early as cell (re)selection whether allowed tenant IDs and / or slice types are supported in a candidate cell. Different prioritization of tenants (identified by tenant IDs) and / or slice types during the initial random access channel (RACH) access procedure. - Handling mobility in the context of network slicing, e.g. determining the resource situation at neighboring gNBs, identifying suitable targets and preparing them for handover procedures; determining whether a potential target is overloaded for a given tenant ID and / or slice type. -Handling overload situations of tenants and / or slices in a gNB. - Providing tenant usage specific functionality such as obtaining usage measurements (e.g., per tenant ID, per slice type, per radio access technology (RAT), per frequency, per technology, and / or per uplink / downlink (UL / DL)) and billing (per slice type); and -Enabling slice type-based dynamic configuration of functional division between CU and DU of a distributed gNB.

[0020] In one aspect, a communication device for a communication system in which network slicing is supported and at least one tenant can communicate using at least one slice type associated with the tenant is provided, the communication device comprising a controller and a transceiver, the transceiver configured to receive network slicing related information transmitted by a base station, the network slicing related information including at least one of: (i) information identifying a tenant whose communication is supported via the base station and support for at least one of the tenant's network slice types supported by the base station, and (ii) information including at least one communication parameter associated with the particular tenant and at least one of the particular slice types of the particular tenant, and the controller configured to control, via the transceiver, communication using a slice having a slice type of a tenant with which the communication device is associated based on information provided in the received network slicing related information, particularly related to the tenant with which the communication device is associated and at least one of the slice types of the tenant with which the communication device is associated.

[0021] In another aspect, a base station for a communication system in which network slicing is supported and at least one tenant can communicate using at least one slice type associated with the tenant is provided, the base station comprising a controller and a transceiver, the controller configured to generate network slicing related information for transmission by the transceiver, the network slicing related information for transmission including at least one of: (i) information identifying support for at least one of the tenants whose communications are supported via the base station and the network slice types of the tenants supported by the base station, (ii) information including at least one communication parameter associated with the particular tenant and at least one of the particular slice types of the particular tenant, and the transceiver operable to transmit the network slicing related information generated by the controller to at least one of other base stations and communication devices.

[0022] In another aspect, a communications device for a communications system in which network slices are supported and at least one tenant can communicate using at least one slice type associated with the tenant is provided, the communications device comprising: a controller and a transceiver, the transceiver configured to receive configuration information for configuring the communications device to obtain, from the at least one neighboring base station, information identifying support by the at least one neighboring base station for at least one of the tenants whose communications are supported via the base station and the tenants' network slice types supported by the base station, the controller configured to obtain, based on the configuration information, from the at least one neighboring base station, the information identifying support by the at least one neighboring base station for at least one of the tenants whose communications are supported via the base station and the tenants' network slice types supported by the base station, generate a report including the obtained information, and the transceiver configured to send the report to the at least one base station.

[0023] In another aspect, a base station for a communication system in which network slices are supported and at least one tenant can communicate using at least one slice type associated with the tenant is provided, the base station comprising a controller and a transceiver configured to send configuration information to a communication device to configure the communication device to obtain, from the at least one neighboring base station, information identifying support by the at least one neighboring base station for at least one of the tenants whose communication is supported via the base station and the network slice types of the tenants supported by the base station, receive from the communication device a report including information identifying support by the at least one neighboring base station for at least one of the tenants whose communication is supported via the base station and the network slice types of the tenants supported by the base station, generate a report including the obtained information, and the controller configured to determine a handover target based on the information identifying the support included in the received report.

[0024] In another aspect, a base station for a communication system in which network slicing is supported and at least one tenant can communicate using at least one slice type associated with the tenant is provided, the base station comprising a controller and a transceiver, the transceiver configured to receive information from a core node indicating that an overload operation should be initiated for at least one particular tenant and at least one particular network slice type of the particular tenant, the controller configured to control communication for at least one particular tenant and at least one particular network slice type of the particular tenant based on the information indicating that an overload operation should be initiated.

[0025] In another aspect, a core node for a communication system in which network slicing is supported and at least one tenant can communicate using at least one slice type associated with the tenant is provided, the core node comprising a controller and a transceiver, the controller configured to determine that an overload operation should be initiated for at least one particular tenant and at least one particular network slice type of the particular tenant, and the transceiver configured to transmit information indicating that an overload operation should be initiated for at least one particular tenant and at least one particular network slice type of the particular tenant to a base station.

[0026] In another aspect, a base station for a communication system in which network slicing is supported and at least one tenant can communicate using at least one slice type associated with the tenant is provided, the base station comprising a controller and a transceiver, the controller configured to obtain data usage information for communication via the base station, the data usage information including respective separate data usage information for at least one of each tenant for which communication is performed via the base station and each network slice type for each tenant for which communication is performed via the base station, and the transceiver configured to provide the respective separate data usage information to a core node.

[0027] In another aspect, a base station apparatus for a communication system in which network slicing is supported and at least one tenant can communicate using at least one slice type associated with the tenant is provided, the base station apparatus comprising a distributed unit and a central unit, each of the distributed unit and the central unit comprising a controller and a transceiver, the controller of the distributed unit configured to provide lower layer functionality of the base station apparatus compared to the central unit, the controller of the central unit configured to provide higher layer functionality of the base station apparatus compared to the distributed unit, there are a plurality of possible functional divisions between the lower layer functionality provided by the distributed units and the higher layer functionality provided by the central unit, and the controller of the distributed unit and the controller of the central unit configured to dynamically reconfigure the functional division between the lower layer functionality provided by the distributed units and the higher layer functionality provided by the central unit from a first one of the possible functional divisions to a second one of the possible functional divisions.

[0028] In another aspect, an apparatus for implementing the distributed unit of the base station apparatus is provided.

[0029] In another aspect, an apparatus is provided for implementing the central unit of the base station apparatus.

[0030] In another aspect, a core node for a communication system is provided, the core node comprising a controller and a transceiver, the controller configured to control communication with a base station device having distributed units and a central unit, the distributed units providing lower layer functionality of the base station device compared to the central unit, the central unit providing higher layer functionality of the base station device compared to the distributed units, the controller configured to determine which of a plurality of possible functional divisions to use for the division between the lower layer functionality provided by the distributed units and the higher layer functionality provided by the central unit, and the transceiver configured to provide an indication to the central unit of the base station device regarding which of a plurality of possible functional divisions to use.

[0031] In another aspect, a method is provided that is performed by a communication device in a communication system in which network slicing is supported and at least one tenant is capable of communicating using at least one slice type associated with the tenant, the method including receiving network slicing related information transmitted by a base station, the network slicing related information including at least one of: (i) information identifying a tenant whose communication is supported via the base station and support for at least one of the tenant's network slice types supported by the base station, and (ii) information including at least one communication parameter associated with the particular tenant and at least one of the particular slice types of the particular tenant, and controlling communication using a slice having a slice type of a tenant associated with the communication device based on information provided in the received network slicing related information, particularly related to the tenant associated with the communication device and at least one of the slice types of the tenant associated with the communication device.

[0032] In another aspect, a method is provided that is performed by a base station in a communication system in which network slicing is supported and at least one tenant can communicate using at least one slice type associated with the tenant, the method including: generating network slicing related information for transmission by a transceiver, the network slicing related information including at least one of (i) information identifying tenants whose communications are supported via the base station and support for at least one of the tenants' network slice types supported by the base station, and (ii) information including at least one communication parameter associated with the particular tenant and at least one of the particular slice types of the particular tenant, and transmitting the generated network slicing related information to at least one of other base stations and communication devices.

[0033] In another aspect, a method is provided that is performed by a communication device in a communication system in which network slices are supported and at least one tenant can communicate using at least one slice type associated with the tenant, the method including: receiving configuration information for configuring the communication device to obtain information identifying support by at least one neighboring base station for at least one of the tenants whose communications are supported via the base station and the tenants' network slice types supported by the base station from the at least one neighboring base station based on the configuration information, obtaining the information identifying support by the at least one neighboring base station for at least one of the tenants whose communications are supported via the base station and the tenants' network slice types supported by the base station from the at least one neighboring base station based on the configuration information, generating a report including the obtained information, and sending the report to the at least one base station.

[0034] In another aspect, a method is provided, performed by a base station in a communication system in which network slices are supported and at least one tenant can communicate using at least one slice type associated with the tenant, comprising: transmitting configuration information to a communication device for configuring the communication device to acquire information identifying support by at least one neighboring base station for at least one of the tenants whose communication is supported via the base station and the tenants' network slice types supported by the base station from the at least one neighboring base station, receiving from the communication device a report including information identifying support by the at least one neighboring base station for at least one of the tenants whose communication is supported via the base station and the tenants' network slice types supported by the base station, generating a report including the acquired information, and determining a handover target based on the information identifying the support included in the received report.

[0035] In another aspect, a method is provided that is performed by a base station in a communication system in which network slicing is supported and at least one tenant can communicate using at least one slice type associated with the tenant, the method including receiving information from a core node indicating that an overload operation should be initiated for at least one of the at least one specific tenant and at least one specific network slice type of the specific tenant, and controlling communication for at least one of the at least one specific tenant and at least one specific network slice type of the specific tenant based on the information indicating that the overload operation should be initiated.

[0036] In another aspect, a method is provided that is performed by a core node in a communication system in which network slicing is supported and in which at least one tenant can communicate using at least one slice type associated with the tenant, the method including: determining that an overload operation should be initiated for at least one of the at least one specific tenant and at least one specific network slice type of the specific tenant, and the transceiver transmitting information indicating that an overload operation should be initiated for at least one of the at least one specific tenant and at least one specific network slice type of the specific tenant to a base station.

[0037] In another aspect, a method is provided that is performed by a base station in a communication system in which network slicing is supported and at least one tenant can communicate using at least one slice type associated with the tenant, the method including obtaining data usage information for communication via the base station, the data usage information including respective separate data usage information for at least one of each tenant for which communication is performed via the base station and each network slice type for each tenant for which communication is performed via the base station, and providing the respective separate data usage information to a core node.

[0038] In another aspect, a method is provided for a communication system in which network slicing is supported and at least one tenant can communicate using at least one slice type associated with the tenant, the method comprising: providing, via the distributed unit, lower layer functionality of the base station device relative to the central unit; and providing, via the central unit, higher layer functionality of the base station device relative to the distributed unit, where there are a plurality of possible functional divisions between the lower layer functionality provided by the distributed unit and the higher layer functionality provided by the central unit; and dynamically reconfiguring the functional division between the lower layer functionality provided by the distributed unit and the higher layer functionality provided by the central unit from a first division to a second division of the possible functional divisions.

[0039] In another aspect, a method is provided that is performed by a core node for a communication system, the method including communicating with a base station device having a distributed unit and a central unit, where the distributed unit provides lower layer functionality for the base station device compared to the central unit, and the central unit provides higher layer functionality for the base station device compared to the distributed unit, determining which of a plurality of possible functional divisions to use for the division between the lower layer functionality provided by the distributed units and the higher layer functionality provided by the central unit, and further including providing an indication to the central unit of the base station device regarding which of a plurality of possible functional divisions to use.

[0040] Aspects of the invention include systems, methods, and computer program products, such as computer readable media storing instructions, which are operable to program a programmable processor or system to perform the methods described above or in the claimed aspects and possibilities, and / or to program a computer suitably adapted to provide an apparatus as described in any of the claims.

[0041] Any feature disclosed in this specification (including the claims) and / or shown in the drawings may be incorporated in the present invention independently (or in combination) with other disclosed and / or shown features. In particular, but not by way of limitation, any feature of a claim depending from a particular independent claim may be incorporated in that independent claim in any combination or individually.

[0042] Although particular hardware apparatus having particular physical configurations (e.g., controller and transceiver circuitry) are disclosed for carrying out the various procedures described below, each method step described herein and / or forming part of the claims may be implemented by any suitable means for carrying out that step. Accordingly, each method aspect of the present invention has a corresponding apparatus aspect including respective means for carrying out each step of that method aspect.

[0043] Exemplary embodiments of the present invention will now be described with reference to the accompanying drawings. [Brief description of the drawings]

[0044] [Figure 1] FIG. 1 shows diagrammatically a mobile telecommunications system of the type in which the present invention can be applied. [Diagram 2] FIG. 2 is a block diagram of a physical device for implementing a mobile telephone suitable for use in the telecommunications system of FIG. [Diagram 3] FIG. 3 is a block diagram of physical equipment for implementing a base station suitable for use in the telecommunications system of FIG. [Figure 4] FIG. 4 is a block diagram of physical equipment for implementing a distributed base station suitable for use in the telecommunications system of FIG. [Diagram 5] FIG. 5 is a block diagram of physical equipment for implementing core network functions suitable for supporting load control in the telecommunications system of FIG. [Figure 6] FIG. 6 is a block diagram of physical equipment for implementing core network functions suitable for supporting the facilitation of the provision of charging functions in the telecommunications system of FIG. [Figure 7] FIG. 7 is a block diagram of physical equipment for implementing core network functions suitable for supporting dynamic configuration of the functional division between distributed units and a central unit of a distributed base station of the type shown in the telecommunications system of FIG. [Figure 8] FIG. 8 illustrates procedures performed between a base station and user equipment of the telecommunications system of FIG. 1 to enable the user equipment to recognize tenant IDs and / or slice type support in a particular cell. [Figure 9] FIG. 9 illustrates a procedure performed between a base station and user equipment of the telecommunications system of FIG. 1 to provide different prioritization for tenants and / or slice types. [Figure 10] FIG. 10 illustrates the procedures carried out within a user equipment of the telecommunications system of FIG. 1 between the radio resource control layer, the medium access control layer and the physical layer when implementing the procedure of FIG. 9 or a similar procedure. [Figure 11] FIG. 11 illustrates several procedures performed between base stations of the type shown in the telecommunications system of FIG. 1 to support mobility in the context of network slicing. [Figure 12] FIG. 12 illustrates several procedures carried out between user equipment and base stations of the type shown in the telecommunications system of FIG. 1 to support mobility in the context of network slicing. [Figure 13]FIG. 13 illustrates procedures carried out between user equipment and base stations of the type shown in the telecommunications system of FIG. 1 to facilitate congestion / overload handling in the gNB. [Figure 14] Figure 14 shows procedures performed between the tie base station and the core network function shown in the telecommunications system of Figure 1 to facilitate congestion / overload handling in the gNB. [Figure 15] Figure 15 illustrates several procedures that may be performed between a tie base station and a core network function shown in the telecommunications system of Figure 1 to facilitate the provision of tenant usage specific functionality, such as billing (e.g., per slice type). [Figure 16] FIG. 16 illustrates a number of different options for the division of functionality between the distributed units and the central unit of a distributed base station of the type shown in the telecommunications system of FIG. [Figure 17] FIG. 17 illustrates procedures carried out in the telecommunications system of FIG. 1 to facilitate dynamic configuration of functional division between distributed units and a central unit of a distributed base station of the type shown in the telecommunications system of FIG. 1. [Figure 18] FIG. 18 illustrates another procedure that may be performed in the telecommunications system of FIG. 1 to facilitate dynamic configuration of functional division between distributed units and a central unit of a distributed base station of the type shown in the telecommunications system of FIG. 1. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0045] overview FIG. 1 shows a schematic diagram of a mobile (cellular) telecommunication system 1 in which a number of differently configured network slices 2 are defined, through which a network operator provides cellular services to different tenants based on their SLAs. It should be noted that the tenant concept allows a network operator to differentiate between different customer requirements and provide customized services using one or many slices. In this example, the mobile telecommunication system 1 operates as a next generation ("5G") system, but many of the features described with reference to this example are broadly applicable in other communication systems. Each base station forms part of an associated Radio Access Network (RAN) for enabling user equipment (UE) 3 (cell phones / smartphones 3-1, 3-2 and 3-3, MTC / IoT devices (not shown), and / or other mobile or fixed location communication devices) to connect to those networks and receive one or more associated services.

[0046] In this example, each UE 3 is provided with communication services by at least one tenant with its own unique tenant ID. Thus, the concept of tenants and slices allows a network operator to provide communication services using one or more types of network slices 2 according to the communication requirements of each tenant.

[0047] Each UE 3 is configured with a multi-dimensional descriptor (MDD) that represents at least the tenant ID of the tenant it belongs to and the service descriptor / slice types (partially governed by the tenant ID) that they are entitled to use. The service descriptor / slice types may contain standardized values ​​and / or operator specific values. The MDD is essentially a matrix in which each row indicates the slices 2 that the UE 3 can request to access or be addressed (so in the case of one slice the MDD is a vector). A row in the MDD is called an MDD vector.

[0048] Services are provided to respective UEs 3 of each tenant via one or more base stations 5-1, 5-2 of the telecommunications system 1. As will be appreciated by those skilled in the art, each base station 5 operates one or more cells 6-1, 6-2, 6-3 over which communication can take place between the base station 5 and the UEs 3 using a suitable radio access technology, such as E-UTRA (Evolved Universal Terrestrial Radio Access) technology.

[0049] The base station is configured to operate according to next generation (5G) standards and in this example includes a non-distributed gNB 5-1 and a distributed gNB 5-2. As shown in FIG. 1, the distributed gNB 5-2 in this example includes a central unit (CU) 5-2b and a number of distributed units (DUs) 5-2a, each serving at least one associated cell.

[0050] It should be noted that, although in this example a "gNB" type base station is described, much of the functionality can be extended to other base stations or similar devices for providing wireless access to UE3, such as mobile (cellular) phones / smartphones, MTC / IoT devices, and / or other mobile or fixed location communication devices.

[0051] The gNBs 5 are connected via an associated core network having a number of logical core network nodes 7 for supporting communications in the telecommunications system 1. The core network nodes 7 in this example implement at least one control plane function 7-1, at least one user plane function 7-2, and at least one policy / charging function 7-4, among other functions. In this example, one of the core network nodes 7 may also implement a mobility management function 7-3 providing mobility management functionality, e.g., corresponding to functions of an LTE mobility management entity (MME), including core overload control. In this example, one of the core network functions 7 may also include a function (referred to herein as a "distributed gNB control function" 7-5) for facilitating dynamic configuration of functional division between the distributed units 5-2a and the central unit 5-2b of the distributed gNB 5-2. It is noted that, although separate functions with specific names are described for purposes of explanation, the corresponding functionality may be implemented separately or in combination by one or more appropriate core network nodes 7 implemented using dedicated circuitry and / or software instructions for controlling associated processors. For example, the distributed gNB control function 7-5 may be implemented as part of any suitable core network node 7, such as a core node performing mobility management functions.

[0052] In this example, the User Plane Function 7-2 comprises at least one, and typically several, so-called Terminating User Plane Functions (TUPFs) for terminating user plane traffic and interfacing with the data network. By way of background, 3GPP Technical Report (TR) 23.799 V0.7.0 introduces the concept of a TUPF, which is essentially a logical network node coupled to one or more cells (gNBs). It is assumed that an appropriate Protocol Data Unit (PDU) session is provided between the TUPF and each connected UE 3 (i.e. a UE made available by a base station coupled to the TUPF).

[0053] Preferably, in one example method, information identifying supported Tenant IDs, (per Tenant ID) slice types, and TUPF 7-2 is broadcast in system information (e.g., in a System Information Block "SIB", such as SIB2 in LTE) by the corresponding gNB 5 so that a particular UE 3 can know as early as possible whether its allowed Tenant IDs and / or slice types are supported in a particular cell. The UE 3 can then pay attention to the relevant SIB in order to check whether any cell supports the particular desired Tenant ID, per Tenant ID slice type, and / or TUPF. Support for the particular desired Tenant ID, per Tenant ID slice type, and / or TUPF is checked based on MDD, UE capabilities, and / or USIM configuration.

[0054] Once the UE 3 has determined that its desired tenant ID, per tenant ID slice type, and TUPF are supported by the cell 6 based on the system information broadcast by the gNB 5, the UE 3 can camp on the cell 6 for any of a number of different purposes (e.g., for an initial access procedure or to request services). A mobile network operator may support many tenants and slices, but any given cell must not broadcast all of them, but only some, depending on how the cell is configured based on local demand. Non-core tenants or slices may be supported by a variety of different tenant or slice types.

[0055] Thus, the gNB 5 can conveniently dynamically change the tenant IDs, per tenant ID slice types, and / or TUPFs supported in a particular cell 6 (based on operator requirements, demand, etc.), and the UE 3 can efficiently determine whether its allowed tenant IDs and / or slice types are supported in that cell 6.

[0056] Preferably, in an example method described in detail below, the communication system shown in FIG. 1 provides procedures to support different processing, thereby providing prioritization of communications for different tenants and / or slice types. In particular, in these example procedures, system information is provided on a per tenant and / or per slice type (for each tenant) basis regarding how the random access channel procedure is performed. Thus, different configuration parameters can be provided for each tenant ID and / or per slice type (for each tenant). In one particularly preferred example, the preamble used for the RACH procedure is in fact "sliced" per tenant ID and / or per slice type within a tenant ID, with a different RACH preamble (or set of preambles) associated with each tenant and / or each slice type associated with a particular tenant ID. Each of these RACH preambles (or set of preambles) is given a respective priority, representing the priority with which communications of the corresponding tenant and / or slice type should be treated. In another example, the system information includes tenant / slice type specific parameters for configuring the power, frequency and / or relative timing used to transmit the RACH request or repetitions of the RACH request.

[0057] Preferably, in an example manner described in detail below, the communications system shown in Figure 1 provides a number of procedures that may take place between base stations of the type shown in the telecommunications system of Figure 1 to support connected mode mobility in the context of network slicing. These procedures include various Inter-gNB tenant ID and slice type resource information exchange procedures to support handover decision making, including procedures to enable neighbouring gNB5s to know which tenant IDs and slice types are supported by each neighbouring gNB5, and procedures to enable neighbouring gNB5s to know the loading status of each tenant, slice type (within tenant ID), and TUPF of each neighbouring gNB5.

[0058] Preferably, in an example manner described in detail below, the communication system shown in Figure 1 provides support for supporting overload control by allowing access banning to be performed based on tenant ID and / or slice identification (index). Similarly, in another example manner described in detail below, the communication system shown in Figure 1 provides support for supporting overload control by allowing core network controlled overload procedures (overload start / stop procedures) to be targeted to one or more specific tenant IDs and / or slice identifications.

[0059] Thus, preferably, in one exemplary manner, in order to take into account each tenant's respective usage for billing and other purposes, the communication system shown in FIG. 1 allows for incorporating measurements for the purpose of calculating downlink and uplink usage by each tenant with respect to slice type and other factors. In particular, a number of new functions and counters are provided to enable the collection of total downlink and uplink data volume per tenant ID, slice type, RAT (since 5G can support various RATs such as WLAN RAT), frequency, technology (such as License Assisted Access (LAA)), and / or UL / DL. For the purpose of data volume collection, each UE 3 may be identified based on a tenant ID, and the total downlink and uplink data consumption for the UE 3 identified via its tenant ID allows the calculation of tenant-specific data usage at various granularities.

[0060] Furthermore, for the purposes of 5G, considering that 5G supports non-3GPP radio access technologies (such as IEEE 802.11, IEEE 802.15, etc.) in a seamless manner, it is also preferable to perform data volume calculations per radio access technology for different RAT-based processing (e.g., charging).

[0061] Advantageously, in an exemplary manner described in detail below, the communication system shown in FIG. 1 improves the flexibility of the base station 5-2 having a central unit and distributed units by allowing the functional division to be dynamically changed to optimize the associated functional division based on channel conditions, loading conditions, quality of service requirements, etc.

[0062] User Device Figure 2 is a block diagram illustrating the main components of the user equipment 3 (such as a mobile phone) shown in Figure 1. As shown, the UE 3 has transceiver circuitry 231 operable to transmit and receive signals to and from a base station 5 (such as a gNB) via one or more antennas 233. Although not shown in Figure 2, it will be appreciated that the UE 3 may have all of the usual functionality of a conventional UE 3 (such as a user interface 235), which may be implemented by any one or any combination of hardware, software and firmware as appropriate. The UE 3 has a controller 237 for controlling the operation of the user equipment 3.

[0063] The controller 237 is associated with a memory 239 and is connected to the transceiver circuitry 231. The software may be pre-installed in the memory 239 and / or may be downloaded, for example, over a telecommunications network or from a Removable Data Storage Device (RMD).

[0064] The controller 237 is configured to control the overall operation of the UE 3, in this example by means of program or software instructions stored in the memory 239. As shown, these software instructions comprise, among others, an operating system 241, a communication control module 243, a slice / tenant information module 245, a Radio Resource Control (RRC) entity 247, a Medium Access Control (MAC) entity 249, a Physical Layer (PHY) entity 251, a Non-Access Stratum (NAS) module 252, and a measurement module 253.

[0065] The memory also stores configuration information 255 used in the UE 3 for communication and control purposes. Typically this information includes, among other things, a Multi-Dimensional Descriptor (MDD) (if configured for the UE), information identifying the communication and other capabilities of the UE, and information specifying how to configure the UE's Subscriber Identity Module (SIM), such as a Universal SIM (Subscriber Identity Module) (USIM).

[0066] The communication control module 243 is operable to control the communication between the UE 3 and the base station 5. The communication control module 243 also controls the separate flows of uplink and control data transmitted to the base station 5 as well as the reception of downlink and control data transmitted by the base station 5. The communication control module 243 is responsible for the UE side of idle and connected mode procedures, e.g. cell (re)selection, cell camping, system information listening, Random Access Channel (RACH) procedures, etc.

[0067] The slice / tenant information module 245 is responsible for managing and maintaining information identifying the tenant to which the UE 3 belongs and information identifying the slices / slice types that the UE 3 can use.

[0068] The RRC entity 247 is responsible for controlling the RRC layer functionality of the UE 3 (under the overall control of the communication control module 243). The MAC entity 249 is responsible for controlling the MAC layer functionality of the UE 3 (under the overall control of the communication control module 243). The PHY entity 251 is responsible for controlling the physical layer functionality of the UE 3 (under the overall control of the communication control module 243). The NAS module 252 is responsible for controlling the NAS functionality of the UE 3 (under the overall control of the communication control module 243).

[0069] The measurement module 253 handles performing measurements of communication conditions (such as received signal power and quality) in the serving cell and neighbouring cells (e.g. based on measurement configuration and control information received from the base station 5). The measurement module 253 also generates associated measurement reports for transmission to the base station 5.

[0070] Non-distributed base station (gNB) Figure 3 is a block diagram illustrating the main components of a non-distributed gNB 5-1 of the type shown in Figure 1. As shown, the gNB 5-1 comprises a transceiver circuit 351 operable to transmit and receive signals to and from a UE 3 via one or more antennas 353, and to transmit and receive signals to and from a core network 7 and / or other gNBs 5 via a network interface 355. The network interface 355 typically comprises an interface such as S1 for communicating with the core network, and a gNB-to-gNB interface (e.g., X2) for communicating with other gNBs. A controller 357 controls the operation of the transceiver circuit 351 according to software stored in memory 359. The software includes, among other things, an operating system 361, a communication control module 363, and a network slice / tenant management module 364.

[0071] The communication control module 363 is operable to control communication between the gNB 5-1 and the UE 3 and other network entities connected to the gNB 5-1. The communication control module 363 also controls separate flows of uplink and downlink user traffic and control data sent to communication devices served by the gNB 5-1, including, for example, control data for managing the operation of the UE 3. The communication control module 363 is responsible for control procedures such as, for example, measurement control / configuration information, communication of system information, gNB's part in the Random Access Channel (RACH) procedure, etc. The communication control module 363 is also responsible for the gNB's side of management of the setup, configuration, and reconfiguration of the gNB-to-gNB interface with neighboring gNBs. The communication control module 363 is also responsible for the gNB's side of management of handovers, including handover decision-making, target selection, etc. (where applicable). The communication control module 363 is also responsible for managing the gNB side of overload / congestion control, such as setting / resetting access barring parameters, performing and terminating core network initiated overload procedures, providing load / congestion information to other nodes (e.g., other gNBs), etc. The communication control module 363 is also responsible for monitoring and measuring UE data usage to perform related counters and provide information to the core network.

[0072] The network slice / tenant management module 364 is operable to store and manage configuration data 365 for defining the various radio access network (RAN) slices available via gNB5-1 for each service / tenant.

[0073] Distributed base station (gNB) Figure 4 is a block diagram illustrating the main components of a distributed gNB 5-2 of the type shown in Figure 1. As shown, the gNB 5-2 comprises a distributed unit 5-2a and a central unit 5-2b. Each unit 5-2a, 5-2b comprises a respective transceiver circuit 451a, 451b. The transceiver circuit 451a of the distributed unit 5-2a is operable to transmit signals to and receive signals from UEs 3 via one or more antennas 453a, and to transmit signals to and receive signals from the central unit 5-2b via an interface 454a.

[0074] The transceiver circuitry 451b of the central unit 5-2b is operable to transmit and receive signals to and from the core network 7 functionality and / or other gNBs 5 via a network interface 455b. The network interface 455b typically comprises an interface such as S1 for communicating with the core network and a gNB-to-gNB interface (e.g., X2) for communicating with other gNBs. The transceiver circuitry 451b of the central unit 5-2b is also operable to transmit and receive signals to and from one or more distributed units 5-2b via an interface 454b.

[0075] Each unit 5-2a, 5-2b comprises a respective controller 457a, 457b that controls the operation of the corresponding transceiver circuit 451a, 451b in accordance with software stored in its respective memory 459a, 459b. The software of each unit comprises, inter alia, a respective operating system 461a, 461b, a respective communication control module 463a, 463b, a respective network slice / tenant management module 464a, 464b, and a respective DU / CU functional partitioning management module 467a, 467b.

[0076] Each communication control module 463a, 463b is operable to control the communications of its corresponding unit 5-2a, 5-2b, including communications from one unit to the other. The communication control module 463a of the distributed unit 5-2a controls communications between the distributed unit 5-2a and the UEs 3, and the communication control module 463b of the central unit 5-2b controls communications between the central unit 5-2b and other network entities connected to the gNB 5-2.

[0077] The communication control modules 463a, 463b also control the part performed by the distributed unit 5-2a and the central unit 5-2b, respectively, of the flow of uplink and downlink user traffic and control data sent to communication devices served by the gNB 5-2, including, for example, control data for managing the operation of UE 3. Each communication control module 463a, 463b is responsible for controlling the respective part performed by the distributed unit 5-2a and the central unit 5-2b of procedures, such as, for example, measurement control / configuration information, communication of system information, the gNB's part in the Random Access Channel (RACH) procedures, etc. Each communication control module 463a, 463b is also responsible for controlling the respective part performed by the distributed unit 5-2a and the central unit 5-2b of the gNB's management of, for example, the setup, configuration, and reconfiguration of gNB-to-gNB interfaces with neighboring gNBs. Each communication control module 463a, 463b is also responsible for controlling the respective parts of the gNB-side handover management performed by the distributed unit 5-2a and the central unit 5-2b, including handover decision-making (where applicable), target selection, etc. Each communication control module 463a, 463b is also responsible for controlling the respective parts of the gNB-side management of overload / congestion control performed by the distributed unit 5-2a and the central unit 5-2b, for example setting / resetting access barring parameters, performing and terminating core network initiated overload procedures, providing load / congestion information to other nodes (e.g. other gNBs). Each communication control module 463a, 463b is also responsible for controlling the respective parts of the UE data usage monitoring and measurement performed by the distributed unit 5-2a and the central unit 5-2b, for example to perform relevant counters and provide information to the core network.

[0078] Each network slice / tenant management module 464a, 464b is operable to perform the respective parts performed by the distributed unit 5-2a and the central unit 5-2b in storing and managing configuration data for defining various radio access network (RAN) slices available via the gNB 5-1 for each service / tenant.

[0079] Each DU / CU functional partitioning management module 467a, 467b is responsible for the respective part performed by the distributed unit 5-2a and the central unit 5-2b in managing, configuring, and reconfiguring the functional partitioning between the distributed unit 5-2a and the central unit 5-2b.

[0080] Mobility Management Function 5 is a block diagram illustrating the main components of a core node 7 providing a mobility management function 7-3 (e.g. a mobility management entity (MME)). The core node 7-3 comprises a transceiver circuit 571 operable to transmit and receive signals to and from the gNB 5 and / or other nodes (e.g. other core nodes providing other core network functions) via a network 575. A controller 577 controls the operation of the transceiver circuit 571 in accordance with software stored in a memory 579. The software includes, among other things, an operating system 581, a communication control module 583, a mobility management module 584, and an overload control module 585.

[0081] The communications control module 583 is operable to control direct and / or indirect communications between the core node 7-3 and other network entities (e.g., gNBs and other core nodes providing other network functions) connected (directly or indirectly) to the core node 7-3.

[0082] The mobility management module 584 is responsible for providing mobility management functionality for the core node 7 including, for example, control over the access network, paging of idle mode UEs, bearer activation / deactivation functions, selection of an appropriate core node 7 (e.g., Serving Gateway and / or TUPF) for the UE upon initial attach and upon handover involving core node relocation, etc. The mobility management module 584 is also responsible for authenticating users, terminating Non-Access Stratum (NAS) signaling, generating and assigning temporary identities to UEs, and other similar functions.

[0083] The overload control module 585 is responsible for managing overload situations in the core network at the core network nodes, including detecting the occurrence and termination of overload situations, sending messages to initiate and terminate overload operation at the gNB, etc.

[0084] Policy / Charging Control Function Figure 6 is a block diagram illustrating the main components of a core node 7 providing a policy / charging control function 7-4. The core node 7-4 comprises a transceiver circuit 671 operable to transmit and receive signals to and from a gNB 5 and / or other nodes (e.g. other core nodes providing other core network functions) via a network interface 675. A controller 677 controls the operation of the transceiver circuit 671 in accordance with software stored in a memory 679. The software includes, among other things, an operating system 681, a communication control module 683, and a policy / charging control module 684.

[0085] The communications control module 683 is operable to control direct and / or indirect communications between the core node 7-4 and other network entities (e.g., gNBs and / or other core nodes providing other network functions) connected (directly or indirectly) to the core node 7-4.

[0086] The policy / charging control module 684 is responsible for providing charging control functions including accumulating data usage statistics from multiple gNBs for a particular tenant and / or slice type. The policy / charging control module 684 performs charging functions based on the accumulated data usage statistics, such as charging on a per tenant basis for different slice types.

[0087] DU / CU functional division management function 7 is a block diagram illustrating the main components of a core node 7 providing a DU / CU functional split management function 7-5 for providing core network based dynamic functional split management (if implemented) in a distributed gNB 5-2. The core node 7-5 comprises a transceiver circuit 771 operable to transmit and receive signals with the gNB 5 and / or other nodes (e.g. other core nodes providing other core network functions) via a network interface 775. A controller 777 controls the operation of the transceiver circuit 771 according to software stored in a memory 779. The software includes, among other things, an operating system 781, a communication control module 783, and a DU / CU functional split management module 784.

[0088] The communications control module 783 is operable to control direct and / or indirect communications between the core node 7-5 and other network entities (e.g., gNBs and / or other core nodes providing other network functions) connected (directly or indirectly) to the core node 7-5.

[0089] The DU / CU functional partitioning management module 784 is responsible for providing management of the DU / CU functional partitioning of the distributed gNB 5-2 of the type described with reference to Figure 4. The DU / CU functional partitioning management module 784 provides support for core network based dynamic functional partitioning management, including determining the optimal functional partitioning for any UE 3, the tenant to which the UE 3 belongs, and / or the slice that the UE 3 wishes to use (if implemented). This determination will typically be made taking into account prevailing channel conditions, loading conditions, and / or quality of service requirements.

[0090] In the above description, mobile phones, UEs, gNBs, and core network nodes implementing core network functions have been described for ease of understanding as having a number of separate modules. These modules may be provided in this manner for certain applications, such as when modifying an existing system to implement the present invention. However, in other applications, such as systems designed with the features of the present invention in mind, these modules may be integrated into an overall operating system or code in such a way that they are not recognized as separate entities. These modules may be implemented in software, hardware, firmware, or a combination thereof.

[0091] By way of example, several procedures are described herein that may be implemented to help provide an efficient slicing mechanism having several advantages, and although each of these procedures may provide independent technical benefits when implemented alone, these procedures may also be implemented in any combination.

[0092] <Cell support for tenant and / or slice types associated with tenant> FIG. 8 illustrates procedures performed between a base station and user equipment of the telecommunications system of FIG. 1 to enable the user equipment to recognize tenant IDs and / or slice type support in a particular cell.

[0093] As shown in Figure 8, the illustrated procedure begins in step S800 when the gNB5 configures a cell to support one or more tenants (indicated by respective tenant identifiers), one or more specific slice types operated by the one or more tenants, and / or one or more TUPFs, or when the gNB5 dynamically configures a cell to change the supported tenants, the specific slice types operated by the one or more tenants, and / or the TUPFs. Note that support of tenant IDs, slice types per tenant ID, and / or TUPFs can be dynamically changed based on a number of different factors, including, but not limited to, operator requirements and current, historical, or forecasted demand.

[0094] The gNB5 periodically broadcasts system information to each cell it operates in the form of a Master Information Block (MIB) and multiple System Information Blocks (SIBs). Each SIB contains information that a UE3 may need to communicate within its cell and / or information that a UE3 may obtain to provide to neighboring gNBs 5 to inform them about the gNB 5 that is broadcasting.

[0095] As an example, in an LTE (Long-Term Evolution) based communication system (the communication system of FIG. 1 may be an evolution of this), typically the MIB includes, inter alia, scheduling information of the other SIBs, SIB1 includes, inter alia, cell access related information, SIB2 includes, inter alia, radio resource configuration information, prohibition information, and radio resource configuration of common channels, SIB3 includes, inter alia, cell reselection information common to intra-frequency, inter-frequency, and / or inter-RAT cell reselection, SIB4 includes, inter alia, neighboring cell related information for intra-frequency cell reselection, and an intra-frequency blacklist cell list, SIB5 includes, inter alia, E-UTRAN (Evolved Universal Terrestrial Radio Access Network) specific inter-frequency neighboring cell related information, and an E-UTRAN specific inter-frequency blacklist cell list, and SIB6 and SIB7 include, inter alia, information regarding cell reselection to the radio access network for each different radio access technology (such as UTRAN, GERAN, CDMA2000, etc.). It should be noted that the above only represents a selection of the SIBs mentioned above, and typically many other SIBs may be broadcast within a cell depending on technology and requirements.

[0096] In the procedure of FIG. 8, in step S804, when gNB5 next broadcasts system information, the system information includes a system information block (e.g., SIB2) configured to include information identifying tenant IDs, slice types per tenant ID, and / or TUPFs supported by the cells operated by the gNB.

[0097] As shown in step S802, UE3 listens for periodic broadcasts of system information provided by gNB5, such that, in step S804, when gNB5 broadcasts the system information, UE3 receives a system information block including information identifying supported tenant IDs, slice types per tenant ID, and / or TUPF.

[0098] It should be noted that although the procedure shown in FIG. 8 is shown at specific points in time, UE 3's monitoring of system information is an ongoing process that UE 3 continues to perform periodically while the UE 3 is turned on.

[0099] Thus, in step S806, the UE 3 can check whether the gNB cell supports its desired tenant ID, per-tenant ID slice type, and / or TUPF. The UE 3 can do so based on whether a particular tenant ID and / or slice (type) is indicated in a multi-dimensional descriptor (MDD), UE capabilities, USIM configuration, and / or dynamically configured NAS.

[0100] If the cell supports UE3's tenant ID and / or a particular slice type within the tenant ID that UE3 is using, UE3 can decide to camp on the cell in step S808.

[0101] It should be noted that the above procedure may be used by the UE 3, for example, when the UE 3 determines whether to reside in any cell for any reason, such as for the purpose of initial access to the network or for the purpose of making a service request.

[0102] If the cell does not support UE3's tenant ID and / or a particular slice type within the tenant ID that UE3 is attempting to use, UE3 may decide not to camp on the cell in step S810.

[0103] <Tenant / slice prioritization> Figure 9 shows procedures performed between the base station and user equipment of the telecommunications system of Figure 1 to provide different prioritization of tenants and / or slice types at an early stage of a UE3's attempt to connect to a particular cell during a random access channel procedure.

[0104] As shown in Figure 9, the illustrated procedure begins in step S900 when system information is broadcast in a cell operated by gNB5 (e.g., as part of the periodic broadcast of system information mentioned with reference to Figure 8). In the procedure of Figure 9, when gNB5 broadcasts the system information in step S900, the system information includes a system information block (e.g., SIB2) configured to include tenant ID-specific parameters and / or slice type-specific parameters. Thus, different parameters can be configured for each tenant ID and / or each slice type associated with a particular tenant ID.

[0105] In this example, a different RACH preamble is associated with each tenant ID and / or each slice type associated with a particular tenant ID. Thus, essentially, the RACH preamble is "sliced" for each tenant ID and / or slice type within a tenant ID. Each of these RACH preambles has a respective priority that represents the priority with which communications for the corresponding tenant and / or slice type should be treated.

[0106] In this example, the tenant ID-specific parameters and / or slice type-specific parameters provided in the system information in step S900 include parameters identifying the respective RACH preambles associated with each tenant's ID and / or each slice type associated with a particular tenant ID.

[0107] As shown in step S902, UE3 listens for periodic broadcasts of system information provided by gNB5, such that when gNB5 broadcasts the system information in step S900, UE3 receives a system information block including tenant ID-specific parameters and / or slice type-specific parameters.

[0108] It should be noted that although the procedure shown in FIG. 9 is shown at specific points in time, UE 3's monitoring of system information is an ongoing process that UE 3 continues to perform periodically while the UE 3 is turned on.

[0109] When a UE 3 determines that it needs to initiate a RACH procedure (e.g., to facilitate initial access to a cell, connection establishment, handover, etc.), it identifies in step S904 the correct preamble to be used for the tenant ID to which it belongs and / or the slice type it is going to use. This identification can be based on parameters provided in the system information broadcast and / or pre-configured parameters in the USIM and / or MDD that identify the respective RACH preambles associated with each tenant ID and / or each slice type associated with a particular tenant ID in conjunction with the tenant ID and / or associated slice type represented in the MDD.

[0110] The UE 3 then generates message 1 of the RACH procedure (e.g., RACH request) to request a random access channel. This message includes information identifying the selected random access preamble (e.g., in the form of an index uniquely associated with the selected random access preamble). In step S906, the message including the information identifying the selected random access preamble is sent to the gNB 5.

[0111] The gNB3 determines a Random Access Radio Network Temporary Identity (RA-RNTI) associated with the UE3 and the number of the timeslot in which the preamble will be sent.

[0112] The gNB5 then prioritizes the UE3's communications (e.g., relative to communications with other UEs) in step S908 based on the preambles identified in message 1 of the RACH procedure and the relative priorities associated with those preambles. Thus, in practice, the gNB5 will treat different preambles with different priorities when it receives RACH message 1.

[0113] After receiving the RACH request, the gNB allocates a temporary identity (Temporary Cell RNTI - TC-RNTI) to the UE 3 which becomes a permanent identity (like the C-RNTI) after a successful RACH procedure and calculates an appropriate timing advance which is used to ensure that the next UE message is sent and received with the correct timing. The gNB 5 also allocates uplink resources.

[0114] The gNB 5 generates an appropriate Random Access Response (RAR) message (message 2) containing the necessary information for the UE 3 to send message 3 (e.g., a Layer 3 message such as an RRC connection request) at the appropriate time. This message is then sent to the UE 3 in step S910. The RAR message is typically sent on the Physical Downlink Control Channel (PDCCH) within a time window of a small number of Transmission Time Intervals (TTIs). For initial access purposes, the RAR message may typically carry a random access preamble identifier, timing adjustment information, an initial UL grant, and a temporary C-RNTI assignment.

[0115] It should be noted that, although not shown in FIG. 9, if the UE 3 does not receive an RAR message from the network, the UE 3 will increase its power in a fixed step and resend the RACH preamble.

[0116] The UE 3 responds to the RAR message with an appropriate message 3 (eg, an appropriate Layer 3 message) in step S912.

[0117] It should be noted that the above-mentioned prioritization of tenant / slice types supporting the RACH procedure may be performed during a number of different situations that may occur in the telecommunication system 1 of Fig. 1. The RACH procedure may be performed, for example, during an initial access procedure when the UE 3 is trying to access the network in RRC idle state, during an RRC connection (re)establishment procedure, during a handover procedure, when uplink synchronization is lost (e.g., when the network has not received anything from the UE 3 in the uplink for a certain period of time), when the UE 3 has no Physical Uplink Control Channel (PUCCH) resources available for a Scheduling Request (SR), and when a timing advance is required for positioning purposes in the RRC connected state for the UE.

[0118] For example: if the RACH procedure is for the purpose of initial access (or RRC connection establishment), message 3 may be an RRC connection request message. If the RACH procedure is for the purpose of RRC connection re-establishment, message 3 may be an RRC connection re-establishment message. If the RACH procedure is for the purpose of a handover type procedure that requires a RACH, message 3 may be an RRC connection reconfiguration complete message.

[0119] In this example, the RACH procedure may also be advantageously used to provide multiple other parameters per tenant and / or slice type (for a particular tenant) to enable prioritized or different treatment of communications for different tenants and / or slice types.

[0120] The following parameters may be provided, for example, for each tenant ID / slice type in system information (e.g., in SIB2) in addition to (or instead of) the preamble information.

[0121] PreambleInitialReceivedTargetPower: This parameter represents the target power level that the gNB5 desires when it receives the first transmission of a RACH request during the RACH procedure. The default value is typically -104 dBm, but can range from -120 dBm to -90 dBm (typically) with a step size of 2 dBm. This parameter may vary based on the tenant ID to which the UE3 belongs and / or the slice type that the UE3 desires to use within the tenant ID.

[0122] PowerRampingStep: This parameter represents the power increment used by the UE 3 when transmitting each subsequent RACH request. This parameter may vary based on the tenant ID to which the UE 3 belongs and / or the slice type that the UE 3 wants to use within the tenant ID, such that different UEs belonging to different tenant IDs (or using different slice types) can use different power steps to transmit subsequent RACH requests. Thus, in practice, a larger power step may be used for a UE belonging to a particular tenant ID (or using a particular slice type) compared to a UE with a smaller power step to increase the likelihood that a subsequent RACH request for the UE is received by the gNB 5.

[0123] prach-ConfigIndex: This parameter defines exactly when (which subframe) the UE will send the RACH in the frequency / time grid. This parameter may also vary based on the Tenant ID to which the UE 3 belongs and / or the slice type that the UE 3 wants to use within the Tenant ID, so that different UEs belonging to different Tenant IDs (or using different slice types) may use different subframes (e.g., 2 or 7) to send their RACH requests.

[0124] prach-FreqOffset:The PRACH frequency offset parameter is used to inform the UE 3 and other neighboring cells about which resources (physical resource blocks) are available for RACH access. This parameter may also vary based on the Tenant ID to which the UE 3 belongs and / or the slice type that the UE 3 wants to use within the Tenant ID, so that different UEs that belong to different Tenant IDs (or use different slice types) can use different frequency resources for RACH access.

[0125] ra-ResponseWindowSize: The RA response window size parameter represents the duration of the random access response window in subframes (e.g., 2, 3, 4, 5, 6, 7, 8, or 10 subframes). This parameter may vary for tenant ID and / or slice type. Furthermore, the earliest time the network can send a RACH response (i.e., the start of the RAR response window) may vary depending on the tenant ID / slice type (e.g., to take into account tenant ID / slice type based preambles). Typically, the RAR response window starts 3 subframes after the RACH preamble.

[0126] preambleTransMax: This parameter defines the maximum number of preamble transmissions (typical possible values ​​are 3, 4, 5, 6, 7, 8, 10, 20, 50, 100, 200). This parameter may vary for different tenant IDs and / or slice types to allow different numbers of transmission attempts for different tenants / slice types.

[0127] Similarly, some parameters may be provided, for example per tenant ID / slice type, in other messages of the RACH procedure. For example, the back-off indicator, which is normally included in the RAR Media Access Control Protocol Data Unit (MAC PDU), may vary for different tenant IDs and / or slice types for prioritization purposes. The back-off indicator is a special MAC sub-header carrying a parameter indicating the time delay between subsequent RACH attempts.

[0128] It should be noted that other physical channels, such as the Physical Downlink Shared Channel (PDSCH) and the Physical Uplink Shared Channel (PUSCH), can be "sliced" in a similar manner to allow preferential treatment of RAR (message 2) and message 3, respectively.

[0129] Similarly, other physical channels may also be "sliced" for prioritized handling (although unrelated to the RACH), such as the Paging Channel (PCH), the Physical Downlink Shared Channel (PDSCH), the Physical Downlink Control Channel (PDCCH), and the Physical Uplink Control Channel (PUCCH).

[0130] The RACH may also contain RRC messages (such as those in UMTS) for easy tenant identification for prioritized processing (eg, if the preamble is not sliced).

[0131] FIG. 10 illustrates the procedures carried out internally between the radio resource control layer, the media access control layer and the physical layer of a user equipment of the telecommunications system of FIG. 1 when implementing the procedure of FIG. 9 or a similar procedure.

[0132] As shown in FIG. 10, the procedure begins in step S1000 when a Radio Resource Control (RRC) entity 247 in the UE 3 sends a request to the UE MAC entity 249 to trigger a RACH procedure.

[0133] In step S1002, the UE MAC entity 249 identifies the correct subframe, preamble and other parameters (such as any of the parameters mentioned with reference to FIG. 9) from the system information block and / or MDD / USIM configuration information for any tenant ID to which the UE 3 belongs and / or slice type that the UE 3 intends to use.

[0134] The UE MAC entity 249 then calculates in step S1004 the allowed preamble index, the ra-RNTI and the power to be used for preamble transmission. These values ​​are indicated in step S1006 to the UEPHY entity 251 together with the RACH subframe in which the transmission of the RACH request has to be performed based on the tenant ID of the tenant to which the UE 3 belongs, the slice type, the MDD, the UE capabilities etc.

[0135] Then, the UEPHY 251 transmits a RACH request in step S1008.

[0136] Support for connected mode mobility 11(a)-(e) show a number of procedures performed between base stations of the type shown in the telecommunications system of FIG. 1 to support connected mode mobility in the context of network slicing. More specifically, FIG. 11(a)-(e) show various inter-gNB tenant ID and slice type resource information exchange procedures to support handover decision making. FIG. 11(a) and (b) show procedures for enabling neighbouring gNB5s to know which tenant IDs and slice types are supported by each neighbouring gNB5. FIG. 11(c)-(e) show procedures for enabling neighbouring gNB5s to know the loading status of each tenant and slice type (within the tenant ID) as well as the TUPF of each neighbouring gNB5. It should be noted that these procedures may be implemented alone or in any technically appropriate combination.

[0137] FIG. 11(f) illustrates a procedure for initiating a handover based on information exchanged in one or more of the procedures illustrated in FIGS. 11(a)-(e).

[0138] Referring to Figures 11(a) and (b), information to enable neighboring gNB5s to know which tenant IDs and slice types are supported by each neighboring gNB5 may be exchanged upon establishment of interfaces between neighboring gNB5s and / or upon configuration updates between neighboring gNBs.

[0139] As shown in FIG. 11(a), for example, during a configuration update between neighboring gNB(A) and gNB(B), gNB(A) sends an interface setup request message to gNB(B) in step S1100 to initiate setup of a gNB-to-gNB interface (e.g., similar to an X2 interface) between gNB(A) and gNB(B). The interface setup request message includes information identifying tenant IDs and / or slice types (per tenant ID) supported by gNB(A). gNB(B) responds with an appropriate interface setup response message in step S1102. The interface setup response message includes information identifying tenant IDs and / or slice types (per tenant ID) supported by gNB(B).

[0140] As shown in FIG. 11(b), upon configuration update between neighboring gNB(A) and gNB(B), gNB(A) sends a gNB configuration update message to gNB(B) to update gNB(B) about the changed support of tenant IDs and / or slice types (per tenant ID) in step S1104. The gNB configuration update message includes information identifying the tenant IDs and / or slice types (per tenant ID) currently supported by gNB(A). gNB(B) responds with an appropriate gNB configuration update acknowledgement message to acknowledge the secure receipt of the updated information in step S1106.

[0141] Referring to Figures 11(c) to (e), information to enable neighbouring gNB5s to be aware of the load status of each tenant and slice type (within the tenant ID) and the TUPF of each neighbouring gNB5 may be exchanged at regular time intervals and / or when triggered by procedures such as, for example, a load indication procedure, a resource status reporting initiation procedure, an unsolicited resource status reporting procedure (similar to the X2AP resource status reporting procedure), etc.

[0142] 11(c) shows a load indication procedure in which, for example, gNB(A) sends a load information message to gNB(B) in step S1108 to inform gNB(B) of the load status (e.g., UL / DL physical resource block usage) of each tenant ID, slice type (within the tenant ID), and / or TUPF associated with gNB(A). The load information message may be a message sent at predetermined regular intervals and / or when triggered by an event as necessary.

[0143] 11(d) shows a resource status report initiation procedure in which gNB(A) sends a resource status request to gNB(B) in order to request gNB(B) to inform gNB(A) of its load status in step S1110. gNB(B) responds with a resource status request message in order to inform gNB(A) of the load status (e.g., UL / DL physical resource block usage) of each tenant ID, slice type (within tenant ID) and / or TUPF associated with gNB(B) in step S1112.

[0144] Figure 11(e) shows a resource status reporting procedure in which gNB(B) sends a resource status update message at periodic intervals and / or when triggered to do so (e.g., by an event), e.g., in step S1114, to update gNB(A) about the prevailing load conditions (e.g., UL / DL physical resource block usage) of each tenant ID, slice type (within the tenant ID) and / or TUPF associated with gNB(B).

[0145] Thus, referring to FIG. 11(f), when a handover becomes necessary, the source gNB (e.g., gNB(A) in FIG. 11) may decide about the handover and select a target gNB (e.g., gNB(B) in FIG. 11) based on load information it obtains from neighboring gNBs (e.g., using one or more of the procedures shown in FIG. 11(c)-(e)) for the tenant to which the UE 3 to be handed over belongs and the slice type that the UE 3 is going to use, as shown in step S1116. This decision may also be based on information it obtains from neighboring gNBs (e.g., using one or more of the procedures shown in FIG. 11(a) and (b)) that support the tenant to which the UE 3 to be handed over belongs and the slice type that it is going to use.

[0146] Thus, in this example, once the determination is made in step S1116, gNB(A) sends a handover request including the tenant ID and / or slice type, and the target gNB (gNB(B) in this example) to gNB(B) in step S1118. gNB(B) responds with a handover response (or handover confirm) message (including a handover command typically sent by the source gNB to the UE3 to initiate the handover) in step S1120. The remainder of the handover process may proceed according to procedures familiar to those skilled in the art, and a detailed description thereof will be omitted for the sake of brevity.

[0147] FIG. 12 illustrates several procedures carried out between user equipment and base stations of the type shown in the telecommunications system of FIG. 1 to support mobility in the context of network slicing.

[0148] As shown in Figure 12, instead of or in addition to one or more of the procedures shown in Figure 11, the UE 3 can provide information to the source gNB about what neighboring (potential target) gNBs can support using measurement reports, and the source gNB can make a decision regarding an appropriate target gNB based on that information.

[0149] Specifically, in the example of FIG. 12, the (source) gNB(A) configures the UE 3 to perform appropriate neighbor cell measurements on neighbor gNBs such as gNB(B) (and possibly the serving gNB) using an appropriate measurement control message sent in step S1200. The UE 3 performs the configured measurements in step S1201 and further obtains the tenant IDs and / or slice types (per tenant ID) supported by the neighbors. The obtained information may for example be obtained from a system information broadcast in the neighbor cells as described with reference to FIG. 8. The UE 3 reports the measurements and the obtained information in at least one measurement report in step S1202. It should be noted that with the UE's assistance, the above mentioned mechanism enhances the Automatic Neighbor Relation (ANR) for the gNB to know the neighbor gNBs as to which tenants / slice types are supported and can use these details to build a Neighbor Relation Table (NRT).

[0150] Then, gNB(A) makes a handover decision and selects a target gNB (e.g., gNB(B)) based on the measurement results and the tenant IDs and / or slice types (per tenant ID) supported by the neighboring gNBs, as shown in step S1204. If a decision is made, gNB(A) sends a handover request including the tenant IDs and / or slice types and the target gNB (gNB(B) in this example) to gNB(B) in step S1206. gNB(B) responds with a handover response (or handover confirm) message in step S1208 (including a handover command typically sent by the source gNB to the UE3 to initiate the handover). The remainder of the handover process (e.g., in step S1210) may proceed according to procedures familiar to those skilled in the art, and a detailed description thereof is omitted for the sake of brevity.

[0151] Handling slice overload conditions In near-overload situations, traffic must be throttled. Based on local operator policies, differentiated policies may be applied to throttle traffic depending on tenant ID and / or slice type. While determining the optimal strategy in this regard is up to the policy framework of a particular operator, the following procedure provides a signaling mechanism that can be used to signal an overload / congestion situation.

[0152] FIG. 13 illustrates procedures carried out between user equipment and base stations of the type shown in the telecommunications system of FIG. 1 to facilitate congestion / overload handling in the gNB.

[0153] In the example of FIG. 13, the procedure is similar to that of Access Class Barring (ACB). However, unlike ACB, this barring is done per tenant ID and / or per slice identifier (e.g., per slice index). As shown in FIG. 13, the procedure starts with the gNB 5 setting (or modifying) access barring parameters per tenant ID and / or per slice index. The access barring parameters may include, for example, per tenant ID / per slice index barring factors and / or barring times. The barring factors are parameters used by the UE 3 to determine whether access to a particular cell is actually barred. In particular, the barring factors (or "access probability") determine the probability that access will be allowed. If the random number n generated by the UE is equal to the factor (or "probability"), the access is barred for an average access barring period corresponding to the barring time.

[0154] In the procedure of FIG. 13, in step S1304, when gNB5 next broadcasts system information, the system information includes a system information block (e.g., SIB2) configured to include information identifying prohibited parameters on a per tenant ID and / or per slice index basis.

[0155] As shown in step S1302, UE3 listens for periodic broadcasts of system information provided by gNB5, such that in step S1304, when gNB5 broadcasts the system information, UE3 receives a system information block including information identifying forbidden parameters on a per tenant ID and / or per slice index basis.

[0156] It should be noted that although the procedure shown in FIG. 13 is shown at specific points in time, UE 3's monitoring of system information is an ongoing process that UE 3 continues to perform periodically while the UE 3 is turned on.

[0157] After receiving information identifying barring parameters on a per tenant ID and / or per slice index basis, in step S1306, UE3 applies the access barring parameters for the tenant it belongs to and / or the slice it is attempting to use when determining whether to attempt access via a gNB / NR-BS.

[0158] Figure 14 shows other procedures carried out between base stations and core network functions of the type shown in the telecommunications system of Figure 1 to facilitate congestion / overload handling in the gNB5.

[0159] In the example of Figure 14, the procedure is similar to that of Access Class Barring (ACB) of the core network controlled overload start and stop procedures. However, unlike existing core overload control procedures, this overload control is handled per tenant ID and / or per slice identifier (e.g., per slice index).

[0160] As shown in Figure 14, the procedure begins in step S1400 when a core network function (such as a mobility management function 7-3) detects an overload condition and determines the appropriate type of overload action on a per-tenant and / or per-slice basis. The core network function 7-3 generates and sends an appropriate overload initiation message to the affected gNB 5 in step S1401. The overload initiation message includes respective overload parameters for each tenant ID and / or slice index. The parameters may include, for example, an overload response parameter and / or a traffic load reduction indication on a per-tenant ID and / or per-slice index basis.

[0161] The gNB 5 receiving the overload initiation message in step S1401 responds in step S1402 by reducing the signaling load to that core network function 7-3, which may be achieved, for example, by rejecting, allowing and / or restricting RRC connection establishment based on respective overload parameters for each tenant ID and / or slice index.

[0162] In step S1403, when the core network function 7-3 detects the end of the overload condition, it generates and sends an appropriate overload stop message to the affected gNB5 in step S1403.

[0163] The gNB5 receiving the overload end message in step S1403 responds by resuming normal operation for the core network functions.

[0164] Additionally, RRC Reject, RRC Release, Preemption, and Access Class Barring procedures can all be utilized (e.g., per tenant and / or per slice) to help control traffic in case of overload / congestion, where overload can be caused by node failure or increased traffic.

[0165] <Tenant usage monitoring> Figure 15 illustrates several procedures performed between the tie base station and core network functions shown in the telecommunications system of Figure 1 to facilitate the provision of tenant usage specific features such as billing (e.g., per slice type).

[0166] As shown in FIG. 15, when one or more UEs 3 are communicating through the gNB 5 in the uplink and / or downlink (as shown in step S1500), the gNB 5 uses dedicated counters to monitor the downlink and uplink data for each UE for each slice type used in step S1502. For the purpose of accumulating data usage, each UE can be identified at a high level based on its tenant ID and therefore data usage can be summed for UEs 3 with the same tenant ID to generate a tenant-specific total DL and UL data volume for each tenant ID and / or per slice type (for each tenant ID). The gNB 5 generates and sends a data volume report including the total DL and UL data volume to a core network function (such as the policy / charging function 7-4) in step S1504.

[0167] In step S1506, the core network function 7-4 calculates total (cumulative) downlink and uplink data usage specific to tenant and / or slice type for multiple gNB5s based on information provided in each data volume report received from each gNB5.

[0168] Then, in step S1508, the core network function 7-4 performs tenant specific usage functions, such as billing, based on the results of the calculations performed in step S1506.

[0169] If non-3GPP radio access technologies (such as IEEE 802.11, IEEE 802.15, etc.) are supported in a seamless manner, data volume calculations can also advantageously be done per radio access technology for different RAT-based charging. If unlicensed spectrum is used with License Assisted Access (LAA), the above information may also be taken into account.

[0170] <Dynamic Functional Division> Figure 16 shows a number of different options for functional division between the distributed units and the central unit of a distributed base station of the type shown in the telecommunications system of Figure 1 and described with reference to Figure 4. The options include:

[0171] <Option 1> According to the functional division of Option 1, the Radio Resource Control (RRC) layer functions are performed in a central unit, while the Packet Data Convergence Protocol (PDCP), Radio Link Control (RLC), Media Access Control (MAC) and Physical (PHY) layer functions, as well as the Radio Frequency (RF) functions, are performed in distributed units.

[0172] <Option 2> According to Option 2 functional division, the RRC layer and PDCP layer functions reside in the central unit, while the RLC, MAC, physical layer and RF functions reside in the distributed units.

[0173] <Option 3> According to the functional division of Option 3, the RRC, PDCP and higher RLC layer (i.e. part of the RLC) functions are present in the central unit, while the lower RLC layer (i.e. other part of the RLC layer) functions, the MAC layer, the physical layer and the RF functions are present in the distributed units.

[0174] <Option 4> According to the functional division according to option 4, the RRC, PDCP and RLC layer functions are present in the central unit, while the MAC, physical layer and RF functions are present in the distributed units.

[0175] <Option 5> According to the Option 5 functional split, RRC, PDCP, RLC and higher MAC layer functionality reside in a central unit, while lower MAC layer (e.g. Hybrid Automatic Repeat Request (HARQ)), physical layer and RF functionality reside in distributed units.

[0176] <Option 6> According to the functional division of Option 6, the RRC, PDCP, RLC and MAC layer functions reside in the central unit. The physical layer and RF functions reside in the distributed units.

[0177] <Option 7> According to the functional division of Option 7, the functions of RRC, PDCP, RLC, MAC and the (upper) part of the physical layer are located in the central unit. The (lower) part of the physical layer and RF functions are located in the distributed units.

[0178] <Option 8> According to the functional division of Option 8, the RRC, PDCP, RLC, MAC and physical layer functions are located in the central unit. The RF functions are located in the distributed units.

[0179] Note that the options shown are not all-inclusive.

[0180] It should be noted that none of the above options for functional division between the central unit and the distributed units is optimal in all scenarios, especially due to varying channel conditions, loading conditions and quality of service requirements.

[0181] Each of Figures 17 and 18 shows procedures used to improve the flexibility of a base station having such a functional partitioning, by allowing the functional partitioning to be dynamically changed to optimize the above-mentioned functional partitioning based on, for example, channel conditions, loading conditions, quality of service requirements, etc. In each of these procedures, each of the different options for functional partitioning described with reference to Figure 16 (or each of at least a subset of these options) is given a respective identifier (e.g. index number). Once the UE's service request is established, the central unit (Figure 17) or core node function 7-5 (Figure 18) of the distributed gNB 5-2 decides which functional partitioning option to use and provides the relevant instructions to set up the appropriate functional partitioning between the central unit and the distributed units.

[0182] It should be noted that these procedures may be implemented separately or in combination (eg, as different options within the telecommunications system 1).

[0183] FIG. 17 illustrates procedures carried out in the telecommunications system of FIG. 1 to facilitate dynamic configuration of functional division between distributed units and a central unit of a distributed base station of the type shown in the telecommunications system of FIG. 1.

[0184] In the example of Figure 17, the procedure begins in step S1700 when a service request is sent to the distributed gNB 5-2 from the UE 3. The service request typically includes information identifying the UE 3, the tenant to which the UE 3 belongs, and / or the slice it wants to use. The distributed unit 5-2a of the gNB 5-2 receives the service request and forwards it to the central unit 5-2b of the gNB 5-2 in step S1702.

[0185] In this example, in step S1704, the central unit 5-2b determines an optimal functional partitioning for the identified UE 3, the tenant to which the UE 3 belongs and / or the slice that the UE 3 wants to use. This determination will typically take into account the prevailing channel conditions, loading conditions and / or quality of service requirements.

[0186] When a decision has been made regarding the optimal functional partitioning, the central unit 5-2b provides functional partitioning instructions to the distributed unit 5-2a in step S1705, and the distributed unit and the central unit configure (reconfigure) the functional partitioning for the UE 3, tenant ID and / or slice in step S1706.

[0187] In step S1708, the service request is forwarded to an appropriate function in the network core 7. This may be part of an initial UE message or the like. The core network function 7 responds in step S1710 by sending a request for UE context setup (e.g. an initial context setup request) to the gNB 5-2. Once the context is properly set up in the gNB 5-2, the central unit 5-2b of the gNB 5-2 sends an appropriate response (e.g. an initial context setup response) to the core network function 7 for confirmation of the UE context setup. Note that these messages and the associated setup of the UE context may take place earlier in the process, for example before or in parallel with the decision on the functional split and associated reconfiguration.

[0188] The procedure continues at step S1714 with appropriate bearer establishment / modification, which will be familiar to those skilled in the art and will not be described in detail here.

[0189] FIG. 18 illustrates another procedure that may be performed in the telecommunications system of FIG. 1 to facilitate dynamic configuration of functional division between distributed units and a central unit of a distributed base station of the type shown in the telecommunications system of FIG. 1.

[0190] In the example of Figure 18, similar to the procedure of Figure 17, the procedure begins in step S1800 when a service request is sent to the distributed gNB 5-2 from the UE 3. The service request typically includes information identifying the UE 3, the tenant to which the UE 3 belongs, and / or the slice it wishes to use. The distributed unit 5-2a of the gNB 5-2 receives the service request and forwards it to the central unit 5-2b of the gNB 5-2 in step S1802.

[0191] In this example, however, in step S1804, the service request is forwarded to the core network. This may be as part of an initial UE message or the like. An appropriate core network function (e.g. a distributed gNB control function 7-5 or a core network function including such a function) determines in step S1806 an optimal functional partitioning for the identified UE 3, the tenant to which the UE 3 belongs and / or the slice that the UE 3 wishes to use. This determination will typically take into account the prevailing channel conditions, loading conditions and / or quality of service requirements.

[0192] The core network sends a request for UE context setup (e.g., an initial context setup request) to the gNB 5-2 including an indication of the functional splitting to the central unit 5-2b of the gNB 5-2 in step S1808. In step S1809, the central unit 5-2b provides the indication of the functional splitting to the distributed unit 5-2a, and in step S1810, the distributed unit and the central unit configure (or reconfigure) the functional splitting of the UE 3, tenant ID and / or slice.

[0193] Once the context has been properly set up in gNB 5-2, the central unit 5-2b of gNB 5-2 sends an appropriate message (e.g. an initial context setup response) to the core network to confirm the setup of the UE context. Note that these messages and the associated setup of the UE context may occur earlier in the process, for example before or in parallel with the notification and (re)configuration of the functional split.

[0194] The procedure continues in step S1814 with appropriate bearer establishment / modification, which will be familiar to those skilled in the art and will not be described in detail here.

[0195] Variations and Substitutions A number of detailed embodiments have been described. As will be appreciated by those skilled in the art, many modifications and alternatives to the above-described embodiments may be made while still benefiting from the invention as described in the examples. For purposes of illustration, some of these alternatives and modifications are described below.

[0196] In the above embodiments, multiple software modules have been described to realize user equipment, base station and / or core network functions, etc. As will be appreciated by those skilled in the art, such software modules may be provided in compiled or uncompiled form, and may be provided to corresponding hardware as a signal over a computer network, or may be provided on a recording medium. Furthermore, the functions performed by some or all of these software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred, as they may facilitate updating of the corresponding hardware to update its functions. Similarly, although the above example embodiments use transceiver circuits, at least some of the functions of the transceiver circuits may also be performed by software.

[0197] For example, although the core network functions have been described as being logical functions, they may be implemented using one or more computer processing devices having one or more hardware computer processors that are programmed with appropriate software instructions to provide the required logical functions (e.g., one or more computer processors forming part of the controller described with reference to Figures 5-7). Furthermore, all or part of these functions may be implemented in hardware as dedicated circuitry, for example using one or more dedicated integrated circuits such as application specific integrated circuits (ASICs).

[0198] Similarly, the functionality of the user equipment and base stations (gNBs) may be implemented using one or more computer processing devices having one or more hardware computer processors that are typically programmed with appropriate software instructions to provide the required logical functionality (e.g. one or more computer processors forming part of the controllers described with reference to Figures 2, 3 and 4). Furthermore, all or part of these functions may be implemented in hardware as dedicated circuitry, for example using one or more dedicated integrated circuits such as application specific integrated circuits (ASICs).

[0199] It should be noted that the controllers referenced in the descriptions of the UEs, gNBs, and core network nodes / functions (with reference to Figures 2-7) may comprise any suitable controller, such as, for example, an analog or digital controller. Each controller may include any suitable form of processing circuitry, including, for example, but not limited to, one or more hardware computer processors, microprocessor central processing units (CPUs), arithmetic logic units (ALUs), input / output (IO) circuitry, internal memory / caches (program and / or data), processing registers, communication buses (e.g., control, data and / or address buses), direct memory access (DMA) functionality, hardware or software counters, pointers, and / or timers.

[0200] Also, although the procedure has been described as dynamically changing the functional partitioning based on channel conditions, quality of service required, etc., the functional partitioning may be fixed with different pre-configured functional partitioning options for different tenant IDs and / or slice types within any tenant ID. Furthermore, while the initial context setup request has been described as an example to provide an indication of the functional partitioning, other equivalents may be used for this purpose. Also, the indication may be signaled at the time of slice index selection, such that a user plane slice is selected with the appropriate functional partitioning between CU and DU (e.g., as in the S1AP initial context setup request).

[0201] Note that while Figure 1 is depicted as representing an entire network slice, the core may have its own slice, and therefore the radio access network RAN. Similarly, the control plane (CP) and user plane (UP) may have entirely different slices. The mapping of RAN slices to core slices may vary depending on standardization and cellular operator policies.

[0202] A tenant may also be a wholesale customer, such as a MVNO or a Mobile Other Licensed Operator (MOLO), that does not own its own wireless network infrastructure, through which a Mobile Virtual Network Operator (MVNO) provides services to their customers. However, a tenant does not necessarily have to be an MVNO. A tenant may also be a corporate customer, such as a multinational corporation, a fleet of vehicles, an emergency service, a security service (e.g., a security company). Each tenant may have different requirements regarding which slice type to use based on service level agreements. The tenant concept allows mobile network operators today to differentiate between diverse customer requirements and provide customized services using one or more slices.

[0203] Also, although different devices have been described as having transceiver circuitry for communicating (i.e., transmitting and receiving) data with other devices / apparatuses, the transceiver functionality may be implemented by software on corresponding hardware controllers to communicate messages and / or information between different functions that are co-located on the same physical device.

[0204] Alternatively or additionally, the TUPF or at least one additional TUPF may be co-located with the access network (eg, to enable a stationary UE scenario).

[0205] It should be noted that the term "participating business" may be used instead of the term "tenant."

[0206] In the above embodiments, a communication system operating according to the 3GPP standard has been described, however, as will be appreciated by those skilled in the art, the techniques described herein may be employed in communication systems operating according to other standards, in particular any Orthogonal Frequency-Division Multiplexing (OFDM) based system, such as the Worldwide Interoperability for Microwave Access (WiMAX) standard.

[0207] In the above example, a mobile phone based telecommunication system was described. As will be appreciated by those skilled in the art, the techniques described in this application can be used in any communication system. In the general case, base stations and mobile phones can be considered as communication nodes or devices that communicate with each other. Other communication nodes or devices may include access points and user devices such as personal digital assistants, laptop computers, web browsers, etc.

[0208] Therefore, the above description may be considered to describe an example of a communication device of the following communication system: A communication device for a communication system in which network slicing is supported and at least one tenant can communicate using at least one slice type associated with the tenant is provided. The communication device comprises a controller and a transceiver, the transceiver configured to receive network slicing related information transmitted by a base station, the network slicing related information including at least one of (i) information identifying a tenant whose communication is supported via the base station and support for at least one of the network slice types of the tenant supported by the base station, and (ii) information including at least one communication parameter associated with the particular tenant and at least one of the particular slice types of the particular tenant, and the controller is configured to control communication, via the transceiver, using a slice having a slice type of the tenant associated with the communication device based on information provided in the received network slicing related information, particularly related to the tenant associated with the communication device and at least one of the slice types of the tenant associated with the communication device.

[0209] As indicated above, the network slicing related information may include information identifying at least one of a tenant whose communication is supported via the base station and a network slice type of the tenant supported by the base station. The controller may be configured to determine whether to camp on the cell based on at least one of whether the base station supports the tenant with which the communication device is associated and whether the base station supports a tenant slice type of the tenant with which the communication device is associated based on the information identifying the support provided in the received network slicing related information.

[0210] As indicated above, the network slicing related information may include at least one communication parameter associated with a particular tenant and at least one of a particular slice type for the particular tenant.

[0211] The at least one communication parameter may include at least one communication parameter identifying at least one random access channel (RACH) specific to at least one of a particular tenant and a particular slice type of the particular tenant. The controller may be configured to select a RACH preamble specific to at least one of the tenant to which the communication device is associated and a slice type of the tenant to which the communication device is associated based on the at least one parameter identifying at least one RACH preamble provided in the received network slicing related information, and to initiate a RACH procedure in which the selected RACH preamble is sent to the base station.

[0212] The at least one communication parameter may include at least one of a parameter representing a target power level for the base station to receive an initial transmission of a radio access channel (RACH) request (e.g., tenant / slice type specific PreambleInitialReceivedTargetPower), a parameter representing a power increment to be used by the communication device when transmitting repetitions of a RACH request (e.g., tenant / slice type specific PowerRampingStep), a parameter representing when the communication device should send a RACH (e.g., tenant / slice type specific prach-ConfigIndex), a parameter representing frequency resources (e.g., physical resource blocks) available for RACH access (e.g., tenant / slice type specific prach-FreqOffset), and a parameter representing the duration of a random access response window (e.g., tenant / slice type specific ra-ResponseWindowSize).

[0213] The at least one communication parameter may include at least one barring parameter, and the controller may be configured to control communications based on the at least one barring parameter.

[0214] The network slicing related information may be received in the broadcast of system information (e.g., a system information block (SIB) such as SIB2) by the base station.

[0215] Therefore, the above description may be considered to describe the following example of a base station: A base station for a communication system in which network slicing is supported and at least one tenant can communicate using at least one slice type associated with the tenant is provided. The base station includes a controller and a transceiver, the controller is configured to generate network slicing related information for transmission by the transceiver, the network slicing related information for transmission includes at least one of: (i) information identifying support for at least one of the tenants whose communication is supported via the base station and the network slice types of the tenants supported by the base station, (ii) information including at least one communication parameter associated with the particular tenant and at least one of the particular slice types of the particular tenant, and the transceiver is configured to transmit the network slicing related information generated by the controller to at least one of other base stations and communication devices.

[0216] As indicated above, the network slicing related information may include information including at least one communication parameter associated with a particular tenant and at least one of a particular slice type of the particular tenant.

[0217] The at least one communication parameter may include at least one parameter identifying at least one Random Access Channel (RACH) specific to a particular tenant and at least one of a particular slice type of the particular tenant. The transceiver may be configured to receive a RACH preamble specific to the particular tenant and at least one of a particular slice type of the particular tenant from a communication device. The controller may be configured to prioritize communications of the particular tenant and at least one of a particular slice type of the particular tenant based on the received RACH preamble.

[0218] The network slicing related information may include at least one communication parameter identifying a load and / or congestion condition for a particular tenant and at least one of a particular slice type of the particular tenant. The transceiver may be configured to transmit the communication parameter identifying a load and / or congestion condition for a particular tenant and at least one of a particular slice type of the particular tenant to at least one other base station via a base station-to-base station interface (e.g., as part of at least one of a resource status reporting procedure, a resource status report initiation procedure, and a load indication procedure).

[0219] The at least one communication parameter may include at least one barring parameter, the controller being operable to control communications based on the at least one barring parameter.

[0220] As indicated above, the network slicing related information may include information identifying at least one of the tenants whose communications are supported via the base station and the network slice types of the tenants supported by the base station. The transceiver may be configured to transmit the information identifying at least one of the tenants whose communications are supported via the base station and the network slice types of the tenants supported by the base station to another base station via a base station-to-base station interface (e.g., as part of at least one of an interface establishment procedure and a configuration update procedure with another base station).

[0221] The transceiver is configured to receive network slicing related information from the at least one other base station, the information including at least one of: (i) information identifying support by at least one other base station for a tenant whose communication is supported via the base station and at least one of the network slice types of the tenant supported by the base station, and (ii) information including at least one communication parameter associated with a particular tenant and at least one of the particular slice types of the particular tenant, and the controller is operable to determine a target of a handover based on the received network slicing related information.

[0222] Therefore, the above description may be considered to describe an example of a base station as follows: A base station for a communication system in which network slicing is supported and at least one tenant can communicate using at least one slice type associated with the tenant is provided, the base station comprising a controller and a transceiver, the controller configured to obtain data usage information for communication via the base station, the data usage information including respective separate data usage information for at least one of each tenant for which communication is performed via the base station and each network slice type for each tenant for which communication is performed via the base station, and the transceiver configured to provide the respective separate data usage information to a core node.

[0223] The controller may be further operable to obtain data usage information for communication via the base station, the data usage information may further include separate data usage information for at least one of: each radio access technology used for communication via the base station, each frequency (each frequency band) used for communication via the base station, each technology used for communication via the base station, uplink communications, and downlink communications.

[0224] Therefore, the above description may be considered to describe the following example of a base station: A base station device for a communication system in which network slicing is supported and at least one tenant can communicate using at least one slice type associated with the tenant is provided, the base station device comprising a distributed unit and a central unit, each of the distributed unit and the central unit comprising a controller and a transceiver, the controller of the distributed unit is configured to provide lower layer functionality of the base station device compared to the central unit, the controller of the central unit is configured to provide higher layer functionality of the base station device compared to the distributed unit, there are a plurality of possible functional divisions between the lower layer functionality provided by the distributed unit and the higher layer functionality provided by the central unit, and the controller of the distributed unit and the controller of the central unit are configured to dynamically reconfigure the functional division between the lower layer functionality provided by the distributed unit and the higher layer functionality provided by the central unit from a first of the possible functional divisions to a second of the functional divisions.

[0225] The controller of the central unit may be configured to determine which of the possible functional partitions should be used, and the controller of the distributed units and the controller of the central unit may be configured to reconfigure the functional partition according to the determination of the functional partition to be used by the controller of the central unit. The controller of the central unit may be configured to determine which of the possible functional partitions should be used based on at least one of channel conditions, quality of service requirements, an identification of a communication device in service, an identification of a slice to use for communication, and an identification of a tenant for which communication is performed via the base station. The controller of the distributed units and the controller of the central unit may be configured to reconfigure the functional partition according to the determination of the functional partition to be used by a core node.

[0226] Many other modifications will be apparent to those skilled in the art, but will not be described in detail here.

[0227] This application claims priority to UK Patent Application No. 1613899.2, filed August 12, 2016, the disclosure of which is incorporated herein in its entirety.

Claims

1. 1. A Radio Access Network (RAN) node, comprising: means for transmitting to another RAN node a RAN node interface setup request message, a RAN node configuration update message, or a resource status update message, the message including information indicating at least one slice type for at least one tenant of the network; At least one respective slice corresponding to the at least one slice type is supported by the RAN node. RAN node.

2. The RAN node interface setup request message, RAN node configuration update message, or resource status update message comprises: Information indicating the user plane endpoints, or Information showing the load status of each slice type 2. The RAN node of claim 1, comprising:

3. 1. A method in a Radio Access Network (RAN) node, comprising: sending, to another RAN node, a RAN node interface setup request message, a RAN node configuration update message, or a resource status update message, the message including information indicating at least one slice type for at least one tenant of the network; At least one respective slice corresponding to the at least one slice type is supported by the RAN node. A method in a RAN node.

4. The RAN node interface setup request message, RAN node configuration update message, or resource status update message comprises: Information indicating the user plane endpoints, or Information showing the load status of each slice type The method of claim 3, comprising any one of the following:

Images