Tracking area identifier (tai) change during authentication request processing

Abstract

Methods, systems, and devices for wireless communication are described. A user equipment (UE) can receive a first authentication request in response to a first trigger request from a mobility management node of a first tracking area (TA) in which the UE is positioned. In some embodiments, the UE can prepare and store an authentication response in accordance with the first authentication request. In response to determining that the UE has moved from the first TA to a second TA, the UE can abort transmission of the authentication response, and can transmit the stored authentication response in accordance with the first authentication request to a mobility management node of the second TA in response to receipt of a second authentication request and further in response to determining that a given parameter of each of the first authentication request and the second authentication request is the same.

Description

Technical Field

[0001] This patent application relates generally to wireless communication systems, and more specifically to the proper processing of authentication requests at a UE in response to a change in the Tracking Area Identifier (TAI) at the User Equipment (UE). Background Technology

[0002] Wireless mobile communication technologies use various standards and protocols to transmit data between base stations and wireless mobile devices. Wireless communication system standards and protocols may include 3GPP Long Term Evolution (LTE) (e.g., 4G) or New Radio (NR) (e.g., 5G); the Institute of Electrical and Electronics Engineers (IEEE) 802.16 standard, commonly referred to by the industry organization as WiMAX; and the IEEE 802.11 standard for Wireless Local Area Networks (WLANs), commonly referred to by the industry organization as Wi-Fi. In the 3GPP Radio Access Network (RAN) of an LTE system, a base station may include RAN nodes such as an Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Node B (also commonly referred to as Evolved Node B, Enhanced Node B, eNodeB, or eNB) and / or a Radio Network Controller (RNC) in the E-UTRAN, which communicates with wireless communication equipment called User Equipment (UE). In the fifth generation (5G) wireless RAN, RAN nodes may include 5G nodes and NR nodes (also known as next-generation node B or g NodeB (gNB)).

[0003] The RAN uses Radio Access Technology (RAT) to communicate between RAN nodes and UEs. The RAN can include Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE) RAN (GERAN), Universal Terrestrial Radio Access Network (UTRAN), and / or E-UTRAN, which provides access to communication services through the core network. Each RAN operates according to a specific 3GPP RAT. For example, GERAN implements the GSM and / or EDGE RAT, UTRAN implements the Universal System for Mobile Communications (UMTS) RAT or other 3GPP RATs, E-UTRAN implements the LTE RAT, and NG-RAN implements the 5G RAT. In some deployments, E-UTRAN may also implement the 5G RAT.

[0004] 5G NR frequency bands can be divided into two distinct frequency ranges. Frequency range 1 (FR1) includes bands below 6 GHz, some of which may be used by previous standards but could potentially be extended to cover new spectrum offerings from 410 MHz to 7125 MHz. Frequency range 2 (FR2) includes bands from 24.25 GHz to 52.6 GHz. The millimeter-wave (mm-Wave) bands in FR2 have a shorter range but higher available bandwidth than those in FR1. Those skilled in the art will recognize that these frequency ranges, presented by way of example, may vary over time or in different regions. Attached Figure Description

[0005] To facilitate identification of any particular element or action being discussed, one or more of the most significant digits in the reference numerals refer to the drawing number in which the element was first introduced.

[0006] Figure 1 A flowchart corresponding to race conditions is shown according to some implementation schemes.

[0007] Figure 2 A flowchart of message transmission corresponding to a solution for a potential race condition is shown.

[0008] Figure 3 An example service-based architecture based on certain implementation schemes is shown.

[0009] Figure 4 A UE according to one implementation is shown.

[0010] Figure 5 A network node according to one implementation scheme is shown. Detailed Implementation

[0011] In some network implementations using a UE being monitored in a Tracking Area (TA), the Tracking Area Identifier (TAI) at the UE may change during the period when the UE is processing an authentication request from the network's Mobility Management Node (MTN) (e.g., in response to the UE moving from one TA to another). Examples of MTNs may include, for example: the Mobility Management Entity (MME) of a 4G LTE network, the Access and Mobility Management Function (AMF) of a 5G network, the combined UTRAN (including Radio Network Controller (RNC) + NodeB) for 3G networks and the Serving GPRS Support Node (SGSN) for the Packet Switched (PS) domain and the Mobile Switching Center (MSC) for the Circuit Switched (CS) domain, and the combined GERAN (including Transceiver Station (BTS) and Base Station Subsystem (BSC)) in a 2G network and the SGSN for the PS domain and the MSC for the CS domain.

[0012] The authentication request (or another) may have been triggered by, for example, a Tracking Area Update (TAU) request (e.g., in 4G LTE), a Routing Area Update (RAU) request (e.g., in 2G, 3G), and / or a Registration request (e.g., in 5G) (and other examples). Such a message (which triggers the authentication request in the manner described) may be referred to herein as a “trigger request”.

[0013] It's possible that in some system / network implementations, the UE can be configured to send an authentication response whenever it receives an authentication request message from the network's mobility management node. However, there are scenarios (e.g., scenarios involving TAI changes at the UE) where this requirement might cause the UE and network to lose synchronization, resulting in the UE switching to limited service mode. In some systems, the only way to switch the UE out of limited service mode might be to reboot the UE (or alternatively, wait for a certain period of time). This can be an undesirable outcome, as it could affect the mobility of UEs for one or more (or at most all) users in these systems, often resulting in a perceived "poor" user experience.

[0014] The following describes a scenario that causes this situation in a 4G LTE instance (which uses a TAU request as the mobility management node of the MME):

[0015] ·UE can pre-occupy the first TA, i.e., TA1

[0016] The UE may send a first TAU ​​request (e.g., a combined TAU request) while in connection mode with the MME of TA1.

[0017] In response to the first TAU ​​request, a TAU acceptance message with reason #17 is received at the UE, which may indicate the failure of the first TAU ​​request.

[0018] The T3411 timer is started in response to the failure of the first TAU ​​request.

[0019] The OT3411 timer expired, and in response, the UE sent a second TAU request while in connected mode with the MME of TA1.

[0020] Finally, the UE receives the first authentication request from the MME of TA1 at its mobile equipment (ME).

[0021] The οME forwards the authentication request to the UE's Universal User Identity Module (USIM).

[0022] Then, the UE performs a cell change and enters connected mode on the second TA (i.e., TA2).

[0023] The UE suspends the ongoing (TA1) TAU request and sends a third (new) TAU request while in connection mode with the MME of TA2.

[0024] The ME of the UE receives an authentication response from the USIM corresponding to the first authentication request received from the MME of TA1, and sends the authentication response message to the network.

[0025] In some cases, a second authentication request (possibly with different authentication vector parameters than the first authentication request, such as random number (RAND) and / or authentication token (AUTN) parameters) may be generated by the TA2's MME before receiving an authentication response. In some implementations, the authentication request may also be sent to the UE. In these cases, the TA2's MME may send an authentication rejection message in response to receiving an authentication response message corresponding to the first authentication request at the network. This may be because the TA2's MME assumes that the authentication response message from the UE (which corresponds to the first authentication request) should be an authentication response to an authentication request corresponding to the TA2 (as prepared by the TA2's MME).

[0026] In other cases, an authentication response can be received before the TA2's MME generates any authentication request for the UE. In these cases, receiving the authentication response can also cause the TA2's MME to send an authentication rejection message, since the TA2's MME does not expect an authentication response from the UE in this situation.

[0027] In either case, the UE may retain pre-emptive limited service (due to the authentication rejection message) until a restart is performed. It should be noted that although the authentication rejection message can be correctly received at the UE even when changing from TA1 to TA2, this change may not invalidate previously established valid encryption and / or integrity protection procedures between the UE and the network. Any of these situations may be referred to herein as a "race condition".

[0028] Scenarios involving these issues may include:

[0029] Scenario A

[0030] A UE in connected mode initiates a TAU request due to the following changes:

[0031] • When the UE changes its network capability information or the MS network capability information, or both;

[0032] • When the UE changes its specific Discontinuous Reception (DRX) parameters;

[0033] • When the UE's usage settings or voice domain preferences for E-UTRAN are changed in the UE

[0034] • When the UE changes its specific DRX parameters;

[0035] • When the UE changes to target GERAN or When both have radio capabilities;

[0036] • When the UE's usage settings or voice domain preferences for E-UTRAN are changed in the UE;

[0037] • When a UE needs to request the use of extended DRX (eDRX) or needs to stop using eDRX;

[0038] • When changes to the eDRX usage conditions at the UE require different extended DRX parameters;

[0039] When T3411 expires

[0040] Other potential triggers were envisioned.

[0041] The UE can be in connected mode, and one of the aforementioned triggers causes the UE to initiate a TAU procedure. During this TAU procedure, a connected mode TAI change occurs. The new TAI detected by the UE in connected mode may not be in the registered TAI list. The UE can abort the ongoing TAU request procedure and then (if it is in connected mode with integrity and encryption activated) send a new TAU request protected by integrity and encryption and wait for an authentication response from the USIM. Simultaneously, the USIM sends the authentication response message corresponding to the original TAU procedure to the UE. Once the authentication response (corresponding to the original TAU procedure) is received from the USIM, the UE sends the authentication response to the MME. The MME determines that the authentication response message is incorrect and / or unexpected, and sends an authentication rejection message protected by integrity and encryption that has been successfully decoded and processed by the UE. Therefore, the UE can preempt limited service until it is restarted.

[0042] Scene B

[0043] The UE triggers a normal TAU procedure due to the trigger described in Scenario A above (wherein the normal TAU procedure differs from the combined TAU procedure because the combined TAU procedure implies attempting both Circuit Switched (CS) and Evolved Packet System (EPS) domain registration, while in a normal TAU only EPS registration is attempted). In this scenario, the normal TAU processing similarly applies to all the above scenarios as to which the combined TAU applies.

[0044] Scene C

[0045] Scenario C is a 5G scenario in connected mode. In 5G NR, a UE triggers a registration request with the type "Mobility and Periodic Registration" in connected mode. In this case, the trigger for the registration request can be any of the following:

[0046] T3511 expires;

[0047] • When the UE changes its 5GS Mobility Management (5GMM) capabilities or S1 UE network capabilities (or both);

[0048] • When the UE's usage settings change;

[0049] • When a UE needs to change the slice it is currently registered to;

[0050] • When the UE changes its specific DRX parameters;

[0051] • When a UE needs to register for Short Message Service (SMS) on a Non-Access Stratum (NAS), indicate a change in the requirement to use SMS on the NAS, or revoke SMS registration on the NAS;

[0052] • When the UE needs to indicate the PDU session status to the network after performing a local release of a Protocol Data Unit (PDU) session as specified in Sections 6.4.1.5 and 6.4.3.5 of 3GPP 24.501;

[0053] • When the UE needs to request new Local Data Network (LADN) information;

[0054] • When the UE needs to request to use eDRX when the eDRX usage conditions at the UE change and different eDRX parameters are required, or when it is necessary to stop using eDRX;

[0055] Other potential triggers were envisioned.

[0056] The registration request process may be in progress, and the UE moves into connected mode to send a registration request to the network. Encryption and integrity protection are not yet activated, and the network sends an authentication request to the UE. The UE has reserved a TAI that is not part of the registration area (e.g., not registered to the TAI list in LTE or the registration area in 5G). When there is a pending authentication request response from the USIM, the UE may abort the ongoing registration request process. The UE triggers a new registration request toward the AMF on the same RRC connection. Subsequently, upon receiving an authentication response corresponding to the original registration request from the USIM, the UE sends that authentication response to the network. The network determines that the authentication response is incorrect and / or unexpected, and sends an authentication rejection message (which may be integrity protected, causing the UE to believe the authentication rejection message is valid), thereby placing the UE in limited service. If the authentication rejection message is sent without integrity protection, the UE may disable the reserved TAI for 30-60 minutes, and there will be no service during that duration.

[0057] In another aspect: When the registration request process is in progress and the UE is in connected mode, and encryption and integrity are activated, the UE pre-allocates a TAI that is not part of the registration area (e.g., not registered to the TAI list in LTE or the registration area in 5G). Then, when there is a pending authentication request response from the USIM, the UE aborts the ongoing registration request process. The UE triggers a new registration request message toward the AMF. Subsequently, an authentication response (corresponding to the original registration request process) is received from the USIM, and the UE sends this authentication response to the network. The AMF determines that the authentication response message is incorrect and / or unexpected, and sends an authentication rejection message (protected by integrity and encryption) that has been successfully decoded and processed by the UE. In response, the UE may pre-allocate limited service until it is restarted.

[0058] Scene D

[0059] Scenario D is a 5G scenario. The UE is in a connected mode with integrity and encryption activated, and the network triggers an authentication request procedure (the network can trigger the authentication request procedure at any time while the UE is in connected mode). Then, while waiting for an authentication response message from the USIM, the UE detects a change in its pre-occupied TAI (which is not part of the registration area). The UE immediately triggers a registration request with the type "Mobility and Periodic Registration". The UE then receives an authentication response from the USIM corresponding to the original authentication request procedure message, and just as the AMF on the new TAI triggers a new authentication request procedure on the new TAI, it sends this authentication response to that AMF. Once the AMF receives this authentication response message, it determines that the authentication response message is incorrect and / or unexpected, and sends an integrity and encryption-protected authentication rejection message that has been successfully decoded and processed by the UE. In response, the UE can pre-occupy limited service until it is restarted.

[0060] Scene E

[0061] Scenario E is a 4G scenario. The UE can be in a connected mode with integrity and encryption activated, and the network triggers an authentication request procedure (the network can trigger the authentication request procedure at any time while the UE is in connected mode). Then, while waiting for an authentication response message from the USIM, the UE detects a change in the pre-allocated TAI (which is not part of the registered TAI list). The UE immediately triggers a TAU request message. Then, an authentication response message corresponding to the original authentication request procedure is received from the USIM, and this authentication response message is sent to the MME on the new TAI, just as the MME on the new TAI triggers a new authentication request message on the new TAI. Once the authentication response message is received at the MME, the MME determines that the authentication response message is incorrect and / or unexpected, and sends an integrity and encryption-protected authentication rejection message that has been successfully decoded and processed by the UE. In response, the UE can pre-allocate limited service until it is restarted.

[0062] Scene F

[0063] Similar issues to those discussed above may also occur in 2G and 3G. In these cases, the UE will initiate a route area request procedure and / or a location update request procedure, thereby causing similar race conditions.

[0064] Imagine that even if the mobility management nodes of TA1 and TA2 are the same mobility management node, the above scenario may still occur.

[0065] In the above system, there may be multiple specific implementations on both the UE side and the network side to handle the above scenarios that may lead to erroneous processing in the UE:

[0066] 1. The network may retransmit the same authentication request from the mobility management node of TA1 as the authentication request sent from the mobility management node of TA2.

[0067] 2. The network may send a new authentication request from the mobility management node of TA1.

[0068] 3. The UE may incorrectly send an authentication response based on TA1's authentication request for the mobility management node from TA1, instead of based on TA2's authentication request for the mobility management node from TA2.

[0069] Figure 1 A flowchart 100 corresponding to a race condition is shown according to some embodiments. The system described herein may include UE 102, MME-TAC1 104 (which may be an MME using a first Tracking Area Code (TAC), i.e., a first TA (i.e., TA1) of TAC1), and MME-TAC2 106 (which may be an MME using a second TA (i.e., TA2) of a second TAC (i.e., TAC2). UE 102 may include USIM 108 and ME 110.

[0070] In box 112, UE 102's ME 110 is in connected mode with MME-TAC1 104, and both UE 102 and MME-TAC1 104 have a valid EPS security context identified by the first key set identifier (KSI), namely KSI-1. UE 102 may initiate a first combined TAU request. This may be due to, for example, T3411 expiring with reason #17, if a previous combined TAU request had been accepted.

[0071] Then, ME 110 of UE 102 can send the first combined TAU request from combined TAU request message 114 to MME-TAC1 104. In response, MME-TAC1 104 can send an authentication request message 116 corresponding to combined TAU request message 114. Authentication request message 116 can be based on a second KSI, i.e., KSI-2. Authentication request message 116 can be received at ME 110 of UE 102.

[0072] Then, ME 110 can forward authentication request message 116 as authentication request message 118 to USIM 108.

[0073] In box 120, ME 110 of UE 102 changes the connection mode cell to a new TA corresponding to TAC2 and MME-TAC2 106.

[0074] In box 122, the UE aborts the ongoing combined TAU request and re-initiates a new combined TAU request using MME-TAC2 106. This can be done using the same Radio Resource Control (RRC) connection as the previously used connection.

[0075] Then, UE 102’s ME 110 can send the new combined TAU request in combined TAU request message 124 to MME-TAC2 106.

[0076] Then, USIM 108 can send authentication response message 126 to ME 110. This authentication response message 126 may correspond to authentication request message 118 forwarded by ME 110 from MME-TAC1 104 to USIM 108. It is possible that UE 102 does not abort the transmission of authentication response message 126 in response to the connection mode cell change to TAC2 in box 120.

[0077] After sending authentication response message 126, the UE can return to the TAC2 coverage area and can pre-occupy the TA corresponding to TAC2 if the periodic timer has not expired.

[0078] Then, ME 110 can forward the authentication response message 126 as authentication response message 128 to MME-TAC2106.

[0079] During or near this time period, MME-TAC2 106 can also prepare authentication request message 130. Authentication request message 130 can be based on the third KSI, i.e., KSI-3.

[0080] Several problematic scenarios may arise here. First, the authentication response message 128 arrives at the MME-TAC2 106 before the MME-TAC2 106 prepares the authentication request message 130. In this case, receiving the authentication response message 128 could cause the MME-TAC2 106 to send an authentication rejection message 134, because in this situation, the MME-TAC2 106 does not expect the authentication response message 128 from the UE.

[0081] The second problematic scenario is that the MME-TAC2 106 may have generated (and may, but not necessarily, sent) an authentication request message 130 before receiving the authentication response message 128. In these cases, it is possible that the authentication request message 130 is generated using different RAND and / or AUTN parameters than the authentication request message 116. In this case, the MME-TAC2 106 may send an authentication rejection message 134 in response to receiving the authentication response message 128 because the MME-TAC2 106 assumes that the authentication response message 128 should respond to the authentication request message 130 (but this is clearly not due to a mismatch in the RAND and / or AUTN parameters between the authentication response message 128 and the authentication request message 130).

[0082] In either case, MME-TAC2 106 prepares an authentication rejection message in box 132. This message can be correctly configured to be accepted at ME 110 in 102 because changing from TA1 to TA2 may not invalidate previously established valid encryption and / or integrity protection procedures between the UE and the network.

[0083] Then, MME-TAC2 106 can send authentication rejection message 134 to ME 110 of UE 102. In response, in box 136, UE 102 can mark USIM 108 as invalid for circuit-switched (CS) and packet-switched (PS) services because it received authentication rejection message 134 in the desired manner, protected by integrity and encryption. UE 102 can also pre-book limited service on the same Public Land Mobile Network (PLMN) after RRC connection release. UE 102 can remain in this reduced availability state until UE 102 is restarted.

[0084] The race condition identified above can be resolved as follows: During the authentication process (e.g., a process discussed previously), if a TAI change occurs that would result in the transmission of a new trigger request corresponding to the new TA, the UE may not send an authentication response message corresponding to the authentication request of the original authentication process to the mobility management node of the new TA (e.g., it may abort the transmission of such a message). Instead, the UE can compute the authentication response message and store it in memory. Then, after aborting the previous authentication process, the UE can re-initiate a new authentication process using the mobility management node of TA2 and wait for a new authentication request message from the network (e.g., from the mobility management node of TA2 according to TA2).

[0085] During this phase, if the UE receives the same authentication request message again (e.g., an authentication request message with the same RAND parameters as the first authentication request message corresponding to the original authentication process), the UE may not send a new authentication request message to the USIM for processing, but may instead reply to it with an authentication response message stored in its memory.

[0086] Figure 2 A flowchart 200 is shown illustrating message passing for a solution corresponding to a potential race condition according to some implementation schemes. Elements 102-228 may be similar to... Figure 1 Similar numbered elements were found in the [the database].

[0087] One difference could be that UE 202 is configured to abort the transmission of authentication response message 228 in response to a connection mode cell change to TAC2, which corresponds to MME-TAC2 206 in block 220. Therefore, ME 210 is configured to abort the transmission of authentication response message 228 (e.g., it does not send authentication response message 228 to MME-TAC2 206), which corresponds to authentication response message 226 received from USIM 208. Furthermore, at block 240, ME 210 can store authentication response message 226 in volatile memory.

[0088] Then, ME 210 can receive authentication request message 242 corresponding to the combined TAU request message 224. ME 210 can determine whether authentication request message 242 is the same as authentication request message 216. This determination can be made by checking the RAND parameters of authentication request message 216 and authentication request message 242 to see if these parameters are the same.

[0089] If the RAND parameters are different, ME 110 can forward authentication request message 242 to USIM 208. Then, USIM 208 can generate the corresponding authentication response message 246 and send it to ME 210. ME 210 can then forward authentication response message 246 as authentication response message 248 to MME-TAC2 206.

[0090] Alternatively, if the RAND values ​​are the same, ME 210 may instead bypass forwarding authentication request message 244 to USIM 208 and retrieve authentication response message 226 from volatile memory (which is stored in box 240, as described above). In this case, it is possible that authentication response message 226 stored in volatile memory is a good response to authentication request message 242 from MME-TAC2 206. Therefore, ME 210 may forward authentication response message 226 as authentication response message 248.

[0091] Exemplary System Architecture

[0092] In some implementations, the 5G system architecture supports data connectivity and services, enabling deployment using technologies such as network function virtualization and software-defined networking. The 5G system architecture can leverage service-based interactions between control plane network functions. Separating user plane functions from control plane functions allows for independent scalability, evolution, and flexible deployment (e.g., centralized or distributed (remote) locations). Modular function design allows for function reuse and enables flexible and efficient network slicing. Network functions and their network function services can interact directly or indirectly with another NF and its network function services via a service communication broker. Another intermediate function helps route control plane messages. This architecture minimizes dependencies between the AN and CN. The architecture may include an aggregated core network with a common AN-CN interface integrating different access types (e.g., 3GPP access and non-3GPP access). The architecture also supports a unified authentication framework, stateless NFs that decouple compute and storage resources, capability exposure, concurrent access to local and centralized services (to support low-latency services and access to local data networks, with user plane functions deployed near the AN), and / or roaming in the visited PLMN using both home-routed traffic and local breakout traffic.

[0093] A 5G architecture can be defined as service-based, and interactions between network functions can include service-based representations, where a network function within the control plane (e.g., an AMF) enables other authorized network functions to access its services. Service-based representations can also include point-to-point reference points. Reference point representations can also be used to illustrate interactions between NF services within network functions described by point-to-point reference points (e.g., N11) between any two network functions (e.g., AMF and SMF).

[0094] Figure 3 A service-based architecture 300 in 5GS according to one implementation is shown. As described in 3GPP TS 23.501, the service-based architecture 300 includes NFs such as NSSF 302, NEF 304, NRF 306, PCF 308, UDM 310, AUSF 312, AMF 314, and SMF 316 for communicating with UE 320, (R)AN 322, UPF 324, and DN 326. NFs and NF services can communicate directly (referred to as direct communication) or indirectly via SCP 318 (referred to as indirect communication). Figure 3It also shows the corresponding service-based interfaces including Nutm, Naf, Nudm, Npcf, Nsmf, Nnrf, Namf, Nnef, Nnssf, and Nausf, as well as reference points N1, N2, N3, N4, and N6. The following describes the... Figure 3 Some exemplary functions provided by NF are shown in the figure.

[0095] NSSF 302 supports functions such as: selecting the set of network slice instances serving the UE; determining the allowed NSSAIs and, if necessary, the mapping to subscribed S-NSSAIs; determining the configured NSSAIs and, if necessary, the mapping to subscribed S-NSSAIs; and / or determining the set of AMFs to be used to serve the UE, or, based on the configuration, possibly by querying the NRF to determine a list of candidate AMFs.

[0096] NEF 304 supports the exposure of capabilities and events. NF capabilities and events can be securely exposed by NEF 304 (e.g., for third parties, application functions, and / or edge computing). NEF 304 can use a standardized interface (Nudr) to UDR to store / retrieve information as structured data. NEF 304 can also securely provide information from external applications to the 3GPP network and can provide application functions to securely provide information to the 3GPP network (e.g., anticipated UE behavior, 5GLAN group information, and service-specific information), where NEF 304 can authenticate and authorize and help restrict application functions. NEF 304 can provide internal-external information translation by translating information exchanged with AF and information exchanged with internal network functions. For example, NEF 304 translates between AF service identifiers and internal 5G core information (such as DNN and S-NSSAI). NEF 304 can handle the masking of network and user-sensitive information to external AFs according to network policies. The NEF 304 can receive information from other network functions (based on their exposure capabilities) and store the received information as structured data using a standardized interface to the UDR. The stored information can then be accessed by the NEF 304 and re-exposed to other network and application functions for purposes such as analysis. For external exposure of services related to a specific UE, the NEF 304 can reside in the HPLMN. Depending on the operator agreement, the NEF 304 in the HPLMN can have an interface with the NF in the VPLMN. When the UE is able to switch between EPC and 5GC, SCEF+NEF can be used for service exposure.

[0097] NRF 306 supports service discovery by receiving NF discovery requests from NF instances or SCPs and providing information about discovered NF instances to the NF instances or SCPs. NRF 306 also supports P-CSCF discovery (a special case of SMF discovery of AFs), maintaining NF profiles of available NF instances and their supported services, and / or notifying subscribed NF service consumers or SCPs of newly registered / updated / deregistered NF instances along with their NF services. In the context of network slicing, multiple NRFs can be deployed at different levels depending on the network implementation, such as PLMN level (NRFs configured with information about the entire PLMN), shared slice level (NRFs configured with information about the network slice set), and / or slice-specific level (NRFs configured with information about the S-NSSAI). In the context of roaming, multiple NRFs can be deployed in different networks, where the NRF in the visited PLMN (referred to as vNRF) is configured with information about the visited PLMN, and the NRF in the home PLMN (referred to as hNRF) is configured with information about the home PLMN, referenced by the vNRF via the N27 interface.

[0098] PCF 308 supports a unified policy framework for managing network behavior. PCF 308 provides policy rules for control plane functions to enforce them. PCF 308 accesses subscription information related to policy decisions in the Unified Data Repository (UDR). PCF 308 can access the UDR located in the same PLMN as PCF.

[0099] The UDM 310 supports the generation of 3GPP AKA authentication credentials, user identification processing (e.g., storage and management of SUPI for each subscriber in a 5G system), de-hiding of privacy-preserving subscription identifiers (SUCI), access authorization based on subscription data (e.g., roaming restrictions), UE service NF registration management (e.g., storing AMF for UE storage services, storing SMF for UE PDU sessions), service / session continuity (e.g., maintaining SMF / DNN allocation for ongoing sessions), MT-SMS delivery, lawful interception functionality (especially in outbound roaming scenarios where the UDM is the only contact point of the LI), subscription management, SMS management, 5GLAN group management processing, and / or external parameter configuration (expected UE behavior parameters or network configuration parameters). To provide these functions, the UDM 310 uses subscription data (including authentication data) that can be stored in the UDR. In this case, the UDM implements application logic and may not require internal user data storage, and several different UDMs can provide services to the same user in different transactions. The UDM 310 may reside in the HPLMN of its subscriber and can access information from the UDR located in the same PLMN.

[0100] AF 328 interacts with the core network to provide services such as: application-driven traffic routing; access to NEF 304; interaction with policy frameworks used for policy control; and / or interaction between IMS and 5GC. Based on operator deployment, application functions trusted by the operator may be allowed to interact directly with relevant network functions. Application functions that the operator does not allow direct access to network functions may interact with relevant network functions via an external exposure framework through NEF 304.

[0101] AUSF 312 supports authentication for 3GPP access and untrusted non-3GPP access. AUSF 312 also provides support for network slicing-specific authentication and authorization.

[0102] AMF 314 supports the termination of the RAN CP interface (N2), the termination of the NAS (N1) for NAS encryption and integrity protection, registration management, connection management, reachability management, mobility management, lawful interception (for AMF events and interfaces to the LI system), transmission of SM messages between the UE and SMF, transparent proxy for routing SM messages, access authentication, access authorization, transmission of SMS messages between the UE and SMSF, SEAF, location service management for regulated services, transmission of location service messages between the UE and LMF and between the RAN and LMF, EPS bearer ID allocation for interoperability with EPS, UE mobility event notification, control plane CIoT 5GS optimization, user plane CIoT 5GS optimization, configuration of external parameters (expected UE behavior parameters or network configuration parameters) and / or network slice-specific authentication and authorization. Some or all of the AMF functions can be supported in a single instance of AMF 314. Regardless of the number of network functions, in some implementations, only one NAS interface instance per access network between the UE and the CN terminates with one of the network functions that implements at least NAS security and mobility management. AMF 314 may also include policy-related functions.

[0103] In addition to the functions described above, AMF 314 may also include the following functions supporting non-3GPP access networks: support for the N2 interface with N3IWF / TNGF, on which some information (e.g., 3GPP cell identifier) ​​and procedures (e.g., handover-related) defined on 3GPP access may not be applicable, and non-3GPP access-specific information not applicable to 3GPP access may be applied; support for NAS signaling by UE via N3IWF / TNGF, where some procedures supported by NAS signaling on 3GPP access may not be applicable to untrusted non-3GPP (e.g., paging) access; support for authentication of UEs connected via N3IWF / TNGF; management of mobility, authentication, and separate security context states for UEs connected via non-3GPP access or simultaneously via 3GPP access or non-3GPP access; support for effective coordination of RM management contexts on both 3GPP and non-3GPP access; and / or support for dedicated CM management contexts for UEs connecting via non-3GPP access. Support for all of the above functions may not be required in network slicing instances.

[0104] SMF 316 supports session management (e.g., session establishment, modification, and publication, including tunnel maintenance between UPF and AN nodes), UE IP address allocation and management (including optional authorization) (where UE IP addresses can be received from the UPF or from an external data network), DHCPv4 (server and client) and DHCPv6 (server and client) functions, the ability to respond to Address Resolution Protocol (ARP) requests and / or IPv6 neighbor request requests with local cached information based on Ethernet PDUs (e.g., the SMF responds to ARP and / or IPv6 neighbor request requests by providing the MAC address corresponding to the IP address sent in the request), selection and control of user plane functions (including controlling the UPF to proxy ARP or IPv6 neighbor discovery or forwarding all ARP / IPv6 neighbor request traffic to the SMF for Ethernet PDU sessions), traffic-directing configuration at the UPF to route traffic to the appropriate destination, and 5G VN group management (e.g., maintaining the topology of the involved PSA UPF, in the PSA...). Establish and publish N19 tunnels between UPFs, configure traffic forwarding at the UPF to apply local handover, and / or N6-based or N19-based forwarding, terminate the interface for policy control functions, lawful interception (for SM events and interfaces to the LI system), charge for data collection and support the billing interface, control and coordinate billing data collection at the UPF, terminate the SM portion of NAS messages, downlink data notification, initiator of AN-specific SM information sent to the AN via the AMF through N2, determination of the SSC mode of the session, control plane CIoT 5GS optimization, header compression, act as an I-SMF in the deployment of insertable / removable / repositionable I-SMFs, configure external parameters (expected UE behavior parameters or network configuration parameters), P-CSCF discovery for IMS services, roaming functions (e.g., handling local implementation to apply QoS). SLA (VPLMN), charging data collection and charging interface (VPLMN) and / or lawful interception (in the VPLMN for SM events and interfaces to LI systems), interaction with external DNs to transmit signaling for PDU session authentication / authorization for external DNs and / or instructing UPF and NG-RAN to perform redundant transmissions on N3 / N9 interfaces. Some or all of the SMF functions may be supported in a single instance of SMF. However, in some implementations, not all functions need to be supported in instances of network slices. In addition to functionality, SMF 316 may include policy-related functions.

[0105] SCP 318 includes one or more of the following functions: indirect communication; delegated discovery; message forwarding and routing to the destination NF / NF service; communication security (e.g., authorization for NF service consumers to access NF service manufacturer APIs), load balancing, monitoring, overload control, etc.; and / or optionally interacting with a UDR to resolve UDM group ID / UDR group ID / AUSF group ID / PCF group ID / CHF group ID / HSS group ID based on UE identity (e.g., SUPI or IMPI / IMPU). Some or all of the SCP functions may be supported in a single instance of the SCP. In some implementations, SCP 318 may be deployed in a distributed manner and / or more than one SCP may exist in the communication path between NF services. SCPs may be deployed at the PLMN level, shared slice level, and slice-specific level. Carrier deployment may be left to ensure that the SCP can communicate with the relevant NRF.

[0106] UE 320 may include devices with radio communication capabilities. For example, UE 320 may include a smartphone (e.g., a handheld touchscreen mobile computing device that can connect to one or more cellular networks). UE 320 may also include any mobile or non-mobile computing device, such as a personal data assistant (PDA), pager, laptop computer, desktop computer, wireless handheld device, or any computing device that includes a wireless communication interface. UE is also referred to as a client, mobile phone, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, or reconfigurable mobile device. UE 320 may include an IoT UE, which may include a network access layer designed to utilize low-power IoT applications with short-lived UE connections. The IoT UE may exchange data with an MTC server or device via a PLMN, other UEs using ProSe or D2D communication, sensor networks, or IoT networks using technologies such as M2M, MTC, or mMTC. M2M or MTC data exchange may be machine-initiated data exchange. An IoT network describes interconnected IoT UEs, which may include uniquely identifiable embedded computing devices (within the Internet infrastructure). IoT UEs may execute background applications (e.g., keeping track of activity messages, status updates, etc.) to facilitate connectivity within the IoT network.

[0107] UE 320 can be configured to connect or communicatively couple with (R)AN 322 via radio interface 330, which can be a physical communication interface or layer configured to operate using cellular communication protocols such as GSM, CDMA network protocols, push-to-talk (PTT), cellular PTT (POC), UMTS, 3GPP LTE, 5G, NR, etc. For example, UE 320 and (R)AN 322 can use a Uu interface (e.g., an LTE-Uu interface) to exchange control plane data via a protocol stack including PHY, MAC, RLC, PDCP, and RRC layers. DL transmissions can be made from (R)AN 322 to UE 320, and UL transmissions can be made from UE 320 to (R)AN 322. UE 320 can also use a sidelink to communicate directly with another UE (not shown) for D2D, P2P, and / or ProSe communication. For example, the ProSe interface may include one or more logical channels, including but not limited to the Physical Side Link Control Channel (PSCCH), Physical Side Link Shared Channel (PSSCH), Physical Side Link Discovery Channel (PSDCH), and Physical Side Link Broadcast Channel (PSBCH).

[0108] (R)AN 322 may include one or more access nodes, which may be referred to as a base station (BS), node B, evolved Node B (eNB), next-generation Node B (gNB), RAN node, controller, transport receiving point (TRP), etc., and may include ground stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., a cell). (R)AN 322 may include one or more RAN nodes for providing coverage of macro cells, pico cells, femto cells, or other types of cells. Macro cells may cover a relatively large geographic area (e.g., with a radius of several kilometers) and may allow UEs to have unrestricted access with a service subscription. Pico cells may cover a relatively small geographic area and may allow UEs to have unrestricted access with a service subscription. Femto cells may cover a relatively small geographic area (e.g., a home) and may allow restricted access for UEs associated with a femto cell (e.g., a UE in a closed subscriber group (CSG), a UE of a user in a home, etc.).

[0109] Although not shown, multiple RAN nodes (such as (R)AN 322) may be used, with Xn interfaces defined between two or more nodes. In some specific implementations, the Xn interface may include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. Xn-U provides non-guaranteed delivery of user plane PDUs and supports / provides data forwarding and flow control functions. Xn-C provides management and error handling functions for managing the functionality of the Xn-C interface; mobility support for UE 320 in connected modes (e.g., CM-CONNECTED) includes functions for managing UE mobility in connected modes between one or more (R)AN nodes. This mobility support may include context transfer from the old (source) serving (R)AN node to the new (destination) serving (R)AN node; and control of user plane tunnels between the old (source) serving (R)AN node and the new (destination) serving (R)AN node.

[0110] The UPF 324 can serve as an anchor point for mobility within and between RATs, an external PDU session point interconnected with the DN 326, and a branch point supporting multihomed PDU sessions. The UPF 324 can also perform packet routing and forwarding, packet inspection, user plane portion enforcement of policy rules, lawful packet interception (UP collection), traffic usage reporting, QoS processing on the user plane (e.g., packet filtering, gating, UL / DL rate enforcement), uplink traffic authentication (e.g., SDF-to-QoS flow mapping), transport-level packet marking in uplink and downlink, and downlink packet buffering and downlink data notification triggering. The UPF 324 may include an uplink classifier to support routing traffic flows to the data network. The DN 326 may represent various network operator services, Internet access, or third-party services. The DN 326 may include, for example, an application server.

[0111] Figure 4 This is a block diagram of a configurable exemplary UE 400 according to various embodiments of the present disclosure, including instructions executed on a computer-readable medium corresponding to any of the exemplary methods and / or processes described herein. The UE 400 includes one or more processors 402, transceiver 404, memory 406, user interface 408, and control interface 410.

[0112] The one or more processors 402 may include, for example, an application processor, an audio digital signal processor, a central processing unit, and / or one or more baseband processors. Each of the one or more processors 402 may include internal memory and / or may include an interface for communicating with external memory (including memory 406). The internal or external memory may store software code, programs, and / or instructions executable by the one or more processors 402 to configure and / or facilitate the UE 400 to perform various operations, including those described herein. For example, the execution of instructions may configure the UE 400 to communicate using one or more wired or wireless communication protocols (including one or more wireless communication protocols standardized by 3GPP, such as those commonly referred to as 5G / NR, LTE, LTE-A, UMTS, HSPA, GSM, GPRS, EDGE, etc.) or any other current or future protocols that can be used in conjunction with the one or more transceivers 404, user interface 408, and / or control interface 410. For example, the one or more processors 402 may execute program code stored in memory 406 or other memory corresponding to the MAC, RLC, PDCP, and RRC layer protocols standardized by 3GPP (e.g., for NR and / or LTE). Alternatively, the processor 402 may execute program code stored in memory 406 or other memory that, together with the one or more transceivers 404, implements the corresponding PHY layer protocol, such as Orthogonal Frequency Division Multiplexing (OFDM), Orthogonal Frequency Division Multiple Access (OFDMA), and Single Carrier Frequency Division Multiple Access (SC-FDMA).

[0113] Memory 406 may include memory regions for the one or more processors 402 to store variables used in the protocols, configurations, controls, and other functions of the UE 400 (including operations corresponding to or including any of the exemplary methods and / or processes described herein). Furthermore, memory 406 may include non-volatile memory (e.g., flash memory), volatile memory (e.g., static or dynamic RAM), or combinations thereof. Additionally, memory 406 may interact with memory time slots through which one or more removable memory cards of various formats (e.g., SD cards, Memory Sticks, Compact Flash, etc.) can be inserted and removed.

[0114] The one or more transceivers 404 may include radio frequency transmitter and / or receiver circuitry that facilitates communication between the UE 400 and other equipment supporting similar wireless communication standards and / or protocols. For example, the one or more transceivers 404 may include switches, mixer circuitry, amplifier circuitry, filter circuitry, and synthesizer circuitry. Such RF circuitry may include a receive signal path having circuitry for down-converting RF signals received from a front-end module (FEM) and providing baseband signals to one or more processors 402. The RF circuitry may also include a transmit signal path that may include circuitry for up-converting the baseband signals provided by the baseband processor and providing an RF output signal for transmission to the FEM. The FEM may include a receive signal path that may include circuitry configured to operate on RF signals received from one or more antennas, amplify the received signals, and provide an amplified version of the received signals to the RF circuitry for further processing. The FEM may also include a transmit signal path that may include circuitry configured to amplify transmit signals provided by the RF circuitry for transmission by one or more antennas. In various implementations, amplification along the transmit or receive signal path can be performed only in the RF circuitry, only in the FEM, or in both the RF and FEM circuitries. In some implementations, the FEM circuitry may include a TX / RX switch to switch between transmit and receive mode operation.

[0115] In some exemplary embodiments, the one or more transceivers 404 include transmitters and receivers that enable device 1200 to communicate with various 5G / NR networks according to various protocols and / or methods proposed for standardization by 3GPP and / or other standards bodies. For example, such functionality may operate cooperatively with one or more processors 402 to implement a PHY layer based on OFDM, OFDMA, and / or SC-FDMA technologies, as described herein with reference to other figures.

[0116] User interface 408 may take various forms depending on the specific implementation, or may not be present in UE 400. In some implementations, user interface 408 includes a microphone, speaker, slide button, pressable button, display, touchscreen display, mechanical or virtual keypad, mechanical or virtual keyboard, and / or any other user interface features typically present on mobile phones. In other implementations, UE 400 may include a tablet computing device with a large touchscreen display. In such implementations, one or more mechanical features of user interface 408 may be replaced by equivalent or functionally equivalent virtual user interface features (e.g., virtual keypad, virtual buttons, etc.) implemented using a touchscreen display, as is well known to those skilled in the art. In other implementations, UE 400 may be a digital computing device, such as a laptop computer, desktop computer, workstation, etc., which includes a mechanical keyboard that can be integrated, detached, or removable according to a particular exemplary implementation. Such digital computing devices may also include a touchscreen display. Many exemplary implementations of UE 400 with a touchscreen display are capable of receiving user input, such as input relating to exemplary methods and / or processes described herein or known to those skilled in the art.

[0117] In some exemplary embodiments of this disclosure, the UE 400 includes an orientation sensor that can be used in various ways by features and functions of the UE 400. For example, the UE 400 can use the output of the orientation sensor to determine when a user has changed the physical orientation of the touchscreen display of the UE 400. An indication signal from the orientation sensor can be used by any application executing on the UE 400 to automatically change the orientation of the screen display (e.g., from portrait to landscape) when the indication signal indicates a change of approximately 90 degrees in the physical orientation of the device. Thus, the application is able to maintain the screen display in a user-readable manner regardless of the physical orientation of the device. Additionally, the output of the orientation sensor can be used in conjunction with various exemplary embodiments of this disclosure.

[0118] The control interface 410 may take various forms depending on the specific implementation. For example, the control interface 410 may include an RS-232 interface, an RS-485 interface, a USB interface, an HDMI interface, a Bluetooth interface, an IEEE (“FireWire”) interface, and an I / O interface. 2 Interfaces include Type-C and PCMCIA interfaces. In some exemplary embodiments of this disclosure, control interface 1260 may include an IEEE 802.3 Ethernet interface, as described above. In some embodiments of this disclosure, control interface 410 may include analog interface circuitry, including, for example, one or more digital-to-analog (D / A) converters and / or analog-to-digital (A / D) converters.

[0119] Those skilled in the art will recognize that the list of features, interfaces, and radio frequency communication standards above is merely exemplary and not limited to the scope of this disclosure. In other words, UE 400 may include more than Figure 4 Further functionalities are shown, including, for example, a video and / or still image camera, microphone, media player, and / or recorder. Additionally, the one or more transceivers 404 may include circuitry for communicating using additional radio frequency communication standards, including Bluetooth, GPS, and / or others. Furthermore, the one or more processors 402 may execute software code stored in memory 406 to control such additional functionalities. For example, directional velocity and / or position estimates output from a GPS receiver can be used by any application executing on the UE 400, including various exemplary methods and / or computer-readable media according to various exemplary embodiments of this disclosure.

[0120] Figure 5 This is a block diagram of a configurable exemplary network node 500 according to various embodiments of the present disclosure, including instructions executed on a computer-readable medium corresponding to any of the exemplary methods and / or processes described herein.

[0121] Network node 500 includes one or more processors 502, a radio network interface 504, a memory 506, a core network interface 508, and other interfaces 510. Network node 500 may include, for example, a base station, eNB, gNB, access node, or components thereof.

[0122] The one or more processors 502 may include any type of processor or processing circuitry and may be configured to perform one of the methods or processes disclosed herein. Memory 506 may store software code, programs, and / or instructions executed by the one or more processors 502 to configure network node 500 to perform various operations, including those described herein. For example, execution of such stored instructions may configure network node 500 to communicate with one or more other devices using protocols according to various embodiments of this disclosure, including one or more methods and / or processes discussed above. Furthermore, execution of such stored instructions may configure and / or facilitate network node 500 to communicate with one or more other devices using other protocols or protocol layers, such as one or more of the PHY, MAC, RLC, PDCP, and RRC layer protocols standardized by 3GPP for LTE, LTE-A, and / or NR, or any other higher-level protocols used in conjunction with radio network interface 504 and core network interface 508. By way of example, and not limitation, core network interface 508 includes an S1 interface, and radio network interface 504 may include a Uu interface, as standardized by 3GPP. Memory 506 may also store variables used in the protocols, configurations, control, and other functions of network node 500. Therefore, memory 506 may include non-volatile memory (e.g., flash memory, hard disk, etc.), volatile memory (e.g., static or dynamic RAM), network-based (e.g., "cloud") storage devices, or combinations thereof.

[0123] The radio network interface 504 may include transmitters, receivers, signal processors, ASICs, antennas, beamforming units, and other circuitry enabling the network node 500 to communicate with other equipment (in some embodiments, such as multiple compatible user equipment (UEs)). In some embodiments, the network node 500 may include various protocols or protocol layers, such as the PHY, MAC, RLC, PDCP, and RRC layer protocols standardized by 3GPP for LTE, LTE-A, and / or 5G / NR. According to further embodiments of this disclosure, the radio network interface 504 may include a PHY layer based on OFDM, OFDMA, and / or SC-FDMA technologies. In some embodiments, the functionality of such a PHY layer may be provided collaboratively by the radio network interface 504 and the one or more processors 502.

[0124] The core network interface 508 may include transmitters, receivers, and other circuitry enabling the network node 500 to communicate with other equipment in the core network (in some embodiments, such as circuit-switched (CS) and / or packet-switched (PS) networks). In some embodiments, the core network interface 508 may include an S1 interface standardized by 3GPP. In some embodiments, the core network interface 508 may include one or more interfaces to one or more SGW, MME, SGSN, GGSN, and other physical devices, including functions known to those skilled in the art in GERAN, UTRAN, E-UTRAN, and CDMA2000 core networks. In some embodiments, these one or more interfaces may be multiplexed together on a single physical interface. In some embodiments, the lower layers of the core network interface 508 may include one or more of Asynchronous Transfer Mode (ATM), Internet Protocol over Ethernet (IP), SDH over fiber, T1 / E1 / PDH over copper, microwave radio, or other wired or wireless transmission technologies known to those skilled in the art.

[0125] Other interfaces 510 may include transmitters, receivers, and other circuitry that enables network node 500 to communicate with external networks, computers, databases, etc., for the operation, management, and maintenance of network node 500 or other network devices operably connected thereto.

[0126] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly explained to users.

[0127] For one or more embodiments, at least one of the components shown in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, and / or methods described in the Embodiments section below. For example, the baseband circuitry described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples below. As another example, circuitry associated with the UE, base station, network element, etc., described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples shown in the Examples section below.

[0128] Example Section

[0129] The following examples relate to other implementation schemes.

[0130] Example 1 is a method for a user equipment (UE), comprising: receiving a first authentication request in response to a first trigger request from the UE to a mobility management node in a first tracking area (TA) where the UE is located; preparing and storing an authentication response based on the first authentication request; in response to determining that the UE has moved from the first TA to a second TA: aborting the transmission of the authentication response; aborting the first trigger request; sending a second trigger request from the UE to the mobility management node of the second TA; receiving a second authentication request from the mobility management node of the second TA in response to the second trigger request; and in response to the reception of the second authentication request and further in response to determining that the given parameters of each of the first authentication request and the second authentication request are the same, sending the stored authentication response based on the first authentication request to the mobility management node of the second TA.

[0131] Example 2 is the method according to Example 1, wherein the given parameter is a RAND parameter.

[0132] Example 3 is the method according to any one of Examples 1 to 2, wherein the first authentication request and the second authentication request are received according to different Key Set Identifiers (KSI).

[0133] Example 4 is a method according to any one of Examples 1 to 3, wherein the mobility management node of the first TA and the mobility management node of the second TA are the same mobility management node.

[0134] Example 5 is a method for a user equipment (UE), comprising: receiving a first authentication request in response to a first trigger request from the UE to a mobility management node in a first tracking area (TA) where the UE is located; in response to determining that the UE has moved from the first TA to a second TA: suspending the transmission of a first authentication response; suspending the first trigger request; sending a second trigger request from the UE to the mobility management node of the second TA; receiving a second authentication request from the mobility management node of the second TA in response to the second trigger request; and sending a second authentication response according to the second authentication request to the mobility management node of the second TA in response to the reception of the second authentication request.

[0135] Example 6 is the method according to Example 5, wherein the second authentication response is sent in further response to determining that the given parameters of each of the first authentication request and the second authentication request are different.

[0136] Example 7 is the method according to any one of Examples 5 to 6, wherein the first authentication request and the second authentication request are received according to different Key Set Identifiers (KSI).

[0137] Example 8 is a method according to any one of Examples 5 to 7, wherein the mobility management node of the first TA and the mobility management node of the second TA are the same mobility management node.

[0138] Example 9 is a computing device for a user equipment (UE), the computing device including a processor and a memory storing instructions. The processor and the memory store instructions that, when executed by the processor, configure the computing device to: process a first authentication request received at the UE in response to a first trigger request from the UE to a mobility management node in a first tracking area (TA) where the UE is located; prepare and store an authentication response based on the first authentication request; in response to determining that the UE has moved from the first TA to a second TA: abort the transmission of the authentication response; abort the first trigger request; prepare a second trigger request to be transmitted from the UE to the mobility management node of the second TA; process a second authentication request received at the UE at the second trigger request from the mobility management node of the second TA; and in response to the reception of the second authentication request at the UE and further in response to determining that the given parameters of each of the first authentication request and the second authentication request are the same, retrieve a stored authentication response based on the first authentication request, the stored authentication response to be transmitted by the UE to the mobility management node of the second TA.

[0139] Example 10 is a computing device according to Example 9, wherein the given parameter is a RAND parameter.

[0140] Example 11 is a computing device according to any one of Examples 9 to 10, wherein the first authentication request and the second authentication request are received according to different Key Set Identifiers (KSI).

[0141] Example 12 is a computing device according to any one of Examples 9 to 11, wherein the mobility management node of the first TA and the mobility management node of the second TA are the same mobility management node.

[0142] Example 13 is a computing device for a user equipment (UE), the computing device including a processor and a memory storing instructions. The processor and the memory store instructions that, when executed by the processor, configure the computing device to: process a first authentication request received at the UE in response to a first trigger request from the UE to a mobility management node in a first tracking area (TA) where the UE is located; in response to determining that the UE has moved from the first TA to a second TA: abort the transmission of a first authentication response; abort the first trigger request; prepare a second trigger request to be sent from the UE to the mobility management node of the second TA; process a second authentication request received at the UE from the mobility management node of the second TA in response to the second trigger request; and in response to the receipt of the second authentication request, prepare a second authentication response based on the second authentication request, the second authentication response to be sent by the UE to the mobility management node of the second TA.

[0143] Example 14 is a computing device according to Example 13, wherein the second authentication response is sent in further response to determining that the given parameters of each of the first authentication request and the second authentication request are different.

[0144] Example 15 is a computing device according to any one of Examples 13 to 14, wherein the first authentication request and the second authentication request are received according to different key set identifiers (KSI).

[0145] Example 16 is a computing device according to any one of Examples 13 to 15, wherein the mobility management node of the first TA and the mobility management node of the second TA are the same mobility management node.

[0146] Example 17 is a non-transitory computer-readable storage medium comprising instructions that, when executed by a computer, cause the computer to: process a first authentication request received at the UE in response to a first trigger request from a mobility management node in a first tracking area (TA) where the UE is located; prepare and store an authentication response according to the first authentication request; in response to determining that the UE has moved from the first TA to a second TA: abort the transmission of the authentication response; abort the first trigger request; prepare a second trigger request to be transmitted from the UE to the mobility management node of the second TA; process a second authentication request received at the UE at the second trigger request from the mobility management node of the second TA; and in response to the reception of the second authentication request at the UE and further in response to determining that the given parameters of each of the first authentication request and the second authentication request are the same, retrieve a stored authentication response according to the first authentication request, the stored authentication response to be transmitted by the UE to the mobility management node of the second TA.

[0147] Example 18 is a non-transitory computer-readable storage medium according to Example 17, wherein the given parameter is a RAND parameter.

[0148] Example 19 is a non-transitory computer-readable storage medium according to any one of Examples 17 to 18, wherein the first authentication request and the second authentication request are received according to different key set identifiers (KSI).

[0149] Example 20 is a non-transitory computer-readable storage medium according to any one of Examples 17 to 19, wherein the mobility management node of the first TA and the mobility management node of the second TA are the same mobility management node.

[0150] Example 21 is a non-transitory computer-readable storage medium comprising instructions that, when executed by a computer, cause the computer to: process a first authentication request received at the UE in response to a first trigger request from a mobility management node in a first tracking area (TA) where the UE is located; in response to determining that the UE has moved from the first TA to a second TA: abort the transmission of a first authentication response; abort the first trigger request; prepare a second trigger request to be sent from the UE to the mobility management node of the second TA; process a second authentication request received at the UE from the mobility management node of the second TA in response to the second trigger request; and in response to the reception of the second authentication request, prepare a second authentication response based on the second authentication request, the second authentication response to be sent by the UE to the mobility management node of the second TA.

[0151] Example 22 is a non-transitory computer-readable storage medium according to Example 21, wherein the second authentication response is sent in further response to determining that the given parameters of each of the first authentication request and the second authentication request are different.

[0152] Example 23 is a non-transitory computer-readable storage medium according to any one of Examples 21 to 22, wherein the first authentication request and the second authentication request are received according to different key set identifiers (KSI).

[0153] Example 24 is a non-transitory computer-readable storage medium according to any one of Examples 21 to 23, wherein the mobility management node of the first TA and the mobility management node of the second TA are the same mobility management node.

[0154] Example 25 may include an apparatus comprising means for performing one or more elements of the method described or associated with any of the above embodiments or any other method or process described herein.

[0155] Example 26 may include one or more non-transitory computer-readable media, the one or more non-transitory computer-readable media including instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of the method or any other method or process described herein as described or associated with any of the above embodiments.

[0156] Example 27 may include an apparatus comprising one or more elements of a logic component, module, or circuit for performing any of the methods described or associated with any of the above embodiments or any other methods or processes described herein.

[0157] Example 28 may include any of the methods, techniques, or processes described or associated with any of the above examples, or any part or component thereof.

[0158] Example 29 may include an apparatus comprising one or more processors and one or more computer-readable media, the one or more computer-readable media including instructions that, when executed by the one or more processors, cause the one or more processors to perform any of the methods, techniques, or processes or portions thereof described or associated with any of the above embodiments.

[0159] Example 30 may include any signal or part or component thereof described or associated with any of the above examples.

[0160] Example 31 may include datagrams, packets, frames, segments, protocol data units (PDUs) or messages or parts or components thereof described or associated with any of the above examples, or otherwise described in this disclosure.

[0161] Example 32 may include a data-encoded signal or part or component thereof described or associated with any of the above examples, or otherwise described in this disclosure.

[0162] Example 33 may include a signal or part or component thereof encoded as a datagram, packet, frame, segment, PDU or message as described or associated with any of the above examples, or otherwise described in this disclosure.

[0163] Example 34 may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors will cause one or more processors to perform any of the methods, techniques, or processes or portions thereof described or associated with any of the above examples.

[0164] Example 35 may include a computer program comprising instructions, wherein execution of the program by a processing element will cause the processing element to perform any of the methods, techniques, or processes or portions thereof described in or associated with any of the above embodiments.

[0165] Example 36 may include signals in a wireless network as shown and described herein.

[0166] Example 37 may include methods for communicating in a wireless network as shown and described herein.

[0167] Example 38 may include a system for providing wireless communication as shown and described herein.

[0168] Example 39 may include a device for providing wireless communication as shown and described herein.

[0169] Unless otherwise expressly stated, any of the above embodiments may be combined with any other embodiment (or combination of embodiments). The foregoing description of one or more specific embodiments provides illustration and description, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise forms disclosed. In view of the teachings above, modifications and variations are possible, or modifications and variations may be obtained from the practice of various embodiments.

[0170] Implementations and specific embodiments of the systems and methods described herein may include various operations embodied in machine-executable instructions to be executed by a computer system. The computer system may include one or more general-purpose or special-purpose computers (or other electronic devices). The computer system may include hardware components, including specific logical components for performing the operations, or may include a combination of hardware, software, and / or firmware.

[0171] It should be recognized that the systems described herein include descriptions of specific implementations. These implementations may be combined into a single system, partially integrated into other systems, divided into multiple systems, or otherwise partitioned or combined. Furthermore, it is conceivable to use parameters, attributes, aspects, etc., of one implementation in another implementation. For clarity, these parameters, attributes, aspects, etc., are described only in one or more implementations, and it should be recognized that unless specifically stated herein, these parameters, attributes, aspects, etc., may be combined with or substituted for parameters, attributes, aspects, etc., of another implementation.

[0172] Although the foregoing has been described in considerable detail for clarity, it will be apparent that certain changes and modifications can be made without departing from the principles of the invention. It should be noted that many alternative ways exist to implement both the processes and apparatus described herein. Therefore, embodiments of the invention should be considered illustrative rather than restrictive, and this specification is not limited to the details given herein, but can be modified within the scope of the appended claims and their equivalents.

Claims

1. A method of a user equipment, UE, comprising: receiving a first authentication request in response to a first trigger request from the UE to a mobility management node of a first tracking area, TA, in which the UE is located; preparing and storing an authentication response in accordance with the first authentication request; in response to determining that the UE has moved from the first TA to a second TA: aborting transmission of the authentication response; aborting the first trigger request; sending a second trigger request from the UE to a mobility management node of the second TA; receiving a second authentication request from the mobility management node of the second TA in response to the second trigger request; and in response to the receiving of the second authentication request and further in response to determining that a given parameter of each of the first authentication request and the second authentication request is the same, sending to the mobility management node of the second TA the stored authentication response in accordance with the first authentication request.

2. The method of claim 1, wherein the given parameter is a RAND parameter.

3. The method of any of claims 1-2, wherein the first authentication request and the second authentication request are received in accordance with different key set identifiers, KSIs.

4. The method of any of claims 1-2, wherein the mobility management node of the first TA and the mobility management node of the second TA are the same mobility management node.

5. A method of a user equipment, UE, comprising: receiving a first authentication request in response to a first trigger request from the UE to a mobility management node of a first tracking area, TA, in which the UE is located; in response to determining that the UE has moved from the first TA to a second TA: aborting transmission of a first authentication response; aborting the first trigger request; sending a second trigger request from the UE to a mobility management node of the second TA; receiving a second authentication request from the mobility management node of the second TA in response to the second trigger request; and in response to the receiving of the second authentication request and further in response to determining that a given parameter of each of the first authentication request and the second authentication request is different, sending to the mobility management node of the second TA a second authentication response in accordance with the second authentication request.

6. The method of claim 5, wherein the first authentication request and the second authentication request are received in accordance with different key set identifiers, KSIs.

7. The method of any of claims 5-6, wherein the mobility management node of the first TA and the mobility management node of the second TA are the same mobility management node.

8. A computing device of a user equipment, UE, the computing device comprising: a processor; and a memory storing instructions that, when executed by the processor, configure the computing device to: process a first authentication request received at the UE in response to a first trigger request from the UE to a mobility management node of a first tracking area, TA, in which the UE is located; ​ ​ ​ preparing and storing an authentication response in accordance with the first authentication request; in response to determining that the UE has moved from the first TA to a second TA: aborting the sending of the authentication response; aborting the first trigger request; preparing a second trigger request to be sent from the UE to a mobility management node of the second TA; processing a second authentication request received at the UE from the mobility management node of the second TA in response to the second trigger request; and in response to the receiving of the second authentication request at the UE and further in response to determining that a given parameter of each of the first authentication request and the second authentication request is the same, retrieving the stored authentication response in accordance with the first authentication request, the stored authentication response to be sent by the UE to the mobility management node of the second TA.

9. The computing device of claim 8, wherein the given parameter is a RAND parameter.

10. The computing device of any of claims 8-9, wherein the first authentication request and the second authentication request are received in accordance with different key set identifiers (KSIs).

11. The computing device of any of claims 8-9, wherein the mobility management node of the first TA and the mobility management node of the second TA are the same mobility management node.

12. A computing device of a user equipment (UE), the computing device comprising: a processor; and a memory storing instructions that, when executed by the processor, configure the computing device to: process a first authentication request received at the UE in response to a first trigger request from the UE to a mobility management node of a first tracking area (TA) in which the UE is located; in response to determining that the UE has moved from the first TA to a second TA: abort the sending of a first authentication response; abort the first trigger request; prepare a second trigger request to be sent from the UE to a mobility management node of the second TA; process a second authentication request received at the UE from the mobility management node of the second TA in response to the second trigger request; and in response to the receiving of the second authentication request and further in response to determining that a given parameter of each of the first authentication request and the second authentication request is different, prepare a second authentication response in accordance with the second authentication request, the second authentication response to be sent by the UE to the mobility management node of the second TA.

13. The computing device of claim 12, wherein the first authentication request and the second authentication request are received in accordance with different key set identifiers (KSIs).

14. The computing device of any of claims 12-13, wherein the mobility management node of the first TA and the mobility management node of the second TA are the same mobility management node.

15. A non-transitory computer-readable storage medium comprising instructions that, when executed by a computer, cause the computer to: processing a first authentication request received at the UE in response to a first trigger request from a mobility management node of a first tracking area, TA, in which the UE is located; preparing and storing an authentication response in accordance with the first authentication request; in response to determining that the UE has moved from the first TA to a second TA: aborting transmission of the authentication response; aborting the first trigger request; preparing a second trigger request to be sent from the UE to a mobility management node of the second TA; processing a second authentication request received at the UE from the mobility management node of the second TA in response to the second trigger request; and in response to the reception of the second authentication request at the UE and further in response to determining that a given parameter of each of the first authentication request and the second authentication request is the same, retrieving the stored authentication response in accordance with the first authentication request, the stored authentication response to be sent by the UE to the mobility management node of the second TA.

16. The non-transitory computer-readable storage medium of claim 15, wherein the given parameter is a RAND parameter.

17. The non-transitory computer-readable storage medium of any one of claims 15-16, wherein the first authentication request and the second authentication request are received in accordance with different key set identifiers, KSIs.

18. The non-transitory computer-readable storage medium of any one of claims 15-16, wherein the mobility management node of the first TA and the mobility management node of the second TA are the same mobility management node.

19. A non-transitory computer-readable storage medium comprising instructions that, when executed by a computer, cause the computer to: process a first authentication request received at the UE in response to a first trigger request from a mobility management node of a first tracking area, TA, in which the UE is located; in response to determining that the UE has moved from the first TA to a second TA: abort transmission of a first authentication response; abort the first trigger request; prepare a second trigger request to be sent from the UE to a mobility management node of the second TA; process a second authentication request received at the UE from the mobility management node of the second TA in response to the second trigger request; and in response to the reception of the second authentication request and further in response to determining that a given parameter of each of the first authentication request and the second authentication request is different, prepare a second authentication response in accordance with the second authentication request, the second authentication response to be sent by the UE to the mobility management node of the second TA.

20. The non-transitory computer-readable storage medium of any one of claims 19, wherein the first authentication request and the second authentication request are received in accordance with different key set identifiers, KSIs.

21. The non-transitory computer-readable storage medium of any of claims 19-20, wherein the mobility management node of the first TA and the mobility management node of the second TA are the same mobility management node.

Images