Improvements in and relating to slice management in a telecommunication network
Patent Information
- Application Number
- GB2024010569
- Authority / Receiving Office
- GB · GB
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-08-23
- Filing Date
- 2024-07-19
- Publication Date
- 2025-02-26
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
The present invention relates to the management of network slices in a telecommunication network. It particularly relates to a scenario where a slice requires replacement. Embodiments find particular, but not exclusive, use in a Fifth Generation (5G) system. The %G System (5GS) supports network slice replacement and network slice instance replacement as described in Sections 5.15.19 and 5.15.20, respectively, of 3GPP TS 23.501 V18.2.1, both of which are reproduced below: 5.15.19 Support of Network Slice Replacement The Network Slice Replacement feature is used to replace an S-NSSAI with an Alternative S-NSSAI when an S-NSSAI becomes unavailable or congested. The Network Slice Replacement may be triggered in the following cases: If the NSSF detects that an S-NSSAI becomes unavailable or congested (e.g. based on 0AM or NWDAF analytics output), it sends network slice availability notification for the S-NSSAI to the AMF. The notification may include an Alternative S-NSSAI which can be used by the AMF to replace the S-NSSAI. The NSSF notifies the AMF when the S-NSSAI is available again. If the PCF detects that an S-NSSAI becomes unavailable or congested for a User Equipment (UE) (e.g. based on 0AM or NWDAF analytics output), it sends access and mobility related policy notification to the AMF. The notification may include an Alternative S-NSSAI which can be used by the AMF to replace the S-NSSAI. The PCF notifies the AMF when the S-NSSAI is available again for the UE. The OAM sends notification to AMF when an S-NSSAI becomes unavailable or congested (and also when this S-NSSAI becomes available again) and provides the Alternative S-NSSAI to AMF. Based on the notification above from NSSF or PCF or OAM, the AMF may determine that an S-NSSAI is to be replaced with Alternative S-NSSAI. For roaming case, the AMF may receive network slice availability notification of the HPLMN S-NSSAI from NSSF in the HPLMN via NSSF in VPLMN, to trigger the Network Slice Replacement of the HPLMN S-NSSAI as described in clause 5.15.6. NOTE 1: It is recommended that, the operator configures to use only one mechanism when triggering the Network Slice Replacement for S-NSSAI. The AMF determines the Alternative S-NSSAI for a UE registered with the S-NSSAI based on the notification from NSSF or PCF, or based on local configuration if the NSSF or PCF do not provide an alternative S-NSSAI. The Alternative S-NSSAI shall be supported in the UE Registration Area. If AMF cannot determine the Alternative S-NSSAI for the S-NSSAI, e.g. PCF or NSSF doesn't provide Alternative S-NSSAI, the AMF may further interact with the PCF to determine the Alternative S-NSSAI. The event trigger in AMF for interacting with PCF is described in clause 6.1.2.5 of TS 23.503
[45] . The UE indicates the support of Network Slice Replacement feature during the UE Registration procedure. For supporting UE in CM-CONNECTED state and if there is a PDU Sessions in the UE context associated with the S-NSSAI that needs to be replaced, the AMF provides the Alternative S-NSSAI for this S-NSSAI in the Allowed NSSAI and in the Configured NSSAI, if not included yet, and the mapping between S-NSSAI(s) to Alternative S-NSSAI(s) to the UE in UE Configuration Update message as follows: for non-roaming UEs, the AMF provides the mapping of the S-NSSAI to the Alternative S-NSSAI to the UE. for roaming UEs when the VPLMN S-NSSAI has to be replaced by a VPLMN Alternative S-NSSAI, the AMF provides the mapping of the VPLMN S-NSSAI to the Alternative VPLMN S-NSSAI to the UE. for roaming UEs when the HPLMN S-NSSAI has to be replaced by an Alternative HPLMN S-NSSAI, the AMF provides the mapping of the HPLMN S-NSSAI to the Alternative HPLMN S-NSSAI to the UE. NOTE 2: The Alternative S-NSSAI or Alternative HPLMN S-NSSAI does not have to be part of the Subscribed S-NSSAI as long as they can be mapped to a HPLMN S-NSSAI that is part of the Subscribed S-NSSA / s. For the supporting UE in CM-IDLE state, when the UE establishes a NAS signalling connection, e.g. through a Service Request procedure or through a UE registration procedure, if the AMF determines that the S-NSSAI is to be replaced and there is a PDU Session associated with the S-NSSAI in the UE context, the AMF sends the mapping of the S-NSSAI to the Alternative S-NSSAI to the UE in the UE Configuration Update message or in the Registration Accept message. NOTE 3: It is left to AMF local policy whether to send the mapping of the S-NSSAI to the Alternative S-NSSAI to the UE when there is no PDU session associated with the S-NSSAI or wait and send the mapping of the S-NSSAI to the Alternative S-NSSAI to the UE when the UE establishes a PDU Session associated with the S-NSSAI. During a new PDU Session establishment procedure towards an S-NSSAI, if the UE is provided with the mapping of the S-NSSAI to an Alternative S-NSSAI, the UE provides both the Alternative S-NSSAI and the S-NSSAI in the PDU Session Establishment message. When the AMF receives the Alternative S-NSSAI and the S-NSSAI in the PDU Session Establishment message, or when the AMF receives only the S-NSSAI in PDU Session Establishment message the AMF determines that the S-NSSAI is to be replaced with the Alternative S-NSSAI, the AMF includes both the Alternative S-NSSAI and the S-NSSAI to the SMF. if the UE is not provided with the mapping of the S-NSSAI to the Alternative S-NSSAI, the UE provides the S-NSSAI in the PDU Session Establishment message. When the AMF determines that the requested S-NSSAI is to be replaced with the Alternative S-NSSAI and if the UE supports Network Slice Replacement, the AMF performs UE Configuration Update procedure to reconfigure the UE with the Alternative S-NSSAI. The AMF continues the PDU Session establishment procedure with the Alternative S-NSSAI and provides both the Alternative S-NSSAI and the S-NSSAI to the SMF. The SMF proceeds with the PDU Session establishment using the Alternative S-NSSAI. The SMF sends the Alternative S-NSSAI to NG-RAN in N2 SM information and to UE in PDU Session Establishment Accept message. For existing PDU Session associated with an S-NSSAI that is replaced with the Alternative S-NSSAI, after the AMF sends mapping of the S-NSSAI to the Alternative S-NSSAI to the supporting UE in UE Configuration Update message, the AMF sends updates to the SMF of the PDU Session, e.g. triggering Nsmf_PDUSession_UpdateSMContext service operation, that the PDU Session is to be transferred to Alternative S-NSSAI and includes the Alternative S-NSSAI as follows (see details in clause 4.3.3 of TS 23.502 [3]): If the SMF determines that the PDU Session needs to be retained (e.g. if the anchor UPF can be reused with the alternative S-NSSAI and SSC mode 1), the SMF sends the Alternative S-NSSAI to the UPF in the N4 message, to the NG-RAN in N2 message and to the supporting UE in PDU Session Modification Command message. If the SMF determines that the PDU Session needs to be re-established, the SMF sends the Alternative S-NSSAI to the supporting UE either in PDU Session Modification Command if the PDU Session is of SSC mode 3, or in PDU Session Release if the PDU Session is of SSC mode 2 or SSC mode 1, to trigger the re-establishment of the PDU Session. The UE includes both, the S-NSSAI and the Alternative S-NSSAI in the PDU Session Establishment message. When the AMF is notified that the S-NSSAI is available again or the congestion of the S-NSSAI has been mitigated, if the AMF has configured the supporting UE with the Alternative S-NSSAI, and the AMF determines for the UE to use the S-NSSAI again, the AMF reconfigures the supporting UE (e.g. by using UE Configuration Update message) to use the S-NSSAI. If there is an existing PDU Session associated with the Alternative S-NSSAI, the AMF sends updates to the SMF of the PDU Session, e.g. triggering Nsmf_PDUSession_UpdateSMContext service operation, that the PDU Session is to be transferred to the S-NSSAI. During a handover procedure, if an S-NSSAI has to be replaced with an Alternative S-NSSAI, the handover procedure (including any PDU session associated with the S-NSSAI to be replaced) shall continue unaffected by the Network Slice Replacement. Any Network Slice Replacement for the S-NSSAI shall not take place during the handover. 5.15.20 Support of Network Slice Replacement The Network Slice Instance Replacement is used when a PDU Session for a given S-NSSAI is established using a selected Network Slice instance and the S-NSSAI corresponding to this Network Slice instance is associated with multiple Network Slice instances. In this case, the network may change the Network Slice instance for the S-NSSAI if the selected Network Slice instance is no longer available (e.g. due to overload). The AMF may subscribe with the NSSF for notifications when any of the Network Slice instances served by the AMF is congested or no longer available. In case of roaming, the NSSF of VPLMN subscribes with the NSSF of the HPLMN for notifications. When the NSSF notifies the AMF that a Network Slice instance is congested or no longer available, for some of PDU Sessions associated with the Network Slice instance that is no longer available, the AMF may delete old NSI ID corresponding to the Network Slice instance that is no longer available and the SMF of the PDU Session(s) selected by using such old NSI ID is informed by the AMF to release the PDU Session(s). Subsequently, the SMF triggers the impacted UE(s) to establish new PDU session(s) associated with the same S-NSSAI as described in clause 5.6.9.2 for PDU Session(s) of SSC Mode 2 and SSC Mode 3. The AMF selects a new Network Slice instance for the given S-NSSAI during PDU Session Establishment. From the above, particularly the passage - “The UE includes both, the S-NSSAI and the Alternative S-NSSAI in the PDU Session Establishment message” - it can be seen that when the slice replacement procedure requires the establishment of a new Protocol Data Unit, PDU, session, the UE should provide the Single - Network Slice Selection Assistance Information (S-NSSAI, i.e. the slice identifier) which is associated with the current PDU session as well as the alternative S-NSSAI. The UE may provide an S-NSSAI during a PDU session establishment procedure e.g. based on its UE Route Selection Policy (URSP) rules. However, the S-NSSAI is an optional parameter which means that the UE may not provide it. For example, the URSP rules may be such that a default rule is used for which there is no S-NSSAI which can be provided. In this case, the UE does not provide an S-NSSAI and it is then up to the network (i.e. the Access and Mobility management Function, AMF) to select a slice for the PDU session. Although the UE may not select an S-NSSAI, the network (i.e. the Session Management Function, SMF) provides the selected S-NSSAI in the PDU Session Establishment Accept message. As such, regardless of whether the UE provided an S-NSSAI or not, the UE will know the slice that is being used for the PDU session based on the S-NSSAI parameter that is received in the PDU Session Establishment Accept message. A slice may be congested and for this the network may provide a back-off (BO) timer to the UE and the UE will not be allowed to request a PDU session for the slice in question. However, the BO timer is not always associated with an S-NSSAI. For example, during a PDU session establishment procedure, the UE may not provide an S-NSSAI as explained above. The SMF may be congested for a particular slice and so the network may apply congestion control to avoid more load on the slice. If the network - in the case that the UE did not actually provide an S-NSSAI during the PDU session establishment - selects the slice for the UE and the slice happens to be congested, then the BO timer that is provided to the UE is deemed to be associated with “no S-NSSAI”. This means that the UE, while the BO timer is running, is not allowed to request a PDU session such that no S-NSSAI is provided by the UE (except for emergency services). Therefore, the BO timer is associated with “no S-NSSAI”. However, the UE can actually send a request to establish a PDU session for another slice if the S-NSSAI is actually determined and provided by the UE. The following summary can thus be made regarding the association of a BO timer with slice congestion: • If the UE explicitly provided an S-NSSAI during the PDU session establishment procedure and a BO timer is provided to the UE, then the UE considers the BO timer to be associated with the S-NSSAI that is explicitly provided by the UE. The UE is not allowed to send another request for this S-NSSAI until the timer expires or is stopped. However, the UE is allowed to send another request for a different S-NSSAI (including “no S-NSSAI”). • If the UE did not provide an S-NSSAI during the PDU session establishment procedure and a BO timer is provided to the UE, then the UE considers the BO timer to be associated with no S-NSSAI. The UE is not allowed to send any 5GSM request that is not associated with any slice (i.e. that is associated with “no S-NSSAI") until the timer expires or is stopped. The UE can send another request for another slice that must be provided and that must be different from “no S-NSSAI”. From the above it can be seen that the association of a BO timer with a slice really depends on the information that the UE provided during the PDU establishment procedure. A first problem experienced in the prior art is a lack of clarity with respect to which S-NSSAI the UE should provide when establishing a new PDU session due to slice replacement. As indicated above, when the UE established a new PDU session due to slice replacement, the UE is supposed to provide the following parameters: 1. an S-NSSAI which is associated with the current PDU session (that is to be replaced), and 2. the alternative S-NSSAI which is the new S-NSSAI that replaces the existing S-NSSAI (identified by the first bullet point above). The problem can be explained as follows. For the first parameter, i.e. the S-NSSAI which is associated with the current PDU session, it is unclear how to actually determine it especially because of the possibility that the UE may not have provided it during the PDU session establishment procedure. For this case, how the UE should determine the S-NSSAI is unclear. A second problem is a lack of AMF behavior when an alternative S-NSSAI is not valid or does not exist. The UE may not provide an alternative S-NSSAI for which the AMF is expected to retrieve one. However, if the AMF is not able to retrieve an alternative S-NSSAI, then it is not clear how the AMF should behave in this case. The same problem exists if the UE did provide an alternative S-NSSAI which is present in the UE’s context, or which is not valid. 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 if the UE attempts to establish a Protocol Data Unit, PDU, session due to slice replacement of a slice identified by a Single - Network Slice Selection Assistance Information, S-NSSAI, for an alternative S-NSSAI, the UE indicates to the telecommunication network an S-NSSAI value previously received in a PDU Session Establishment Accept message in connection with an existing PDU session. In an embodiment, the alternative S-NSSAI is sent to the network in a PDU Session Establishment Request message. In an embodiment, the PDU Session Establishment Request message is sent by a Session Management Function, SMF. In an embodiment, if the alternative S-NSSAI cannot be determined or is invalid, then an Access and Mobility management Function, AMF, sends a 5GMM STATUS message or DL NAS TRANSPORT message indicating that the alternative S-NSSAI cannot be determined or is invalid. According to a second aspect of the present invention, there is provided apparatus arranged to perform the method of the first aspect. In an embodiment, the apparatus comprises at least one UE. The UE uses the S-NSSAI received in the PDU Session Establishment Accept message as the S-NSSAI that is sent in a subsequent PDU Session Establishment Request message which includes an alternative S-NSSAI. The SMF should send the alternative S-NSSAI in the PDU Session Establishment Accept message whenever an alternative S-NSSAI is used for the establishment of a PDU session. The AMF sends a 5GMM STATUS message or DL NAS TRANSPORT message (with a 5GSM message which is not forwarded) whenever the alternative S-NSSAI cannot be determined or is determined to be invalid. The AMF may indicate with a new 5GMM cause value that the alternative S-NSSAI is invalid or cannot be determined. 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 a S-NSSAI information element; Figures 2a and 2b show an alternative NSSAI information element and an entry therein; and Figure 3 shows a flowchart illustrating an embodiment of the invention. In a first embodiment, the UE determines the S-NSSAI based on what it has provided as part of the initial PDU session establishment procedure. Note that the following relates to the case when the UE wants to establish a new PDU session for an alternative S-NSSAI which is replacing an existing S-NSSAI, and for which the UE may already have an established PDU session. As such the following proposals relate to how to set the S-NSSAI when the UE wants to establish a new PDU session for which the UE should provide an S-NSSAI and an alternative S-NSSAI. As such all the details herein apply for the case when the UE is attempting to establish a new PDU session (e.g. when the UE sends the PDU Session Establishment Request message) and also should send an S-NSSAI along with an alternative S-NSSAI, where the S-NSSAI is assumed to be associated with an existing PDU session for which the S-NSSAI is being replaced (by an alternative S-NSSAI). In this option, the UE determines the S-NSSAI to be the same as the S-NSSAI that the UE used in the PDU session establishment procedure for the PDU session that is already established (or for which the associated S-NSSAI is to be replaced with an alternative S-NSSAI). It should be noted that this means that the UE may have not provided any S-NSSAI and as such the associated S-NSSAI may be “no S-NSSAI”. Therefore, for the existing PDU session (for which the network has optionally provided an alternative S-NSSAI), if the UE had provided an S-NSSAI during the PDU session establishment procedure, then the UE should consider that S-NSSAI (which was provided by the UE) as the associated S-NSSAI and hence the UE should provide it again (i.e. as the S-NSSAI) when it is establishing a new PDU session with an alternative S-NSSAI. In an alternative solution, the UE may consider the S-NSSAI that is received in the PDU Session Establishment Accept message as the S-NSSAI that the UE should provide when it establishes a new PDU session (e.g. in relation to slice replacement or for an alternative S-NSSAI). Note that this solution may be used by the UE in all cases i.e. regardless of whether or not the UE provided an S-NSSAI during the PDU session establishment procedure of the current PDU session (for which the associated S-NSSAI is to be replaced). Alternatively this solution may be used only if the UE did not provide an S-NSSAI for the current PDU session for which an S-NSSAI is being replaced (by an alternative S-NSSAI). In an alternative solution, the UE may behave as follows, in any combination or order: • If the UE did not provide an S-NSSAI during the PDU session establishment procedure, then the UE provides the S-NSSAI which was received in the PDU Session Establishment Accept message • If the UE did not provide an S-NSSAI during the PDU session establishment procedure, then the UE does not provide an S-NSSAI during the establishment of the new PDU session, but the UE should provide the alternative S-NSSAI. The UE may indicate that the S-NSSAI is not being provided using any Information Element (IE) or bit. The UE may include this indication in the UL NAS TRANSPORT message • If the UE did provide an S-NSSAI during the PDU session establishment procedure, then the UE includes the S-NSSAI which was provided as the S-NSSAI. The UE also includes the alternative S-NSSAI. In an alternative option, the UE determines the S-NSSAI as follows: • The UE receives the alternative S-NSSAI in the PDU Session Modification Command message, noting that this is a single S-NSSAI value representing the alternative slice that has to be used (to replace another slice) • The UE is assumed to have an alternative S-NSSAI information which it may have received from the AMF (e.g. in the mobility management message such as Registration Accept or Configuration Update Command message), where this alternative S-NSSAI is a list of entries (or at least one entry) such that each entry contains an S-NSSAI to be replaced and an associated (or mapped) alternative S-NSSAI (which is a single entry that is supposed to replace the S-NSSAI to be replaced). • The UE should use the (single) alternative S-NSSAI (which is received in the PDU Session Modification Command message - hereafter referred to as the 5GSM message) to find the matching (or corresponding) S-NSSAI (or S-NSSAI to be replaced) from the alternative S-NSSAI information (which is not necessarily a single value). When the UE finds a match between the single alternative S-NSSAI (received in the 5GSM message) and the alternative S-NSSAI entry in the alternative S-NSSAI information, then the UE considers the S-NSSAI (to be replaced) of the corresponding alternative S-NSSAI value (for which there is a match) as the S-NSSAI which is associated with the PDU session, or as the S-NSSAI that the UE should provide when establishing a new PDU session (in addition to the alternative S-NSSAI that the UE should also provide) • The UE may behave as described above regardless of whether it provided an S-NSSAI for the current PDU session, or optionally only if it provided an S-NSSAI for the current PDU session To further clarify the details above, the alternative S-NSSAI received in the 5GSM message (e.g. PDU Session Modification Command message) as taught is section 9.11.2.8 of 3GPP TS 24.501 is reproduced in Figure 1. Here, it can be seen that the contents (starting from octet 3, SST - Slice Service Type) represent the single alternative S-NSSAI entry. The UE may have alternative S-NSSAI information which is received at the mobility management layer (i.e. from the AMF) which contains at least one entry, and is represented as shown in Figures 2a and 2b, which is taken from section 9.11.3.97 of 3GPP TS 24.501. By reference to Figure 2 the objective of how to determine the S-NSSAI that should be provided by the UE (in addition to the alternative S-NSSAI) when it is establishing a new PDU session (due to slice replacement) will be described. This S-NSSAI is the S-NSSAI to be replaced. The UE uses the alternative S-NSSAI received in the 5GSM message i.e. represented by Figure 1 and the UE attempts to find the matching alternative S-NSSAI using the contents shown in Figure 2a and Figure 2b, where the alternative S-NSSAI shown in figure 2a and 2b should be checked for a match with the alternative S-NSSAI from Figure 1 (or where the alternative S-NSSAI shown in figure 1 should be checked for a match with the alternative S-NSSAI from Figure 2a and 2b). If a match is found, the UE considers the S-NSSAI (i.e. the field referred to as ‘S-NSSAI to be replaced’ in Figure 2b) to be the S-NSSAI associated with the matching alternative S-NSSAI of Figure 2b. This S-NSSAI should also be considered as the S-NSSAI to be replaced. Therefore, after the S-NSSAI is determined (based on the description above), when the UE is establishing a new PDU session (due to slice replacement), the UE provides both the S-NSSAI and the alternative S-NSSAI, where the S-NSSAI is the S-NSSAI which has been determined based on the explanation above (i.e. this is the S-NSSAI to be replaced), and the alternative S-NSSAI is the S-NSSAI which is to replace the S-NSSAI to be replaced. The determined S-NSSAI may be considered to be the S-NSSAI associated with the current PDU session and hence all the proposals herein would apply. If the AMF receives an UL NAS TRANSPORT message which includes an alternative S-NSSAI but does not include an S-NSSAI (in the S-NSSAI IE), then the AMF may behave as follows: • The AMF determines the S-NSSAI to be the S-NSSAI of the PDU session for which a matching alternative S-NSSAI exists. As such, the matching alternative S-NSSAI is used by the AMF to determine the corresponding S-NSSAI which is to be replaced. As such this corresponding S-NSSAI is then determined to be the S-NSSAI • The AMF may determine to not forward the 5GSM message to an SMF. The AMF may send a DL NAS TRANSPORT message and include the 5GSM message which was not forwarded to an SMF. The AMF may indicate that the 5GSM message was not forwarded because the S-NSSAI is not known (or is missing), or that there is no correspondence or association between the alternative S-NSSAI and the S-NSSAI which is being replaced. The AMF may use a new 5GMM cause value or an existing cause value. o If the UE receives a DL NAS TRANSPORT message with a 5GSM message that is not forwarded, optionally with an indication of a lack of S-NSSAI or lack of association between an S-NSSAI and an alternative S-NSSAI, the 5GMM entity may forward this indication along with the 5GSM message (which was not forwarded) to the 5GSM entity • Alternatively, if the AMF receives an alternative S-NSSAI but does not receive an S-NSSAI, the AMF may send the 5GMM STATUS message to the UE and indicate with a new cause value that the S-NSSAI is missing, or that there is no association between an alternative S-NSSAI and an S-NSSAI. The AMF may discard the received 5GSM message. Furthermore, the UE may not request the establishment of a new PDU session for this alternative S-NSSAI optionally until a certain time elapses or until the allowed NSSAI is changed such that this alternative S-NSSAI is part of the allowed NSSAI. Note that for any of the details herein in which the AMF does not (or can not) forward a 5GSM message to an SMF, and for any of details herein (or in the current AMF behaviour) for which the AMF does not forward (or can not forward) a 5GSM message in relation to an alternative S-NSSAI, if the AMF sends the DL NAS TRANSPORT message - containing a 5GSM message which was not forwarded to an SMF - to a UE, the AMF should include the alternative S-NSSAI in the DL NAS TRANSPORT, optionally the AMF should also include the S-NSSAI which may have been received. The AMF may include the alternative S-NSSAI (optionally together with the S-NSSAI) to indicate any problem which is related to the alternative S-NSSAI. As such for any reason that the AMF is not able to forward a 5GSM message such that the reason is associated with an alternative S-NSSAI (either which is determined by an AMF or explicitly received by an AMF), the AMF should send the alternative S-NSSAI in the DL NAS TRANSPORT so as to notify the UE about the alternative S-NSSAI for which the issue is related to. Note that the SMF currently only provides on S-NSSAI in the PDU session establishment accept message. This S-NSSAI may be the alternative S-NSSAI if the AMF did provide the alternative S-NSSAI to the SMF. However, as set out herein, the SMF should provide both the S-NSSAI and the alternative S-NSSAI in the PDU Session Establishment Accept message so as to provide the correct information to a UE i.e. so as to clearly and explicitly indicate which S-NSSAI is being replaced and the alternative S-NSSAI that is used to replace the existing S-NSSAI. As such the PDU Session Establishment Accept message now includes both the S-NSSAI and the alternative S-NSSAI whenever the SMF accepts a PDU session that is being established with an alternative S-NSSAI (e.g. for slice replacement feature). When the UE receives a PDU Session Establishment Accept message with both an S-NSSAI and an alternative S-NSSAI, the UE determines that the slice which is replaced is the S-NSSAI in the 5GSM message, and the alternative S-NSSAI is the slice which replaces the S-NSSAI, and that the PDU session is now associated with the indicated alternative S-NSSAI. A second embodiment relates to AMF behaviour for an invalid (or undetermined) alternative S-NSSAI. The AMF may receive an UL NAS TRANSPORT message with a 5GSM message such that the AMF may attempt to determine an alternative S-NSSAI. For example, the UL NAS TRANSPORT message may contain an S-NSSAI which the AMF determines to be a slice that has to be replaced (e.g. by an alternative S-NSSAI). If the AMF cannot determine the alternative S-NSSAI, then the AMF should not forward the 5GSM message to any SMF. The AMF should then send the DL NAS TRANSPORT message to the UE and include the 5GSM message which was not forwarded. The AMF may indicate that the reason for not forwarding the 5GSM message is because an alternative S-NSSAI is not determined or there is not valid alternative S-NSSAI for the slice which is to be replaced. The AMF may use a new 5GMM cause value or an existing 5GMM cause value in the DL NAS TRANSPORT message. Note that the AMF may behave as described above if the AMF did receive an alternative S-NSSAI in the UL NAS TRANSPORT message (which contains a 5GSM message) such that the alternative S-NSSAI does not exist or is invalid. In this case, the AMF can also send the DL NAS TRANSPORT message to the UE and optionally include the 5GSM message which was not forwarded. The AMF may indicate the reason is because of an invalid alternative S-NSSAI. The AMF may do so with a new 5GMM cause value. The UE may behave as set out above i.e. the 5GMM entity may send the 5GSM message (which was not forwarded) and the new 5GMM cause value to the 5GSM entity. Furthermore, the UE may not request the establishment of a new PDU session for this alternative S-NSSAI optionally until a certain time elapses or until the allowed NSSAI is changed such that this alternative S-NSSAI is part of the allowed NSSAI. Note that for any of the details set out herein, the UL / DL NAS TRANSPORT message which carries a 5GSM message may mean that the Payload container type IE is set to "N1 SM information". It may also mean that the Request type IE is set to "initial request". Note that any combination of this may also apply. Note that all the details herein may apply in any order or combination. Figure 3 illustrates, for completeness, a representation of an embodiment of the present invention. It shows the steps in a method where, at S101 a User Equipment, UE, is in communication with a telecommunication network. At S102, a slice replacement is required. At S103, the UE indicates to the telecommunication network an S-NSSAI value previously received in a PDU Session Establishment Accept message in connection with an existing PDU session. 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 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 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 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 User Equipment, UE, in communication with a telecommunication network, wherein if the UE attempts to establish a Protocol Data Unit, PDU, session due to slice replacement of a slice identified by a Single -5 Network Slice Selection Assistance Information, S-NSSAI, for an alternative S-NSSAI, the UE indicates to the telecommunication network an S-NSSAI value previously received in a PDU Session Establishment Accept message in connection with an existing PDU session.
2. The method of claim 1 wherein the alternative S-NSSAI is sent to the network in a 10 PDU Session Establishment Request message.
3. The method of claim 2 wherein the PDU Session Establishment Request message is sent by a Session Management Function, SMF.
4. The method of any preceding claim wherein if the alternative S-NSSAI cannot be determined or is invalid, then an Access and Mobility management Function, AMF,15 sends a 5GMM STATUS message or DL NAS TRANSPORT message indicating thatthe alternative S-NSSAI cannot be determined or is invalid.
5. Apparatus arranged to perform the method of any preceding claim.
6. The apparatus of claim 5 comprising at least one UE.
Citation Information
Patent Citations
Network slice-specific authentication and authorization
GB2596897A