Supporting slices on a cell level in a telecommunication network

Abstract

Disclosed is a method of operating a User Equipment (UE) in communication with a telecommunication network, wherein the UE and the telecommunication network support network slicing, wherein the UE ind

Description

Network slicing is supported in the Fifth Generation System, 5GS, (Release 15, Rel-15), where a User Equipment, UE, requests to register for a set of slices by sending a ‘requested NSSAI’ (Network Slice Selection Assistance Information) and the network allocates the set of slices that are allowed to be used, where these slices are indicated in the ‘allowed NSSAI’. The requested NSSAI or the allowed NSSAI can contain a maximum of 8 slices (i.e. 8 S-NSSAIs) -the definition / encoding of these information elements, lEs, can be found in 3GPP TS 24.501 V17.4.1. When sending the requested NSSAI, the UE can populate it based on the configured NSSAI and / or a previous allowed NSSAI that may be available in the UE. Note that the configured NSSAI can contain up to a maximum of 16 slices. In the prior art, the allowed NSSAI includes S-NSSAIs that the UE is allowed to use in the serving Public Land Mobile Network, PLMN, and current registration area, RA. basis, i.e. any allowed NSSAI which is provided to the UE is valid within the current registration area of the UE and, as such, the UE can expect that any S-NSSAI in the allowed NSSAI would be accessible. Moreover, the UE can establish and maintain Protocol Data Unit, PDU, session(s) with any S-NSSAI in the allowed NSSAI. The registration area of the UE is a set of tracking areas, Tas, each of which is identified by a TA Identity, TAI, and may include a set of cells that broadcast the same Tracking Area Code, TAC. All cells in a TA support the same set of S-NSSAIs. Note that after a successful registration with the Access and Mobility Management Function, AMF, of the core network of the 5GS, the UE is provided with a Registration Area, RA, i.e. with a list of TAIs that define the areas where the UE can move within / into without needing to register again. The AMF determines the UE’s Registration Area, RA, in way that Allowed NSSAI slices are available in all TAs of RA. The concept of network slicing has evolved in Release-16 and Release-17. For example, in Rel-16, the UE may not be able to use a slice, and hence will not get an allowed NSSAI, until a secondary authentication and authorization succeeds for any S-NSSAI that requires this. As such, the allowed NSSAI may only be obtained when this procedure successfully completes. In another example, a feature was introduced in Rel-17 in which the UE can only be registered to a slice if the maximum number of UEsthat are registered forthat slice has not reached the maximum number of UEs that can be supported, and so on. In all the network slicing features so far defined, a common assumption exists which is that the allowed NSSAI is on a per Registration Area, RA, basis, and the UE expects to use the slice regardless of the TA in which the UE is in within the RA. However, new use cases have emerged for which a set of slices may not be available across all the TAs of the RA. Some slices may be available in one or more TAs but not in another. A slice group may also be defined such that, e.g.: • A slice group 1 is known to contain the slices identified by S-NSSAI A and S-NSSAI B • A slice group 2 is known to contain slices identified by S-NSSAI C As an example, Figure 1 shows an example deployment scenario with two slice groups within the RA of the UE. In Figure 1, both Cell 1 and Cell 2 broadcast TAI 1, whereas Cell 3 and Cell 4 broadcast TAI 2. TA1 contains slice group 1 and TA2 contains both slice group 1 and slice group 2. Where slice group 1 contains S-NSSAIs A and B, whereas slice group 2 is composed of S-NSSAI C. Note that Figure 1 just illustrates an example of how slices can be deployed in different TAs of an RA. It may be the case that one cell alone supports a certain slice X, and so on. There may also be one, two or more groups. The availability of certain slices in specific TAs introduces additional problems and these are explained in more detail in the following. A particular problem may be experienced when / if a slice is available in one TA but not the other as is described below. As indicated earlier, a prior art UE assumes that all the slices in the allowed NSSAI are available in the entire RA. If this assumption is no longer valid due to new deployment scenarios, such as those set out above, then the UE needs to be informed so that this basic yet important assumption is no longer considered by the UE, and that the UE will have to treat certain slices as allowed / available only within certain TAs of the RA. There are currently no means by which a UE in this scenario can be provided with this indication and, moreover, not all UEs would be capable of processing such new deployments. For example, a Rel-15 UE would not be able to “comprehend” or process a non-homogeneous slice availability within an RA. Therefore, it is an aim of embodiments of the present invention to provide a method to inform certain UEs about any new deployments while also being able to serve UEs of a previous release in a backwards compatible manner. Once the network determines which UE(s) can be informed about the new deployment, a subsequent aspect that needs to be addressed is about the actual indication and its contents. In other words, what information is sent to the UE and which information element, IE, should be used to do so must be defined. For example, whether and how to indicate which slice belongs to which group needs to be described and specified. Moreover, how the UE behaves when it receives the new indication(s) is also not currently defined. This depends on assumptions that can be made regarding the deployments and how such slices can be accessible. For example, how the UE decides to use or request a slice based on the current TA is yet to be defined. Another potential problem is about the status of a Protocol Data Unit, PDU, session that might have been established in a previous TA but now the UE has moved into a new TA where the slice that is associated with that session is not available: should the session be released or kept? As can be seen, the above are a few examples of certain issues that should be addressed. A standardized set of solutions is desirable so that all the UEs behave in a manner that is consistent with the expected feature. According to the present invention there is provided an apparatus and method as set forth in the appended claims. Other features of the invention will be apparent from the dependent claims, and the description which follows. According to a first aspect of the present invention, there is provided a method of operating a User Equipment, UE, in communication with a telecommunication network, wherein the UE and the telecommunication network support network slicing, wherein the UE indicates to the telecommunication network its ability to support at least one slice on either a per-cell level or a per-Tracking Area, TA, level. In an embodiment, the UE receives information on one or more slices or slice groups from an Access and Mobility Management Function, AMF, in the telecommunication network. In an embodiment, the UE stores the information received from the AMF. According to a second aspect of the present invention, there is provided a method of operating a telecommunication network in communication with at least one UE, wherein the UE and the telecommunication network support network slicing, wherein the telecommunication network informs the at least one UE, of one or more slices or one or more associated slice groups which are available in one or more of a cell, a Tracking Area or Registration Area, RA. In an embodiment, the telecommunication network informs the at least one UE via an Access and Mobility Management Function, AMF. In an embodiment, the AMF provides priority information to the at least one UE, the priority information being associated with at least one slice group. In an embodiment, the telecommunication network provides information to the at least one UE indicating one or more slices which belong to a specific slice group. In an embodiment, the slice group is identified by a Group ID, GID. In an embodiment, one or more slice is / are only available in one slice group. According to a third aspect of the present invention, there is provided a UE operable to perform the method of the first aspect. According to a fourth aspect of the present invention, there is provided a telecommunication network operable to perform the method of the second aspect. Although a few preferred embodiments of the present invention have been shown and described, it will be appreciated by those skilled in the art that various changes and modifications might be made without departing from the scope of the invention, as defined in the appended claims. For a better understanding of the invention, and to show how embodiments of the same may be carried into effect, reference will now be made, by way of example only, to the accompanying diagrammatic drawings in which: Figure 1 shows an illustration of an example deployment with heterogneous slice availability within an RA, according to an embodiment of the present invention. In a first embodiment, the UE indicate to the network, either via RRC or NAS messages (which may be existing messages or new messages), whether the UE supports slices on a per cell level or per tracking area (TA) level, or whether the UE supports the use / access of slices that are not homogeneously deployed in a given registration area (RA). Note that the name of the indication is just an example and may be different. However this is achieved, the UE indicates to the network that it is capable to process, support, etc, the availability of slices in some areas (e.g. one or more cells, one or more TAs) of the RA. For example, this capability may be defined as a new bit in the 5GMM capability IE that the UE sends in a Registration Request message. Alternatively, the UE provides this indication in any other IE (new or existing) that can be sent in any NAS message. Alternatively, this indication may be sent in the RRC message to the RAN. Note that the indication from the UE may be in the form of a bit position (e.g. in an existing IE) or in the form of a new IE. Upon reception of this new indication by the Radio Access Network, RAN, entity (e.g. base stations, gNB), the RAN entity may locally save this information in the UE’s context and determine whether the UE supports the use / access, etc, of slices within an area (e.g. one or more cells, one or more TAs) of the RA. The RAN entity may further send this indication to the core network (e.g. AMF) using any message e.g. on the N2 protocol interface. The network e.g. AMF, may receive an indication that the UE supports the use / access, etc, of slices within some areas (e.g. one or more cells, one or more TAs) of the RA, where this indication may be received in any IE of a NAS message (e.g. in the 5GMM capability IE of the Registration Request message) or this indication may be received from the RAN entity as described above. If the network supports the deployment of slices, or the network supports slices, in different areas (e.g. one or more cells, one or more TAs) of the RA, then the network may indicate to the UE about this support using any IE (e.g. 5GS network feature support IE). The indication may be in the form of a new bit or a new IE altogether. The value of this indication is set such that the network indicates if the slices are available in all the TAs (or cells) of the RA, or only within some areas (e.g. one or more cells, one or more TAs) of the RA. Note that the meaning of the indication may be for different levels of slice support e.g. per cell, more than one cell, a TA, more than one TA, etc. The UE may receive an indication that slices are not homogeneously deployed in an RA, or that slices are available in certain areas (e.g. one or more cells, one or more TAs) of the RA. The UE may determine that slices are either available in all of the RA or not based on this new indication e.g. that is received in the 5GS network feature support IE, or based on any other RRC message (which may be dedicated or broadcast). Note that the UE may make the determination about the support of certain slices in certain areas (e.g. one or more cells, one or more TAs) of the RA based on the value received in an IE of the NAS message (e.g. based on a new bit position in the 5GS network, feature support IE, or based on a new IE in any NAS message), or based on any RRC message (dedicated or broadcast). The UE may optionally make this determination in combination with at least one other IE that may be received in any NAS message e.g. based on additionally receiving a new IE indicating which slices are available (e.g. in some TAs), or based on receiving an allowed NSSAI IE and optionally a new IE which indicates which slices are available (e.g. in some TAs). Note that the steps above can also apply if the indications from the UE and / or the network have other meanings such as “support of slice group per TA”, or any combination of new indications of support of new features. As such the examples provided above are not to be limited to the names given to them but can be general to cover the general support of heterogenous slice deployment within an RA, optionally where the slices are known to belong to a group (identified by a group ID), and optionally where a slice may or may not be only available in one group. Note that herein, the term group ID (GID) may refer to a set of slices (e.g. set of S-NSSAIs) that are considered to be part of the group, or may explicitly directly refer to the set of slices themselves. For simplicity, the term GID will be used herein. It should be again noted that this is an example of how slices can be deployed in a heterogeneous manner within an RA and it should not be taken as a limitation i.e. the use of GID is an example only, but other representations of how slices are deployed within an RA may be possible, and hence the method set out herein also apply for these other potential representations. In a second embodiment, a technique is deployed to indicate the slices which are supported in an RA / TA. The following describes the means by which the UE determines which slices are available in the sub-areas of an RA e.g. in certain cells and / or TAs, etc. Note that these methods may be used in combination with the details set out above e.g. these methods may be used for / by a UE that supports access to slices that are deployed in a heterogeneous manner, and / or by a network that supports slices that are deployed in a heterogeneous manner. Note: the term “that are deployed in a heterogeneous manner” is not to be considered as a restriction but rather as an example of a deployment in which the available slices are not accessible available in all of the RA but rather in some sub-areas of the RA e.g. on a cell or TA, level within the RA, or it may mean that the slices that are allowed for a UE are not available in the UE’s entire RA as is currently the case in the prior art. The network defines a GID which may represent a set of slices (e.g. S-NSSAIs), optionally with information about the availability of the GID either on a per cell level or TA level or RA level. For the sake of simplicity, the example of TA level will be used hereafter however this is to be considered as an example only and not a limitation. As such, unless stated otherwise, the same steps would apply for cell level or RA level. Moreover, TA level may contain more than one TA and, as such, it should be considered as a set of TA (which then also means that it can be a set of cells, etc). The network e.g. AMF stores information about each GID, the corresponding set of slices, and the TA(s) where the GID is available. For a UE that supports heterogeneous slices (as described earlier), the AMF determines whether the use of heterogeneous slices is permitted for the UE e.g. based on local configuration and / or subscription information and / or indication from the UE about the support of the feature. If the network determines that use of heterogeneous slice is allowed for the UE then: • The network should indicate that heterogeneous slice availability is supported / allowed for the UE, where this may be achieved by providing an indication to the UE as described earlier • The network should send the detailed information indicating which slices are available in their corresponding TA: o The network may send a new IE indicating any of the following: a GID, the set of slices that correspond to the GID, and optionally the TA(s) where the GID is available. Note that this information may also contain priority information to indicate which priority is associated with a GID, where the priority may be based on predefined level or an explicit priority indication, etc. o The network may also indicate which slice is available in all the TAs or in the UEs RA. This may be achieved by either: ■ Sending any such slice in the Allowed NSSAI IE (which is the current IE that is used), or ■ Indicating explicitly which GID and / or slices are available in all the TAs, if any • The network may also inform the RAN about the UE’s support of heterogeneous slices e.g. as part of the UE’s context that is provided from the core network (e.g. AMF) to the RAN If the network determines that use of heterogeneous slice is NOT allowed for the UE, e.g. either because the subscription and / or local configuration does not permit it, or because the UE does not support heterogeneous slices (e.g. a UE of a previous release, or a UE that simply does not support the feature), then: • The network (e.g. AMF) indicates that heterogeneous slices are not supported (or does not indicate that heterogeneous slices are supported) • The network determines if there is any slice, either from the UE’s requested slices or from the slices that are marked as default in the UE’s subscription, which is available in the entire RA: o If at least one such slice is available (in the entire RA), then the network provides this slice in the allowed NSSAI if the slice is indeed allowed to be used (e.g. no other condition needs to be verified). For example, if the slice is subject to secondary authentication or authorization, then the slice is sent to the UE as a pending NSSAI instead. However, the main idea is that the network determines if there is any potential slice that can be accessed / allowed for the UE in the entire RA, and if yes, then the network sends it to the UE in the appropriate IE (e.g. Allowed NSSAI IE or Pending NSSAI IE, or both lEs may be sent if needed / possible). In this option, the proposal may be implemented such that the AMF first determines the RA for the UE and based on that verifies which slices are available in the determined RA and then handles the slices as described above. The AMF may be configured to operate in this manner o If at least one slice is available, but not in the entire RA, then the AMF may determine the RA to be the set of TAs where the slice is available. Then the AMF handles the at least one slice as described in the bullet point above. In this option, the AMF may first determine the slices that are available in some TAs and based on that the AMF determines that these TAs are what composed the RA, and then handles the slices as described in the bullet point above given that the RA is now determined. The AMF may be configured to operate in this manner o If no slice can be provided to the UE such that at least one slice is available in the entire RA, then the AMF may reject the UE’s registration, or deregister the UE, and include the appropriate cause in the NAS message, where the cause may be an existing cause value or a new value The UE may send a different / new request for slices, where the request may be a request for a GID. For example, a new requested GID IE may be defined (where this is to be considered as an example of an IE name and not a restriction). The UE may be configured with the GID that can be requested e.g. either the UE is pre-configured in the ME (mobile equipment), or in the USIM (e.g. in an existing elementary file or a new elementary file), or from a previous registration with the network where the UE may have obtained this GID. The GID that is requested by the UE may be based on a priority level, or a default priority level (e.g. for initial registration, where priority may not be known for the case that it can only be known after registration, etc), or based on userchoice / input. The priority level may be configured in the UE using the means stated above for the GID. As such, the GID may also have a corresponding priority level. The UE may request the GID with the highest priority or may request a set of GIDs in a priority order which may be explicit or implicit e.g. based on the position of the GID in the list of requested GID. As such, the network may determine to indicate support of heterogeneous slices e.g. based on this new requested GID IE, and / or based on a new indication from the UE, or any combination. For example, the reception of a new requested GID IE, optionally from a UE, may act as an implicit indication that heterogeneous slices is supported by the UE, however the NAS message may also contain an explicit indication about the support as described earlier. A UE may receive an indication that the network supports heterogeneous slices, where this indication may be an explicit indication (e.g. in an IE of an RRC / NAS message, or broadcast message) or may be a new IE e.g. allowed GID IE where this new IE may contain the GID and optionally the set of slices that they contain and optionally the TAs where each GID is available. Note that this may be received in addition to the existing Allowed NSSAI IE (or pending NSSAI IE) which is considered to refer to slices that are available in the entire RA. When the UE receives the indication as described, the UE determines that the network supports heterogeneous slices. The UE stores the received information accordingly and may use it as described in the following. In a third embodiment, the UE uses the slice GID. The UE may have a stored GID (where the contents of the GID is as listed earlier e.g. a GID is associated with a set of slices, the TA(s) where the GID is available, the priority level of a GID, or any other information, and in any combination), where this information may have been configured in the UE using the means described earlier (e.g. pre-configured, or provided by the network from a previous registration, etc) or the UE may receive this information in a new IE that is included in any NAS message e.g. Registration Accept message. The UE should store any such information if received in any NAS message. The UE may determine that heterogenous slices is supported when the UE either receives an explicit indication about it (e.g. in the 5GS network feature support IE that may be sent in the Registration Accept message) or when the UE receives a new IE with a GID as described earlier. The UE stores and uses the GID as is described next. The GID may have a priority information and, as such, the UE may determine to use a GID (or a set of slices optionally corresponding to a GID) with a certain priority, where this priority may be part of the information that is received (optionally from the network e.g. in any NAS message) or may be based on a configuration in the UE or may be based on user input / preference, or any combination or other method. The RRC layer in the UE should indicate a GID to the NAS layer optionally in addition to the current TA, where the GID indicates the GID alone or the set of slices associated with it. As such, the network e.g. RAN, should broadcast GID information where the GID may be the GID supported in the current cell and / or the GID supported in neighboring cells. The NAS layer may receive one or more GIDs from the RRC (or lower layers) indicating e.g. the GID of the current cell and / or the GID of a neighboring cell. Based on this information, the NAS may determine to register to use a certain GID (and hence a certain set of slices) by sending a Registration Request and indicating the GID that the UE wants to use, and optionally indicating the set of slices that correspond to the GID, and optionally indicating a priority level. The UE may do so if the selected GID is supported in the current cell or TA. Additionally or optionally, the NAS layer may determine to select / use a GID in a neighbouring cell based on the GID being of a higher priority than the current GID that is either being used or that is in this cell / TA. The NAS may consequently (re-)select a GID, e.g. based on priority of the GID or user preference or local UE policies or the UE Route Selection Policy, URSP, rules in the UE, etc, and once a GID is selected, the NAS layer indicates the selected / preferred GID (or optionally a list of selected GID in some priority order) to the lower layers (or RRC). The RRC may receive a set of selected GIDs, optionally with a priority order. The RRC may perform cell reselection based on the highest priority GID if it is available. Once a cell is selected based on a GID (as described), the RRC indicates the GID and optionally the TA of the cell. The NAS may receive an indication from the lower layers (e.g. RRC) about a GID and optionally a TA that is different from the current GID and / or TA, or that maybe the selected GID that the UE has not yet registered to. When this occurs, the NAS may determine that the GID in the current cell / TA is different from the last / previous GID of the previous cell / TA, or may determine that this is a new GID that has not yet been registered to. Based on this determination, the UE sends a Registration Request message and includes the GID (or set of slices that it corresponds to) in order to register to the slices. At least some of the example embodiments described herein may be constructed, partially or wholly, using dedicated special-purpose hardware. Terms such as ‘component’, ‘module’ or ‘unit’ used herein may include, but are not limited to, a hardware device, such as circuitry in the form of discrete or integrated components, a Field Programmable Gate Array (FPGA) or Application Specific Integrated Circuit (ASIC), which performs certain tasks or provides the associated functionality. In some embodiments, the described elements may be configured to reside on a tangible, persistent, addressable storage medium and may be configured to execute on one or more processors. These functional elements may in some embodiments include, by way of example, components, such as software components, object-oriented software components, class components and task components, processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuitry, data, databases, data structures, tables, arrays, and variables. Although the example embodiments have been described with reference to the components, modules and units discussed herein, such functional elements may be combined into fewer elements or separated into additional elements. Various combinations of optional features have been described herein, and it will be appreciated that described features may be combined in any suitable combination. In particular, the features of any one example embodiment may be combined with features of any other embodiment, as appropriate, except where such combinations are mutually exclusive. Throughout this specification, the term “comprising” or “comprises” means including the component(s) specified but not to the exclusion of the presence of others. Attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and / or all of the steps of any method or process so disclosed, may be 12 combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and 5 drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features. The invention is not restricted to the details of the foregoing embodiment(s). The invention 10 extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.

Claims

1. A method of operating a telecommunication network in communication with at least one 5 UE, wherein the UE and the telecommunication network support network slicing, wherein the telecommunication network informs the at least one UE, of one or more slices or one or more associated slice groups which are available in one or more of a cell, a Tracking Area or Registration Area, RA wherein the telecommunication network informs the at least one UE via an Access and Mobility Management Function, AMF and wherein the AMF provides priority 10 information to the at least one UE, the priority information being associated with at least one slice group, wherein the telecommunication network provides information to the at least one UE indicating one or more slices which belong to a specific slice group and wherein the slice group is identified by a Group ID, GID.15 2. The method of claim 1 wherein one or more slice is / are only available in one slice group.

3. A telecommunication network operable to perform the method of any preceding claim.

Images