Paging timing conflict control

Abstract

This application relates to paging timing conflict control. Specifically, it relates to devices and components for exchanging offset values ​​(e.g., IMSI offset values) between user equipment and a network, including means, systems, and methods for paging timing conflict control.

Description

[0001] Cross-references to related applications

[0002] This application relates to the common U.S. Provisional Application No. 63 / 248,367, filed September 24, 2021, and U.S. Application No. 17 / 518,404, filed November 3, 2021, the full text of which is incorporated herein by reference for all purposes. Technical Field

[0003] This application relates to wireless communication. Background Technology

[0004] The 3GPP Technical Specifications (TS) define the standards for wireless networks. These TSs describe aspects related to mobility for operations within such networks. Summary of the Invention

[0005] According to one aspect of this application, a method of operating a network element is disclosed, the method comprising: receiving a request message including a request offset value from a user equipment (UE); sending an acceptance message including a first offset value to the UE based on the request message; and after sending the acceptance message, and during a first paging cycle of the UE: paging the UE according to a first paging timing based on a first UE identity index value, wherein the first UE identity index value is based on the first offset value; and paging the UE according to a second paging timing based on a second UE identity index value, wherein the second UE identity index value is based on a second offset value different from the first offset value.

[0006] According to another aspect of this application, there is an apparatus comprising: a processing circuit configured to: generate a request message including a request offset value; acquire an acceptance message in response to the request message and including a first offset value; generate a completion message in response to the acceptance message; monitor paging timing based on a storage offset value different from the first offset value based on a transmission failure of the completion message; and a memory coupled to the processing circuit, the memory being configured to store the storage offset value. Attached Figure Description

[0007] Figure 1 A network environment according to some implementation schemes is shown.

[0008] Figure 2 An example is shown of using a tracking area update process to exchange negotiated IMSI offset values ​​between user equipment and the network, according to some implementation schemes.

[0009] Figure 3An example is shown of using a registration process to exchange negotiated 5G-S-TMSI offset values ​​between user equipment and the network, according to some implementation schemes.

[0010] Figure 4 Techniques for handling failed exchanges of negotiated IMSI offsets between user equipment and the MME, according to some implementation schemes, are shown.

[0011] Figure 5 The presents a technique for handling failed exchanges of negotiated 5G-S-TMSI offset between user equipment and AMF, according to some implementation schemes.

[0012] Figure 6 Another technique for handling failed exchanges of negotiated IMSI offsets between user equipment and the MME, according to some implementation schemes, is shown.

[0013] Figure 7 Another technique for handling failed exchanges of negotiated 5G-S-TMSI offset between user equipment and AMF, according to some implementation schemes, is shown.

[0014] Figure 8 The operational flow / algorithm structure according to some implementation schemes is shown.

[0015] Figure 9 The operational flow / algorithm structure according to some implementation schemes is shown.

[0016] Figure 10 The operational flow / algorithm structure according to some implementation schemes is shown.

[0017] Figure 11 The operational flow / algorithm structure according to some implementation schemes is shown.

[0018] Figure 12 User equipment according to some implementation schemes is shown.

[0019] Figure 13 A base station according to some implementation schemes is shown. Detailed Implementation

[0020] The following detailed description relates to the accompanying drawings. The same reference numerals may be used in different drawings to identify the same or similar elements. In the following description, specific details, such as particular structures, architectures, interfaces, technologies, etc., are set forth for illustrative and non-limiting purposes to provide a thorough understanding of various aspects of the various embodiments. However, it will be apparent to those skilled in the art that various aspects of the various embodiments may be practiced in other examples departing from these specific details. In some cases, descriptions of well-known devices, circuits, and methods have been omitted so as not to obscure the description of the various embodiments with unnecessary detail. For the purposes of this document, the phrase "A or B" means (A), (B), or (A and B). For the purposes of this document, the phrase "A based on B" means "A is at least based on B".

[0021] The following is a glossary of terms that may be used in this disclosure.

[0022] As used herein, the term "circuit" refers to, is part of, or includes the following: hardware components such as electronic circuits, logic circuits, processors (shared, dedicated, or grouped) or memories (shared, dedicated, or grouped), application-specific integrated circuits (ASICs), field-programmable devices (FPDs) (e.g., field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), complex PLDs (CPLDs), high-capacity PLDs (HCPLDs), structured ASICs, or programmable system-on-a-chip (SoCs)), digital signal processors (DSPs), etc. In some embodiments, a circuit may execute one or more software or firmware programs to provide at least some of the said functions. The term "circuit" may also refer to a combination of one or more hardware elements and program code for performing the functions (or a combination of circuits used in an electrical or electronic system). In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuit.

[0023] As used herein, the term "processor circuit" means, is part of, or includes the following: a circuit capable of sequentially and automatically performing a series of arithmetic or logical operations or recording, storing, or transmitting digital data. The term "processor circuit" may also refer to an application processor, baseband processor, central processing unit (CPU), graphics processing unit, single-core processor, dual-core processor, triple-core processor, quad-core processor, or any other device capable of executing or otherwise operating computer-executable instructions (such as program code, software modules, and / or functional procedures).

[0024] As used herein, the term "interface circuit" refers to, is part of, or includes a circuit that enables the exchange of information between two or more components or devices. The term "interface circuit" can refer to one or more hardware interfaces, such as buses, I / O interfaces, peripheral component interfaces, network interface cards, etc.

[0025] As used herein, the term "user equipment" or "UE" refers to equipment of a remote user that has radio communication capabilities and can describe network resources in a communication network. Furthermore, the term "user equipment" or "UE" can be considered synonymous and can be 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, reconfigurable mobile device, etc. Additionally, the term "user equipment" or "UE" can include any type of wireless / wired equipment or any computing device that includes a wireless communication interface.

[0026] As used herein, the term "computer system" means any type of interconnected electronic device, computer device, or component thereof. Additionally, the term "computer system" or "system" may refer to the various components of a computer that are communicatively coupled to each other. Furthermore, the term "computer system" or "system" may refer to multiple computer devices or multiple computing systems that are communicatively coupled to each other and configured to share computing resources or network resources.

[0027] As used herein, the term "resource" refers to physical or virtual devices, physical or virtual components within a computing environment, or physical or virtual components within a specific device, such as computer equipment, mechanical equipment, memory space, processor / CPU time, processor / CPU utilization, processor and accelerator load, hardware time or utilization, power supply, input / output operations, port or network sockets, channel / link allocation, throughput, memory utilization, storage, network, databases and applications, units of workload, etc. "Hardware resource" can refer to computing, storage, or networking resources provided by physical hardware components. "Virtualized resource" can refer to computing, storage, or networking resources provided by virtualization infrastructure to applications, devices, systems, etc. The terms "network resource" or "communication resource" can refer to resources that computer equipment / systems can access via a communication network. The term "system resource" can refer to any kind of shared entity providing services and can include computing or network resources. System resources can be considered as a coherent set of functions, network data objects, or services accessible through a server, wherein such system resources reside on a single host or multiple hosts and are clearly identifiable.

[0028] As used herein, the term "channel" refers to any tangible or intangible transmission medium used for transmitting data or data streams. The term "channel" may be synonymous or equivalent with "communication channel," "data communication channel," "transmission channel," "data transmission channel," "access channel," "data access channel," "link," "data link," "carrier," "radio frequency carrier," or any other similar term indicating a path or medium through which data is transmitted. Additionally, as used herein, the term "link" refers to a connection between two devices used for transmitting and receiving information.

[0029] As used in this article, the terms "instantiate" and "instantiate" refer to the creation of an instance. "Instance" also refers to the concrete occurrence of an object, which may occur, for example, during the execution of program code.

[0030] The term “connection” can mean that two or more elements at a common communication protocol layer have an established signaling relationship with each other through a communication channel, link, interface, or reference point. The term “obtain” is used to indicate any of its common meanings, such as calculation, derivation, (e.g., from another element or device) receiving, and / or (e.g., from a memory / storage device as described below) retrieval.

[0031] As used herein, the term "network element" refers to the physical or virtualized equipment or infrastructure used to provide wired or wireless communication network services. The term "network element" may be considered synonymous with or referred to as networked computers, network hardware, network equipment, network nodes, virtualized network functions, etc.

[0032] The term "information element" refers to a structural element that contains one or more fields. The term "field" refers to the individual content of an information element, or the data element that contains that content. An information element may include one or more additional information elements.

[0033] This document describes techniques for paging timing conflict control. Such techniques may be applicable to UEs, for example, those supporting multiple Universal User Identity Modules (MUSIM devices). In some cases, such techniques can allow the UE and network to recover from lower-level fault conditions and enable the UE to continue receiving paging in a battery-efficient manner.

[0034] Figure 1 A network environment 100 according to some implementation schemes is illustrated. Network environment 100 may include a UE 104 and base stations (BS) 108 and 128. UE 104 may be a MUSIM device as described below. UE 104 may operate according to the Long Term Evolution (LTE) or Fifth Generation (5G) New Radio (NR) system standards provided by 3GPP TS, or in a manner compatible with these LTE or NR standards.

[0035] Each base station 108 / 128 can provide a radio access cell (e.g., an LTE cell or an NR cell) to provide user plane and control plane protocol termination to UE 104. For example, base station 108 may be an evolved Node B (eNB) providing an LTE access cell and coupled to an evolved packet core network (EPC) 112 of the evolved packet system (EPS); and base station 128 may be an ng-eNB providing an LTE access cell and coupled to a 5G core network (5GC) of a 5G system (5GS), or a gNB providing an NR access cell and coupled to a 5GC of 5GS. UE 104 can communicate with base stations 108 and 128 through air interfaces compatible with 3GPP TS, such as those defining the fifth-generation (5G) NR system standard.

[0036] Network environment 100 may also include a core network (CN) 112. For example, CN 112 may include an EPC. CN 112 may communicate with base station 108 via fiber optic or wireless backhaul. CN 112 may provide functionality to UE 104 via base station 108. These functions may include managing subscriber profile information, subscriber location, service authentication, or handover functions for voice and data sessions.

[0037] CN 112 may include a Mobility Management Entity (MME) 116, which may be implemented in one or more servers or other devices in a centralized or distributed location. MME 116 may be a control plane function providing registration management, connection management, reachability management, and mobility management services, and may serve as an endpoint for Non-Access Stratum (NAS). Registration management allows the UE to register and deregister with CN 112. During registration, a UE context may be created within CN 112. The UE context may be a set of parameters that identify and characterize the UE. The UE context may include identity information, subscription information, capability information, access and mobility information, or Protocol Data Unit (PDU) session information. Connection management can be used to establish and release control plane signaling connections between the UE and MME 116. Establishing a control plane signaling connection moves the UE from a Connection Management (CM) idle state to a CM connected state. Reachability management allows the UE to be located and paged when a move is expected to terminate the connection. Mobility management can be used to maintain the UE's location information within the network. In some implementations, BS 108 may be coupled to MME 116 of core network 112 via an S1-MME interface. The S1-MME interface may use the S1 Application Protocol (S1-AP) to transmit signaling messages (e.g., NAS messages) between BS 108 and MME 116.

[0038] Network environment 100 may also include a core network (CN) 132. For example, CN 132 may include a 5GC. CN 132 may communicate with base station 128 via fiber optic or wireless backhaul. CN 132 may provide functionality to UE 104 via base station 128. These functions may include managing subscriber profile information, subscriber location, service authentication, or handover functions for voice and data sessions.

[0039] CN 132 may include Access and Mobility Management Functions (AMF) 136, which may be implemented in one or more servers or other devices in a centralized or distributed location. AMF 136 may be a control plane function providing registration management, connection management, reachability management, and mobility management services, and may serve as an endpoint for NAS. Registration management allows the UE to register and deregister with CN 132. During registration, a UE context may be created within CN 132. The UE context may be a set of parameters that identify and characterize the UE. The UE context may include identity information, subscription information, capability information, access and mobility information, or Protocol Data Unit (PDU) session information. Connection management can be used to establish and release control plane signaling connections between the UE and AMF 136. Establishing a control plane signaling connection moves the UE from Connection Management (CM) idle to CM connected. Reachability management allows the UE to be located and paged when a move is expected to terminate the connection. Mobility management can be used to maintain the UE's location information within the network. In some implementations, BS 128 may be coupled to AMF 136 of core network 132 using an NG control (NG-C) interface. The NG-C interface may use the Next Generation Application Protocol (NGAP) to transmit signaling messages (e.g., NAS messages) between BS 128 and AMF 136.

[0040] Current deployments support many UEs (e.g., manuals, smartphones, etc.) that have more than one USIM card. These UEs, known as multi-USIM devices or MUSIM devices, are particularly popular in emerging economies and Asian countries, and the use of MUSIM devices is expanding to other regions. MUSIM devices typically support two USIMs, but support for more than two USIMs is also possible.

[0041] In a typical use case, a MUSIM device user has multiple subscriptions and uses the MUSIM device to access two (or all) of these subscriptions using the same device. For example, a user can use a USIM device to access individual subscriptions and service subscriptions. Additionally or alternatively, a user can use a USIM device to access multiple individual subscriptions (e.g., a separate subscription and a "family plan" subscription). In either case, the USIM associated with the various subscriptions may come from the same mobile network operator or from different mobile network operators.

[0042] The current range of MUSIM devices comprises a diverse set of proprietary implementations, which can function very differently from one another. Support for MUSIM in the current 3GPP TS is limited and scarce, and MUSIM-related operations are currently handled in a specific and largely unpredictable manner.

[0043] To reduce costs, MUSIM devices are typically configured to share radio and / or baseband components across various USIM systems. Such sharing can lead to performance issues when using devices within 3GPP systems. For example, while actively communicating with the first system, the MUSIM device may need to periodically check another system (e.g., monitor paging timing, read System Information Blocks (SIBs)), and such operations can adversely affect the performance of one or both of these systems, depending on how the device is implemented.

[0044] Paging conflicts can occur while using MUSIM devices, especially when the same UE identifier value is associated with more than one USIM for that device, and such conflicts can lead to missed paging. When a UE does receive a paging message on the second system, it may not have enough information about the service type that triggered the paging to know how to respond. If the UE is unable to respond to a paging message on the second system without suspending ongoing activities on the first system, the UE may need to disconnect the RRC connection and stop activity on the first system, resulting in a degraded user experience and wasted system resources.

[0045] Open questions regarding MUSIM support in 3GPP systems may include any of the following: how to handle the mobile termination (MT) service of the UE's first USIM when the UE actively communicates on the second USIM; how to implement paging reception and / or avoid paging conflicts in the MUSIM device; how to handle service priority when a UE active on the first USIM receives a paging message on the second USIM; how USIM configuration and user preferences determine the behavior of the MUSIM device; and how to coordinate a leave to suspend ongoing activity on one USIM and resume it later, allowing the UE to temporarily participate in activity on another USIM. Support for MUSIM in 3GPP systems may be expected, as such support enables the standardization and / or more cost-effective implementation of MUSIM devices.

[0046] A MUSIM device can be paged on multiple Radio Access Technologies (RATs), during which time the device may register with different systems. The device may not be able to monitor paging on all 3GPP RATs simultaneously (e.g., due to shared radio and / or baseband components in USIM), and therefore may need to select the paging channel to monitor. Such limitations may result in unsuccessful paging on some paging channels and, in some cases, missed paging.

[0047] For MUSIM devices operating in EPS and / or 5GS, it may be desirable to achieve paging reception across two USIMs. For example, it may be desirable to specify how the system operates when paging across different 3GPP RATs, where paging overlaps in time; and / or consider whether the system needs to know specific UE constraints (such as a single Rx) in order for the MUSIM device to receive paging.

[0048] To reduce power consumption, UEs registered with the system but not currently participating in active communication with the system can operate in idle mode. The UE can be woken from idle mode according to the Discontinuous Reception (DRX) cycle to monitor the paging channel. When using DRX, the UE only needs to monitor one paging opportunity per DRX cycle. For MUSIM devices, the UE needs to monitor one paging opportunity per DRX cycle for each USIM.

[0049] The paging timing occurs within a subframe of the paging frame (PF). The UE determines the PF according to the following formula listed in Clause 7.1 of 3GPP Technical Specification (TS) 36.304 (“LTE; Evolved Universal Terrestrial Radio Access (E-UTRA); User Equipment (UE) Procedures in Idle Mode”), v16.4.0 (2021-09):

[0050] SFN mod T=(T / N)*(UE_ID mod N)

[0051] Where SFN represents the system frame number, T represents the duration of the UE's DRX period (in frames) (e.g., as defined in System Information Block 2 (SIB2)), N is the minimum of T and the value nB (e.g., as defined in SIB2), and UE_ID is the UE identity index value. For EPC, UE_ID is based on the UE's International Mobile Subscriber Identity (IMSI). For 5GC, UE_ID is based on the UE's 5G-S-Temporary Mobile Subscriber Identifier (5G-S-TMSI) (e.g., as defined in Clause 5.9.4 of 3GPP TS23.501 (“3rd Generation Partner Program; Technical Specification Group Services and Systems Aspects; System Architecture of 5G Systems (5GS); Phase 2”), v17.1.1 (2021-06)).

[0052] The paging timing is determined by the index i_s, which points to the subframe pattern as defined in Clause 7.2 of 3GPP TS 36.304. The value of i_s is derived from the following calculation:

[0053] i_s = floor(UE_ID / N) mod Ns,

[0054] Where Ns = max(1, nB / T).

[0055] 3GPP TS 23.401 (“3rd Generation Partner Project; Technical Specification Group Services and Systems Aspects; Enhancements to General Packet Radio Service (GPRS) for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Access”), v17.1.0 (2021-06), Clause 4.3.33.5 describes how an IMSI offset value can be used to avoid potential paging conflicts and increase the likelihood of successful paging reception for different USIMs for MUSIM devices. The UE and MME can negotiate the IMSI offset value and use it to calculate an alternative IMSI value as described in Clause 4.3.33.5. The UE and MME can then use the alternative IMSI value instead of the IMSI to obtain the UE_ID, which is used to derive the paging timing listed in Clause 7.1 of 3GPP TS 36.304 as described above.

[0056] To avoid paging conflicts between the two networks, the MUSIM device can utilize the EPC's MME to initiate a Tracking Area Update (TAU) procedure to request an IMSI offset from the MME (e.g., as described in Clause 5.5.3 of 3GPP TS 24.301 (“3rd Generation Partners Project; Technical Specification Group Core Networks and Terminals; Non-Access Stratum (NAS) Protocol for Evolved Packet Systems (EPS); Phase 3”), v17.3.0 (2021-06)).

[0057] The UE can initiate a TAU procedure by sending a Tracking Area Update Request message to the MME, including a request for an IMSI offset. In response to the Tracking Area Update Request message, the MME sends a Tracking Area Update Accept message to the UE, including a negotiated IMSI offset, and stores the negotiated IMSI offset in the UE context. The negotiated IMSI offset may have the same value as the requested IMSI offset, or it may have a different value. In response to the Tracking Area Update Accept message, the UE sends a Tracking Area Update Complete message to the MME.

[0058] Alternatively, the MUSIM device may initiate a connection procedure (e.g., as described in Clause 5.5.1 of 3GPP TS 24.301) to connect to the EPS, and may also request an IMSI offset value from the MME. The UE may initiate a connection procedure by sending a connection request message to the MME including the requested IMSI offset. In response to the connection request message, the MME sends a connection acceptance message to the UE including the negotiated IMSI offset and stores the negotiated IMSI offset in the UE context. The negotiated IMSI offset may have the same value as the requested IMSI offset, or it may have a different value. In response to the connection acceptance message, the UE sends a connection completion message to the MME.

[0059] Figure 2 The following example illustrates the use of a TAU procedure to successfully exchange negotiated IMSI offset values ​​between MUSIM device 104 and MME 116 via eNB 108, and subsequent handover of paging using a paging timing based on the new negotiated IMSI offset value. Before UE 104 initiates the TAU procedure, MME 116 can use the previously negotiated IMSI offset value (or IMSI value, if an IMSI offset has not yet been negotiated) to calculate its UE_ID to provide to eNB 108 to derive the paging timing for UE 104. Before UE 104 initiates the TAU procedure, UE 104 also uses the previously negotiated IMSI offset value (or IMSI value, if an IMSI offset has not yet been negotiated) to calculate the UE_ID to derive the paging timing. When sending a Tracking Area Update Request message, UE 104 starts timer T3430. Upon receiving a Tracking Area Update Request message, MME 116 calculates a new negotiated IMSI offset (which may be the same as or different from the requested IMSI offset in the Tracking Area Update Request message). The MME 116 generates a Tracking Area Update Accept Message that includes the new negotiated IMSI offset, and when sending the Tracking Area Update Accept Message, the MME 116 starts timer T3450.

[0060] If UE 104 receives a Tracking Area Update Acceptance message before timer T3430 expires, the UE sends a Tracking Area Update Complete message. If MME 116 receives a Tracking Area Update Complete message before timer T3450 expires, the negotiation is successful. In this case, MME 116 uses the new negotiated IMSI offset value to calculate a new UE_ID and provides this new UE_ID to eNB 108 to derive the paging timing for UE 104. UE 104 also uses the new negotiated IMSI offset value to calculate a new UE_ID to derive the paging timing. The connection procedure replaces the TAU procedure to successfully exchange the negotiated IMSI offset value between MUSIM device 104 and MME 116 via eNB 108, and subsequent paging using the paging timing based on the new negotiated IMSI offset value can be performed in a similar manner.

[0061] As described in Clause 4.3.33.5 of 3GPP TS 23.401 (“3rd Generation Partner Project; Technical Specification Group Services and Systems Aspects; General Packet Radio Service (GPRS) Enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) Access”), v17.1.0 (2021-06), UE 104 and MME 116 can use the negotiated IMSI offset value to calculate an alternative IMSI value based on the IMSI of UE 104, as follows:

[0062] Alternatively, the IMSI value can be calculated as follows: [Mobile Country Code (MCC)][Mobile Network Code (MNC)][(Mobile Subscriber Identity (MSIN) value + Negotiated IMSI offset) mod (MSIN address space)]

[0063] The MCC, MNC, and MSIN values ​​are fields of the UE's IMSI, as defined, for example, in Clause 2.2 of 3GPP TS 23.003 (“3rd Generation Partner Program; Technical Specification Group Core Network and Terminals; Numbering, Addressing and Identification”), v17.3.0 (2021-09).

[0064] Instead of the IMSI stored in the USIM, UE 104 can use an alternative IMSI value calculated as above to determine the paging timing as described above. MME 116 can use the alternative IMSI value calculated as above instead of the UE's IMSI to calculate the UE Identity Index (UE_ID) (e.g., as described in clauses 9.1.6 and 9.2.3.10 of 3GPP TS 36.413 (“LTE; Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)”, v.16.6.0 (2021-08)) for eNB 108 to derive the paging timing as described above.

[0065] Clause 5.5.1 of 3GPP TS 24.501 (“3rd Generation Partner Program; Technical Specification Group Core Network and Terminals; Non-Access Stratum (NAS) Protocol for 5G Systems (5GS); Phase 3”), v17.3.1 (2021-06) describes a registration process that can be initiated by a UE with an AMF having a 5GC. For example, sub-clause 5.5.1.3.2 of 3GPP TS 24.501 specifies a registration process for mobility and periodic registration updates, which is similar to the TAU process described in clause 5.5.3 of 3GPP TS 24.301, and sub-clause 5.5.1.2.2 of 3GPP TS 24.501 specifies a registration process for initial registration, which is similar to the connection process described in clause 5.5.1 of 3GPP TS 24.301.

[0066] As mentioned above, the UE_ID in 5GS is based on the UE's 5G-S-TMSI instead of IMSI. It may be desirable to allow UE 104 and AMF 136 to use the negotiated 5G-S-TMSI offset value to calculate an alternative 5G-S-TMSI value based on UE 104's 5G-S-TMSI (e.g., in a similar manner to the calculation of the alternative IMSI value as described above). Similarly, it may be desirable to extend the registration process as described above to allow MUSIM devices to... (referring to the above references) Figure 2 The same method is used to initiate negotiation with the 5GC's AMF to request such a 5G-S-TMSI offset value. Figure 3 An example of this is shown: a registration process (e.g., for mobility and periodic registration updates) is used to successfully exchange the negotiated 5G-S-TMSI offset value between MUSIM device 104 and AMF 136 via gNB 128, and subsequent paging is performed using paging timing based on the new negotiated 5G-S-TMSI offset value.

[0067] exist Figure 3In the example, before UE 104 initiates the registration process, AMF 136 can use the previously negotiated 5G-S-TMSI offset value (or the 5G-S-TMSI value, if the 5G-S-TMSI offset has not yet been negotiated) to calculate the UE_ID it provides to gNB 128 to derive the paging timing for UE 104, and UE 104 also uses the previously negotiated 5G-S-TMSI offset value (or the 5G-S-TMSI offset, if the 5G-S-TMSI offset has not yet been negotiated) to calculate the UE_ID to derive the paging timing. Upon sending a registration request message, UE 104 starts timer T3510. Upon receiving the registration request message, AMF 136 calculates a new negotiated 5G-S-TMSI offset (which may be the same as or different from the requested 5G-S-TMSI offset in the registration request message). After sending a registration accept message including the new negotiated 5G-S-TMSI offset, AMF 136 starts timer T3550.

[0068] If UE 104 receives a registration acceptance message before timer T3510 expires, the UE sends a registration completion message. If AMF 136 receives a registration completion message before timer T3550 expires, the negotiation is successful. In this case, AMF 136 uses the new negotiated 5G-S-TMSI offset value to calculate a new UE_ID and provides this new UE_ID to gNB 128 to derive the paging timing for UE 104. UE 104 also uses the new negotiated 5G-S-TMSI offset value to calculate a new UE_ID to derive the paging timing. Initial registration is performed using a similar extended registration procedure to successfully exchange the negotiated 5G-S-TMSI offset value between MUSIM device 104 and AMF 136 via gNB 128, and subsequent paging using the paging timing based on the new negotiated 5G-S-TMSI offset value can be performed in a similar manner.

[0069] Clause 5.5.3.2.4 of TS 24.301 (“Normal and Periodic Tracking Area Update Procedures Accepted by the Network”) specifies:

[0070] "If the Tracking Area Update Accept message includes a negotiated IMSI offset IE, a MUSIM-enabled UE should forward the IMSI offset value to the lower layer. If the Tracking Area Update Accept message does not include a negotiated IMSI offset IE, a MUSIM-enabled UE should instruct the lower layer to erase any IMSI offset values ​​(if available). If the Tracking Area Update Accept message includes a GUTI [Globally Unique Temporary Identifier] or a negotiated IMSI offset IE, the UE should return a Tracking Area Update Complete message to the MME to acknowledge the received GUTI or the received negotiated IMSI offset IE."

[0071] As mentioned above, such as Figure 2 The success of the negotiation illustrated depends, for example, on the MME116 receiving the Tracking Area Update Complete message before timer T3450 expires. Lower-layer faults (e.g., Access Layer (AS) level faults) can prevent the successful transmission of the Tracking Area Update Complete message. Lower-layer faults can occur before the MME receives the Tracking Area Update Complete message, and this fault can lead to uncertainty on the network side regarding which (negotiated) IMSI value the UE is currently using. If the network fails to successfully receive the Tracking Area Update Complete message, three possible scenarios exist at the UE:

[0072] 1) The UE may not have a negotiated IMSI offset value. For example, the UE may only have an initial IMSI value, and the network may have already attempted to give the UE a new negotiated IMSI offset value in the Tracking Area Update Accept message.

[0073] 2) The UE may already have an old negotiated IMSI offset value, and the network may have tried to give the UE a new negotiated IMSI offset value in the tracking area update accept message.

[0074] 3) The UE may already have an old negotiated IMSI offset value, and the network may have sent a Tracking Area Update Accept message without including any new negotiated IMSI offset value (e.g., the old negotiated IMSI offset value, or no offset value at all).

[0075] It may be desirable to provide efficient techniques for handling negotiated IMSI offset values ​​during lower-layer failures. For example, given the lower-layer failure situation described above, it may be desirable to enable the network to determine how to page the UE in this situation; determine how the UE and the network recover from this situation and reach a common negotiated IMSI offset value; handle such recovery in a highly efficient manner so that the UE does not waste battery power while monitoring multiple paging opportunities; and / or minimize additional signaling impact on network entities (e.g., UE, MME, eNB, AMF, and / or gNB) so that the recovery can be handled efficiently. It may also be desirable to extend such techniques to 5GS and NR. Additionally or alternatively, it may be desirable to provide techniques for handling negotiated IMSI offset values ​​during lower-layer failures that can be used to take advantage of additional power savings through paging subpackets.

[0076] In the aforementioned fault scenario, the UE attempts to respond to the Tracking Area Update Acceptance Message by sending a Tracking Area Update Complete Message. However, due to a lower-layer fault, the UE does not receive a Radio Link Control (RLC) Acknowledgment (ACK). Therefore, the UE knows that the Tracking Area Update Complete Message was not delivered to the network. For the case of "transmission failure indicated by the Tracking Area Update Complete Message, where no [Tracking Area Identity (TAI)] has changed from the lower layer," sub-clause (j) of clause 5.5.3.2.6 ("Abnormal Conditions in the UE") of 3GPP TS 24.301 only specifies that "how to re-run the ongoing process depends on the specific implementation of the UE." For the case of a “transmission failure indicating a Tracking Area Update Complete Message where the TAI changes from a lower layer,” sub-clause (i) of clause 5.5.3.2.6 of 3GPP TS 24.301 only specifies that “if the current TAI is not in the TAI list, the Tracking Area Update process should be immediately aborted and re-initiated. The UE should set the EPS update status to “EU2 Not Updated” and “if the current TAI is still part of the TAI list, how to re-run the ongoing process depends on the specific implementation of the UE.” Such specifications fail to address the uncertainty regarding which offset value should be used after a failure.

[0077] Because the network did not receive the Tracking Area Update Complete message (e.g., due to a lower-layer fault), timer T3450 expired on the network side (e.g., at the MME). In response to the expiration of timer T3450, the network aborted the TAU procedure and entered idle mode. Although the network knows it did not receive the Tracking Area Update Complete message, it is uncertain on the network side whether the UE received the negotiated IMSI offset in the Tracking Area Update Accept message. Therefore, the handshake failed, and the propagation of the new negotiated IMSI offset was not successfully completed.

[0078] Figure 4Techniques for handling failed exchanges of negotiated IMSI offsets between the MUSIM device and the MME (e.g., due to lower-layer faults) according to some embodiments are illustrated. Figure 2 In the example, UE 104 can initiate a TAU procedure by sending a Tracking Area Update Request message, including a requested IMSI offset, to MME 116. The requested IMSI offset can be selected from a predetermined set of offset values ​​(e.g., provided by UE 104) provided by MME 116. Alternatively, the requested IMSI offset can be selected from a predetermined range of offset values ​​(e.g., provided by UE 104). Such a range can be indicated, for example, by a maximum offset value provided by MME 116 to UE 104.

[0079] In response to a Tracking Area Update Request message, MME 116 sends a Tracking Area Update Accept message to the UE, including a negotiated IMSI offset, and stores the negotiated IMSI offset in the UE context. The negotiated IMSI offset may have the same value as the requested IMSI offset, or it may have a different value. The negotiated IMSI offset may be selected from a predetermined set of offset values ​​(e.g., provided by MME 116 to MME 116 by UE 104). Additionally or alternatively, the negotiated IMSI offset may be selected from a predetermined range of offset values ​​(e.g., provided by MME 116 to MME 116). Such a range may be indicated, for example, by a maximum offset value, provided by UE 104 to MME 116.

[0080] In response to the Tracking Area Update Accept message, the UE sends a Tracking Area Update Complete message to the MME 116. However, in this case, the MME 116 does not receive the Tracking Area Update Complete message (e.g., due to a lower-layer failure). Therefore, the network continues paging UE 104 using only the previous, old negotiated IMSI offset value (e.g., the network continues to use the old paging timing). In other words, the network does not use the new negotiated IMSI offset sent in the last Tracking Area Update Accept message. If paging is successful (e.g., the UE responds to the paging), the UE can then initiate a new TAU procedure. If paging is unsuccessful (e.g., the UE does not respond to the paging), the network can initiate a deregistration procedure and cause the UE to reconnect. According to this technique, the MME 116 only switches to the new negotiated IMSI offset to calculate the new UE_ID and paging timing (and transmits the new UE_ID to the eNB 108) when the TAU procedure is successfully completed.

[0081] On the UE side, UE 104 knows an error has occurred because it has not received an RLC ACK in response to the Tracking Area Update Complete message from the lower layer. For example, the failure to receive the RLC ACK could be indicated by the expiration of a timer (e.g., a timer started by the UE when sending the Tracking Area Update Complete message to the lower layer). However, UE 104 is unsure whether the network has received the Tracking Area Update Complete message. Because the UE is aware of the error, it continues to monitor paging timings derived only using the old negotiated IMSI offset (e.g., the UE is not using the new negotiated IMSI offset received in the Tracking Area Update Accept message to derive a new paging timing). The UE can initiate a new TAU procedure using a Tracking Area Update Request message, or the UE can even attempt to establish a new connection using a Connection Request message. According to this technique, UE 104 only switches to the new negotiated IMSI offset to calculate the new UE_ID and paging timing if the TAU procedure completes successfully. It might be expected that the UE will attempt to establish the negotiated IMSI offset by immediately initiating a new TAU procedure (e.g., at the first available timing).

[0082] like Figure 4 An alternative to the technology shown involves multiple paging opportunities per DRX cycle for the use of the USIM of the MUSIM device. In this alternative, the network switches to a new negotiated IMSI offset. If the UE has successfully received the new negotiated IMSI offset, the UE also switches to the new negotiated IMSI offset; otherwise, the UE continues to use the old negotiated IMSI offset. The next time the network needs to page the UE, the network first pages the UE within a paging opportunity determined using the UE_ID based on the new negotiated IMSI offset. If the paging is successful (e.g., if the UE responds to the MME), the network discards the old negotiated IMSI offset value. Otherwise, if the UE does not respond to the paging, the network may page the UE again within a different paging opportunity determined using the UE_ID based on the old negotiated IMSI offset value, and the network may discard the new negotiated IMSI offset value.

[0083] and Figure 4 Compared to the techniques shown, this alternative lacks a clear mechanism regarding when to discard one of the UE_IDs and which UE_ID to use. Therefore, the UE may easily miss paging, potentially leading to a poor user experience (e.g., depending on service type and data type). Monitoring multiple paging opportunities per DRX cycle can be inefficient and battery-intensive for the UE and may result in increased paging signaling load on the air interface, service setup delays (e.g., due to potential double paging delays), and / or increased idle wake-up duration on the UE (which can adversely affect the UE's power performance).

[0084] Compared to the alternative options mentioned above, as referenced Figure 4 The described technique allows both the UE and the network to work deterministically using the old negotiated IMSI offset values, and paging messages can still be delivered despite potential errors during offset negotiation. The network does not need to switch from one UE_ID to another to page the same UE, avoiding potential delays in paging delivery. The UE does not need to switch from one UE_ID to another, which can be beneficial because the UE is unaware of when such a handover might be necessary.

[0085] For reference Figure 4 The described techniques may also be advantageous for paging subgroups. For example, it may be desirable to divide UEs sharing paging opportunities into multiple subgroups. Such subgroups can reduce paging false alarms, resulting in additional UE power savings. Subgroups can be controlled by the network (e.g., based on individual UE characteristics). Configuration options may also be provided where subgroups can be supported through randomization (e.g., by UE_ID) without the network choosing to provide specific subgroup information. Furthermore, the core network (CN) may be responsible for assigning UEs to paging subgroups based on UE characteristics. When a UE is in the RRC_IDLE state, it may be desirable for the UE to use the same subgroup as when the UE is in the RRC_INACTIVE state.

[0086] Using recovery techniques that involve changing the paging timing by using multiple UE_IDs simultaneously, as in the alternative described above, is expected to reduce the efficiency of the paging subgroup implementation and result in a loss of energy savings. However, it is expected that using techniques as described in the reference... Figure 4 The described technique maintains additional UE power saving, which can be achieved by using paging subgroups.

[0087] As referenced above Figure 4 The described technology can also be extended to NR and 5GS. For example, such technology can be used to avoid NR paging collisions when using NAS-based 5G S-TMSI reassignment, where the same failure conditions may occur (e.g., failure to transmit completion messages). According to this technology, the NR UE can continue to listen to the old paging configuration until all signaling message exchanges between the UE and the network for paging collision resolution have been successfully completed. If this is not successful, the UE can further re-trigger the NAS procedure to re-establish new negotiated values. If multiple such re-attempts also fail, the UE can re-initiate the entire process again (e.g., to resolve the original problem of the paging collision).

[0088] Figure 5Techniques for handling failed exchanges of the negotiated 5G-S-TMSI offset between MUSIM devices and the AMF (e.g., due to lower-layer faults) are illustrated according to some embodiments. Figure 3 In the example, UE 104 can initiate a registration process (e.g., for mobility and periodic registration updates) by sending a registration request message to AMF 136 that includes a request for a 5G-S-TMSI offset. The requested 5G-S-TMSI offset can be selected from a predetermined set of offset values ​​(e.g., provided to UE 104 by AMF 136). Additionally or alternatively, the requested 5G-S-TMSI offset can be selected from a predetermined range of offset values ​​(e.g., provided to UE 104 by AMF 136). Such a range can be indicated, for example, by a maximum offset value, provided to UE 104 by AMF 136.

[0089] In response to the registration request message, AMF 136 sends a registration acceptance message to the UE including a negotiated 5G-S-TMSI offset and stores the negotiated 5G-S-TMSI offset in the UE context. The negotiated 5G-S-TMSI offset may have the same value as the requested 5G-S-TMSI offset, or it may have a different value. The negotiated 5G-S-TMSI offset can be selected from a predetermined set of offset values ​​(e.g., provided by AMF 136) provided by UE 104 to AMF 136. Additionally or alternatively, the negotiated 5G-S-TMSI offset can be selected from a predetermined range of offset values ​​(e.g., provided by AMF 136). Such a range may be indicated, for example, by a maximum offset value provided by UE 104 to AMF 136.

[0090] In response to the registration accept message, the UE sends a registration complete message to the AMF 136. However, in this case, the AMF 136 does not receive the registration complete message (e.g., due to a lower-layer failure). Therefore, the network continues to page UE 104 using only the previous, old negotiated 5G-S-TMSI offset value (e.g., the network continues to use the old paging timing). In other words, the network does not send a new negotiated 5G-S-TMSI offset in the final registration accept message. If paging is successful (e.g., the UE responds to the paging), the UE can then initiate a new registration procedure (e.g., for mobility and periodic registration updates). If paging is unsuccessful (e.g., the UE does not respond to the paging), the network can initiate a deregistration procedure, causing the UE to initiate a new registration procedure (e.g., for initial registration). According to this technique, the AMF 136 only switches to the new negotiated 5G-S-TMSI offset to calculate the new UE_ID and paging timing (and transmits this new UE_ID to the gNB 128) when the registration procedure is successfully completed.

[0091] On the UE side, UE 104 knows an error has occurred because it has not received an RLC ACK in response to the registration completion message from the lower layer. However, UE 104 is unsure whether the network has received the registration completion message. Because the UE is aware of the error, it continues to monitor the paging timing derived only using the old negotiated 5G-S-TMSI offset (e.g., the UE is not using the new negotiated 5G-S-TMSI offset received in the registration acceptance message to derive a new paging timing). The UE can initiate a new registration procedure using the registration request message used for mobility and periodic registration updates, or the UE can even attempt a new registration procedure using the registration request message used for initial registration. According to this technique, UE 104 only switches to the new negotiated 5G-S-TMSI offset to calculate the new UE_ID and paging timing if the registration procedure completes successfully. It may be expected that the UE will attempt to establish the negotiated 5G-S-TMSI offset by immediately initiating a new registration procedure (e.g., at the first available timing).

[0092] Refer to the above Figure 4In the described scenario, MME 116 does not receive the Tracking Area Update Complete (TAC) message, and it is assumed that UE 104 is aware that an error has occurred because the UE has not received an RLC ACK in response to the TAC message from the lower layer. However, in some cases, UE 104 may not be aware that an error has occurred. For example, even if the TAC message is lost between eNB 108 and MME 116, UE 104 may still receive an RLC ACK in response to the TAC message from the lower layer, making UE 104 unaware that an error has occurred. In other cases, UE 104 may not be aware that MME 116 has received the TAC message. For example, even if the TAC message has been successfully delivered to MME 116, eNB 108 may fail to deliver an RLC ACK to UE 104, making UE 104 unaware of the successful delivery. To handle one or more of these error conditions, one or more other methods may be desired.

[0093] Figure 6 Another technique, according to some embodiments, is shown for handling failed exchanges of negotiated IMSI offsets between the MUSIM device and the MME (e.g., due to network failures and / or lower-layer failures). Figure 2 In the example, UE 104 can initiate a TAU procedure by sending a Tracking Area Update Request message, including a requested IMSI offset, to MME 116. The requested IMSI offset can be selected from a predetermined set of offset values ​​(e.g., provided to UE 104 by MME 116). Alternatively, the requested IMSI offset can be selected from a predetermined range of offset values ​​(e.g., provided to UE 104 by MME 116). Such a range can be indicated, for example, by a maximum offset value, provided to UE 104 by MME 116.

[0094] In response to a Tracking Area Update Request message, MME 116 sends a Tracking Area Update Accept message to the UE including a negotiated IMSI offset and stores the negotiated IMSI offset in the UE context. The negotiated IMSI offset may have the same value as the requested IMSI offset, or it may have a different value. The negotiated IMSI offset may be selected from a predetermined set of offset values ​​(e.g., provided by MME 116 to UE 104). Alternatively, the negotiated IMSI offset may be selected from a predetermined range of offset values ​​(e.g., provided by MME 116 to UE 104). Such a range may be indicated, for example, by a maximum offset value, provided by UE 104 to MME 116. In this case, MME 116 also assigns (e.g., dispatches) a new GUTI to UE 104 and includes this new GUTI in the Tracking Area Update Accept message.

[0095] In response to the Tracking Area Update Accept message, UE 104 sends a Tracking Area Update Complete message to MME 116 and also begins subsequent communication with the network using the new GUTI. However, in this example, MME 116 does not receive the Tracking Area Update Complete message before timer T3450 expires (e.g., the Tracking Area Update Complete message is lost between UE 104 and eNB 108, or the Tracking Area Update Complete message is lost between eNB 108 and MME 116), and UE 104 may or may not know that an error has occurred.

[0096] Therefore, the network continues to page UE 104 using the previous old negotiated IMSI offset value (e.g., the network continues to use the old paging timing), and simultaneously (e.g., within the same DRX cycle or paging cycle of UE 104), the network continues to page UE 104 using the new negotiated IMSI offset sent in the last Tracking Area Update Accept message (e.g., the network also uses the new paging timing). If the UE successfully receives the Tracking Area Update Accept message (as in...), Figure 6In the example, UE 104 responds to paging based on the new negotiated IMSI offset value by initiating a service request procedure using the new GUTI (e.g., by sending a Service Request (SR) message, Extended Service Request (ESR) message, or Control Plane Service Request (CPSR) message). For example, the SR, ESR, or CPSR message may include a System Architecture Evolution-Temporary Mobile Subscriber Identity (S-TMSI) based on the new GUTI. Alternatively, if UE 104 does not receive a Tracking Area Update Acceptance message before timer T3430 expires, UE 104 responds to paging based on the old negotiated IMSI offset value by initiating a service request procedure using the old GUTI. For example, the SR, ESR, or CPSR message may include an S-TMSI based on the old GUTI. Upon receiving a response from UE 104 to the paging (e.g., an SR, ESR, or CPSR message), the network continues to use the IMSI offset and GUTI indicated by that response (e.g., when communicating with the UE and / or with the relevant eNB). For example, one of the old and new negotiated IMSI offset values ​​may be indicated by UE identity information in SR, ESR, or CPSR messages (e.g., the old or new GUTI, or the S-TMSI based on the old or new GUTI). If UE 104 does not receive a Tracking Area Update Acceptance message before timer T3430 expires, it may be expected that the UE will attempt to establish the negotiated IMSI offset by immediately initiating a new Tracking Area Update procedure (e.g., at the first available moment).

[0097] For reference Figure 6 The described technique allows the network to avoid delays when delivering paging to UE 104 in a deterministic manner because the network simultaneously (e.g., during the same paging cycle of the UE) uses both old and new IMSI offsets and old and new GUTI values ​​to page UE 104. The appropriate IMSI offset and GUTI value are selected based on how UE 104 responds. No behavioral changes are required on the UE side, and even in the event of an error during IMSI offset negotiation, UE 104 can continue to monitor only one paging opportunity per paging cycle per USIM. No delay occurs during service establishment (e.g., unlike the case where the UE is first paged with one value and then subsequently paged with another value if the UE does not respond). The use of methods such as those described in the references is also anticipated. Figure 6 The described technique maintains additional UE power saving, which can be achieved by using paging subgroups as described above.

[0098] As referenced above Figure 6The technology can also be extended to NR and 5GS. For example, such technology can be used to avoid NR paging collisions when using NAS-based 5G S-TMSI reassignment, where the same failure conditions (e.g., failure to transmit a completed message) may occur.

[0099] Figure 7 Another technique, according to some implementations, is shown for handling failed exchanges of negotiated 5G-S-TMSI offsets between MUSIM devices and the AMF (e.g., due to network failures and / or lower-layer failures). Figure 3 In the example, UE104 can initiate a registration process (e.g., for mobility and periodic registration updates) by sending a registration request message including a request for a 5G-S-TMSI offset to AMF 136. The requested 5G-S-TMSI offset can be selected from a predetermined set of offset values ​​(e.g., provided to UE104 by AMF 136). Additionally or alternatively, the requested 5G-S-TMSI offset can be selected from a predetermined range of offset values ​​(e.g., provided to UE104 by AMF 136). Such a range can be indicated, for example, by a maximum offset value, provided to UE104 by AMF 136.

[0100] In response to the registration request message, AMF 136 sends a registration acceptance message to the UE including a negotiated 5G-S-TMSI offset and stores the negotiated 5G-S-TMSI offset in the UE context. The negotiated 5G-S-TMSI offset may have the same value as the requested 5G-S-TMSI offset, or it may have a different value. The negotiated 5G-S-TMSI offset can be selected from a predetermined set of offset values ​​(e.g., provided by AMF 136) provided by UE 104 to AMF 136. Additionally or alternatively, the negotiated 5G-S-TMSI offset can be selected from a predetermined range of offset values ​​(e.g., provided by AMF 136). Such a range may be indicated, for example, by a maximum offset value provided by UE 104 to AMF 136. In this case, AMF 136 also assigns (e.g., dispatches) a new GUTI to UE 104 and includes the new GUTI in the registration acceptance message.

[0101] In response to the registration accept message, the UE sends a registration complete message to AMF 136 and also begins subsequent communication with the network using the new GUTI. However, in this scenario, AMF 136 does not receive the registration complete message before timer T3550 expires (e.g., the registration complete message is lost between UE 104 and gNB 128, or between gNB 128 and AMF 136), and UE 104 may or may not know that an error has occurred.

[0102] Therefore, the network continues to page UE 104 using the previously negotiated 5G-S-TMSI offset (e.g., the network continues to use the old paging timing), and simultaneously (e.g., within the same DRX cycle or paging cycle of UE 104), the network continues to page UE 104 using the new negotiated 5G-S-TMSI offset sent in the final registration accept message (e.g., the network also uses the new paging timing). If the UE successfully receives the registration accept message (e.g., in...), Figure 7 In the example, UE 104 responds to paging based on the new negotiated IMSI offset value by initiating a service request procedure using the new GUTI (e.g., by sending a Service Request (SR) message or a Control Plane Service Request (CPSR) message). For example, the SR or CPSR message may include a 5G-S-Temporary Mobile Subscriber Identity (5G-S-TMSI) based on the new GUTI. Alternatively, if UE 104 does not receive a registration acceptance message before timer T3510 expires, UE 104 responds to paging based on the old negotiated IMSI offset value by initiating a service request procedure using the old GUTI. For example, the SR or CPSR message may include a 5G-S-TMSI based on the old GUTI. Upon receiving a response from UE 104 to paging (e.g., an SR or CPSR message), the network continues to use the 5G-S-TMSI offset and GUTI indicated by the response (e.g., for communicating with the UE and / or with the relevant gNB). For example, one of the old and new negotiated 5G-S-TMSI offset values ​​may be indicated by the UE identity information in the SR or CPSR message (e.g., the old or new GUTI, or the S-TMSI based on the old or new GUTI). If UE 104 does not receive a registration acceptance message before timer T3510 expires, it may be expected that the UE will attempt to establish the negotiated 5G-S-TMSI offset by immediately initiating a new registration update procedure (e.g., at the first available moment).

[0103] Figure 8An operational flow / algorithm structure 800 according to some implementation schemes is shown. The operational flow / algorithm structure 800 may be executed or implemented by a UE such as UE 104 or UE 900; or their components (e.g., baseband processor 904A).

[0104] The operation flow / algorithm structure 800 may include generating a request message including a request offset value at 804. The request message may be, for example, a connection request message and a tracking area update request message. The request message may be, for example, a registration request message, which may indicate a request to update registration. The request offset value may be, for example, an IMSI offset value or a 5G-S-TMSI offset value.

[0105] The operation flow / algorithm structure 800 may include receiving an acceptance message at 808 in response to a request message and including a first offset value. The first offset value may be the same as the request offset value. Alternatively, the first offset value may be different from the request offset value. The first offset value may be, for example, a negotiated offset value (e.g., a negotiated IMSI offset value or a negotiated 5G-S-TMSI offset value).

[0106] The operation flow / algorithm structure 800 may include generating a completion message at 812 in response to receiving a message.

[0107] The operation flow / algorithm structure 800 may include, at 816, monitoring paging timing based on a stored offset value, which differs from a first offset value, in response to a transmission failure of the completion message. For example, the operation flow / algorithm structure 800 may include starting a timer when a completion message is sent, and the timer's expiration indicating a transmission failure of the completion message. Additionally or alternatively, a lack of acknowledgment of the completion message transmission at a lower layer may indicate a transmission failure of the completion message. The stored offset value may be a negotiated offset value (e.g., another negotiated IMSI offset value or another negotiated 5G-S-TMSI offset value).

[0108] The operation flow / algorithm structure 800 may further include generating a second update request, including a second request offset value, based on a transmission failure of the completion message. The second request offset value may be the same as the request offset value. Alternatively, the second request offset value may be different from the request offset value. The second request offset value may be, for example, a second request IMSI offset value or a second request 5G-S-TMSI offset value.

[0109] Figure 9 An operational flow / algorithm structure 900 according to some implementation schemes is shown. The operational flow / algorithm structure 900 may be executed or implemented by network elements (such as MME 116 or AMF 136) or their components (e.g., one or more processors).

[0110] The operation flow / algorithm structure 900 may include receiving a request message including a requested offset value from the UE at 904. The request message may be, for example, a connection request message and a tracking area update request message. The request message may be, for example, a registration request message, which may indicate a request to update registration. The requested offset value may be, for example, an IMSI offset value or a 5G-S-TMSI offset value.

[0111] The operation flow / algorithm structure 900 may include sending an accept message including a first offset value to the UE at 908 based on the request message. The first offset value may be the same as the requested offset value. Alternatively, the first offset value may be different from the requested offset value. The first offset value may be, for example, a negotiated offset value (e.g., a negotiated IMSI offset value or a negotiated 5G-S-TMSI offset value).

[0112] Operational flow / algorithm structure 900 may include calculating a UE identity index value based on a second offset value at 912, and paging the UE according to a paging timing based on the UE identity index value after sending an accept message, wherein the second offset value is different from the first offset value. The UE identity index value may be, for example, UE_ID. The second offset value may be, for example, a negotiated offset value (e.g., another negotiated IMSI offset value or another negotiated 5G-S-TMSI offset value). Operational flow / algorithm structure 900 may include using the UE identity index value to derive the paging timing. Operational flow / algorithm structure 900 may include sending the UE identity index value to a base station (e.g., eNB or gNB) before receiving a request message.

[0113] Figure 10 An operational flow / algorithm structure 1000 according to some implementation schemes is shown. The operational flow / algorithm structure 1000 may be executed or implemented by network elements (such as MME 116 or AMF 136) or their components (e.g., one or more processors).

[0114] Operation flow / algorithm structure 1000 may include using a stored offset value at 1004 to derive the UE identity index value of the UE. The UE identity index value may be, for example, UE_ID.

[0115] The operation flow / algorithm structure 1000 may include receiving a request message from the UE at 1008, which includes a requested offset value that differs from the stored offset value. The request message may be, for example, one of a connection request message and a tracking area update request message. The request message may be, for example, a registration request message, which may indicate a request to update registration. The requested offset value may be, for example, an IMSI offset value or a 5G-S-TMSI offset value.

[0116] The operation flow / algorithm structure 1000 may include sending an accept message including a first offset value to the UE based on the request message at 1012 and starting a timer. The first offset value may be the same as the requested offset value. Alternatively, the first offset value may be different from the requested offset value. The first offset value may be, for example, a negotiated offset value (e.g., a second negotiated IMSI offset value or a second negotiated 5G-S-TMSI offset value).

[0117] The operation flow / algorithm structure 1000 may include, at point 1016, deciding not to update the stored offset value based on a timer expiration. Timer expiration may indicate that the network element has not yet received a message in response to an accept message. The operation flow / algorithm structure 1000 may also include sending the UE identity index value to the base station (e.g., in a paging message) before receiving a request message and / or after the timer expiration.

[0118] Figure 11 An operational flow / algorithm structure 1100 according to some implementation schemes is shown. The operational flow / algorithm structure 1100 may be executed or implemented by network elements (such as MME 116 or AMF 136) or their components (e.g., one or more processors).

[0119] The operation flow / algorithm structure 1100 may include receiving a request message including a requested offset value from the UE at 1104. The request message may be, for example, one of a connection request message and a tracking area update request message. The request message may be, for example, a registration request message, which may indicate a request to update registration. The requested offset value may be, for example, an IMSI offset value or a 5G-S-TMSI offset value.

[0120] The operation flow / algorithm structure 1100 may include sending an accept message including a first offset value to the UE at 1108 based on a request message. The first offset value may be the same as the requested offset value. Alternatively, the first offset value may be different from the requested offset value. The first offset value may be, for example, a negotiated offset value (e.g., a negotiated IMSI offset value or a negotiated 5G-S-TMSI offset value).

[0121] Operation flow / algorithm structure 1100 may include, at 1112, executing blocks 1116 and 1120 after sending an acceptance message and during the first paging cycle of the UE. Block 1116 may include paging the UE according to a first paging timing based on a first UE identity index value, wherein the first UE identity index value is based on a first offset value. The first UE identity index value may be, for example, UE_ID. Block 1116 may include paging the UE according to a second paging timing based on a second UE identity index value, wherein the second UE identity index value is based on a second offset value, which is different from the first offset value. The second offset value may be, for example, a negotiated offset value (e.g., another negotiated IMSI offset value or another negotiated 5G-S-TMSI offset value). The second UE identity index value may be, for example, UE_ID. Operation flow / algorithm structure 1100 may include using the first UE identity index value to derive the first paging timing and / or using the second UE identity index value to derive the second paging timing. The operation process / algorithm structure 1100 may include storing the second UE identity index value and / or sending the second UE identity index value to the base station (e.g., eNB or gNB) before receiving the request message.

[0122] Figure 12 A UE 1200 according to some implementation schemes is shown. UE 1200 may be similar to Figure 1 The UE 104 is essentially interchangeable with it.

[0123] UE 1200 can be any mobile or non-mobile computing device, such as, for example, mobile phones, computers, tablets, industrial wireless sensors (e.g., microphones, carbon dioxide sensors, pressure sensors, humidity sensors, thermometers, motion sensors, accelerometers, laser scanners, fluid level sensors, stock sensors, voltmeters / ammeters, actuators, etc.), video surveillance / monitoring devices (e.g., cameras, camcorders, etc.), wearable devices (e.g., smartwatches), and loosely coupled IoT devices.

[0124] UE 1200 may include a processor 1204, RF interface circuitry 1208, memory / storage device 1212, user interface 1216, sensor 1220, drive circuitry 1222, power management integrated circuit (PMIC) 1224, antenna structure 1226, and battery 1228. Components of UE 1200 may be implemented as integrated circuits (ICs), portions of integrated circuits, discrete electronic devices or other modules, logic components, hardware, software, firmware, or combinations thereof. Figure 12 The block diagram is intended to show a high-level view of some of the components of the UE 1200. However, some of the components shown may be omitted, additional components may be present, and different arrangements of the components shown may occur in other specific implementations.

[0125] The components of UE 1200 can be coupled to various other components via one or more interconnects 1232, which can represent any type of interface, input / output, bus (local, system, or extended), transmission line, trace, optical connector, etc., that allows various circuit components (on common or different chips or chipsets) to interact with each other.

[0126] Processor 1204 may include processor circuitry, such as, for example, baseband processor circuitry (BB) 1204A, central processing unit circuitry (CPU) 1204B, and graphics processing unit circuitry (GPU) 1204C. Processor 1204 may include any type of circuitry or processor circuitry that executes or otherwise operates computer-executable instructions (such as program code, software modules, or functional processes from memory / storage device 1212) to cause UE 1200 to perform the operations described herein.

[0127] In some implementations, the baseband processor circuit 1204A can access the communication protocol stack 1236 in the memory / storage device 1212 to communicate over a 3GPP-compliant network. Generally, the baseband processor circuit 1204A can access the communication protocol stack to perform the following operations: user plane functions at the PHY, MAC, RLC, PDCP, SDAP, and PDU layers; and control plane functions at the PHY, MAC, RLC, PDCP, RRC, and non-access layers. In some implementations, PHY layer operations may additionally / optionally be performed by components of the RF interface circuit 1208.

[0128] The baseband processor circuit 1204A can generate or process baseband signals or waveforms carrying information in a 3GPP-compliant network. In some implementations, the waveforms used for NR may be based on cyclic prefix OFDM (“CP-OFDM”) in the uplink or downlink, and Discrete Fourier Transform Extended OFDM (“DFT-S-OFDM”) in the uplink.

[0129] Memory / storage device 1212 may include one or more non-transitory computer-readable media, including instructions (e.g., communication protocol stack 1236) that can be executed by one or more processors in processor 1204 to cause UE 1200 to perform the various operations described herein. Memory / storage device 1212 includes any type of volatile or non-volatile memory that can be distributed throughout UE 1200. In some embodiments, some memory / storage devices in memory / storage device 1212 may be located on processor 1204 itself (e.g., L1 cache and L2 cache), while other memory / storage devices 1212 may be located external to processor 1204 but accessible via a memory interface. Memory / storage device 1212 may include any suitable volatile or non-volatile memory, such as, but not limited to, dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state memory, or any other type of memory device technology.

[0130] The RF interface circuit 1208 may include transceiver circuitry and a radio frequency front-end module (RFEM), which allows the UE 1200 to communicate with other devices via a radio access network. The RF interface circuit 1208 may include various components arranged in the transmission or reception path. These components may include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, control circuitry, etc.

[0131] In the receiving path, the RFEM can receive the radiated signal from the air interface via antenna structure 1226 and continue to filter and amplify the signal (using a low-noise amplifier). This signal can be provided to the receiver of the transceiver, which downconverts the RF signal into a baseband signal that is provided to the baseband processor of processor 1204.

[0132] In the transmission path, the transceiver's transmitter upconverts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM amplifies the RF signal using a power amplifier before it is radiated across the air interface via antenna 1226.

[0133] In various implementations, the RF interface circuit 1208 can be configured to transmit / receive signals in a manner compatible with NR access technology.

[0134] Antenna 1226 may include antenna elements to convert electrical signals into radio waves for propagation through the air and to convert received radio waves back into electrical signals. These antenna elements may be arranged in one or more antenna panels. Antenna 1226 may have omnidirectional, directional, or combinations thereof antenna panels to enable beamforming and multiple-input / multiple-output communication. Antenna 1226 may include microstrip antennas, printed antennas fabricated on the surface of one or more printed circuit boards, patch antennas, phased array antennas, etc. Antenna 1226 may have one or more panels designed for a specific frequency band included in FR1 or FR2.

[0135] User interface circuitry 1216 includes various input / output (I / O) devices designed to enable users to interact with UE 1200. User interface circuitry 1216 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for accepting input, particularly including one or more physical or virtual buttons (e.g., a reset button), a physical keyboard, a keypad, a mouse, a touchpad, a touchscreen, a microphone, a scanner, a headset, etc. Output device circuitry includes any physical or virtual means for displaying information or otherwise conveying information (such as sensor readings, actuator positions, or other similar information). Output device circuitry may include any number or combination of audio or visual displays, particularly including one or more simple visual outputs / indicators (e.g., binary status indicators, such as light-emitting diodes (LEDs)) and multi-character visual outputs, or more complex outputs, such as display devices or touchscreens (e.g., liquid crystal displays, LED displays, quantum dot displays, projectors, etc.), wherein the output of characters, graphics, multimedia objects, etc., is generated or produced by the operation of UE 1200.

[0136] Sensor 1220 may include devices, modules, or subsystems intended to detect events or changes in their environment and transmit information about the detected events (sensor data) to other devices, modules, subsystems, etc. Examples of such sensors include, in particular: inertial measurement units including accelerometers, gyroscopes, or magnetometers; microelectromechanical systems (MEMS) or nanoelectromechanical systems (NEMS) including triaxial accelerometers, triaxial gyroscopes, or magnetometers; level sensors; flow sensors; temperature sensors (e.g., thermistors); pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (e.g., cameras or lensless aperture sensors); light detection and ranging sensors; proximity sensors (e.g., infrared radiation detectors, etc.); depth sensors; ambient light sensors; ultrasonic transceivers; microphones or other similar audio capture devices; etc.

[0137] The driving circuit 1222 may include software and hardware elements for controlling specific devices embedded in, attached to, or otherwise communicatively coupled to the UE 1200. The driving circuit 1222 may include various drivers that allow other components to interact with or control various input / output (I / O) devices that may exist within or be connected to the UE 1200. For example, the driving circuit 1222 may include: a display driver for controlling and allowing access to a display device; a touchscreen driver for controlling and allowing access to a touchscreen interface; a sensor driver for acquiring sensor readings of the sensor circuit 1220 and controlling and allowing access to the sensor circuit 1220; a driver for acquiring actuator positions of electromechanical components or controlling and allowing access to electromechanical components; a camera driver for controlling and allowing access to an embedded image capture device; and an audio driver for controlling and allowing access to one or more audio devices.

[0138] The PMIC 1224 manages the power supplied to various components of the UE 1200. Specifically, relative to the processor 1204, the PMIC 1224 controls power selection, voltage scaling, battery charging, or DC-DC conversion.

[0139] In some implementations, the PMIC 1224 may control or otherwise incorporate various power-saving mechanisms of the UE 1200, including DRX, as discussed herein.

[0140] Battery 1228 can power UE 1200, but in some examples, UE 1200 may be mounted in a fixed location and may have a power source coupled to the mains. Battery 1228 may be a lithium-ion battery, a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, etc. In some specific implementations, such as in vehicle-based applications, battery 1228 may be a typical lead-acid automotive battery.

[0141] Figure 13 An access node 1300 (e.g., a base station such as an eNB or gNB) is shown according to some embodiments. The access node 1300 may be similar to or interchangeable with base station 108 or 128.

[0142] Access node 1300 may include processor 1304, RF interface circuit 1308, core network (CN) interface circuit 1312, memory / storage circuit 1316 and antenna structure 1326.

[0143] The components of access node 1300 can be coupled to various other components via one or more interconnectors 1328.

[0144] The processor 1304, RF interface circuit 1308, memory / storage circuit 1316 (including communication protocol stack 1310), antenna structure 1326, and interconnect 1328 can be similar to those described above. Figure 12 Similar named elements are shown and described.

[0145] The CN interface circuit 1312 may provide connectivity to a core network (e.g., a 5GC using a 5G core network (5GC) compatible network interface protocol (such as Carrier Ethernet) or some other suitable protocol). Network connectivity may be provided to / from access node 1300 via fiber optic or wireless backhaul. The CN interface circuit 1312 may include one or more dedicated processors or FPGAs for communicating using one or more of the aforementioned protocols. In some implementations, the CN interface circuit 1312 may include multiple controllers for providing connectivity to other networks using the same or different protocols.

[0146] 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.

[0147] 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, or methods as described in the Examples 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.

[0148] Example

[0149] Further exemplary implementations are provided in the following sections.

[0150] Example 1 includes a method comprising: generating a request message including a request offset value; obtaining an acceptance message in response to the request message, the acceptance message including a first offset value; generating a completion message in response to the acceptance message; and monitoring paging timing based on a stored offset value, which is different from the first offset value, based on a transmission failure of the completion message. Such a method may be performed by a UE (e.g., a MUSIM device) and / or by processing circuitry within the UE (e.g., a MUSIM device), such as a baseband chipset.

[0151] Example 2 includes the method according to Example 1 or some other embodiments herein, wherein the method includes starting a timer when a completion message is sent, and the timer expiring indicates a transmission failure of the completion message.

[0152] Example 3 includes the method according to Example 1 or some other embodiments herein, wherein the lower layer lacks an acknowledgment of the transmission of the completion message indicating a transmission failure of the completion message.

[0153] Example 4 includes the method according to Example 1 or some other embodiments herein, wherein the request message is one of a connection request message and a tracking area update request message (e.g., in EPS).

[0154] Example 5 includes the method according to Example 1 or some other embodiments herein, wherein the request message is a registration request message (e.g., in 5GS).

[0155] Example 6 includes the method according to Example 5 or some other embodiments herein, wherein the request message indicates a request to update the registration.

[0156] Example 7 includes the method according to Example 1 or some other examples herein, wherein the storage offset value is a negotiated offset value.

[0157] Example 8 includes the method according to Example 1 or some other examples herein, wherein the first offset value is the same as the requested offset value.

[0158] Example 9 includes the method according to Example 1 or some other examples herein, wherein the first offset value is different from the requested offset value.

[0159] Example 10 includes the method according to Example 1 or some other embodiments herein, wherein the method further includes generating a second update request including a second request offset value based on the transmission failure of the completion message.

[0160] Example 11 includes the method according to any one of Examples 1 to 10 or some other embodiments herein, wherein the method includes selecting the requested offset value from a predetermined set of offset values ​​or from a predetermined range of offset values.

[0161] Example 12 includes the method according to any one of Examples 1 to 11 or some other embodiments herein, wherein the requested offset value is a requested IMSI offset value, the first offset value is a first IMSI offset value, and the stored offset value is a stored IMSI offset value.

[0162] Example 13 includes a method for operating a network element, the method comprising: receiving a request message including a request offset value from a UE; sending an acceptance message including a first offset value to the UE based on the request message; calculating a UE identity index value based on a second offset value, and paged the UE according to a paging timing based on the UE identity index value after sending the acceptance message, wherein the second offset value is different from the first offset value. Example 13 may further include assigning a first temporary UE identifier to the UE, wherein the acceptance message includes the first temporary UE identifier, the request message includes the second temporary UE identifier, and paged the UE includes sending a paging message to the UE, the paging message including UE identity information from the second temporary UE identifier.

[0163] Example 14 includes the method according to Example 13 or some other embodiments herein, wherein the method includes sending the UE identity index value to the base station before receiving the request message.

[0164] Example 15 includes the method according to Example 13 or some other embodiments herein, wherein the request message is one of a connection request message and a tracking area update request message (e.g., in EPS).

[0165] Example 16 includes the method according to Example 13 or some other embodiments herein, wherein the request message is a registration request message (e.g., in 5GS).

[0166] Example 17 includes the method according to Example 16 or some other embodiments herein, wherein the request message indicates a request to update the registration.

[0167] Example 18 includes the method according to Example 13 or some other examples herein, wherein the second offset value is a negotiated offset value.

[0168] Example 19 includes the method according to Example 13 or some other embodiments herein, wherein the first offset value is the same as the requested offset value.

[0169] Example 20 includes the method according to Example 13 or some other embodiments herein, wherein the first offset value is different from the requested offset value.

[0170] Example 21 includes the method according to any one of Examples 13 to 20 or some other embodiments herein, wherein the method includes selecting the first offset value from a predetermined set of offset values ​​or from a predetermined range of offset values. Example 21 may further include assigning a first temporary UE identifier to the UE, wherein the acceptance message includes the first temporary UE identifier.

[0171] Example 22 includes the method according to any one of Examples 13 to 21 or some other embodiments herein, wherein the requested offset value is a requested IMSI offset value, the first offset value is a first IMSI offset value, and the stored offset value is a stored IMSI offset value.

[0172] Example 23 includes the method according to any one of Examples 13 to 22 or some other embodiments herein, wherein the network element is a mobility management entity (e.g., in EPS).

[0173] Example 24 includes the method according to any one of Examples 13 to 22 or some other embodiments herein, wherein the network element is an access and mobility management function (e.g., in 5GS).

[0174] Example 25 includes a method for operating a network element, the method comprising: using a stored offset value to calculate a UE identity index value for a UE; receiving a request message from the UE, the request message including a request offset value different from the stored offset value; based on the request message, sending an acceptance message including a first offset value to the UE, and starting a timer; and based on the expiration of the timer, deciding not to update the stored offset value.

[0175] Example 26 includes the method according to Example 25 or some other embodiments herein, wherein the timer expiration indicates that the network element has not yet received a message in response to the acceptance message.

[0176] Example 27 includes the method according to Example 25 or some other embodiments herein, wherein the request message is one of a connection request message and a tracking area update request message.

[0177] Example 28 includes the method according to Example 25 or some other embodiments herein, wherein the request message is a registration request message.

[0178] Example 29 includes the method according to Example 25 or some other embodiments herein, wherein the first offset value is the same as the requested offset value.

[0179] Example 30 includes the method according to any one of Examples 25 to 29 or some other embodiments herein, wherein the method includes selecting the first offset value from a predetermined set of offset values ​​or from a predetermined range of offset values.

[0180] Example 31 includes the method according to any one of Examples 25 to 30 or some other embodiments herein, wherein the requested offset value is a requested IMSI offset value, the first offset value is a first IMSI offset value, and the stored offset value is a stored IMSI offset value.

[0181] Example 32 includes the method according to any one of Examples 25 to 31 or some other embodiments herein, wherein the network element is a mobility management entity.

[0182] Example 33 includes the method according to any one of Examples 25 to 31 or some other embodiments herein, wherein the network element is an access and mobility management function.

[0183] Example 34 includes a method of operating a base station, the method comprising: receiving from a UE a first transmission having a request message, the request message including a request offset value; transmitting to the UE a second transmission having an acceptance message, the acceptance message responding to the request message and including the first offset value; and receiving a UE identity index value based on the second offset value, and after transmitting the second transmission, sending a third transmission to the UE according to a paging timing based on the UE identity index value, wherein the second offset value is different from the first offset value.

[0184] Example 35 includes the method according to Example 34 or some other embodiments herein, wherein the method includes receiving the UE identity index value from a network element prior to receiving the first transmission.

[0185] Example 36 includes the method according to Example 34 or some other embodiments herein, wherein the request message is one of a connection request message and a tracking area update request message.

[0186] Example 37 includes the method according to Example 34 or some other embodiments herein, wherein the request message is a registration request message.

[0187] Example 38 includes the method according to Example 37 or some other embodiments herein, wherein the request message indicates a request to update the registration.

[0188] Example 39 includes the method according to Example 34 or some other examples herein, wherein the second offset value is a negotiated offset value.

[0189] Example 40 includes the method according to Example 34 or some other embodiments herein, wherein the first offset value is the same as the requested offset value.

[0190] Example 41 includes the method according to Example 34 or some other embodiments herein, wherein the first offset value is different from the requested offset value.

[0191] Example 42 includes the method according to any one of Examples 34 to 41 or some other embodiments herein, wherein the requested offset value is a requested IMSI offset value, the first offset value is a first IMSI offset value, and the second offset value is a stored IMSI offset value.

[0192] Example 43 includes a method for operating a network element, the method comprising: receiving a request message including a request offset value from a UE; sending an acceptance message including a first offset value to the UE based on the request message; and after sending the acceptance message and during a first paging cycle of the UE: paging the UE according to a first paging timing based on a first UE identity index value, wherein the first UE identity index value is based on the first offset value; and paging the UE according to a second paging timing based on a second UE identity index value, wherein the second UE identity index value is based on a second offset value, the second offset value being different from the first offset value.

[0193] Example 44 includes the method according to Example 43 or some other embodiments herein, wherein the accept message includes a temporary UE identifier.

[0194] Example 45 includes the method according to Example 43 or some other embodiments herein, wherein the method includes assigning a temporary UE identifier to the UE based on the request message, wherein the acceptance message includes the temporary UE identifier.

[0195] Example 46 includes the method according to any one of Examples 43 to 46 or some other embodiments herein, wherein the second offset value is stored by the network element prior to receiving the request message.

[0196] Example 47 includes the method according to any one of Examples 43 to 46 or some other embodiments herein, wherein: the method further includes starting a timer when the receive message is sent, and paging the UE according to a second paging timing based on the expiration of the timer.

[0197] Example 48 includes the method according to Example 47 or some other embodiments herein, wherein the timer expiration indicates that the network element has not yet received a message in response to the acceptance message.

[0198] Example 49 includes the method according to any one of Examples 43 to 48 or some other embodiments herein, wherein the request message is one of: a connection request message, a tracking area update request message (e.g., in EPS), and a registration request message (e.g., in 5GS).

[0199] Example 50 includes the method according to any one of Examples 43 to 49 or some other embodiments herein, wherein the first offset value is the same as the requested offset value.

[0200] Example 51 includes the method according to any one of Examples 43 to 49 or some other embodiments herein, wherein the method includes selecting the first offset value from a predetermined set of offset values ​​or from a predetermined range of offset values.

[0201] Example 52 includes the method according to any one of Examples 43 to 51 or some other embodiments herein, wherein the network element is a mobility management entity (e.g., in EPS) or an access and mobility management function (e.g., in 5GS).

[0202] Example 53 includes the method according to any one of Examples 43 to 52 or some other embodiments herein, wherein the requested offset value is a requested IMSI offset value, the first offset value is a first IMSI offset value, and the second offset value is a second IMSI offset value.

[0203] Example 54 includes the method according to any one of Examples 43 to 53 or some other embodiments herein, wherein the method further includes: after paging the UE according to the first paging timing and paging the UE according to the second paging timing, receiving from the UE a SERVICE REQUEST message, an EXTENDED SERVICE REQUEST message, or a CONTROL PLANESERVICE REQUEST message; and responding to the SERVICE REQUEST message, EXTENDED SERVICE REQUEST message, or CONTROL PLANESERVICE REQUEST message based on one of the first offset value and the second offset value, wherein the first offset value and the second offset value are indicated by UE identity information in the SERVICE REQUEST message, EXTENDED SERVICE REQUEST message, or CONTROL PLANESERVICE REQUEST message.

[0204] Example 55 may include an apparatus comprising one or more elements for performing the method or related to any of Examples 1 to 54 or any other method or process described herein.

[0205] Example 56 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 Examples 1 to 54.

[0206] Example 57 may include an apparatus comprising logic components, modules, or circuitry for performing one or more elements of the method described or associated with any of Examples 1 to 54 or any other method or process described herein.

[0207] Example 58 may include the methods, techniques, or processes described or associated with any of Examples 1 to 54, or parts or components thereof.

[0208] Example 59 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 a method, technique, or process, or a portion thereof, according to or related to any of Examples 1 to 54.

[0209] Example 60 may include a signal, or a portion thereof, described or associated with any of Examples 1 to 54.

[0210] Example 61 may include datagrams, information elements, packets, frames, segments, PDUs or messages, or portions or components thereof, as described or otherwise in this disclosure, according to any of Examples 1 to 54.

[0211] Example 62 may include a signal encoded with data, or a portion or component thereof, as described or associated with any of Examples 1 to 54, or otherwise described in this disclosure.

[0212] Example 63 may include a signal, or a portion or component thereof, encoded as a datagram, IE, packet, frame, segment, PDU, or message, as described or associated with any of Examples 1 to 54, or otherwise described in this disclosure.

[0213] Example 64 may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors will cause the one or more processors to perform a method, technique, or process, or a portion thereof, as described or associated with any of Examples 1 to 54.

[0214] Example 65 may include a computer program comprising instructions, wherein execution of the program by a processing element will cause the processing element to perform a method, technique, or process, or a portion thereof, as described or associated with any of Examples 1 to 54.

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

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

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

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

[0219] Unless otherwise expressly stated, any of the examples above may be combined with any other example (or combination of examples). 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 form disclosed. In light of the teachings above, modifications and variations are possible, or modifications and variations may be derived from practice of various embodiments.

[0220] Although the above embodiments have been described in considerable detail, many variations and modifications will become apparent to those skilled in the art once the disclosure is fully understood. This disclosure is intended to render the following claims as encompassing all such variations and modifications.

Claims

1. A method performed by a network element, the method comprising: Receive a request message from the user equipment (UE) including a requested offset value, the requested offset value being different from the stored offset value; Based on the request message, an acceptance message including a first offset value is sent to the UE and a timer is started; as well as In response to the failure to receive a completion message from the UE before the timer expires, the UE is paged according to a paging timing based on a stored offset value that is different from and not based on the first offset value.

2. The method of claim 1, wherein the method includes assigning a temporary UE identifier to the UE based on the request message, wherein the acceptance message includes the temporary UE identifier.

3. The method according to any one of claims 1 to 2, wherein, The request message is one of the following: Connection request message, Tracking region update request messages, and Registration request message.

4. The method according to any one of claims 1 to 2, wherein the network element is a mobility management entity or an access and mobility management function.

5. The method according to any one of claims 1 to 2, wherein: The requested offset value is the requested IMSI offset value. The first offset value is the first IMSI offset value, and The storage offset value is the storage IMSI offset value.

6. The method according to any one of claims 1 to 2, wherein the method further comprises: After paging the UE according to the paging timing, a service request message, an extended service request message, or a control plane service request message is received from the UE; as well as The system responds to the service request message, the extended service request message, or the control plane service request message based on the storage offset value, wherein the storage offset value is indicated by the UE identity information in the service request message, the extended service request message, or the control plane service request message.

7. An apparatus for wireless communication, the apparatus comprising: Processing circuit, the processing circuit being used for: Generate a request message that includes the requested offset value; Obtain an acceptance message in response to the request message and including a first offset value; In response to the accepted message, a completion message is generated; Based on the transmission failure of the completion message, monitor paging timing based on a storage offset value but not based on the first offset value, where the storage offset value differs from the first offset value. A memory coupled to the processing circuit, the memory being used to store the storage offset value.

8. The apparatus according to claim 7, wherein: The requested offset value is the requested IMSI offset value. The first offset value is the first IMSI offset value, and The storage offset value is the storage IMSI offset value.

9. The apparatus according to any one of claims 7 and 8, wherein, The received message includes a new temporary user equipment identifier.

Images