A gNB may support multiple and different network slices, and on different frequencies in different regions. In TR 38.832, in order to support fast cell selection and cell reselection for particular network slices, solutions based on broadcasting slice related information are being studied. The broadcast slice related cell info may contain e.g. NSSAI, SST, slice grouping or slice associated information. In this key issue, the following questions are to be addressed:

- Whether broadcasting slice related information in this scenario will cause any privacy issue.
- If so, mitigation solutions need to be provided.

According to TS 23.501, SST refers to the expected Network Slice behaviour in terms of features and services. An SST could be represented with a standardised SST value or without a standardised SST value. The currently standardized SST values can indicate the slice types of eMBB, URLCC, MIoT and V2X, from which sensitive information of a specific slice can hardly be derived. Hence there is no privacy issue if SST is included in the broadcast SIB. An S-NSSAI is comprised of a SST and an optional Slice Differentiator (SD), which is to differentiate amongst multiple network slices of the same Slice/Service type. An S-NSSAI may contain privacy-sensitive information, e.g. when dedicated to a group of users may expose the group identity. An S-NSSAI may also contain sensitive information, e.g. network topology that the operator may not want to share with others. A cell broadcasting sensitive S-NSSAI may become a target of attackers interested in the S-NSSAI information. It is likely for an attacker to further link the S-NSSAI with its UEs/users together with other knowledge/tools, e.g. a frequency band supports only the sensitive S-NSSAI or a few allowing attackers to narrow down the scope. Broadcasting sensitive S-NSSAI should be avoided. Slice group information may or may not leak sensitive information depending on how the slice group is defined. For example, if a slice group is defined based on the standardized slice type or SST values, there may be no privacy issue as discussed above. S-NSSAIs with only SST values are valid slice identifiers. On the other hand, there may be cases that a not well designed slice group contains only one SST (used in an S-NSSAI as a valid slice identifier), one S-NSSAI or a few S-NSSAI having the same SD values thus exposing network topologies or being dedicated to special groups of users. In such a case, broadcasting group info may lead to leak of sensitive information. Slice grouping information (slice group identity and group mapping info) is assumed to be delivered to UE through NAS signaling which is protected. The group identifier is broadcasted rather than Slice Group itself. The group identifier is to be defined to identify the slice group. Therefore, the slice group information for which the slice group identifier is to be broadcasted needs to be defined taking into consideration the leakage of sensitive information.

Slice group information needs to be defined taking into consideration the possible leakage of sensitive information due to the group identifier being broadcasted.

A new Network Slice Admission Control (NSAC) procedure has been introduced in TS 23.501 and TS 23.502, where the number of registered UEs is monitored for a network slice (i.e. S-NSSAI) and a UE will be rejected to access if the number of UE registered in the requested S-NSSAI has reached its quota. However, the NSAC procedure needs to be studied further to address potential security risks, for examples:

• In the current NSAC procedure, the number of registered UE in an S-NSSAI is updated independently from other S-NSSAIs during the registration procedure. In other words, the granularity level at registration is S-NSSAI. However, it is not the case in the de-registration procedure. The numbers are only updated when the UE exits from all network slices, i.e. de-registered. Since a UE may access multiple slices, e.g. eight, the UE would still be counted against quota usage of ALL S-NSSAIs even the UE is not using some or most of slices ("idly occupied" by the UE). This may lead to the quota reached fast which does not reflect the real usage of a slice. Other legitimate UEs will suffer from DoS - "dog in the mager". It is notable that an attacker can use legitimate UEs to launch such attacks.
• The Early Admission Control (EAC) mode has been introduced where the admission control can be inactive if the number of UE bellows a pre-configured threshold. This may pose a security risk that exceeds the slice quota when a sudden increase in the slice registration requests, maliciously or accidentally.

If EAC mode is not activated properly, it has the potential risk to cause unavailability of the network slices.

The 5G system should prevent a potential risk due to the EAC inactive mode.

As specified in TS 23.501 and TS 23.502, the current utilization state of a network slice, e.g. the number of UEs registered for a network slice or the current number of PDU Sessions established on a network slice, can be reported to an AF deployed within a 3GPP system or in a third party domain. In either case, the AF should be authenticated and authorized beforehand and the 5G system should make sure no sensitive information leakage. In TS 23.502, a notification procedure has been specified to allow an AF to get access to the network slide information through NEF. However, it is not clear how the AF is authenticated and authorized. The authorization details (e.g. what parameters and whether slice-specific parameters need to be verified) need to be specified to avoid ambiguity and potential attacks. It is expected that the AF deployed within the 3GPP domain or a third party domain will be authenticated or authorized in a different way, which should be also studied and specified. In addition, the procedure needs to take into account the privacy issue of S-NSSAI since S-NSSAI may not be available at a third party AF due to concerns on the sensitivity information leakage (an S-NSSAI may not to be made known to a third-party AF).

If an AF is not authenticated or authorized before accessing to the network slice information, a mischievous AF may collect such information for other purposes. If S-NSSAI is sent to a third party AF, sensitive information may leak out of 3GPP systems.

S-NSSAI information shall not be sent to a third party AF for network slice quota-usage notification.

AF authentication and authorization is subject to whether the AF lies in the 3GPP system or in a third party domain. Existing but different mechanisms are chosen for the two scenarios. In case AF is a third party NF, S-NSSAI is not required at AF to prevent sensitive information leakage.

This solution addresses the key issue #3 by optionally storing a mapping between an S-NSSAI and ENSI in NEF. The AF which is outside the 3GPP operator domain is configured with ENSI instead of S-NSSAI to avoid sensitive information leakage. This solution is in line with the defined procedures for the AF to get access to the network slice quota information. The NSACF services, i.e. "Nnsacf_SliceEventExposure_Subscribe/Unsubscribe" and "Nnsacf_SliceEventExposure_Notify" are not affected and can be kept as is in TS 23.502. Optionally, the corresponding NEF services may be updated with the different Event Filter values.