Patent Application
20240284377
The present disclosure related to a method of a User Equipment (UE) and a User Equipment (UE).
The Network Slice Simultaneous Registration Group (NSSRG) concept is introduced by NPL 5 during the 3GPP SA Working Group 145E meeting. The NSSRG concept is introduced to the 5GS based on the service requirement form the GSMA as described in NPL 2.
According to NPL 5, the subscription information for a UE may include for each S-NSSAI a NSSRG information constraining which S-NSSAIs can be simultaneously provided to the UE in the Allowed NSSAI.
If the UE has received NSSRG information together with the Configured NSSAI, the UE only includes in the Requested NSSAI S-NSSAIs that all share a common NSSRG, for example, when the UE sends a Registration request message to an AMF.
Two S-NSSAIs sharing at least one NSSRG can be simultaneously included in the Allowed NSSAI. Otherwise, these S-NSSAIs cannot be included simultaneously in the Allowed NSSAI. For example, in a case where a first NSSRG only includes first S-NSSAI and a second NSSRG only includes second S-NSSAI, these S-NSSAIs cannot be included simultaneously in the Allowed NSSAI.
The NSSRG information, defining the association of S-NSSAIs to NSSRG, is provided as an additional and separate information. A supporting AMF/NSSF, when it receives a Requested NSSAI, evaluates the S-NSSAIs of the HPLMN (in the mapping information of the Requested NSSAI in the registration request message, when a mapping information is applicable) based on any received NSSRG information for these S-NSSAIs, to determine whether they can be provided together in the Allowed NSSAI.
According to NPL 5, the NSSRG is configured for the UE in a HPLMN as the subscription information. Inventors of this disclosure identify problem how the NSSRG needs to be handled in some situations.
In an aspect of the present disclosure, a method of a User Equipment (UE) includes performing communication with a network apparatus and including first Single Network Slice Selection Assistance Information (S-NSSAI) to Requested Network Slice Selection Assistance Information (NSSAI) for a first access. The first S-NSSAI shares Network Slice Simultaneous Registration Group (NSSRG) common to second S-NSSAI of Allowed NSSAI for a second access.
In an aspect of the present disclosure, a User Equipment (UE) includes means for performing communication with a network apparatus and means for including first Single Network Slice Selection Assistance Information (S-NSSAI) to Requested Network Slice Selection Assistance Information (NSSAI) for a first access. The first S-NSSAI shares Network Slice Simultaneous Registration Group (NSSRG) common to second S-NSSAI of Allowed NSSAI for a second access.
Each of aspects and elements included in the each aspects described below may be implemented independently or in combination with any other. These aspects include novel characteristics different from one another. Accordingly, these aspects contribute to achieving objects or solving problems different from one another and contribute to obtaining advantages different from one another. For example, Aspect 1 and Aspect 5 can be combined, Aspect 3 and Aspect 5 can be combined, Aspect 1 and Aspect 3 and Aspect 5 can be combined. For example, Aspect 1, Aspect 5 and at least one of variants of Aspect 3 can be combined. For example, Aspect 3, Aspect 5 and at least one of variants of Aspect 3 can be combined.
For the purposes of the present document, the abbreviations given in NPL 1 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in NPL 1.
For the purposes of the present document, the terms and definitions given in NPL 1 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in NPL 1.
Those skilled in the art will appreciate that elements in the figures are illustrated for simplicity and may not have necessarily been drawn to scale. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the figures by conventional symbols, and the figures may show only those specific details that are pertinent to understanding the Aspects of the present disclosure so as not to obscure the figures with details that will be readily apparent to those skilled in the art having the benefit of the description herein.
For the purpose of promoting an understanding of the principles of the disclosure, reference will now be made to the Aspect illustrated in the figures and specific language will be used to describe them. It will nevertheless be understood that no limitation of the scope of the disclosure is thereby intended. Such alterations and further modifications in the illustrated system, and such further applications of the principles of the disclosure as would normally occur to those skilled in the art are to be construed as being within the scope of the present disclosure.
The terms “comprises”, “comprising”, or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process or method that comprises a list of steps does not include only those steps but may include other steps not expressly listed or inherent to such a process or method. Similarly, one or more devices or entities or sub-systems or elements or structures or components preceded by “comprises . . . a” does not, without more constraints, preclude the existence of other devices, sub-systems, elements, structures, components, additional devices, additional sub-systems, additional elements, additional structures or additional components. Appearances of the phrase “in an Aspect”, “in another Aspect” and similar language throughout this specification may, but not necessarily do, all refer to the same Aspect.
Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this disclosure belongs. The system, methods, and examples provided herein are only illustrative and not intended to be limiting.
In the following specification and the claims, reference will be made to a number of terms, which shall be defined to have the following meanings. The singular forms “a”, “an”, and “the” include plural references unless the context clearly dictates otherwise.
As used herein, information is associated with data and knowledge, as data is meaningful information and represents the values attributed to parameters. Further knowledge signifies understanding of an abstract or concrete concept. Note that this example system is simplified to facilitate description of the disclosed subject matter and is not intended to limit the scope of this disclosure. Other devices, systems, and configurations may be used to implement the Aspects disclosed herein in addition to, or instead of, a system, and all such Aspects are contemplated as within the scope of the present disclosure.
The NSSRG policy includes information of the NSSRG. The NSSRG policy may be called as NSSRG slice selection policy, NSSRG information, NSSRG, information indicating NSSRG or information related to NSSRG. The NSSRG policy may include information indicating which S-NSSAI(s) in an Allowed NSSAI can be simultaneously provided to the UE. For example, the NSSRG policy includes information indicating that S-NSSAI 1 and S-NSSAI 2 can be simultaneously provided to the UE. In this case, the S-NSSAI 1 and the S-NSSAI 2 are included in the same NSSRG. The S-NSSAI 1 may be called as first S-NSSAI and the S-NSSAI 2 may be called as second S-NSSAI. Access type may be called as access. For example, 3GPP access type may be called as 3GPP access. For example, non-3GPP access type may be called as non-3GPP access.
In the following specifications, the allowed NSSAI can also be pending NSSAI. The registration request message can be for initial registration procedure, mobility registration procedure, periodic registration procedure or emergency registration procedure.
All the aspects also apply for the case when the UE is registered over an access type with an allowed NSSAI and an S-NSSAI in the requested NSSAI does not share a common NSSRG with the S-NSSAI(s) in the allowed NSSAI. All the aspects also apply for the case when the UE is registered over an access type with an allowed NSSAI and an S-NSSAI in the requested NSSAI of the same access type does not share a common NSSRG with the S-NSSAI(s) in the allowed NSSAI of the same access type.
First Aspect can solve, for example, a problem statement 1 as shown below.
If the UE registers to a 5GS via both over 3GPP access and non-3GPP access, the UE maintains two independent Allowed NSSAIs, that is one for 3GPP access and another one for non-3GPP access.
It is not clear which S-NSSAI(s) can be set to the Requested NSSAI in the registration request message over an access type in a situation where the UE has been registered over another access type and has an Allowed NSSAI for another access type.
The first Aspect includes defining Network Slice Simultaneous Registration Group per access type (e.g. 3GPP access and non-3GPP access) for a PLMN and configuring this to the UE. The UE constitutes Requested NSSAI when registering to a PLMN via an access type as per the NSSRG of the access type. The network enforces the NSSRG policy to the UE as per the access type depending on which access type the UE is registering to the 5GS.
The detailed steps of the registration procedure using the NSSRG policy are given below.
The NSSRG per access type can be interpreted based on at least two ways below:
In one example, the NSSRG may be assigned to each subscribed S-NSSAI per combination of access type and VPLMN where the UE roams to.
In one example, the NSSRG may be assigned to each subscribed S-NSSAI per RAT type.
In one example the UDM also sends NSSRG information for another access type i.e. for an access type other than the current access type. In this case, Nudm_SDM_GET Response message contains the NSSRG policy together with an access type identifier which identifies the access type, as e.g. {(NSSRG policy 1, 3GPP access), (NSSRG policy 2, non-3GPP access)}. In this case, (NSSRG policy 1, 3GPP access) means that NSSRG policy 1 is for 3GPP access, and (NSSRG policy 2, non-3GPP access) means that NSSRG policy 2 is for non-3GPP access.
For example, if the Requested NSSAI includes S-NSSAI 1 and S-NSSAI 2 and the received NSSRG policy includes information indicating that S-NSSAI 1 and S-NSSAI 2 can be simultaneously provided to the UE (that is, the information indicates that S-NSSAI 1 and S-NSSAI 2 are included in same NSSRG), the AMF sends, to the UE, the Allowed NSSAI including S-NSSAI 1 and S-NSSAI 2.
For example, if the Requested NSSAI includes S-NSSAI 1 and S-NSSAI 2 and the received NSSRG policy includes information indicating that S-NSSAI 1 and S-NSSAI 3 can be simultaneously provided to the UE (that is, the information indicates that S-NSSAI 1 and S-NSSAI 3 are included in same NSSRG), the AMF sends, to the UE, the Allowed NSSAI including S-NSSAI 1 and a rejected cause value regarding S-NSSAI 2 to reject S-NSSAI 2.
In a case where the Registration procedure fails due to some reason, e.g. none of the S-NSSAI is set in the Allowed NSSAI, the network (e.g., AMF) sends, to the UE, Registration Reject message containing the NSSRG policy of the access type. In one example the NSSRG policy is sent in security protected Registration Reject message (that is, the message is integrity protected or ciphered or both). The Registration Reject message may not be security protected.
In one example the NSSRG policy can be sent in a NAS message during the network initiated deregistration procedure, e.g. the NSSRG policy is set in the deregistration request message. The AMF sends NSSRG policy during deregistration procedure when the network determines that the NSSRG policy in the UE is not the latest or receives a request from the UDM to update the NSSRG policy for the access type.
In another example the NSSRG policy per access type may be provided to the UE via the UE Configuration Update procedure. If the NSSRG policy per access type related to one or more network slices that the UE has already registered is changed based on changes in the UE subscription or as a result of operator's policy update, the AMF updates the NSSRG policy per access type for these network slice(s) in the UE via the UE Configuration Update procedure.
In one example the AMF sends NSSRG policy related to an access type other than the current access type. When the network (e.g. AMF) sends NSSRG policy of more than one access type, then the NSSRG policy is sent together with an access type identifier which identifies the access type, as e.g. {(NSSRG policy 1, 3GPP access), (NSSRG policy 2, non-3GPP access)}. In this case, (NSSRG policy 1, 3GPP access) means that NSSRG policy 1 is for 3GPP access, and (NSSRG policy 2, non-3GPP access) means that NSSRG policy 2 is for non-3GPP access.
For example, the UE includes S-NSSAIs which can be allowed simultaneously in the Requested NSSAI of the Registration request message as per the NSSRG policy for the current access type. For example, the UE includes S-NSSAI 1 and S-NSSAI 2 in the Requested NSSAI of the Registration request message in a case where the NSSRG policy indicates that S-NSSAI 1 and S-NSSAI 2 can be allowed simultaneously.
The AMF may manage NSSRG policy per each access type level context. Table 1 shows an example of the UE context in the AMF. The UE context as defined in the Table 1 may be equally applicable to the UE context in the UE.
Second Aspect can solve, for example, the problem statement 1 and a problem statement 2 as shown below.
In roaming case the UE can be registered to a first VPLMN over 3GPP access and to a second VPLMN over non-3GPP access.
It is not clear how the UE and AMF enforce the NSSRG policy in a situation where the UE is registering to second VPLMN over non-3GPP access while the UE has been registered to a first VPLMN over 3GPP access.
In the second Aspect, when a UE is registered over a first PLMN via a first access type the AMF informs the Allowed NSSAI of the first access type to the UDM. The Allowed NSSAI of the first access type may be called as the Allowed NSSAI for the first PLMN.
When the UE is registering to access the second PLMN via second access type then the AMF fetches the Allowed NSSAI of the first access type from the UDM and compares the S-NSSAI(s) included in the Requested NSSAI with the S-NSSAI(s) included in the Allowed NSSAI for the first PLMN. If the S-NSSAI(s) in the Requested NSSAI is compatible with S-NSSAI(s) in the Allowed S-NSSAI(s) for the first PLMN then the Requested NSSAI is accepted and included in the Allowed NSSAI.
The detailed steps of registration procedure to different PLMNs via 3GPP access and non-3GPP access are described below.
The AMF may also send the Configured NSSAI 1 to the UDM. The VPLMN 1 identity may be an AMF identity, 5G-GUTI or combination on MCC and MNC. For example:
If the Allowed NSSAI 1 contains S-NSSAI 1 and the Requested NSSAI in step 1 contains S-NSSAI 1 and S-NSSAI 2, but S-NSSAI 1 and S-NSSAI 2 cannot be created (or allowed) simultaneously according to NSSRG policy then the AMF 2 includes only S-NSSAI 1 in the Allowed NSSAI 2 of the PLMN 2. The AMF 2 may obtain the NSSRG policy from the UDM. For example, the AMF 2 obtains the NSSRG policy in the steps 3 to 5 of the
In case the Allowed NSSAI 1 is stored in another NF then the AMF fetches the Allowed NSSAI 1 from the NF. The NSSRG policy may be related to access type. For example, the NSSRG policy is related to either 3GPP access or non-3GPP access.
The VPLMN 2 identity is an identity or an identifier for identifying the VPLMN 2.
In this Aspect, the first access type is 3GPP access and the second access type is non-3GPP access respectively or vice versa. In this Aspect, the first access type and the second access type may be same access type.
In step 1, the UE may send the Allowed NSSAI 1 of the VPLMN 1 and the Requested NSSAI 2 in the Registration request message.
In step 6, the AMF 2 may use the Allowed NSSAI 1 that is received in the step 1 and calculate the Allowed NSSAI 2 for the VPLMN 2 as defined in the step 6.
In step 1, the UE may send the 5G-GUTI 1 of the UE in the Registration Request message. During the registration procedure, the AMF 2 may fetch the Allowed NSSAI 1 from the AMF 1 by sending a first message containing 5G-GUTI 1 to the AMF 1. The AMF 1 may send the Allowed NSSAI 1 corresponding to the 5G-GUTI 1 to the AMF 2 in the second message. The first and second messages may be existing messages defined for communication between two AMFs or may be new messages.
In step 6, the AMF 2 may use the Allowed NSSAI 1 that is received in the step 1 and calculate the Allowed NSSAI 2 for the VPLMN 2 as defined in the step 6.
The AMF may manage NSSRG policy and VPLMN identity per each access type level context. Table 2 shows an example of the UE context in the AMF. The UE context as defined in the Table 2 may be equally applicable to the UE context in the UE.
Third Aspect can solve, for example, the problem statement 1.
In the third Aspect, a UE is configured with a common NSSRG for any access types. The UE is registered over the first access type and an Allowed NSSAI of the first access type and Configured NSSAI of the first access type are assigned to the UE.
The UE gets a trigger to register for an S-NSSAI over second access type. The UE shall include only S-NSSAI(s) that belong to the NSSRG including at least one of the S-NSSAIs of the Allowed NSSAI of the first access type. In this Aspect, the first access type is 3GPP access and the second access type is non-3GPP access respectively or vice versa. The first access type and the second access type are always different. This Aspect can be applicable for a case where a UE has been registered over the first access type with PLMN 1 and is performing registration procedure over the second access type with PLMN 2. In all variants of this aspect, the received NSSRG policy over an access type is applicable for both first access type and second access type.
The detailed steps of the procedure is defined as below.
For example, the UE receives the Allowed NSSAI 1, the Configured NSSAI 1 and the NSSRG information of the first access type for the PLMN 1 by receiving the Registration Accept message in a same manner as the step 6 in
Upon receiving the Registration Request message, on the basis of the NSSRG information, the AMF shall check if the S-NSSAI 1 shares a common group with all S-NSSAI present in the allowed NSSAI 1. If this is true then the AMF includes S-NSSAI 1 as Allowed NSSAI in the Registration Accept message, according to the registration procedure, otherwise the AMF shall reject the S-NSSAI 1 with cause value that the slice is not compatible with the Allowed NSSAI of the first access type. The Allowed NSSAI included in the Registration accept message is related to the second access type.
Example i. UE has Configured NSSAI and information of NSSRG and Allowed NSSAI.
The Configured NSSAI includes S-NSSAI A, S-NSSAI B and S-NSSAI C. The NSSRG includes two groups such as {S-NSSAI A, S-NSSAI B} and {S-NSSAI B, S-NSSAI C}. That is, in this case, the S-NSSAI A and the S-NSSAI B belong to first group, and the S-NSSAI B and the S-NSSAI C belong to second group. Allowed NSSAI 1 includes S-NSSAI A.
For example, the UE receives a request, from the upper layer, to trigger registration procedure for the S-NSSAI B or the S-NSSAI A over the second access type. In this case, the UE checks if the S-NSSAI B or the S-NSSAI A shares a common NSSRG with the S-NSSAI A in the Allowed NSSAI 1.
In this case, the S-NSSAI A and the S-NSSAI B belong to the first group, hence the UE determines that the S-NSSAI B or the S-NSSAI A which the upper layer requests shares a common NSSRG with the S-NSSAI A in the Allowed NSSAI 1. Then the UE sends a Registration Request message including a Requested NSSAI set to the S-NSSAI B or the S-NSSAI A.
In other words, the UE checks if S-NSSAI which the upper layer requests (that is, the S-NSSAI which can be set to Requested NSSAI) and S-NSSAI(s) in the Allowed NSSAI belong to same NSSRG. If the S-NSSAI which the upper layer requests and S-NSSAI(s) in the Allowed NSSAI belong to same NSSRG, the UE sends a Registration Request message including Requested NSSAI set to the S-NSSAI which the upper layer requests.
Further in other words, the UE checks whether S-NSSAI which the upper layer requests (that is, the S-NSSAI which can be set to Requested NSSAI) is included in NSSRG including S-NSSAI(s) in the Allowed NSSAI. If the S-NSSAI which the upper layer requests is included in the NSSRG, the UE sends a Registration Request message including Requested NSSAI set to the S-NSSAI which the upper layer requests.
In addition, the AMF also checks if the S-NSSAI B or the S-NSSAI A in the Requested NSSAI of the Registration Request message shares a common NSSRG with the S-NSSAI A in the Allowed NSSAI 1 in a same manner as the UE. In this case, the S-NSSAI A and the S-NSSAI B belong to the first group, hence the AMF also determines that the S-NSSAI B or the S-NSSAI A in the Requested NSSAI shares a common NSSRG with the S-NSSAI A in the Allowed NSSAI 1. Then the AMF includes the S-NSSAI B or S-BSSAI A as the Allowed NSSAI in the Registration Accept message, and sends the Registration Accept message to the UE.
That is, if the Requested NSSAI over the second access type is S-NSSAI B or S-NSSAI A, then registration procedure is allowed to initiate over the second access.
For example, the UE receives a request, from the upper layer, to trigger registration procedure for the S-NSSAI C over the second access type. In this case, the UE checks if the S-NSSAI C shares a common NSSRG with the S-NSSAI A in the Allowed NSSAI 1.
In this case, the S-NSSAI C belongs to the second group, hence the UE determines that the S-NSSAI C which the upper layer requests does not share a common NSSRG with the S-NSSAI A in the Allowed NSSAI 1. Then the UE does not send a Registration Request message including a Requested NSSAI set to the S-NSSAI C.
That is, if the Requested NSSAI over the second access type is S-NSSAI C then registration procedure is not allowed to initiate over the second access.
Example ii. UE has Configured NSSAI and information of NSSRG and Allowed NSSAI. The Configured NSSAI includes S-NSSAI A, S-NSSAI B, S-NSSAI C and S-NSSAI D. The NSSRG includes three groups such as {S-NSSAI A, S-NSSAI B}, {S-NSSAI B, S-NSSAI C} and {S-NSSAI A, S-NSSAI B, S-NSSAI C} That is, in this case, the S-NSSAI A and the S-NSSAI B belong to first group, and the S-NSSAI B and the S-NSSAI C belong to second group, and the S-NSSAI A, S-NSSAI B and the S-NSSAI C belong to third group. Allowed NSSAI 1 includes S-NSSAI A and S-NSSAI B.
For example, the UE receives a request, from the upper layer, to trigger registration procedure for the S-NSSAI C over the second access type. In this case, the UE checks if the S-NSSAI C shares a common NSSRG with the S-NSSAI A and the S-NSSAI B in the Allowed NSSAI 1.
In this case, the S-NSSAI A, the S-NSSAI B and the S-NSSAI C belong to the third group, hence the UE determines that the S-NSSAI C which the upper layer requests shares a common NSSRG with the S-NSSAI A and the S-NSSAI B in the Allowed NSSAI 1. Then the UE sends a Registration Request message including a Requested NSSAI set to the S-NSSAI C.
In addition, the AMF also checks if the S-NSSAI C shares a common NSSRG with the S-NSSAI A and the S-NSSAI B in the Allowed NSSAI 1 in a same manner as the UE. In this case, the S-NSSAI A, the S-NSSAI B and the S-NSSAI C belong to the third group, hence the AMF also determines that the S-NSSAI C in the Requested NSSAI shares a common NSSRG with the S-NSSAI A and the S-NSSAI B in the Allowed NSSAI 1. Then the AMF includes the S-NSSAI C as the Allowed NSSAI in the Registration Accept message, and sends the Registration Accept message to the UE.
That is, if the Requested NSSAI over the second access type is S-NSSAI C then registration procedure is allowed to initiate over second access.
For example, the UE receives a request, from the upper layer, to trigger registration procedure for the S-NSSAI D over the second access type. In this case, the UE checks if the S-NSSAI D shares a common NSSRG with the S-NSSAI A and the S-NSSAI B in the Allowed NSSAI 1.
In this case, the S-NSSAI D does not belong to any groups, hence the UE determines that the S-NSSAI D which the upper layer requests does not share a common NSSRG with the S-NSSAI A and the S-NSSAI B in the Allowed NSSAI 1. Then the UE does not send a Registration Request message including a Requested NSSAI set to the S-NSSAI D.
That is, if the Requested NSSAI over the second access type is S-NSSAI D then registration procedure is not allowed to initiate over second access.
In addition, for example, the steps 1, 2a and 2b in
In addition, for example, the steps 1, 2a and 2b in
If the S-NSSAI 1 does not share a common NSSRG with the S-NSSAI(s) of the Allowed NSSAI 1 then the UE shall not send Registration Request message with S-NSSAI 1, then the UE may perform deregistration procedure over the first access. After the deregistration procedure over the first access the UE shall initiate registration procedure over the second access and send a Registration Request message containing S-NSSAI 1 in the Requested NSSAI.
The UE and the network (e.g. AMF) enforce NSSRG policy independently for the first access and second access for the UE. When the UE initiates registration procedure over the second access while the UE is registered over the first access then the UE shall not check whether Requested NSSAI over the second access shares a common NSSRG of the Allowed NSSAI of the first access type. In this case, the AMF may check whether Requested NSSAI over the second access shares a common NSSRG of the Allowed NSSAI of the first access type. In addition, the AMF may obtain the NSSRG information of the first access type for the PLMN 1 to check whether Requested NSSAI over the second access shares a common NSSRG of the Allowed NSSAI of the first access type. For example, the AMF obtains the NSSRG information of the first access type for the PLMN 1 from the UDM in a same manner as the steps 4 and 5 in
The AMF may manage NSSRG policy per UE level context. Table 3 shows an example of the UE context in the AMF. The UE context as defined in the Table 3 may be equally applicable to the UE context in the UE.
In step 0, the network (e.g. AMF) sends a configuration parameter e.g. NSSRG access type priority. For example, configuration parameter is sent to the UE. The configuration parameter indicates whether the first access or the second access has the higher priority to continue the ongoing NAS procedure. For example, the configuration parameter indicates whether the first access or the second access has the higher priority to continue the ongoing NAS procedure if the UE is registered over first access and has an allowed NSSAI and the requested NSSAI for the second access type does not share a common NSSRG with the Allowed NSSAI over the first access. This configuration parameter is sent in an existing NAS message or a new NAS message during a NAS procedure (e.g. Registration accept message of registration procedure, or Configuration Update command message during generic configuration update command procedure). The network (e.g. AMF) may send the configuration parameter regardless of a registration status of the UE in 3GPP access or non-3GPP access. The AMF may obtain the configuration parameter from the UDM as a subscriber data.
In steps 1 and 2, when the UE receives a trigger to register for the S-NSSAI 1 over the second access if the configuration parameter indicates that the second access has higher priority than the first access and the S-NSSAI 1 does not share a common NSSRG with the S-NSSAIs of the allowed NSSAI 1 of the first access type, the UE sends registration request message containing the S-NSSAI 1 in the requested NSSAI. If the configuration parameter indicates the first access has higher priority than the second access type then the UE shall not send the registration request message containing the S-NSSAI 1 in the requested NSSAI to the network. Once the UE has allowed NSSAI for the second access type, the UE may initiate other NAS procedure for the S-NSSAI(s) in the allowed NSSAI e.g. PDU session establishment related to the allowed NSSAI or service request procedure.
The UE or the AMF may release the N1 signaling connection over the first access if the second access has higher priority. The UE may trigger a registration request message over the first access containing the S-NSSAI belonging to the common NSSRG of the S-NSSAI of the requested NSSAI of the second access. In one example, the UE initiates a NAS signaling over the second access only after the UE or the network releases the N1 signaling connection over the first access, or the UE or the network puts S-NSSAI(s) that does not belong to the common NSSRG with the allowed NSSAI for the second access type to the rejected NSSAI over the first access or the UE or the network deregisters the UE over the first access.
The 3GPP access has always the higher priority than the non-3GPP access. In step 1, if the first access is non-3GPP access then the UE may send registration request message over the 3GPP access containing the S-NSSAI 1 in the requested NSSAI. The UE or the AMF may release the N1 signaling connection over the non-3GPP access, or the UE or the network may put S-NSSAI(s) that does not belong to the common NSSRG with the allowed NSSAI for the 3GPP access type to the rejected NSSAI over the non-3GPP access type or may deregister the UE over the non-3GPP access.
The UE or the AMF processes the registration request message if the S-NSSAI(s) in the requested NSSAI over the second access does not share the common NSSRG with S-NSSAI(s) of the allowed NSSAI of the first access when there is no PDU session or no DRB is established for the first access type. Once the UE has allowed NSSAI for the second access type, the UE may initiate other NAS procedure for the S-NSSAI(s) in the allowed NSSAI e.g. PDU session establishment related to the allowed NSSAI or service request procedure.
In one example in step 1, the UE sends registration request message containing the S-NSSAI 1 as the requested over the second access type if the UE has no PDU session or no DRB for the first access type otherwise the UE shall wait for the PDU session or DRB to be released for the first access type and then sends registration request message containing the S-NSSAI 1.
In step 0, during the registration procedure in a NAS message (e.g. registration accept message) or in a NAS message during a NAS procedure, the AMF sends a configuration parameter indicating whether the UE can initiate registration procedure for a requested NSSAI over the second access type if the S-NSSAI(s) of the requested NSSAI does not share the common NSSRG with S-NSSAI(s) of the Allowed S-NSSAI of the first access type.
In steps 1 and 2, if the configuration parameter indicates that the UE is allowed to send a requested NSSAI over the second access type if the S-NSSAI(s) of the requested NSSAI does not share the common NSSRG with the S-NSSAI(s) of the allowed NSSAI then the UE shall initiate registration procedure for the requested NSSAI over the second access type, otherwise the UE shall not initiate registration procedure over the second access with the requested NSSAI. Once the UE has allowed NSSAI for the second access type, the UE may initiate other NAS procedure for the S-NSSAI(s) in the allowed NSSAI e.g. PDU session establishment related to the allowed NSSAI or service request procedure.
In one example, the Allowed NSSAI of the first access type includes S-NSSAI 1 and requested NSSAI over the second access type is S-NSSAI 2. If the S-NSSAI 2 does not share common NSSRG with the S-NSSAI 1 and the UE configuration parameter indicates the UE is allowed to initiate registration over the second access type if the requested NSSAI(s) does not share common NSSRG of the allowed NSSAI(s) over the first access type, then the UE shall initiate registration procedure over the second access type with requested NSSAI set to S-NSSAI 2. Otherwise the configuration parameter does not allow this, the UE shall not initiate the registration request procedure over the second access type with the requested NSSAI set to S-NSSAI 2.
In one example, the UE may initiate all the NAS procedure over the second access type (e.g. service request procedure) if the configuration parameter allows the UE to initiate the registration procedure over the second access type if the allowed NSSAI of the first access doesn't share the common NSSRG with the requested NSSAI or allowed NSSAI over the second access type.
Each access applies the NSSRG policy independently on their NAS or AS procedure. The UE and the network apply the NSSRG policy on allowed NSSAI or requested NSSAI of one access type independent of the allowed or requested NSSAI of another access type i.e. the requested NSSAI or allowed NSSAI of a second access type does not depend on the allowed or requested NSSAI of the first access type in case where the NSSRG policy is sent to the UE and this NSSRG policy applies for both access. It means that although there is a common NSSRG per UE applicable to both 3GPP access type and non-3GPP access type, each access type has its own NSSRG management (e.g. its own NSSRG policy) and disregards to a NSSRG management in another access type (e.g. NSSRG policy in another access type).
For example, the UE has configured S-NSSAI 1 and S-NSSAI 2. The NSSRG policy is {S-NSSAI 1} and {S-NSSAI 2}, the UE may send Registration request message containing S-NSSAI 2 in the requested NSSAI over the second access type if the allowed NSSAI of the first access type is {S-NSSAI 1}. The network (e.g. AMF) can accept the S-NSSAI 2 as allowed NSSAI for the second access type.
In step 2a, if the network (e.g. AMF) receives the registration request message from the UE with the S-NSSAI 1 in requested NSSAI over the second access type wherein the received S-NSSAI 1 cannot co-exist with S-NSSAI(s) in the allowed NSSAI of the first access type according to the common NSSRG rule for both access types, then the network (e.g. AMF) accepts the S-NSSAI 1 of the second access type. In this case, the network (e.g. AMF) sends the registration accept message to the UE including the S-NSSAI 1 to the allowed NSSAI for the second access type and new parameter rejected NSSAI with other access type that includes all incompatible S-NSSAI(s) in the first access type to the S-NSSAI 1. Upon reception of the registration accept message, the UE updates the allowed NSSAI and Rejected NSSAI in the UE. Alternatively, the network (e.g. AMF) initiates the separate configuration update command procedure to update the new allowed NSSAI or/and rejected NSSAI over the first access type by sending the Configuration Update Command message containing the allowed NSSAI and rejected NSSAI based on a result of the registration management procedure over the second access type.
Example, UE is configured with slice S-NSSAI A, S-NSSAI B and S-NSSAI C. The NSSRG policy includes compatible slice {S-NSSAI A, S-NSSAI B} and {S-NSSAI B, S-NSSAI C}. The UE is registered over the first access type with allowed NSSAI={S-NSSAI A, S-NSSAI B}. The UE sends registration request message over the second access type containing Request NSSAI set to S-NSSAI C. The network upon reception of the registration request message, accepts the requested NSSAI and sends Registration accept message containing Allowed NSSAI set to S-NSSAI C. The network sends Configuration update command procedure with allowed NSSAI set to S-NSSAI B and rejected NSSAI set to S-NSSAI A with reason that the slice can't co-exist or not compatible with allowed NSSAI as per the NSSRG policy. For example, the network sends Configuration update command procedure with allowed NSSAI of the first access type set to S-NSSAI B and rejected NSSAI set to S-NSSAI A with reason that the slice can't co-exist or not compatible with allowed NSSAI as per the NSSRG policy.
In step 2b, if the network (e.g. AMF) receives the registration request message from the UE with the S-NSSAI 1 in requested NSSAI over the second access type wherein the received S-NSSAI 1 cannot co-exist with S-NSSAI(s) in the allowed NSSAI of the first access type according to the common NSSRG rule for both access types, then the network (e.g. AMF) rejects the registration procedure by sending a registration reject message containing a cause indicating the UE to register over the second access with S-NSSAI sharing common NSSRG with allowed NSSAI over the first access type. The UE on receiving the Registration reject message may send registration request message over the second access type containing the requested NSSAI set to only S-NSSAI(s) compatible with S-NSSAI(s) of the allowed NSSAI of the first access type.
Alternatively, the UE on receiving the Registration reject message may send the registration request message over the first access type without containing the request NSSAI set to the S-NSSAI(s) that are incompatible with S-NSSAI(s) that were set to the requested NSSAI in the registration request message over the second access type. I.E., the UE removes all incompatible S-NSSAI(s) from the allowed NSSAI over the first access type. After the successful registration procedure over the first access type, then the UE re-initiates the registration procedure again over the second access type.
In step 1, the UE may send registration request over the second access containing the requested NSSAI if the S-NSSAI in the requested NSSAI has higher priority than the S-NSSAI(s) of the allowed NSSAI over the first access type when the S-NSSAI of the requested NSSAI does not share the common NSSRG of the allowed NSSAI of the first access. Priority of the S-NSSAI (s) can be configured by the network (e.g. AMF) or the UE determines the priority of the S-NSSAI(s) e.g. if a first application mapping to a first S-NSSAI has a higher priority over a second application mapping to a second S-NSSAI then the first S-NSSAI has higher priority than the second S-NSSAI.
Fourth Aspect can solve, for example, a problem statement 3 as shown below.
When the UE performs the Registration procedure, an assigned AMF for the UE may be changed to another one (that is, another AMF) due to various reasons. For example, the reason is long distance UE movement, lack of support for new S-NSSAI in the Requested NSSAI from the UE, etc.
In this case, it is not clear how the new AMF obtains the NSSRG information as new AMF may not always download the subscriber data from the UDM in every single registration procedure.
In the Fourth Aspect, an AMF stores the NSSRG information in the UE context. If the registration procedure requires an AMF change, then an old AMF transfers the NSSRG information to a new AMF so that the new AMF can generate an Allowed NSSAI taking the NSSRG information into account.
The detailed steps of the procedure is defined as below.
If the UE has registered to another access type with the same AMF, i.e., the UE is registered to both 3GPP access and non-3GPP access with a single PLMN, the old AMF may include an Allowed NSSAI that has been assigned to the UE for another access type to the Namf_Communication_UEContextTransfer response message in step 3. For example, if the UE has registered to first access type (e.g. 3GPP access) with the new AMF and the UE performs a registration procedure to the new AMF via second access type (e.g. non-3GPP access), the old AMF may include an Allowed NSSAI that has been assigned to the UE for the first access type to the Namf_Communication_UEContextTransfer response message in step 3.
In this case, the new AMF generates an Allowed NSSAI taking the S-NSSAI(s) assigned to another access type for the UE into account. For example, the new AMF generates an Allowed NSSAI of the second access type taking the S-NSSAI(s) in the Allowed NSSAI of the first access type for the UE into account. For example, the new AMF generates the Allowed NSSAI of the second access type which includes at least one of the S-NSSAIs in the Allowed NSSAI of the first access type.
The AMF may manage NSSRG policy per UE level context. Table 4 shows an example of the UE context in the AMF. The UE context as defined in the Table 4 may be equally applicable to the UE context in the UE.
Fifth Aspect can solve, for example, a problem statement 4 as shown below.
When a handover for the UE is performed, it is not clear how the RAN node takes the NSSRG information into account for the handover.
In the fifth Aspect, for service continuity, at mobility via handover the source RAN (Radio Access Network) shall consider the NSSRG affiliation of the network slices supported by the target cells, as shown in
The NSSRG affiliation of the network slices supported by the target cells may be called as NSSRG information of the target cells.
For example, the AMF sends Nudm_SDM_GET Request (Nudm_SDM_GET_Req) message to the UDM to retrieve the UE subscription parameter(s) for the UE. The UDM sends, to the AMF, Nudm_SDM_GET Response (Nudm_SDM_GET Rsp) message including the UE subscription information and NSSRG information for the network slices which the UE has requested to register for. For example, the Nudm_SDM_GET Request message may include information indicating the network slice(s) which the UE has requested to register for (e.g. S-NSSAI), then the UDM may chose or select appropriate NSSRG information based on the information indicating the network slice(s), and send the NSSRG information to the AMF. For example, the UDM may chose or select NSSRG information indicating that NSSRG comprises at least one of the network slice(s) which the UE has requested to register for.
The AMF constructs the Allowed NSSAI for the UE so that each of the S-NSSAI(s) in the Allowed NSSAI shares at least one NSSRG between them. For example, the AMF constructs the Allowed NSSAI so that the S-NSSAI(s) in the Allowed NSSAI is included in a same NSSRG. In addition, the Allowed NSSAI may include S-NSSAI included in the Requested NSSAI in step 1.
For example, when the handover is performed, the source RAN Node may retrieve the NSSRG information regarding the network slice(s) supported in the target RAN via the X2 interface. For example, based on the NSSRG information received in step 4 (that is, NSSRG information regarding the source RAN) and the NSSRG information regarding the target RAN, the source RAN Node may select a target cell of the target RAN which has same NSSRG to the NSSRG of the source RAN.
The steps 7 and 8 in
The above described aspects solve problem how the NSSRG needs to be handled in some situations.
The telecommunication system 1 represents a system overview in which an end to end communication is possible. For example, UE 3 (or user equipment, ‘mobile device’ 3) communicates with other UEs 3 or service servers in the data network 20 via respective (R)AN nodes 5 and a core network 7.
The (R)AN node 5 supports any radio accesses including a 5G radio access technology (RAT), an E-UTRA radio access technology, a beyond 5G RAT, a 6G RAT and non-3GPP RAT including wireless local area network (WLAN) technology as defined by the Institute of Electrical and Electronics Engineers (IEEE).
The (R)AN node 5 may split into a Radio Unit (RU), Distributed Unit (DU) and Centralized Unit (CU). In some aspects, each of the units may be connected to each other and structure the (R)AN node 5 by adopting an architecture as defined by the Open RAN (O-RAN) Alliance, where the units above are referred to as O-RU, O-DU and O-CU respectively.
The (R)AN node 5 may be split into control plane function and user plane function. Further, multiple user plane functions can be allocated to support a communication. In some aspects, user traffic may be distributed to multiple user plane functions and user traffic over each user plane functions are aggregated in both the UE 3 and the (R)AN node 5. This split architecture may be called as ‘dual connectivity’ or ‘Multi connectivity’.
The (R)AN node 5 can also support a communication using the satellite access. In some aspects, the (R)AN node 5 may support a satellite access and a terrestrial access.
In addition, the (R)AN node 5 can also be referred as an access node for a non-wireless access. The non-wireless access includes a fixed line access as defined by the Broadband Forum (BBF) and an optical access as defined by the Innovative Optical and Wireless Network (IOWN).
The core network 7 may include logical nodes (or ‘functions’) for supporting a communication in the telecommunication system 1. For example, the core network 7 may be 5G Core Network (5GC) that includes, amongst other functions, control plane functions and user plane functions. Each function in a logical nodes can be considered as a network function. The network function may be provided to another node by adapting the Service Based Architecture (SBA).
A Network Function can be deployed as distributed, redundant, stateless, and scalable that provides the services from several locations and several execution instances in each location by adapting the network virtualization technology as defined by the European Telecommunications Standards Institute, Network Functions Virtualization (ETSI NFV).
The core network 7 may support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
As is well known, a UE 3 may enter and leave the areas (i.e. radio cells) served by the (R)AN node 5 as the UE 3 is moving around in the geographical area covered by the telecommunication system 1. In order to keep track of the UE 3 and to facilitate movement between the different (R)AN nodes 5, the core network 7 comprises at least one access and mobility management function (AMF) 70. The AMF 70 is in communication with the (R)AN node 5 coupled to the core network 7. In some core networks, a mobility management entity (MME) or a mobility management node for beyond 5G or a mobility management node for 6G may be used instead of the AMF 70.
The core network 7 also includes, amongst others, a Session Management Function (SMF) 71, a User Plane Function (UPF) 72, a Policy Control Function (PCF) 73, a Network Exposure Function (NEF) 74, a Unified Data Management (UDM) 75, and a Network Data Analytics Function (NWDAF) 76. When the UE 3 is roaming to a visited Public Land Mobile Network (VPLMN), a home Public Land Mobile Network (HPLMN) of the UE 3 provides the UDM 75 and at least some of the functionalities of the SMF 71, UPF 72, and PCF 73 for the roaming-out UE 3.
The UE 3 and a respective serving (R)AN node 5 are connected via an appropriate air interface (for example the so-called “Uu” interface and/or the like). Neighboring (R)AN node 5 are connected to each other via an appropriate (R)AN node 5 to (R)AN node interface (such as the so-called “Xn” interface and/or the like). Each (R)AN node 5 is also connected to nodes in the core network 7 (such as the so-called core network nodes) via an appropriate interface (such as the so-called “N2”/“N3” interface(s) and/or the like). From the core network 7, connection to a data network 20 is also provided. The data network 20 can be an internet, a public network, an external network, a private network or an internal network of the PLMN. In case that the data network 20 is provided by a PLMN operator or Mobile Virtual Network Operator (MVNO), the IP Multimedia Subsystem (IMS) service may be provided by that data network 20. The UE 3 can be connected to the data network 20 using IPV4, IPv6, IPv4v6, Ethernet or unstructured data type.
The “Uu” interface may include a Control plane of Uu interface and User plane of Uu interface.
The User plane of Uu interface is responsible to convey user traffic between the UE 3 and a serving (R)AN node 5. The User plane of Uu interface may have a layered structure with SDAP, PDCP, RLC and MAC sublayer over the physical connection.
The Control plane of Uu interface is responsible to establish, modify and release a connection between the UE 3 and a serving (R)AN node 5. The Control plane of Uu interface may have a layered structure with RRC, PDCP, RLC and MAC sublayers over the physical connection.
For example, the following messages are communicated over the RRC layer to support AS signaling.
The UE 3 and the AMF 70 are connected via an appropriate interface (for example the so-called N1 interface and/or the like). The N1 interface is responsible to provide a communication between the UE 3 and the AMF 70 to support NAS signaling. The N1 interface may be established over a 3GPP access and over a non-3GPP access. For example, the following messages are communicated over the N1 interface.
The UE 3 may, for example, support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
The UE 3 may, for example, be an item of equipment for production or manufacture and/or an item of energy related machinery (for example equipment or machinery such as: boilers; engines; turbines; solar panels; wind turbines; hydroelectric generators; thermal power generators; nuclear electricity generators; batteries; nuclear systems and/or associated equipment; heavy electrical machinery; pumps including vacuum pumps; compressors; fans; blowers; oil hydraulic equipment; pneumatic equipment; metal working machinery; manipulators; robots and/or their application systems; tools; molds or dies; rolls; conveying equipment; elevating equipment; materials handling equipment; textile machinery; sewing machines; printing and/or related machinery; paper converting machinery; chemical machinery; mining and/or construction machinery and/or related equipment; machinery and/or implements for agriculture, forestry and/or fisheries; safety and/or environment preservation equipment; tractors; precision bearings; chains; gears; power transmission equipment; lubricating equipment; valves; pipe fittings; and/or application systems for any of the previously mentioned equipment or machinery etc.).
The UE 3 may, for example, be an item of transport equipment (for example transport equipment such as: rolling stocks; motor vehicles; motor cycles; bicycles; trains; buses; carts; rickshaws; ships and other watercraft; aircraft; rockets; satellites; drones; balloons etc.).
The UE 3 may, for example, be an item of information and communication equipment (for example information and communication equipment such as: electronic computer and related equipment; communication and related equipment; electronic components etc.).
The UE 3 may, for example, be a refrigerating machine, a refrigerating machine applied product, an item of trade and/or service industry equipment, a vending machine, an automatic service machine, an office machine or equipment, a consumer electronic and electronic appliance (for example a consumer electronic appliance such as: audio equipment; video equipment; a loud speaker; a radio; a television; a microwave oven; a rice cooker; a coffee machine; a dishwasher; a washing machine; a dryer; an electronic fan or related appliance; a cleaner etc.).
The UE 3 may, for example, be an electrical application system or equipment (for example an electrical application system or equipment such as: an x-ray system; a particle accelerator; radio isotope equipment; sonic equipment; electromagnetic application equipment; electronic power application equipment etc.).
The UE 3 may, for example, be an electronic lamp, a luminaire, a measuring instrument, an analyzer, a tester, or a surveying or sensing instrument (for example a surveying or sensing instrument such as: a smoke alarm; a human alarm sensor; a motion sensor; a wireless tag etc.), a watch or clock, a laboratory instrument, optical apparatus, medical equipment and/or system, a weapon, an item of cutlery, a hand tool, or the like.
The UE 3 may, for example, be a wireless-equipped personal digital assistant or related equipment (such as a wireless card or module designed for attachment to or for insertion into another electronic device (for example a personal computer, electrical measuring machine)).
The UE 3 may be a device or a part of a system that provides applications, services, and solutions described below, as to “internet of things (IoT)”, using a variety of wired and/or wireless communication technologies.
Internet of Things devices (or “things”) may be equipped with appropriate electronics, software, sensors, network connectivity, and/or the like, which enable these devices to collect and exchange data with each other and with other communication devices. IoT devices may comprise automated equipment that follow software instructions stored in an internal memory. IoT devices may operate without requiring human supervision or interaction. IoT devices might also remain stationary and/or inactive for a long period of time. IoT devices may be implemented as a part of a (generally) stationary apparatus. IoT devices may also be embedded in non-stationary apparatus (e.g. vehicles) or attached to animals or persons to be monitored/tracked.
It will be appreciated that IoT T technology can be implemented on any communication devices that can connect to a communications network for sending/receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.
It will be appreciated that IoT devices are sometimes also referred to as Machine-Type Communication (MTC) devices or Machine-to-Machine (M2M) communication devices or Narrow Band-IoT UE (NB-IoT UE). It will be appreciated that a UE 3 may support one or more IoT or MTC applications.
The UE 3 may be a smart phone or a wearable device (e.g. smart glasses, a smart watch, a smart ring, or a hearable device).
The UE 3 may be a car, or a connected car, or an autonomous car, or a vehicle device, or a motorcycle or V2X (Vehicle to Everything) communication module (e.g. Vehicle to Vehicle communication module, Vehicle to Infrastructure communication module, Vehicle to People communication module and Vehicle to Network communication module).
The communications control module 552 (using its transceiver control sub-module) is responsible for handling (generating/sending/receiving) signalling between the (R)AN node 5 and other nodes, such as the UE 3, another (R)AN node 5, the AMF 70 and the UPF 72 (e.g. directly or indirectly). The signalling may include, for example, appropriately formatted signalling messages relating to a radio connection and a connection with the core network 7 (for a particular UE 3), and in particular, relating to connection establishment and maintenance (e.g. RRC connection establishment and other RRC messages), NG Application Protocol (NGAP) messages (i.e. messages by N2 reference point) and Xn application protocol (XnAP) messages (i.e. messages by Xn reference point), etc. Such signalling may also include, for example, broadcast information (e.g. Master Information and System information) in a sending case.
The controller 54 is also configured (by software or hardware) to handle related tasks such as, when implemented, UE mobility estimate and/or moving trajectory estimation.
The (R)AN node 5 may support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
The (R)AN node 5 based on O-RAN architecture represents a system overview in which the (R)AN node is split into a Radio Unit (RU) 60, Distributed Unit (DU) 61 and Centralized Unit (CU) 62. In some aspects, each unit may be combined. For example, the RU 60 can be integrated/combined with the DU 61 as an integrated/combined unit, the DU 61 can be integrated/combined with the CU 62 as another integrated/combined unit. Any functionality in the description for a unit (e.g. one of RU 60, DU 61 and CU 62) can be implemented in the integrated/combined unit above. Further, CU 62 can separate into two functional units such as CU Control plane (CP) and CU User plane (UP). The CU CP has a control plane functionality in the (R)AN node 5. The CU UP has a user plane functionality in the (R)AN node 5. Each CU CP is connected to the CU UP via an appropriate interface (such as the so-called “E1” interface and/or the like).
The UE 3 and a respective serving RU 60 are connected via an appropriate air interface (for example the so-called “Uu” interface and/or the like). Each RU 60 is connected to the DU 61 via an appropriate interface (such as the so-called “Front haul”, “Open Front haul”, “F1” interface and/or the like). Each DU 61 is connected to the CU 62 via an appropriate interface (such as the so-called “Mid haul”, “Open Mid haul”, “E2” interface and/or the like). Each CU 62 is also connected to nodes in the core network 7 (such as the so-called core network nodes) via an appropriate interface (such as the so-called “Back haul”, “Open Back haul”, “N2”/“N3” interface(s) and/or the like). In addition, a user plane part of the DU 61 can also be connected to the core network nodes 7 via an appropriate interface (such as the so-called “N3” interface(s) and/or the like).
Depending on functionality split among the RU 60, DU 61 and CU 62, each unit provides some of the functionality that is provided by the (R)AN node 5. For example, the RU 60 may provide a functionalities to communicate with a UE 3 over air interface, the DU 61 may provide functionalities to support MAC layer and RLC layer, the CU 62 may provide functionalities to support PDCP layer, SDAP layer and RRC layer.
The communications control module 6052 (using its transceiver control sub-module) is responsible for handling (generating/sending/receiving) signalling between the RU 60 and other nodes or units, such as the UE 3, another RU 60 and DU 61 (e.g. directly or indirectly). The signalling may include, for example, appropriately formatted signalling messages relating to a radio connection and a connection with the RU 60 (for a particular UE 3), and in particular, relating to MAC layer and RLC layer.
The controller 604 is also configured (by software or hardware) to handle related tasks such as, when implemented, UE mobility estimate and/or moving trajectory estimation.
The RU 60 may support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
As described above, the RU 60 can be integrated/combined with the DU 61 as an integrated/combined unit. Any functionality in the description for the RU 60 can be implemented in the integrated/combined unit above.
The DU 61 may support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
As described above, the RU 60 can be integrated/combined with the DU 61 or CU 62 as an integrated/combined unit. Any functionality in the description for DU 61 can be implemented in one of the integrated/combined unit above.
The CU 62 may support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
As described above, the CU 62 can be integrated/combined with the DU 61 as an integrated/combined unit. Any functionality in the description for the CU 62 can be implemented in the integrated/combined unit above.
The AMF 70 may support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
The UDM 75 may support the Non-Public Network (NPN). The NPN may be a Stand-alone Non-Public Network (SNPN) or a Public Network Integrated NPN (PNI-NPN).
Detailed aspects have been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above aspects whilst still benefiting from the disclosures embodied therein. By way of illustration only a number of these alternatives and modifications will now be described.
In the above description, the UE 3 and the network apparatus are described for ease of understanding as having a number of discrete modules (such as the communication control modules). Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the disclosure, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities. These modules may also be implemented in software, hardware, firmware or a mix of these.
Each controller may comprise any suitable form of processing circuitry including (but not limited to), for example: one or more hardware implemented computer processors; microprocessors; central processing units (CPUs); arithmetic logic units (ALUs); input/output (IO) circuits; internal memories/caches (program and/or data); processing registers; communication buses (e.g. control, data and/or address buses); direct memory access (DMA) functions; hardware or software implemented counters, pointers and/or timers; and/or the like. In the above aspects, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied to the UE 3 and the network apparatus as a signal over a computer network, or on a recording medium. Further, the functionality performed by part or all of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the UE 3 and the network apparatus in order to update their functionalities.
In the above aspects, a 3GPP radio communications (radio access) technology is used. However, any other radio communications technology (e.g. WLAN, Wi-Fi, WiMAX, Bluetooth, etc.) and other fix line communications technology (e.g. BBF Access, Cable Access, optical access, etc.) may also be used in accordance with the above aspects.
Items of user equipment might include, for example, communication devices such as mobile telephones, smartphones, user equipment, personal digital assistants, laptop/tablet computers, web browsers, e-book readers and/or the like. Such mobile (or even generally stationary) devices are typically operated by a user, although it is also possible to connect so-called ‘Internet of Things’ (IoT) devices and similar machine-type communication (MTC) devices to the network. For simplicity, the present application refers to mobile devices (or UEs) in the description but it will be appreciated that the technology described can be implemented on any communication devices (mobile and/or generally stationary) that can connect to a communications network for sending/receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.
Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.
The whole or part of the example embodiments disclosed above can be described as, but not limited to, the following.
For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905 [1].
An S-NSSAI identifies a Network Slice.
An S-NSSAI is comprised of:
An S-NSSAI can have standard values (i.e. such S-NSSAI is only comprised of an SST with a standardised SST value, see clause 5.15.2.2, and no SD) or non-standard values (i.e. such S-NSSAI is comprised of either both an SST and an SD or only an SST without a standardised SST value and no SD). An S-NSSAI with a non-standard value identifies a single Network Slice within the PLMN with which it is associated.
An S-NSSAI with a non-standard value shall not be used by the UE in access stratum procedures in any PLMN other than the one to which the S-NSSAI is associated.
The S-NSSAIs in the NSSP of the URSP rules (see TS 23.503 clause 6.6.2) and in the Subscribed S-NSSAIs (see clause 5.15.3) contain only HPLMN S-NSSAI values.
The S-NSSAIs in the Configured NSSAI, the Allowed NSSAI (see clause 5.15.4.1), the Requested NSSAI (see clause 5.15.5.2.1), the Rejected S-NSSAIs contain only values from the Serving PLMN. The Serving PLMN can be the HPLMN or a VPLMN.
The S-NSSAI(s) in the PDU Session Establishment contain one Serving PLMN S-NSSAI value and in addition may contain a corresponding HPLMN S-NSSAI value to which this first value is mapped (see clause 5.15.5.3).
The optional mapping of Serving PLMN S-NSSAIs to HPLMN S-NSSAIs contains Serving PLMN S-NSSAI values and corresponding mapped HPLMN S-NSSAI values.
The NSSAI is a collection of S-NSSAIs. An NSSAI may be a Configured NSSAI, a Requested NSSAI or an Allowed NSSAI. There can be at most eight S-NSSAIs in Allowed and Requested NSSAIs sent in signalling messages between the UE and the Network. The Requested NSSAI signalled by the UE to the network allows the network to select the Serving AMF, Network Slice(s) and Network Slice instance(s) for this UE, as specified in clause 5.15.5.
Based on the operator's operational or deployment needs, a Network Slice instance can be associated with one or more S-NSSAIs, and an S-NSSAI can be associated with one or more Network Slice instances. Multiple Network Slice instances associated with the same S-NSSAI may be deployed in the same or in different Tracking Areas. When multiple Network Slice instances associated with the same S-NSSAI are deployed in the same Tracking Areas, the AMF instance serving the UE may logically belong to (i.e. be common to) more than one Network Slice instance associated with this S-NSSAI.
In a PLMN, when an S-NSSAI is associated with more than one Network Slice instance, one of these Network Slice instances, as a result of the Network Slice instance selection procedure defined in clause 5.15.5, serves a UE that is allowed to use this S-NSSAI. For any S-NSSAI, the network may at any one time serve the UE with only one Network Slice instance associated with this S-NSSAI until cases occur where e.g. this Network Slice instance is no longer valid in a given Registration Area, or a change in UE's Allowed NSSAI occurs, etc. In such cases, procedures mentioned in clause 5.15.5.2.2 or clause 5.15.5.2.3 apply.
Based on the Requested NSSAI (if any) and the Subscription Information, the 5GC is responsible for selection of a Network Slice instance(s) to serve a UE including the 5GC Control Plane and User Plane Network Functions corresponding to this Network Slice instance(s). The Subscription Information may contain restrictions to the simultaneous registration of network slices. This is provided to the serving AMF as part of the UE subscription, in the form of Network Slice Simultaneous Registration Group (NSSRG) information (see clause 5.15.x).
The (R)AN may use Requested NSSAI in access stratum signalling to handle the UE Control Plane connection before the 5GC informs the (R)AN of the Allowed NSSAI. The Requested NSSAI is used by the RAN for AMF selection, as described in clause 6.3.5. The UE shall not include the Requested NSSAI in the RRC Resume when the UE asks to resume the RRC connection and is CM-CONNECTED with RRC Inactive state.
When a UE is successfully registered over an Access Type, the CN informs the (R)AN by providing the Allowed NSSAI for the corresponding Access Type.
NOTE: The details of how the RAN uses NSSAI information are described in TS 38.300 [27].
The Subscription Information shall contain one or more S-NSSAIs i.e. Subscribed S-NSSAIs. Based on operator's policy, one or more Subscribed S-NSSAIs can be marked as a default S-NSSAI. If an S-NSSAI is marked as default, then the network is expected to serve the UE with a related applicable Network Slice instance when the UE does not send any permitted S-NSSAI to the network in a Registration Request message as part of the Requested NSSAI.
The Subscription Information for each S-NSSAI may contain:
The network verifies the Requested NSSAI the UE provides in the Registration Request against the Subscription Information. For the S-NSSAIs subject to Network Slice-Specific Authentication and Authorization the clause 5.15.10 applies.
In roaming case, the UDM shall provide to the VPLMN only the S-NSSAIs from the Subscribed S-NSSAIs the HPLMN allows for the UE in the VPLMN. If the UE is subject to restrictions of simultaneous registration of network slices (i.e. if the Subscription Information for the S-NSSAIs contains NSSRG information), the UDM provides to the VPLMN subscribed S-NSSAIs and, if applicable, NSSRG information, as described in clause 5.15.x.
When the UDM updates the Subscribed S-NSSAI(s) to the serving AMF, based on configuration in this AMF, the AMF itself or the NSSF determines the mapping of the Configured NSSAI for the Serving PLMN and/or Allowed NSSAI to the Subscribed S-NSSAI(s). The serving AMF then updates the UE with the above information as described in clause 5.15.4.
The Network Slice configuration information contains one or more Configured NSSAI(s). A Configured NSSAI may either be configured by a Serving PLMN and apply to the Serving PLMN, or may be a Default Configured NSSAI configured by the HPLMN and that applies to any PLMNs for which no specific Configured NSSAI has been provided to the UE. There is at most one Configured NSSAI per PLMN.
The Default Configured NSSAI, if it is configured in the UE, is used by the UE in a Serving PLMN only if the UE has no Configured NSSAI for the Serving PLMN.
The Configured NSSAI of a PLMN may include S-NSSAIs that have standard values or PLMN-specific values.
The Configured NSSAI for the Serving PLMN includes the S-NSSAI values which can be used in the Serving PLMN and may be associated with mapping of each S-NSSAI of the Configured NSSAI to one or more corresponding HPLMN S-NSSAI values.
A UE subscription may contain Network Slice Simultaneous Registration Group (NSSRG) information. If so, the UE configuration is performed as described in clause 5.15.x.2.
The UE may be pre-configured with the Default Configured NSSAI. The UE may be provisioned/updated with the Default Configured NSSAI, determined by the UDM in the HPLMN, using the UE Parameters Update via UDM Control Plane procedure defined in clause 4.20 of TS 23.502 [3]. Each S-NSSAI in the Default Configured NSSAI may have a corresponding S-NSSAI as part of the Subscribed S-NSSAI(s). Consequently, if the Subscribed S-NSSAI(s) which are also present in the Default Configured NSSAI are updated the UDM should update the Default Configured NSSAI in the UE.
In the HPLMN, the S-NSSAIs in the Configured NSSAI provided as described in clause 5.15.4.2, at the time when they are provided to the UE, shall match the Subscribed S-NSSAIs for the UE. When the Subscribed S-NSSAI(s) are updated (i.e. some existing S-NSSAIs are removed and/or some new S-NSSAIs are added) and one or more are applicable to the Serving PLMN the UE is registered in, as described in clause 5.15.3, or when the associated mapping is updated the AMF shall update the UE with the Configured NSSAI for the Serving PLMN and/or Allowed NSSAI and/or the associated mapping to HPLMN S-NSSAIs (see clause 5.15.4.2). When there is the need to update the Allowed NSSAI, the AMF shall provide the UE with the new Allowed NSSAI and the associated mapping to HPLMN S-NSSAIs, unless the AMF cannot determine the new Allowed NSSAI (e.g. all S-NSSAIs in the old Allowed NSSAI have been removed from the Subscribed S-NSSAIs), in which case the AMF shall not send any Allowed NSSAI to the UE but indicate to the UE to perform a Registration procedure. If the UE is in a CM-IDLE state, the AMF may trigger Network Triggered Service Request or wait until the UE is in a CM-CONNECTED state as described in clause 4.2.4.2, TS 23.502 [3].
When providing a Requested NSSAI to the network upon registration, the UE in a given PLMN only includes and uses S-NSSAIs applying to this PLMN. The mapping of S-NSSAIs of the Requested NSSAI to HPLMN S-NSSAIs may also be provided (see clause 5.15.4.1.2 for when this is needed). The S-NSSAIs in the Requested NSSAI are part of the Configured and/or Allowed NSSAIs applicable for this PLMN, when they are available. If the UE has received NSSRG information together with the Configured NSSAI, it only includes in the Requested NSSAI S-NSSAIs that all share a common NSSRG. If no Configured NSSAI and Allowed NSSAI for the PLMN are available, the S-NSSAIs in the Requested NSSAI correspond to the Default Configured NSSAI, if configured in the UE. Upon successful completion of a UE's Registration procedure over an Access Type, the UE obtains from the AMF an Allowed NSSAI for this Access Type, which includes one or more S-NSSAIs and, if needed (see clause 5.15.4.1.2 for when this is needed), their mapping to the HPLMN S-NSSAIs. These S-NSSAIs are valid for the current Registration Area and Access Type provided by the AMF the UE has registered with and can be used simultaneously by the UE (up to the maximum number of simultaneous Network Slice instances or PDU Sessions).
The UE might also obtain one or more rejected S-NSSAIs with cause and validity of rejection from the AMF. An S-NSSAI may be rejected:
While it remains RM-REGISTERED in the PLMN and regardless of the Access Type, the UE shall not re-attempt to register to an S-NSSAI rejected for the entire PLMN until this rejected S-NSSAI is deleted as specified below.
While it remains RM-REGISTERED in the PLMN, the UE shall not re-attempt to register to an S-NSSAI rejected in the current Registration Area until it moves out of the current Registration Area.
S-NSSAIs that the UE provides in the Requested NSSAI which are neither in the Allowed NSSAI nor provided as a rejected S-NSSAI, shall, by the UE, not be regarded as rejected, i.e. the UE may request to register these S-NSSAIs again next time the UE sends a Requested NSSAI.
The UE stores (S-)NSSAIs as follows:
At any time, the AMF may provide the UE with a new Configured NSSAI for the Serving PLMN, associated with mapping of the Configured NSSAI to HPLMN S-NSSAIs as specified in clause 5.15.4.1. The Configured NSSAI for the Serving PLMN and the mapping information is either determined in the AMF (if based on configuration, the AMF is allowed to determine the Network Slice configuration for the whole PLMN) or by the NSSF. The AMF provides an updated Configured NSSAI as specified in TS 23.502 [3], clause 4.2.4 UE Configuration Update procedure.
The AMF shall provide the UE with NSSRG information alongside the Configured NSSAI if NSSRG information is included in the subscription information received from the UDM and if the UE has indicated support for the feature as part of the registration request, see clause 5.15.x.
If the HPLMN performs the configuration update of a UE registered in the HPLMN (e.g. due to a change in the Subscribed S-NSSAI(s) or due to a change of NSSRG information), this results in updates to the Configured NSSAI for the HPLMN and, if applicable, NSSRG information for each S-NSSAI of the Configured NSSAI. Updates to the Allowed NSSAI and/or, if present, to the associated mapping of the Allowed NSSAI to HPLMN S-NSSAIs are also possible if the configuration update affects S-NSSAI(s) in the current Allowed NSSAI.
If the VPLMN performs the configuration update of a UE registered in the VPLMN (e.g. due to a change in the Subscribed S-NSSAI(s), the associated mapping is updated, or due to a change of NSSRG information), this results in updates to the Configured NSSAI for the Serving PLMN and/or to the associated mapping of the Configured NSSAI for the Serving PLMN to HPLMN S-NSSAIS and, if applicable, NSSRG information for each S-NSSAI of the Configured NSSAI. Updates to the Allowed NSSAI and/or to the associated mapping of the Allowed NSSAI to HPLMN S-NSSAIs are also possible if the configuration update affects S-NSSAI(s) in the current Allowed NSSAI.
A UE for which the Configured NSSAI for the Serving PLMN has been updated as described in clause 5.15.4.1 and has been requested to perform a Registration procedure, shall initiate a Registration procedure to receive a new valid Allowed NSSAI (see clause 5.15.5.2.2).
When the subscribed S-NSSAIs change, a UDR flag is set in the HPLMN to make sure the current PLMN (or, if the UE was not reachable, the next serving PLMN) is informed by the UDM that the subscription data for network slicing has changed. The AMF, when it receives the indication from the UDM subscription has changed, indicates the UE that subscription has changed and uses any updated subscription information from the UDM to update the UE. Once the AMF updates the UE and obtains an acknowledgment from the UE, the AMF informs the UDM that the configuration update was successful and the UDM clears the flag in the UDR. If the UE is in a CM-IDLE state, the AMF may trigger Network Triggered Service Request or wait until the UE is in a CM-CONNECTED state as described in clause 4.2.4.2, TS 23.502 [3].
If the UE receives indication from the AMF that Network Slicing subscription has changed, the UE locally deletes the network slicing information it has for all PLMNs, except the Default Configured NSSAI (if present). It also updates the current PLMN network slicing configuration information with any received values from the AMF.
The update of URSP rules (which include the NSSP), if necessary at any time, is described in TS 23.503 [45].
When a UE registers over an Access Type with a PLMN, if the UE has either or both of:
The Requested NSSAI shall be one of:
The subset of S-NSSAIs in the Configured-NSSAI provided in the Requested NSSAI consists of one or more S-NSSAI(s) in the Configured NSSAI applicable to this PLMN, if one is present, and for which no corresponding S-NSSAI is already present in the Allowed NSSAI for the access type for this PLMN. The UE shall not include in the Requested NSSAI any S-NSSAI that is currently rejected by the network (i.e. rejected in the current registration area or rejected in the PLMN). For the registration to a PLMN for which neither a Configured NSSAI applicable to this PLMN or an Allowed NSSAI are present, the S-NSSAIs provided in the Requested NSSAI correspond to the S-NSSAI(s) in the Default Configured NSSAI unless the UE has HPLMN S-NSSAI for established PDU Session(s) in which case the HPLMN S-NSSAI(s) shall be provided in the mapping of Requested NSSAI in the NAS Registration Request message, with no corresponding VPLMN S-NSSAI in the Requested NSSAI. If the UE has been provided with NSSRG information together with the Configured NSSAI, the UE only includes in the Requested NSSAI S-NSSAIs that share a common NSSRG, see clause 5.15.x.2.
When a UE registers over an Access Type with a PLMN, the UE shall also indicate in the Registration Request message when the Requested NSSAI is based on the Default Configured NSSAI.
The UE shall include the Requested NSSAI in the RRC Connection Establishment and in the establishment of the connection to the N3IWF/TNGF (as applicable) and in the NAS Registration procedure messages subject to conditions set out in clause 5.15.9. However, the UE shall not indicate any NSSAI in RRC Connection Establishment or Initial NAS message unless it has either a Configured NSSAI for the corresponding PLMN, an Allowed NSSAI for the corresponding PLMN and Access Type, or the Default Configured NSSAI. If the UE has HPLMN S-NSSAI(s) for established PDU Session(s), the HPLMN S-NSSAI(s) shall be provided in the mapping of Requested NSSAI in the NAS Registration Request message, independent of whether the UE has the corresponding VPLMN S-NSSAI. The (R)AN shall route the NAS signalling between this UE and an AMF selected using the Requested NSSAI obtained during RRC Connection Establishment or connection to N3IWF/TNGF respectively. If the (R)AN is unable to select an AMF based on the Requested NSSAI, it routes the NAS signalling to an AMF from a set of default AMFs. In the NAS signalling, if available, the UE provides the mapping of each S-NSSAI of the Requested NSSAI to a corresponding HPLMN S-NSSAI.
When a UE registers with a PLMN, if for this PLMN the UE has not included a Requested NSSAI nor a GUAMI while establishing the connection to the (R)AN, the (R)AN shall route all NAS signalling from/to this UE to/from a default AMF. When receiving from the UE a Requested NSSAI and a 5G-S-TMSI or a GUAMI in RRC Connection Establishment or in the establishment of connection to N3IWF/TNGF, if the 5G-AN can reach an AMF corresponding to the 5G-S-TMSI or GUAMI, then 5G-AN forwards the request to this AMF. Otherwise, the 5G-AN selects a suitable AMF based on the Requested NSSAI provided by the UE and forwards the request to the selected AMF. If the 5G-AN is not able to select an AMF based on the Requested NSSAI, then the request is sent to a default AMF.
When the AMF selected by the AN during Registration Procedure receives the UE Registration request, or after an AMF selection by MME (i.e. during EPS to 5GS handover) the AMF receives S-NSSAI(s) from SMF+PGW-C in 5GC:
When either no Requested NSSAI was included, or the mapping of the S-NSSAIs in Requested NSSAI to HPLMN S-NSSAIs is incorrect, or a Requested NSSAI is not considered valid in the PLMN and as such at least one S-NSSAI in the Requested NSSAI was rejected as not usable by the UE in the PLMN, or the UE indicated that the Requested NSSAI is based on the Default Configured NSSAI, the AMF may update the UE slice configuration information for the PLMN as described in clause 5.15.4.2.
If the Requested NSSAI does not include S-NSSAIs which map to S-NSSAIs of the HPLMN subject to Network Slice-Specific Authentication and Authorization and the AMF determines that no S-NSSAI can be provided in the Allowed NSSAI for the UE in the current UE's Tracking Area and if no default S-NSSAI(s) could be added as described in step (A), the AMF shall reject the UE Registration and shall include in the rejection message the list of Rejected S-NSSAIs, each of them with the appropriate rejection cause value.
If the Requested NSSAI includes S-NSSAIs which map to S-NSSAIs of the HPLMN subject to Network Slice-Specific Authentication and Authorization, the AMF shall include in the Registration Accept message an Allowed NSSAI containing only those S-NSSAIs that are not to be subject to Network Slice-Specific Authentication and Authorization and, based on the UE Context in AMF, those S-NSSAIs for which Network Slice-Specific Authentication and Authorization for at least one of the corresponding HPLMN S-NSSAIs succeeded previously regardless the Access Type, if any.
The AMF shall also provide the list of Rejected S-NSSAIs, each of them with the appropriate rejection cause value.
The S-NSSAIs which map to S-NSSAIs of the HPLMN subject to Network Slice-Specific Authentication and Authorization is ongoing are in “pending” state in the AMF and shall be included in the Pending NSSAI. The Pending NSSAI may contain a mapping of the S-NSSAI(s) for the Serving PLMN to the HPLMN S-NSSAIs, if applicable. The UE shall not include in the Requested NSSAI any of the S-NSSAIs from the Pending NSSAI the UE stores, regardless of the Access Type.
If:
Then, the AMF shall initiate the Network Slice-Specific Authentication and Authorization procedure as described in clause 5.15.10 for each S-NSSAI that requires it, except, based on Network policies, for those S-NSSAIs for which Network Slice-Specific Authentication and Authorization have been already initiated on another Access Type for the same S-NSSAI(s). At the end of the Network Slice-Specific Authentication and Authorization steps, the AMF by means of the UE Configuration Update procedure shall provide a new Allowed NSSAI to the UE which also contains the S-NSSAIs subject to Network Slice-Specific Authentication and Authorization for which the authentication and authorization is successful. The AMF may perform AMF selection when NSSAA completes for the S-NSSAIs subject to S-NSSAI in “pending” status. If an AMF change is required, this shall be triggered by the AMF using the UE Configuration Update procedure indicating a UE re-registration is required. The S-NSSAIs which were not successfully authenticated and authorized are not included in the Allowed NSSAI and are included in the list of Rejected S-NSSAIs with a rejection cause value indicating Network Slice-Specific Authentication and Authorization failure.
Once completed the Network Slice-Specific Authentication and Authorization procedure, if the AMF determines that no S-NSSAI can be provided in the Allowed NSSAI for the UE, which is already authenticated and authorized successfully by a PLMN, and if no default S-NSSAI(s) could be added as described in step (A), the AMF shall execute the Network-initiated Deregistration procedure described in TS 23.502 [3], clause 4.2.2.3.3, and shall include in the explicit De-Registration Request message the list of Rejected S-NSSAIs, each of them with the appropriate rejection cause value.
If an S-NSSAI is rejected with a rejection cause value indicating Network Slice-Specific Authentication and Authorization failure or revocation, the UE can re-attempt to request the S-NSSAI based on policy, local in the UE.
For roaming scenarios:
Depending on operator's policy and the configuration in the AMF, the AMF may decide the S-NSSAI values to be used in the VPLMN and the mapping to the Subscribed S-NSSAIs.
For the home routed case, the V-SMF sends the PDU Session Establishment Request message to the H-SMF along with the S-NSSAI with the value used in the HPLMN (a).
The subscription information for a UE may include for each S-NSSAI Network Slice Simultaneous Registration Group (NSSRG) information constraining which S-NSSAIs can be simultaneously provided to the UE in the Allowed NSSAI.
Two S-NSSAIs sharing at least one NSSRG can be simultaneously included in the Allowed NSSAI. Otherwise, these S-NSSAIs cannot be included simultaneously in the Allowed NSSAI.
The NSSRG information, defining the association of S-NSSAIs to NSSRG, is provided as an additional and separate information.
If the optional NSSRG information is not present for the S-NSSAIs of a subscription, and other restrictions do not apply e.g. availability at a specific location, then it is assumed that all the S-NSSAIs in the subscription information can be simultaneously provided to the UE in the Allowed NSSAI. However, if NSSRG information is present in the subscription information, at least one NSSRG shall be associated with each of the S-NSSAIs in the subscription information. At any time, if the AMF has received subscription information for a UE that includes NSSRG information, the Allowed NSSAI for the UE can only include S-NSSAIs which share a common NSSRG.
The default S-NSSAIs, if more than one is present, are associated with the same NSSRGs, i.e. the UE is always allowed to be registered with all the default S-NSSAIs simultaneously. The HPLMN only sends S-NSSAIs sharing all the NSSRGs of the Default S-NSSAIs to a non-supporting VPLMN as part of the subscription information, i.e. in addition to the default S-NSSAI(s), the HPLMN may send any other subscribed S-NSSAI which shares at least all the NSSRG defined for the default S-NSSAI(s), and the HPLMN sends no NSSRG information to the VPLMN. A subscription information that includes NSSRG information shall include at least one default S-NSSAI.
A supporting AMF/NSSF, when it receives a Requested NSSAI, evaluates the S-NSSAIs of the HPLMN (in the mapping information of the Requested NSSAI, when a mapping information is applicable) based on any received NSSRG information for these S-NSSAIs, to determines whether they can be provided together in the Allowed NSSAI.
A UE may support the subscription-based restrictions to simultaneous registration of network slice feature. In this case, the UE indicates its support in the Registration Request message in the Initial Registration and the Mobility Registration Update. The supporting AMF stores in the UE context whether the UE has indicated support for the feature.
When the serving PLMN AMF provides the Configured NSSAI to the UE, and the UE has indicated it supports the subscription-based restrictions to simultaneous registration of network slices feature, the AMF also provides the UE with the NSSRG information related to the S-NSSAIs of the HPLMN which are in the mapping information of the Configured NSSAI. A UE which receives the NSSRG values in the network slicing configuration information shall only include in the Requested NSSAI S-NSSAIs that share a common NSSRG as per the received information. If the HPLMN changes NSSRG information in the subscription information for a UE, the UDM updates the supporting AMF serving the UE with the new NSSRG information and the AMF updates the UE as necessary with network slicing configuration by means of the UE Configuration Update procedure (this may include changes in the Configured NSSAI (and related mapping information) and changes in the Allowed NSSAI as applicable). The UE acknowledges this UE Configuration Update as per clause 4.2.4.2 in TS 23.502 [3].
An AMF which supports the subscription-based restrictions to simultaneous registration of network slice feature configures a non-supporting UE with a Configured NSSAI including only compatible S-NSSAIs, except if it has been instructed otherwise by the UDM. In addition to the default S-NSSAI(s), the AMF sends to the UE in the Configured NSSAI any other subscribed S-NSSAI whose NSSRG match at least those defined for the default S-NSSAI(s).
The UDM in a supporting HPLMN may optionally keep a record of the PEIs or Type Allocation Codes values regarding UE ability to handle network slices that cannot be provided simultaneously in Allowed NSSAI.
The UDM may, based on configuration or the optional PEI records, indicate the AMF to provide the non-supporting UEs with the full set of subscribed S-NSSAIs even if they do not share a common NSSRG. The UDM instructs the supporting AMFs of a PLMN to do so by indicating that the UE can be given a Configured NSSAI with all the S-NSSAIs in the subscription information.
Based on its policy (including configuration or optionally checking the specific PEI or Type Allocation Code used by the UE, and subject to roaming agreement) the UDM may also provide the serving AMF in a non-supporting VPLMN with all the S-NSSAI in the subscription information. In this case the AMF provides the UE with a Configured NSSAI including all the S-NSSAIs in the subscription information the AMF receives.
The AMF provides no NSSRG information to a non-supporting UE.
When an AMF which supports the subscription-based restrictions to simultaneous registration of network slice feature, receives from a supporting UE a Requested NSSAI including S-NSSAIs that are supported in the Tracking Area but do not share a common NSSRG, the AMF assumes the UE configuration is not up-to-date, and it provides the UE with an updated configuration including the up-to-date NSSRG information for the S-NSSAIs in the Configured NSSAI as described above.
<5.15.x.2 UE and UE Configuration Aspects when the UE is Accessing 3GPP Access and Non-3GPP Access>
When the UE receives a NSSRG policy over an access type (e.g. 3GPP access type), the UE shall apply the NSSRG policy to another access type (e.g. non-3GPP access type). In addition, the network sends an indication in the registration accept message over the access type indicating whether the UE shall apply NSSRG policy on the NAS or AS procedure over an access type independent of another access type. If the network indicates that the UE applies the NSSRG policy to the NAS or AS procedure over an access type independent NSSRG policy over the other access type, then S-NSSAI(s) in the requested NSSAI of an access type does not depend on the allowed NSSAI of the other access type as per the NSSRG policy i.e. the Requested NSSAI over an access type may contain an S-NSSAI which does not share the common NSSRG with the S-NSSAI(s) of the allowed NSSAI over the second access type.
While the disclosure has been particularly shown and described with reference to exemplary Aspects thereof, the disclosure is not limited to these Aspects. It will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present disclosure as defined by this document. For example, the Aspects above are not limited to 5GS, and the Aspects are also applicable to communication system other than 5GS.
The whole or part of the example Aspects disclosed above can be described as, but not limited to, the following supplementary notes.
Allowed NSSAI of the first access type,
While the invention has been particularly shown and described with reference to example embodiments thereof, the invention is not limited to these embodiments. It will be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from the spirit and scope of the present invention as defined by the claims.
This application is based upon and claims the benefit of priority from Indian provisional patent application No. 20/211,1025931, filed on Jun. 10, 2021, the disclosure of which is incorporated herein in its entirety by reference.
| Number | Date | Country | Kind |
|---|---|---|---|
| 202111025931 | Jun 2021 | IN | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/JP2022/020687 | 5/18/2022 | WO |
