 in Ethernet networks deployed in offices or factories. Release-16 addresses unique network identification and access control for private networks, also referred to as non-public networks (NPNs). Two NPN deployment models are supported: Stand-alone non-public network (SNPN), i.e. scenarios where the entire network (RAN and core network) is deployed on-site (e.g. inside a factory). Public-network-integrated non-public network (PNI-NPN) refers to scenarios where the core network control-plane and typically subscription management (UDM) are shared between NPN and PLMN. RAN and core network user-plane may either be shared or are dedicated to the NPN. 3.2.7.2 Stand-Alone Non-public Networks The key challenge for SNPNs is that the existing identification scheme for cellular networks, i.e. the PLMN ID consisting of mobile country code (MCC) and mobile network code (MNC) has not been designed with a large number of non-public networks in mind. As a result, it is not feasible to assign a unique PLMN ID for each SNPN deployment. Furthermore, while the International Telecommunication Union (ITU) has allocated MCC 999 for use by private networks (ITU 2018), MNCs under this MCC can be used by anyone without further consultation with ITU. In other words, PLMN IDs using MCC 999 also fall short of providing a unique network ID for SNPNs. Non-unique network IDs can lead to SNPN UEs not receiving service, for example, if a UE serving a robot arm tries to connect to an SNPN B that uses the same network ID as its own SNPN A. SNPN B would reject the registration attempt, upon which the UE would blacklist the network ID and remain disconnected. It is worth noting that connection attempts by unauthorized UEs (which are rejected by the network) consume radio resources and may therefore also degrade the performance of SNPNs. The latter may be an issue in the case of time-sensitive non-public network services, for example, if the SNPN is used for industrial automation. To enable SNPN operators to configure a unique network ID, Release-16 