Patent Description:
This application relates to the field to cellular telecommunication networks. More specifically, the application relates to configuration of routing IDs in such networks.

3GPP is currently standardizing the <NUM> Core Network (5GC) as part of the overall <NUM> System architecture. The <NUM> Core Network is standardized in 3GPP TS <NUM> (v. <NUM>) and 3GPP TS <NUM>. It is composed of a set of relevant functional entities, called Network Functions (NFs). 3GPP TS <NUM> defines the <NUM> System Architecture as a Service Based Architecture (SBA) for the control plane, i.e. a system architecture in which the system functionality is achieved by a set of NFs providing services to other authorized NFs to access their services. Control Plane (CP) NFs in the <NUM> System architecture are based on SBA. An NF service is one type of capability exposed by a first NF (NF Service Producer) to a second, authorized NF (NF Service Consumer) through a service-based interface (SBI). An NF service may support one or more NF service operations. An SBI represents how the set of services is provided or exposed by a given NF. This is the interface where the NF service operations are invoked, and it is based on HTTP/<NUM> protocol.

An example of the <NUM> System reference architecture as defined in 3GPP TS <NUM>, showing service-based interfaces used within the Control Plane, is depicted in <FIG> (not all NFs are depicted).

The Network Repository Function (NRF) is a key NF within the 5GC SBA Framework that provides support to service providers to register their services so that service consumers can dynamically discover them. The service discovery function enabled by NRF provides the address of the NF instances that exist in a network for providing a service and all necessary information to issue and route requests towards the selected target NF producer (i.e. protocol, port, FQDN and/or IP address of target NF instance amongst other parameters required to create a URI used in the http request). The NF interactions with the NRF for registration and discovery may be mostly be managed as background traffic independent from the traffic related to UE procedures.

Some deployments of 5GC may define segments of Authentication User Function (AUSF), Unified Data Management (UDM), and/or Unified Data Repository (UDR) for managing different sets of users within the Home Public Land Mobile Network (HPLMN), e.g., in case of regional AUSF/UDM/UDR deployments facilitating the administration of the subscription base within large PLMNs). For these scenarios, 3GPP has defined the possibility for AUSF/UDM/UDR to register in NRF using segment parameters provided to NF consumers during AUSF/UDM/UDR discovery to facilitate the selection of the right AUSF/UDM/UDR instance for a given UE procedure.

These segment parameters are defined in 3GPP TS <NUM> (v. <NUM>) and can include the following as shown below in Table TT1.

In particular, the Routing Indicator is of relevance during initial interactions with the UE as it is included within the SUCI provided by a UE when the privacy feature is active.

The use of the Routing Indicator to route the UE authentication requests to the right AUSF/UDM/UDR segment of the UE represented by the SUCI is illustrated in the following figure.

With reference to <FIG>, a PLMN may deploy separate AUSF/UDM/UDR segments managing different segments of subscribers, e.g., regional setups. As shown in <FIG>, AUSF/UDM/UDR discovery/selection based on segment parameters may be realized by (a) UDR, UDM, and/or AUSF can register in the PLMN/ (Network Slice Selection Assistance Information) NSSAI level NRF including relevant segment parameters; (b) serving notes discover, via NRF, registered instances of AUSF/UDM/UDR available at, e.g., PLMN ID, NSSAI, etc. (<NUM>) During UE procedure, serving node may select an applicable AUSF/UDM/UDR instance based on NRF information retrieved in (b). (1b) the serving node can make a subscription permanent identifier (SUPI) based discovery request if not enough information is available to resolve to the desired AUSF/UDM/UDR. For example, this may be done in roaming cases or if a segment parameter becomes too scattered such that it cannot be used for registration or discovery. A routing database may keep an association of individual SUPI/GPSIs with AUSF/UDM/UDR segment parameters if needed. (<NUM>) the serving node selects and interacts thereafter with target AUSF/UDM/UDR.

There currently exist certain challenges. The mechanisms to route the UE authentication requests to the right AUSF/UDM/UDR segment of the UE represented by the Subscription Concealed Identifier (SUCI) based on the Routing Indicator illustrated in <FIG> are based on defined discovery and selection procedures. These however assumes that the UE is providing a correct Routing ID which corresponds with the actual configuration in the different AUSF/UDM/UDR segments within the HPLMN.

However, if UE/SIMs are provisioned with an incorrect Routing ID the selected UDM will reject the Authentication Request with an "HN Public Key ID Not Supported" type of error if HN Public Key ID is not supported in the selected UDM (e.g., the SUCI cannot be decrypted) or an "UNKNOWN USER" type of error when the UDM is unable to find SUPI in UDR. In the Subscriber Identity Modules (SIMs) may be referred to as herein as a Universal Subscriber Identity Modules (USIMs).

<FIG> depicts a misconfiguration of a routing ID of a UE. UE procedures include information flows that (authentication in the first place) may be routed to the AUSF/UDM/UDR segment based on the routing ID provided (e.g. segment <NUM>). The Access and Mobility Management Function (AMF) may issue an authentication request including the SUCI to one of the AUSF instances matching the routing ID provided by the UE. It may be assumed that there are multiple AUSF/UDM/UDR instances registered in the PLMN for the routing ID provided by the UE. Otherwise, the AMF will reject the UE registration.

However, if UE/SIMs are provisioned with an incorrect routing ID the selected you DM may reject the authentication request with an "HN Public Key ID Not Supported" error or an "UNKNOWN USER" error.

A potential approach may be to utilize a mechanism to update the routing ID in the misconfigured UE/SIMs. However, there is a need to allow this type of wrongly configured UEs to connect to the core network so that they can be properly configured afterwards. Certain aspects of the present disclosure and their embodiments may provide solutions to these or other challenges.

<NPL>, discloses a mechanism between the UPF and SMF/PCF for updating a UE's URSP for an active PDU session.

<CIT> discloses a serving gateway support node that controls connections through at least one serving gateway of a radio telecommunications network.

<NPL>, disclose various proposals on UDM and SIDF discovery.

Furthermore, the embodiments of the invention are those defined by the claims.

The present disclosure includes the following figures:.

These figures will be better understood by reference to the following detailed description of the embodiments.

This disclosure provides for a mechanism or mechanisms for UE/USIMs which are configured with a wrong Routing ID to be redirected to the right AUSF/UDM/UDR set that the UE belongs to, so they can authenticate and register in the core network and later be updated with a correct Routing ID. An exemplary embodiment is shown in <FIG>.

<FIG> depicts the redirection of misconfigured UE/USIMS to correct AUSF/UDM/UDR segment according to some embodiments of the present disclosure. The mechanism for redirection/correction is based on detection at the UDM/SIDF of possible UE/SIM misconfiguration. This may be based on an unknown SUPI or unknown HN Public Key ID. The UDM may determine whether the SUPI and/or the HN Pub Key ID are/is defined elsewhere within the HPLMN. This may be done, for example, by interacting with the NRF based on the SUPI and/or HN Public Key ID, as shown at step 2a of <FIG>. The UDM may reject the authentication request with a new error code, e.g., an "Incorrect Routing ID" error code, at step 2b. This may include additional information regarding the user, such as the SUPI, and/or information about the right AUSF/UDM instances to use, e.g., the correct routing ID. The AMF may make a new AUSF/UDM selection based on the information or criteria provided within the air. For example, the AMF may make the new AUSF/UDM selection based on the SUPI and/or the new routing ID. The AMF may query the NRF as part of this selection or information collection, at step 2c. The AMF may thereafter reach the correct AUSF/UDM/UDR segment where the user (the UE/USIM) is authenticated and/or registered, at step <NUM>. Subsequently, the UE/USIM can be properly configured with the correct routing ID.

There are, proposed herein, various embodiments which address one or more of the issues disclosed herein.

Certain embodiments may provide one or more of the following technical advantage(s). The mechanism to redirect UE/USIMs which are configured with a wrong Routing ID to the right AUSF/UDM/UDR segment allows these misconfigured UE/USIMs to be able to authenticate and register in the 5GC in such a way that they can later be updated with a correct Routing ID. The mechanism may utilize on existing SBA services and just adds additional information elements and error codes relevant for the execution of the use case.

Without this mechanism provided herein, these UEs may remain locked-out from the system, since they will be rejected within the 5GC and will have to be updated with its right Routing ID by some other offline means (e.g. change/update of USIM at operator premises) with additional costs for the operator.

<FIG> shows more in detail the various of the solution proposed by this disclosure to redirect UE/USIMs which are configured with a wrong Routing ID to the right AUSF/UDM/UDR segment. On the 5GC side, the HPLMN may deploy segments of AUSF/UDM/UDR instances (e.g., segment#<NUM> and segment#<NUM>) with each segment managing a different set of users within the HPLMN. That means that AUSF/UDMs of a given segment will not be able to authenticate/register a UE that belongs to a different segment, since the corresponding user profile will not be found within the segment. The AUSF/UDM/UDR in the different segments register in NRF using its segment parameters (e.g., Range of SUPI/GPSI, Group ID and/or Routing ID). Other NFs, such as AMF, can discover available AUSF/UDM/UDR instances per segment.

This may be done based on NRF registration/discovery mechanisms. In some embodiments, this may also be done using the HN Public Key ID also as segment parameter for AUSF/UDM/UDR registration and discovery if different HN Public/Private Keys for the privacy feature are also used in the different AUSF/UDM/UDR segments.

On the UE side, the USIM is configured to use the privacy feature (i.e. HN Public Key, Scheme) and a Routing ID which happens to be incorrect (e.g. Routing ID#<NUM> configured in USIM corresponds with Segment#<NUM> in the HPLMN while the user belongs to Segment#<NUM>). The operations providing the disclosed mechanism may be described as a series of operations or steps. Some embodiments of these operations may include additional or alternative operations in between, after, before, or as part of the enumerated operations.

At step one, the UE attempts to connect to the 5GC. For example, the UE of FIG. QQB may attempt to connect to the 5GC via an AMF. At step <NUM>, the AMF may select an AUSF in Segment#<NUM> of the PLMN to trigger primary authentication of the UE based on the Routing ID provided by the UE (i.e. Routing ID#<NUM>). At step <NUM>, the AUSF may receive the request and send a corresponding request to a UDM instance. For example, the AUSF may receive the Nausf_UEAuthentication_Authenticate request and may send a Nudm_UEAuthentication_Get request to a UDM instance within its segment, segment#<NUM>.

At step <NUM>, the UDM may receive receiving an authentication request including a SUCI and then attempt to resolve the corresponding SUPI in its role as SIDF. For that the UDM may require a HN Private Key corresponding to the HN Public Key ID used for the SUCI creation and included within the received SUCI. At this point, the UDM may either (a) not be able to decrypt the SUCI because it does not have the corresponding HN Private Key or (b) not be able to find the resulting SUPI in the UDR of its segment, segment#<NUM>.

At step <NUM>, in this situation and before rejecting the authentication requests with an "UNKNOWN USER/HNPubKeyID" type of error, the UDM checks if the SUPI/HN Public Key ID provided by the UE is managed in any other AUSF/UDM/UDR segment within the HPLMN. In some embodiments, this may be done by UDM, which may query the NRF for available AUSF/UDM/UDR instances for the given SUPI/HN Public Key ID. A successful response from NRF may be considered by UDM as a potential situation of a misconfigured Routing ID at the UE/USIM. It should be noted that an unsuccessful response from NRF may be managed in the UDM as an "UNKNOWN USER" or an "HN Public Key ID" type of error. Accordingly, the AUSF/UDM/UDR discovery requests based may be based on SUPI, in some embodiments, based on HN Public Key ID in other embodiments. Thus, the disclosure provides for AUSF/UDM/UDR to register in NRF using this segment parameter so AMF/UDM/UDR would be able to discover available AUSF/UDM/UDR instances managing a given HN Public Key ID.

At step <NUM>, instead of rejecting the authentication requests with an "UNKNOWN USER/HNPubKeyID" type of error, the UDM may reject the Nudm_UEAuthentication_Get request with a new error code which can indicate the error condition to the AMF. For example, the UDM may issue an "Incorrect Routing ID" error code. Additionally, the UDM may include additional information which can be utilized to facilitate the AMF in the selection of the AUSF in the right AUSF/UDM/UDR segment. Such additional information could be, e.g., the SUPI when the UDM is able to decrypt the SUCI, and/or the Routing ID, as received from the NRF, managed by the AUSF/UDM/UDR segment to which the UE belongs. The AUSF may also reject the Nausf_UEAuthentication_Authenticate request including the same error code (e.g., the "Incorrect Routing ID") and additional information accordingly.

At step <NUM>, the AMF receives the authentication reject with the new error type, message, or indicator that indicates that an incorrect routing identifier is being used in associated with the UE. This error may be referred to as an "Incorrect Routing ID" error type. The AMF may then select a new AUSF instance to resend the authentication request to (or to send a new authentication request to) based on the additional information included in the error response. In some embodiments, at a step 7b, the AMF may query the NRF using the received SUPI/Routing ID if information regarding available AUSF instances matching those parameters is not available at the AMF.

At step <NUM>, the AMF resends the Nausf_UEAuthentication_Authenticate request to the new AUSF selected this time in the right segment, segment#<NUM>, to which the UE belongs. The AUSF may send a corresponding Nudm_UEAuthentication_Get request to a UDM instance within its segment#<NUM>. These Nausf/Nudm_UEAuthentication requests may provide an additional indication to the UDM, so that the UDM can mark the UE subscription as pending to be updated with the right or correct Routing ID. This can be in the form of an explicit indicator, e.g., an "Update Routing ID indicator," and/or the wrong Routing ID value provided by the UE.

At step <NUM>, the rest of the UE Authentication and Registration procedure may be completed using the right AUSF/UDM/UDR segment as currently defined.

At step <NUM>, while the UE is connected within the 5GC, the HPLMN may update the Routing ID of the UE/USIM and, in some embodiments, also the HN Public Key if needed.

The same principles can be applied in situations in which the UE/USIM is not configured with a Routing ID when it should be. In this case, the AMF will select any available AUSF/UDM instance within the HPLMN and unless the selected AUSF/UDM instances happen to be in the right segment, the selected AUSF/UDM instance will detect the error situation (still an "incorrect or Missing Routing ID") and use the same mechanisms to route the UE to the right AUSF/UDM segment.

Some embodiments of the proposed solution provided in this disclosure make use of the NRF as a primary mechanism to allow UDM and other NFs in general to register and discover the services with the right granularity including segment parameters. However, the principles of this solution may be applied in other embodiments without using NRF by means of configuration of the available AUSF/UDM segment information at the AMF and UDM.

After a "wrong" UDM queries an NRF to know if SUPI/HN Public Key ID is managed by another UDM within the PLMN (as in step <NUM> above), the "wrong" UDM may include within the new error response to the AMF the information about AUSF/UDM instance(s) the AMF should use to redirect the authentication request so the AMF can skip further queries to NRF. Possible alternative mechanisms for the UDM to be able to check if the SUPI/HN Public Key ID provided by the UE is managed in any other AUSF/UDM segment within the HPLMN (again, as in step <NUM>) are as depicted in <FIG>.

<FIG> depicts alternative mechanisms for detecting a misconfigured UE. As shown in <FIG>, the UDM may query a Routing DB which can keep the mapping of SUPI/HN Pub Key ID with the Routing ID and/or the AUSF/UDM Group ID, as in 5b above. This Routing DB may be the same one that supports the NRF during the registration and/or discovery procedures using these parameters.

The access to the Routing DB may be via the UDR within the same segment which would proxy the request towards the Routing DB, as in 5c above. The UDM may send a broadcast notification to other UDMs within PLMN to get ACK (and Routing ID) from the ones managing the given SUPI/HN Public Key ID, as in 5d.

According to latest version of 3GPP TS <NUM> [<NUM>] (v15. <NUM>) a given AUSF/UDM instance may be registered in the NRF supporting <NUM> to N Routing Indicators (i.e., different UE/USIMs configured with different Routing IDs may be served by the same AUSF/UDM instance). In such an embodiment, when the "wrong" UDM checks with the NRF if the SUPI/HN Public Key ID provided by the UE is served by any other AUSF/UDM within the PLMN, as in 5d, the NRF may provide a positive response including corresponding AUSF/UDM instances but also multiple Routing IDs supported by these instances. Based on this response, the UDM may be aware that the UE shall be managed by a different AUSF/UDM segment, but it will not be able to tell the AMF the exact Routing ID the UE should have used. To manage such a situation, we propose that if the "wrong" UDM preformed the discovery request using the SUPI, the NRF include the Routing ID assigned to the UE in the response. The NRF may determine the Routing ID of a given UE either by a local configuration in NRF of the mapping of SUPI Ranges to Routing ID, the NRF supported by a Routing DB including the mapping of SUPI Ranges and/or individual SUPIs with corresponding Routing IDs, the AUSF/UDM registering in the NRF explicitly the relation of supported SUPI Ranges with corresponding Routing IDs. If provided by the AUSF/UDM during registration, the NRF will be utilized to provide such information also during the AUSF/UDM discovery procedure.

Further, a procedure for triggering Routing Identifier update may open an avenue for a potential attack as follows. The attacker changes the Routing Identifier from the SUCI over-the-air to something other than the one sent by the UE. The network may notice a different Routing Identifier and trigger the Routing Identifier update procedure. This may result in an unnecessary signaling load in the network, which can get worse if the attacker changes the Routing Identifier from a large number of SUCIs over-the-air. Some, or in some instance all, of the UEs whose SUCIs were changed may consequently be updated unnecessarily. This may produce unwanted signaling over-the-air, unwanted processing in the UE, and delay in service access. And after the update has happened, the attacker may repeat the attack again. This may be possible because the root-cause of the above protection is the network not being able to detect that the received Routing Identifier is the one sent by the UE.

One solution for the above problem is to have the network keep track of expected Routing Identifier from UEs and detect the above attack. For example, if a UE has a SUPI_1 and a Routing_Identifier_3, and if the network has not updated that UE, then the network is able to detect the above attack if the network receives SUPI_1 (after decryption) and a Routing_Identifier_4. The network may include a mechanism to minimize the damage of such a potential attack by, e.g., having limits on how many times the Routing Identifier update procedure is triggered within a static time span or dynamically determined time span, for all UEs, or for particular UE, or for particular group of UEs, for particular network function (CN or RAN) like AMF.

Further, another solution for the above potential attack is that the UE integrity protects the Routing Identifier and the network verifies the integrity protection of the receiving Routing Identifier. For example, the UE when using Elliptic Curve Integrated Encryption Scheme (ECIES), could include at least the Routing Identifier, preferably in SharedInfo2 or in SharedInfo1 parameters. Then the network may cryptographically verify that the received Routing Identifier is indeed sent by the UE, i.e., with the help of a MAC-tag or a MAC key.

Although the subject matter described herein may be implemented in any appropriate type of system using any suitable components, the embodiments disclosed herein are described in relation to a wireless network, such as the example wireless network illustrated in <FIG>. For simplicity, the wireless network of <FIG> only depicts network <NUM>, network nodes <NUM> and 760b, and WDs <NUM>, 710b, and 710c. In many respects, the wireless network of <FIG> presents an alternative diagram of the network architecture shown in <NUM>, with <FIG> providing additional detail with respect to the network <NUM>. In practice, a wireless network may further include any additional elements suitable to support communication between wireless devices or between a wireless device and another communication device, such as a landline telephone, a service provider, or any other network node or end device. Of the illustrated components, network node <NUM> and wireless device (WD) <NUM> are depicted with additional detail. The wireless network may provide communication and other types of services to one or more wireless devices to facilitate the wireless devices' access to and/or use of the services provided by, or via, the wireless network.

Interface <NUM> is used in the wired or wireless communication of signaling and/or data between network node <NUM>, network <NUM>, and/or WDs <NUM>.

Antenna <NUM> may be coupled to radio interface <NUM> and may be any type of antenna capable of transmitting and receiving data and/or signals wirelessly.

As used herein, wireless device (WD) refers to a device capable, configured, arranged and/or operable to communicate wirelessly with network nodes and/or other wireless devices. Unless otherwise noted, the term WD may be used interchangeably herein with user equipment (UE). Communicating wirelessly may involve transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information through air. In some embodiments, a WD may be configured to transmit and/or receive information without direct human interaction. For instance, a WD may be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the network. Examples of a WD include, but are not limited to, a smart phone, a mobile phone, a cell phone, a voice over IP (VoIP) phone, a wireless local loop phone, a desktop computer, a personal digital assistant (PDA), a wireless cameras, a gaming console or device, a music storage device, a playback appliance, a wearable terminal device, a wireless endpoint, a mobile station, a tablet, a laptop, a laptop-embedded equipment (LEE), a laptop-mounted equipment (LME), a smart device, a wireless customer-premise equipment (CPE). a vehicle-mounted wireless terminal device, etc.. A WD may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-everything (V2X) and may in this case be referred to as a D2D communication device. As yet another specific example, in an Internet of Things (IoT) scenario, a WD may represent a machine or other device that performs monitoring and/or measurements, and transmits the results of such monitoring and/or measurements to another WD and/or a network node. The WD may in this case be a machine-to-machine (M2M) device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the WD may be a UE implementing the 3GPP narrow band internet of things (NB-IoT) standard. Particular examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or home or personal appliances (e.g. refrigerators, televisions, etc.) personal wearables (e.g., watches, fitness trackers, etc.). In other scenarios, a WD may represent a vehicle or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation. A WD as described above may represent the endpoint of a wireless connection, in which case the device may be referred to as a wireless terminal. Furthermore, a WD as described above may be mobile, in which case it may also be referred to as a mobile device or a mobile terminal.

Network connection interface <NUM> may be configured to provide a communication interface to network 843a. Network 843a may encompass wired and/or wireless networks such as a local-area network (LAN), a wide-area network (WAN), a computer network, a wireless network, a telecommunications network, another like network or any combination thereof. For example, network 843a may comprise a Wi-Fi network.

In <FIG>, processing circuitry <NUM> may be configured to communicate with network 843b using communication subsystem <NUM>. Network 843a and network 843b may be the same network or networks or different network or networks. Communication subsystem <NUM> may be configured to include one or more transceivers used to communicate with network 843b.

Network 843b may encompass wired and/or wireless networks such as a local-area network (LAN), a wide-area network (WAN), a computer network, a wireless network, a telecommunications network, another like network or any combination thereof. For example, network 843b may be a cellular network, a Wi-Fi network, and/or a near-field network.

Access network <NUM> comprises a plurality of base stations 1012a, 1012b, 1012c, such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 1013a, 1013b, 1013c. Each base station 1012a, 1012b, 1012c is connectable to core network <NUM> over a wired or wireless connection <NUM>. A first UE <NUM> located in coverage area 1013c is configured to wirelessly connect to, or be paged by, the corresponding base station 1012c. A second UE <NUM> in coverage area 1013a is wirelessly connectable to the corresponding base station 1012a.

Connections <NUM> and <NUM> between telecommunication network <NUM> and host computer <NUM> may extend directly from core network <NUM> to host computer <NUM> or may go via an optional intermediate network <NUM><NUM>.

It is noted that host computer <NUM>, base station <NUM> and UE <NUM> illustrated in <FIG> may be similar or identical to host computer <NUM>, one of base stations 1012a, 1012b, 1012c and one of UEs <NUM>, <NUM> of <FIG>, respectively.

Wireless connection <NUM> between UE <NUM> and base station <NUM> is in accordance with the teachings of the embodiments described throughout this disclosure. One or more of the various embodiments improve the performance of OTT services provided to UE <NUM> using OTT connection <NUM>, in which wireless connection <NUM> forms the last segment. More precisely, the teachings of these embodiments may improve the operation of devices attempting to communicate via a wireless network and which have been misconfigured with an incorrect routing ID and thereby provide benefits such as permitting the correction of such misconfigurations without requiring interventions at a network operators premises.

Claim 1:
A method for redirecting a user equipment with a routing misconfiguration, the method comprising:
detecting a potential misconfiguration associated with the user equipment or a subscriber identity module, SIM, associated with the user equipment in response to an access request transmitted by the user equipment; and
generating an error code indicating a potential misconfiguration associated with the user equipment of the SIM associated with the user equipment, wherein the error code further indicates that the potential misconfiguration is an incorrect routing identifier and includes additional user information;
wherein an authentication module directs the access request to a first functional module based on the incorrect routing identifier included in the access request, and the authentication module redirects the access request to a second functional module based on the generated error code or information included with the generated error code, wherein the second functional module authenticates or registers the user equipment or SIM;
and wherein the first functional module comprises at least one of a first authentication server function, AUSF, module, a first unified data management, UDM, module, or a first unified data repository, UDR, module, and the second functional module comprises at least one of a second AUSF module, a second UDM module, or a second UDR module.