Improvements in and relating to the avoidance of slice deregistration in a telecommunication network

Abstract

A method for use in telecommunication network, operatively connected to a User Equipment, UE, of transferring a Protocol Data Unit, PDU, session from a non-3GPP access to a 3GPP access, wherein the UE or the network take account of an "Allowed PDU session status" Information Element, IE, in order to determine if a particular slice (S-NSSAI) is being used via the 3GPP access, then the network or the UE should stop a deregistration inactivity timer associated with the slice over the 3GPP access. In the prior art, the deregistration timer is only controlled in response to 5GSM signalling. However, sessions can also be transferred from non-3GPP to 3GPP slices and this doesn’t involve any 5GSM signalling. The present application therefore allows control (e.g. reset or stop) of the deregistration timer responsive additionally to an Allowed PDU session status IE indicating the slice is being used for 3GPP access. After transferring the PDU session to 3GPP type the UE and network consider that the slice is active and remove any indication to the contrary. The method may be performed by the UE or the network or by both together.

Description

The present invention relates to improved methods to avoid slice deregistration for transferred Protocol Date Unit, PDU, sessions. 3GPP has developed several features related to network slicing, one of which uses a slice deregistration inactivity timer where the timer is per slice (Single - Network Slice Selection Assistance Information, S-NSSAI) and per access type (i.e. 3GPP or non-3GPP). The timer guards the inactivity period for the slice in question such that if the timer expires and the User Equipment, UE, has not used the slice, then the slice is deemed to be no longer available for the UE, and the slice is removed from the allowed NSSAI which enforces the lack of the slices availability since only slices in the allowed NSSAI can be used. The following is from 3GPP TS 23.501 which describes this concept: “The 5GC performs Network Slice usage monitoring to be able to enforce the release of inactive PDU Sessions, and deregistering of UEs from Network Slices with no PDU Sessions on them according to its own policies. In order to support usage monitoring for a Network Slice: the AMF runs a slice deregistration inactivity timer per S-NSSAI and access type to deregister the Network Slice which is started when the Network Slice is not used by any PDU Session over the corresponding access type. The slice deregistration inactivity timer is stopped and reset when at least a PDU Session associated with the Network Slice is successfully established or the Network Slice is removed form the Allowed NSSAI. When the slice deregistration inactivity timer for a Network Slice over an access type expires, the AMF removes the Network Slice from the Allowed NSSAI over the access type by sending the UE Configuration Update Command to impacted UE(s).” The following is from section 4.6.2.9 of 3GPP TS 24.501 which describes the start of the timer and the outcome of its expiry (similar to what is shown above): “The slice deregistration inactivity timer is: a) started when there is no established PDU session, including any MA PDU session, associated with the S-NSSAI over the corresponding access type; and b) stopped and reset when at least a PDU session, including any MA PDU session, associated with the S-NSSAI is successfully established over the corresponding access type(s) or the S-NSSAI is removed from the allowed NSSAI.” The following is from section 6.4.1.3 of 3GPP TS 24.501 which describes that the deregistration inactivity timer is stopped upon the successful establishment of a PDU session, noting that this is associated with explicit session management signaling that is exchanged with the network for the session to be established: “If the UE supports network slice usage control and: a) a PDU session is successfully established for the on-demand S-NSSAI, the UE shall stop and reset the slice deregistration inactivity timer for the on-demand S-NSSAI over corresponding access type, if running; and b) an MA PDU session is successfully established for the on-demand S-NSSAI, the UE shall stop and reset the slice deregistration inactivity timer for the on-demand S-NSSAI over both 3GPP access and non-3GPP access, if running.” To summarize, the following key points can be observed from the above: • A slice is associated with a deregistration inactivity timer, where the timer guards the period of inactivity for the slice. The expiry of the timer means the slice is no longer available for use • The timer is per slice and access technology (i.e. 3GPP or non-3GPP) • The timer is stopped upon successful establishment of a PDU session, where this requires explicit session management signaling. A UE which supports non-3GPP access and 3GPP access may be registered to the network via both access technology types. The UE may have a PDU session which is already established over the non-3GPP access, say with PDU session ID 1. The 3GPP supports the transfer of a session from across these access types as is described next using two methods, a) and b): a) Transfer of a session between 3GPP access &non-3GPP access by means of session management messages The UE can use explicit session management messages (referred to as 5GSM messages) in order to transfer an already established PDU session on one access to the other access. Note that this requires the sending of a 5GSM message to achieve the transfer. This method can be used to transfer a session from 3GPP access to non-3GPP access, or from non-3GPP access to 3GPP access. b) Transfer of a session from non-3GPP access to 3GPP access by means of the Allowed PDU session status IE Before describing how this works, it should be noted that this method only works for the transfer of a session from non-3GPP access to 3GPP access i.e. this cannot be used to transfer a session in the other direction i.e. from 3GPP access to non-3GPP access. A UE may have a PDU session, say with PDU session ID 1, which is established over the non-3GPP access. The network may determine that the UE is not reachable over the non-3GPP where, in fact, paging is not supported. However, since the UE is (assumed to be) also registered over the 3GPP access, the network (which determines that there is downlink data for PDU session ID 1) can page the UE over the 3GPP access and indicate in the paging message that the cause of the paging is related to the non-3GPP access. When the UE receives the paging message and determines that the cause is for a service over the non-3GPP access, the UE is required to send the (Control Plane) Service Request, CPSR, message and include the Allowed PDU session status Information Element, IE. The IE contains bit positions that correspond to PDU session identities and therefore by setting a bit position to 1, then the UE “indicates that the user-plane resources of corresponding PDU session can be re-established over 3GPP access” as described above. In this case, the PDU session would have user plane established over the 3GPP access and hence is now considered to be associated with the 3GPP access as described above: “If the PDU session reactivation result IE is included in the SERVICE ACCEPT message indicating that the user-plane resources have been successfully reactivated for a PDU session that was indicated by the UE in the Allowed PDU session status IE as allowed to be re-established over 3GPP access, the UE considers the corresponding PDU session to be associated with the 3GPP access. If the user-plane resources of a PDU session have been successfully reactivated over the 3GPP access, the AMP and SMF update the associated access type of the corresponding PDU session.” If the bit was set to 0, then the UE does not allow the transfer of the session from non-3GPP access to 3GPP access and so the session continues to be associated with the non-3GPP access. The following key points can therefore be highlighted: • A PDU session can be transferred from non-3GPP access to 3GPP access by means of the Allowed PDU session status IE • This does not require any 5GSM signalling between the UE and the network. A problem in the prior art is that the current mechanism to stop the slice deregistration inactivity timer has only considered PDU session establishment by means of explicit 5GSM messages, whereas PDU session transfer by means of the Allowed PDU session status IE is ignored. This can lead to the slice deregistration inactivity timer expiring, even though the session is active on the 3GPP access after being transferred from non-3GPP. The following describes, in more detail, the problem experienced in the prior art. Assume the UE: • has an allowed NSSAI for the 3GPP access which includes S-NSSAI X, the UE has started the slice deregistration inactivity timer for S-NSSAI X (as there is no active PDU session over the 3GPP access) • has an allowed NSSAI for the non-3GPP access which also includes S-NSSAI X, and the UE has a PDU session active for this slice over the non-3GPP access • the UE gets paged for non-3GPP access and the UE indicates in the Allowed PDU session status IE that the session (associated with S-NSSAI X) is to be transferred from non-3GPP access to 3GPP access • the user plane gets established over the 3GPP access for the PDU session with S-NSSAI X, and the session is now considered to be associated with the 3GPP access • the deregistration inactivity timer for S-NSSAI X over the 3GPP access is still running, and its expiry leads to removal of S-NSSAI X from the allowed NSSAI and hence an abrupt end to the active PDU session. This leads to a very negative user experience. The reason why the problem exists is because the stopping of the deregistration inactivity timer is strictly dependent on a successful establishment of a PDU session for the access type in question by means of explicit 5GSM signaling. Therefore, any transfer of a session by means of the Allowed PDU session status IE will not lead to stopping of the timer and hence the PDU session will eventually be dropped. It is an aim of embodiments of the present invention to address this problem and, therefore, to avoid negative user experience and possible network malfunction. 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 invention, in a telecommunication network, operatively connected to a User Equipment, there is a method of transferring a Protocol Data Unit, PDU, session from a non-3GPP access to a 3GPP access, wherein the UE or the network take account of an “Allowed PDU status” Information Element, IE, in order to determine if a particular slice is being used via the 3GPP access, then the network or the UE should stop a deregistration inactivity timer associated with the slice over the 3GPP access. In an embodiment, after the transferring of the PDU session, the UE and the network consider that the slice associated with the transferred PDU session to be active and, if necessary, to remove any indication contrary to this status. In an embodiment, wherein the method is performed by either the UE individually, the telecommunication network individually or both the network and UE together. According to a second aspect, there is provided apparatus arranged to perform the method of the first aspect. Certain aspects of the invention are: • The UE and the network should consider the Allowed PDU status IE in order to determine if a slice is being used or not via the 3GPP access • If a PDU session is transferred over to the 3GPP access using the Allowed PDU session status IE, then the network should stop (and optionally reset) any deregistration inactivity timer for that slice over the 3GPP access • If a PDU session is transferred over to the 3GPP access using the Allowed PDU session status IE, then the UE should stop (and optionally reset) any deregistration inactivity timer forthat slice over the 3GPP access • After the transfer of the PDU session from non-3GPP to 3GPP by means of the Allowed PDU session status IE, both the UE and network should consider that the slice associated with the transferred PDU session is active i.e. is being used, and hence remove or delete any flag or local indication that states otherwise, if any • After the transfer of a PDU session from a source access to a target access, either by means of the Allowed PDU session status IE or by means of explicit signalling, the deregistration inactivity timer should be started for the S-NSSAI associated with the source access, and the deregistration inactivity timer should be stopped for the S-NSSAI associated with the target access • The establishment of a PDU session which leads to stopping of the deregistration inactivity timer should consider both the establishment of a new PDU session or the transfer of a PDU session, where this distinction can be made based on the value indicated in the Request type IE, 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 flowchart illustrating an embodiment of the intention from a network perspective; and Figure 2 shows a flowchart illustrating an embodiment of the intention from a UE perspective. Note that herein, any relevant method steps, where appropriate, may be performed in in any order or combination. Whenever NAS message names are listed, they can be considered as examples but not restrictions. As such the proposals can apply to other NAS messages which are either existing or new. Wherever reference is made to the Access and Mobility management Function, AMF, these may also be applied to the Session Management Function, SMF, or other suitable network entity. Reference is primarily made to Fifth Generation, 5G, systems, but embodiments may find use in other systems (e.g. 6G, 4G, etc) where similar network functions are available. Embodiments may apply for a UE and the network support network slice usage control (where for example this may be for a UE and / or network that exchange related capability indications using any IE or NAS message). Herein, the S-NSSAI in question may be referred to as an on-demand S-NSSAI, and optionally the S-NSSAI may be associated with a deregistration inactivity timer and optionally an access type. The deregistration inactivity timer may refer to a slice deregistration inactivity timer. A slice may refer to an S-NSSAI. For any embodiment which involves stopping of the deregistration inactivity timer, this may also involve resetting of the timer, optionally, after stopping of the timer. The following relates to AMF behaviour with respect to the deregistration inactivity timer and the Allowed PDU session status IE The network may page the UE and indicate that the access for which the paging is performed is the non-3GPP access. The network may use the AMF, which has triggered the paging via the NG-RAN. The AMF may receive a NAS message, e.g. a Registration Request, Service Request, or Control Plane Service Request, where the Allowed PDU session status IE is included, the AMF may determine to establish (e.g. activate or reactive) the user plane resources for a PDU session which the UE has indicated that should / can be transferred to the 3GPP access (e.g. the Allowed PDU session status IE has at least one bit which is set to the value 1 - “indicates that the user-plane resources of corresponding PDU session can be re-established over 3GPP access”). When the AMF determines that a PDU session has been transferred from the non-3GPP access to the 3GPP access, where this is done by means of the Allowed PDU session status IE, then the AMF should stop and optionally reset slice deregistration inactivity timer for the slice (or for the S-NSSAI) which is associated with the PDU session that has been transferred over to the 3GPP access (from the non-3GPP access). The timer that is stopped and reset is associated with the slice (or S-NSSAI) in question and the 3GPP access. The AMF may behave as described above (when or after any of the above occurs) in any of the following ways: • After the AMF receives (optionally from the UE) the Allowed PDU session status IE such that the PDU session associated with the slice (or S-NSSAI) for which there is a running deregistration inactivity timer, has an associated bit position whose value is set to 1 (i.e. the UE is requesting the reactivation of user plane resources over the 3GPP access) • After the AMF establishes (or reactivates) the user plane resources for the PDU session which is associated with the slice (or S-NSSAI), for which there is a running deregistration inactivity timer • After the AMF (and / or SMF) updates the associated access type of the corresponding PDU session e.g. when the AMF (and / or SMF) updates the associated access type of the session such that the PDU session is now considered to be associated with the 3GPP access (optionally when or after any of the previous proposals occur) for e.g. when user plane resources are established on the 3GPP access. Note that for any of the above the AMF stops and, optionally, resets a (slice) deregistration inactivity timer for the slice (or S-NSSAI) in question and the 3GPP access, if any is running. In addition to the above, the AMF should also behave as follows: • After a session has been transferred from non-3GPP access to 3GPP access, either by means of explicit 5GSM signalling or by means of the Allowed PDU session status, the AMF should (optionally reset and) start the deregistration inactivity timer for the slice (or S-NSSAI) in question and the non-3GPP access i.e. the timer is that which is associated with the non-3GPP access. As such, when a PDU session is transferred from non-3GPP access to 3GPP access, the AMF behaves as described above (e.g. resets and stops the timer associated with the slice and the 3GPP access) and optionally also (resets and) starts the deregistration inactivity timer for the same slice (or S-NSSAI) and the non-3GPP access. • Similarly, when a PDU session is transferred from 3GPP access to non-3GPP access by means of explicitly 5GSM signalling, the AMF should start the deregistration inactivity timer for the slice (or S-NSSAI) and 3GPP access i.e. the timer which is associated with the slice (or S-NSSAI) and the 3GPP access o The AMF may behave as set out above (i.e. with regards to stopping of a deregistration inactivity timer) when: ■ the access type of the PDU session is updated to the new access type i.e. when the access type of the PDU session is changed / updated from 3GPP access to non-3GPP access ■ the PDU session establishment procedure (optionally where the Request type IE is set to the value ‘010’ “existing PDU session”) completes successfully • In general, after a session has been transferred from a source access (e.g. 3GPP access or non-3GPP access) to a target access (e.g. non-3GPP access or 3GPP access, respectively) by means of explicit 5GSM signalling, then the UE should (optionally reset and) start the deregistration inactivity timer for the slice (or S-NSSAI) in question and the source access i.e. the timer is that which is associated with the source access. As such, when a PDU session is transferred from a source access to a target access, the UE behaves as described herein (e.g. resets and stops the timer associated with the slice and the target access) and optionally also (resets and) starts the deregistration inactivity timer for the same slice (or S-NSSAI) and source access. Note that it is specified that the AMF stops and resets the deregistration inactivity timer for a slice after the successful establishment of the PDU session over the corresponding access and for the slice in question. However, there is no distinction regarding whether the PDU session establishment is for a new PDU session or for an existing PDU session. The successful completion of the PDU session establishment can hint that this is for a new session only. As such, according to an embodiment: • after the successful completion of a PDU session establishment, where the Request type IE is set to the value ‘001’ “initial request” , or is set to ‘010’ “existing PDU session”, then the AMF should reset and stop the deregistration inactivity timer • after the successful completion of a PDU session establishment, where the Request type IE is set to the value ‘001’ “initial request” , or is set to ‘010’ “existing PDU session”, then the UE should reset and stop the deregistration inactivity timer o Note that herein, the PDU session transfer can occur for the case when the: ■ PDU session is first associated with the 3GPP access, the PDU session has been transferred to the non-3GPP access, and optionally the PDU session is now considered to be associated with the non-3GPP access, or ■ PDU session is first associated with the non-3GPP access, the PDU session has been transferred to the 3GPP access, and optionally the PDU session is now considered to be associated with the 3GPP access. Note that for all of the above, if the AMF determines that a PDU session has not been successfully transferred from the non-3GPP access to the 3GPP access, e.g. by means of the Allowed PDU session status IE, where for example the Allowed PDU session status IE indicates that the user-plane resources of corresponding PDU session is not allowed to be reestablished over 3GPP access (e.g. the bit position corresponding to the PDU session is set to the value ‘0’), then the AMF: • does not reset or stop the deregistration inactivity timer for the slice and 3GPP access, e.g. the AMF maintains the timer running • does not reset or start the deregistration inactivity timer for the slice and the non-3GPP access, e.g. the AMF maintains the timer not running for the non-3GPP access (except if the slice is removed from the allowed NSSAI for the non-3GPP access, or the PDU session is released over the non-3GPP access). Note that for all of the above, if the AMF determines that a PDU session has not been successfully transferred from a source access (which may be 3GPP or non-3GPP access) to target access (which may be non-3GPP or 3GPP access, respectively), e.g. user plane resources could not be established successfully on target access and identified this e.g. by means of explicit 5GSM signalling, where the Request type IE indicates “existing PDU session”, then the AMF: • does not reset or stop the deregistration inactivity timer for the slice and the target access, e.g. the AMF maintains the timer running • does not reset or start the deregistration inactivity timer for the slice and the source access, e.g. the AMF maintains the timer not running for the source access (except if the slice is removed from the allowed NSSAI for the source access, or the PDU session is released over the source access). Figure 1 shows an example of how the AMF should behave based on the details set out above. It shows steps 1) to 5): 1) A PDU session exists for the UE on non-3GPP access, say for S-NSSAI K. The AMF has a deregistration inactivity timer running for S-NSSAI K for 3GPP access. 2) The AMF initiates paging over 3GPP access bit for non-3GPP access PDU session(s) e.g. the access type in the paging indicates non-3GPP access. 3) The AMF receives a NAS message with Allowed PDU session status IE indicating that at least one PDU is to be transferred to 3GPP access. This includes the PDU session ID associated with S-NSSAI K. 4) The AMF stops (and optionally resets) the deregistration inactivity timer for S-NSAAI K and the 3GPP access. Optionally, if the PDU session for S-NSSAI K is indicated in the IE, or after the establishment of UP resources, or after the AMF (and / or SMF) updates the access type for the PDU session with S-NSSAI K to be 3GPP access. 5) The AMF starts the deregistration inactivity timer for S-NSSAI K and the non-3GPP access. This step applies to any PDU session transfer with explicit 5GSM signalling. The following relates to UE behaviour with respect to the deregistration inactivity timer and the Allowed PDU session status. The UE should also reset and stop any timer, where the timer is the deregistration inactivity timer, that is associated with a slice (e.g. an S-NSSAI) and the 3GPP access when a PDU session is transferred from the non-3GPP access to the 3GPP access by means of the Allowed PDU session status IE. When the UE sends a NAS message, a Registration Request, Service Request, or Control Plane Service Request, where the Allowed PDU session status IE is included such that the user plane resources for a PDU session is indicated (by the UE) to be transferred to the 3GPP access (e.g. the Allowed PDU session status IE has at least one bit which the UE has set to the value 1 - “indicates that the user-plane resources of corresponding PDU session can be reestablished over 3GPP access”), then the UE should reset and stop the deregistration inactivity timer for the slice (e.g. S-NSSAI) and the 3GPP access. The UE can behave as described above when (or after) any of the following occurs: • The UE determines that the PDU session has been transferred from the non-3GPP access to the 3GPP access optionally by means of the Allowed PDU session status IE • The UE determines that the user plane resources have been established, for example: o The UE determines this locally by means of interaction with the lower layers o The UE receives the PDU session reactivation result IE in any NAS message indicating that the user plane resources have been successfully reactivated for a PDU session that was indicated by the UE in the Allowed PDU session status IE (as allowed to be re-established over 3GPP access) o The user plane resources are established on the 3GPP access for the corresponding PDU session. • The UE updates the access type of the PDU session such that there is a new access type associated with the PDU session, where for example the new access type is the 3GPP access (and optionally the previous access type was the non-3GPP access) • For any of the above, the slice associated with the transferred PDU session optionally has a deregistration inactivity timer which is running. As indicated previously, a PDU session can be transferred from one access type to another access type by means of explicit 5GSM signalling. The process to do so is the PDU session establishment procedure. The specification indicates that the UE should stop the timer i.e. the deregistration inactivity timer, which is associated with a slice (e.g. S-NSSAI) and access type after the successful establishment of the PDU session. However, it is not explicitly indicated if the establishment procedure is for a new PDU session or for the transfer of a PDU session. In an embodiment, both options are addressed and the means to do so would be dependent on the value of the Request type IE that the UE includes in the NAS message: • after the successful completion of a PDU session establishment, where the Request type IE is set to the value ‘00T “initial request” , or is set to ‘010’ “existing PDU session”, then the AMF should reset and stop the deregistration inactivity timer • after the successful completion of a PDU session establishment, where the Request type IE is set to the value ‘001’ “initial request” , or is set to ‘010’ “existing PDU session”, then the UE should reset and stop the deregistration inactivity timer o Note that herein, the PDU session transfer can occur for the case when the: ■ PDU session is first associated with the 3GPP access, the PDU session has been transferred to the non-3GPP access, and optionally the PDU session is now considered to be associated with the non-3GPP access, or ■ PDU session is first associated with the non-3GPP access, the PDU session has been transferred to the 3GPP access, and optionally the PDU session is now considered to be associated with the 3GPP access. In addition to the above, the UE should also behave as follows: • After a session has been transferred from non-3GPP access to 3GPP access, either by means of explicit 5GSM signalling or by means of the Allowed PDU session status, for e.g. user plane resources are established on 3GPP access, the UE should (optionally reset and) start the deregistration inactivity timer for the slice (or S-NSSAI) in question and the non-3GPP access i.e. the timer is that which is associated with the non-3GPP access. As such, when a PDU session is transferred from non-3GPP access to 3GPP access, the UE behaves as described above (e.g. resets and stops the timer associated with the slice and the 3GPP access) and optionally also (resets and) starts the deregistration inactivity timer for the same slice (or S-NSSAI) and the non-3GPP access • After a session has been transferred from a source access (e.g. 3GPP access or non-3GPP access) to a target access (e.g. non-3GPP access or 3GPP access, respectively) by means of explicit 5GSM signalling, then the UE should (optionally reset and) start the deregistration inactivity timer for the slice (or S-NSSAI) in question and the source access i.e. the timer is that which is associated with the source access. As such, when a PDU session is transferred from a source access to a target access, the UE behaves as described herein (e.g. resets and stops the timer associated with the slice and the target access) and optionally also (resets and) starts the deregistration inactivity timer for the same slice (or S-NSSAI) and source access. For all the details and procedures herein (for the UE and / or the AMF), where the Request type IE is mentioned, the described techniques can be applied for the case when the Request type IE is included in the UL NAS TRANSPORT message, where optionally the message includes a 5GSM message, e.g. where the Payload container type IE indicates “N1 SM information” (i.e. the value is set to ‘0001 ’) and optionally where the payload container contents contain a 5GSM message. Note that for all of the above, if the UE determines that a PDU session has not been successfully transferred from a source access (which may be 3GPP or non-3GPP access) to target access (which may be non-3GPP or 3GPP access, respectively), e.g. by means of explicit 5GSM signalling, where the Request type IE indicates “existing PDU session” or if the user plane resources could not be established on target access, then the UE: • does not reset or stop the deregistration inactivity timer for the slice and the target access, e.g. the UE maintains the timer running • does not reset or start the deregistration inactivity timer for the slice and the source access, e.g. the UE maintains the timer not running for the source access (except if the slice is removed from the allowed NSSAI for the source access, or the PDU session is released over the source access). Figure 2 shows an example of how the UE should behave based on the details herein. It shows steps 11) to 15). 11) a PDU session exists for the UE on non-3GPP access, say of S-NSSAI K. The UE has a deregistration inactivity timer running for S-NSSAI K for 3GPP access. 12) the UE receives a paging message over the 3GPP access but for non-3GPP access PDU session(s) e.g. the access type indicates non-3GPP. 13) the UE sends a NAS message with Allowed PDU session status IE indicating that at least one PDU session to be transferred to 3GPP access. This includes PDU session ID associated with S-NSSAI K. 14) The UE stops (and optionally resets) the deregistration inactivity timer for S-NSAAI K and the 3GPP access. Optionally, if the PDU session reactivation result IE is received and indicates that that the UP resources for the PDU session with S-NSSAI K are established, or after establishment of the UP resources for the PDU session for S-NSSAI K over the 3GPP access. 15) the UE starts the deregistration inactivity timer for S-NSSAI K and the non-3GPP access. This step applies to any PDU session transfer with explicit 5GSM signalling. It should be noted that the flowcharts shown in Figures 1 and 2, provided for the AMF and the UE, respectively, may also be used together although this is not shown explicitly herein. The following provides examples of how the 3GPP specifications) can be updated based on the details herein, noting that these are examples only and are not to be considered as restrictions. For example, the following paragraph in section 4.6.2.9 of 3GPP TS 24.501 can be updated as follows, where the update is shown with underlined text: “The slice deregistration inactivity timer is: a) started when there is no established PDU session, including any MA PDU session, associated with the S-NSSAI over the corresponding access type, or when a PDU session is transferred from one access type to another: and b) stopped and reset when at least a PDU session, including any MA PDU session, associated with the S-NSSAI is successfully established over the corresponding access type(s) or the S-NSSAI is removed from the allowed NSSAI.” For example, the following paragraph in section 5.5.1.3.4 of 3GPP TS 24.501 can be updated as follows, where the update is shown with underlined text: “If the PDU session reactivation result IE is included in the REGISTRATION ACCEPT message indicating that the user-plane resources have been successfully reactivated for a PDU session that was indicated by the UE in the Allowed PDU session status IE as allowed to be re-established over 3GPP access, the UE considers the corresponding PDU session to be associated with the 3GPP access, and optionally the UE shall stop and reset the slice deregistration inactivity timer for the on-demand S-NSSAI over the 3GPP access (optionally if any is running). The UE shall (optionally reset and) start the slice deregistration inactivity timer for the on-demand S-NSSAI over the non-3GPP access. If the user-plane resources of a PDU session have been successfully reactivated over the 3GPP access, the AMF and SMF update the associated access type of the corresponding PDU session. Optionally the AMF shall stop and reset the slice deregistration inactivity timer for the on-demand S-NSSAI over the 3GPP access (optionally if any is running). The AMF shall (optionally reset and) start the slice deregistration inactivity timer for the on-demand S-NSSAI over the non-3GPP access.” For example, the following paragraph in section 5.6.1.4.1 of 3GPP TS 24.501 can be updated as follows, where the update is shown with underlined text: “If the PDU session reactivation result IE is included in the SERVICE ACCEPT message indicating that the user-plane resources have been successfully reactivated for a PDU session that was indicated by the UE in the Allowed PDU session status IE as allowed to be re-established over 3GPP access, the UE considers the corresponding PDU session to be associated with the 3GPP access, and optionally the UE shall stop and reset the slice deregistration inactivity timer for the on-demand S-NSSAI over the 3GPP access (optionally if any is running). The UE shall (optionally reset and) start the slice deregistration inactivity timer for the on-demand S-NSSAI over the non-3GPP access. If the user-plane resources of a PDU session have been successfully reactivated over the 3GPP access, the AMF and SMF update the associated access type of the corresponding PDU session.” Note that the above can also be applied to the case when the UE sends the Control Plane Service Request message i.e. when the UE receives Service Accept message after sending the Control Plane Service Request message. For example, the following paragraph in section 6.3.3.3 of 3GPP TS 24.501 can be updated as follows, where the update is shown with underlined text: “If the UE supports network slice usage control: a) all PDU session associated with an on-demand S-NSSAI are released or transferred to another access type, and there is no MA PDU session associated with this on-demand S-NSSAI, the UE shall start the slice deregistration inactivity timer for this on-demand S-NSSAI over the corresponding access type; b) all MA PDU session associated with an on-demand S-NSSAI are released and there is no PDU session associated with this on-demand S-NSSAI, the UE shall start the slice deregistration inactivity timer for this on-demand S-NSSAI over both 3GPP access and non-3GPP access; or c) all PDU session and all MA PDU session associated with an on-demand S-NSSAI are released, the UE shall start the slice deregistration inactivity timer for this on-demand S-NSSAI over both 3GPP access and non-3GPP access. ” For example, the following paragraph in section 6.4.1.3 of 3GPP TS 24.501 can be updated as follows, where the update is shown with underlined text: “If the UE supports network slice usage control and: a) a new PDU session is successfully established for the on-demand S-NSSAI, the UE shall stop and reset the slice deregistration inactivity timer for the on-demand S-NSSAI over corresponding access type, if running; b) an existing PDU session is successfully transferred for the on-demand S-NSSAI, the UE shall stop and reset the slice deregistration inactivity timer for the on-demand S-NSSAI over corresponding access type, if running; and b) an MA PDU session is successfully established for the on-demand S-NSSAI, the UE shall stop and reset the slice deregistration inactivity timer for the on-demand S-NSSAI over both 3GPP access and non-3GPP access, if running.” Note that the transfer of a PDU session may refer to a PDU session that is not for emergency services. 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, 5 or any novel combination, of the steps of any method or process so disclosed.

Claims

1. In a telecommunication network, operatively connected to a User Equipment, a methodof transferring a Protocol Data Unit, PDU, session from a non-3GPP access to a 3GPP 5 access, wherein the UE or the network take account of an “Allowed PDU status” InformationElement, IE, in order to determine if a particular slice is being used via the 3GPP access, then the network or the UE should stop a deregistration inactivity timer associated with the slice over the 3GPP access.10 2. The method of claim 1 wherein after the transferring of the PDU session, the UE and thenetwork consider that the slice associated with the transferred PDU session to be active and, if necessary, to remove any indication contrary to this status.

3. The method of claim 1 or 2 wherein the method is performed by either the UE 15 individually, the telecommunication network individually or both the network and UE together.

4. Apparatus arranged to perform the method of any preceding claim.

Images