Session management back-off timer maintenance

Abstract

This disclosure provides systems, methods and apparatuses for back-off timer handling for Session Management (SM) congestion control. A UE (102) starts a back-off timer based on receiving a downlink (DL) non-access stratum (NAS) message (150) from a core network (110) indicating congestion in a data network or network slice. The DL NAS message can also cause the UE to deactivate the back-off timer. While the back-off timer is running or deactivated, the UE refrains (160) from sending further SM messages for the congested data network or slice. The UE resumes (170) a running or deactivated back-off timer following an attempt to manually reset the back-off timer which might otherwise contribute to network congestion. A core network can send a DL NAS message (180) to cause the UE to update or stop a back-off timer. The core network can provide retry parameters (186) that control UE retry behavior.

Description

SESSION MANAGEMENT BACK-OFF TIMER MAINTENANCECROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This International Application claims the benefit of priority of United States Provisional Patent Application No. 63 / 616,610 filed on December 30, 2024, the contents of which are incorporated by reference in their entirety herein.TECHNICAL FIELD

[0002] This disclosure relates generally to wireless communication and some aspects relate to handling a back-off timer for session management (SM) congestion control.BACKGROUND

[0003] This background description is provided for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.

[0004] A wireless communication system provides resources for a user equipment (UE) to access one or more network services. The wireless communication system typically includes one or more radio access networks (RANs) communicatively coupled to a core network (CN). The UE communicates via a radio connection between the UE and the RAN using access stratum (AS) protocol layers that are based on the radio access technology (RAT) of the RAN. After establishing a radio connection to the RAN, the UE can register with the core network and request network services using a non-access stratum (NAS) protocol layer. The core network manages UE access to the network services, network slices, and packet data networks using NAS protocols. Many of the AS and NAS protocols are defined by the 3rd Generation Partnership Project (3GPP) technical specifications.

[0005] A core network of a wireless communication system can implement session management (SM) to provide connectivity between a UE and various services. 3GPP supports an SM congestion control mechanism to mitigate NAS signaling congestion. The congestion control mechanism is designed to prevent a UE from sending SM related messages for a datanetwork (or network slice) when the data network is congested. When NAS signaling congestion occurs, the network instructs the UE to start a back-off timer (which may be referred to as a session management timer). While the back-off timer is active, the UE disables NAS signaling to a core network. The 3 GPP technical specifications define several types of back-off timers and congestion control messages depending on the type of core network, congestion, and UE capability. Some SM congestion controls can mitigate congestion for a specific Data Network Name (DNN). For the Evolved Packet System (EPS) or the Universal Mobile Telecommunications System (UMTS), the 3GPP describes an Access Point Name (APN) based SM congestion control mechanism including the usage of an SM level back-off timer (the UE manages NAS timer T3396 for this purpose) which is bound to an APN or no APN. An SM back-off timer prohibits the UE from sending SM signaling to the APN while the timer for that APN is running in the UE. Further details are specified in 3GPP TS 23.432 clause 4.3.7.4.2.2 and 3GPP TS 24.301 clause 6.3.5. For the 5th generation system (5GS), the 3GPP describes a DNN based congestion control, which is similar to the APN based SM congestion control plus an accounting for the usage of DNN in the 5GS. Additionally, for the 5GS, the 3GPP supports a network slice based SM congestion control mechanism based on Single Network Slice Selection Assistance Information (S- NSSAI). For DNN based congestion control, a back-off timer (referred to as T3396) is associated with a DNN regardless of the presence of an S-NSSAI (as specified in 3GPP TS 23.501 sub-clause 5.19.7.3 and 3GPP TS 24.501 sub-clause 6.2.7). The back-off timers T3396 are started and stopped on a per DNN, and per public land mobile network (PLMN) basis. For S-NSSAI based congestion control mechanism, the back-off timer (T3584 or T3585) is associated with the S-NSSAI and optionally the DNN (as specified in 3GPP TS 23.501 sub-clause 5.19.7.4 and 3GPP TS 24.501 sub-clause 6.2.8). The back-off timer referred to as T3584 is associated with an S-NSSAI and a DNN. The back-off timer referred to as T3585 is associated with the S-NSSAI regardless of the presence of a DNN.

[0006] Collectively, the T3396, T3584, and T3585 (or other timers) may be referred to as back-off timers and they function similarly to prevent NAS signaling during times of congestion. The back-off timers are started by protocol data unit (PDU) session management messages (such as PDU session establishment reject message, PDU session modification reject message, and PDU session release command). For example, the PDU sessionmanagement message includes a cause code (such as cause #26, #67, or #69) to indicate S- NSSAI congestion. The core network can optionally indicate a timer value for the back-off timer in the PDU session management message. The UE starts the back-off timer as a countdown timer initialized with the indicated timer value. While the back-off timer is running, the UE refrains from communicating NAS signaling for the DNN or network slice. When the back-off timer expires, the UE can reattempt NAS signaling. 3GPP TS 24.008 provides additional information regarding timer values that can be provided for a back-off timer. For example, the timer value can be coded as a 3 -bit value, where each combination of bit values represents a timer value (such as a number in multiples of 10 minutes, 1 hour, 10 hours, 2 seconds, 30 seconds, 1 minute, 320 hours).

[0007] As an alternative to the timer values representing a time duration, the core network can send a timer value (referred to as “deactivated”) that does not have a specific duration. The core network might indicate the timer value of “deactivated” for a back-off timer when the core network experiences a congestion of unknown duration or extent. The “deactivated” timer value informs the UE to deactivate the back-off timer for an indefinite (or infinite) time period. While the back-off timer is either running (for a duration) or in the deactivated state, the UE does not reattempt SM NAS signaling for that DNN and / or S-NSSAI.BRIEF SUMMARY

[0008] The systems, methods, and apparatuses of this disclosure each have several innovative aspects, no single one of which is solely responsible for the desirable attributes disclosed herein.

[0009] One innovative aspect of the subject matter described in this disclosure can be implemented as a method for wireless communication by a user equipment (UE). The method includes receiving a first downlink (DL) non-access stratum (NAS) message for congestion control of a first data network or network slice, starting a back-off timer for the first network or network slice based on the DL NAS message, refraining from communicating session management (SM) requests for the first data network or network slice while the back-off timer is running. The method further includes receiving a second DL NAS message that includes update information regarding the first data network or network slice and updating the backoff timer based on the update information.

[0010] Another innovative aspect of the subject matter described in this disclosure can be implemented as another method for wireless communication by a UE. The method includes receiving a first DL NAS message in response to a first SM request for a first data network or network slice, where the first DL NAS message includes congestion control information for the first data network or network slice. The method includes starting a back-off timer for the first network or network slice based on the DL NAS message and refraining from communicating SM requests for the first data network or network slice while the back-off timer is running. The method further includes transmitting one or more uplink (UL) NAS messages to retry the first SM request after expiration of the back-off timer based on retry parameters being satisfied.

[0011] Another innovative aspect of the subject matter described in this disclosure can be implemented as another method for wireless communication by a UE. The method includes receiving a first DL NAS message for congestion control of a first data network or network slice, starting a back-off timer for the first network or network slice based on the DL NAS message, and refraining from communicating SM requests for the first data network or network slice while the back-off timer is running. The method further includes storing a status of the back-off timer in a non-volatile memory of the UE while the back-off timer is running with a timer value or deactivated state, and restoring the back-off timer to the status in the non-volatile memory following a restart operation of the UE.

[0012] Another innovative aspect of the subject matter described in this disclosure can be implemented as a method for wireless communication by a core network. The method includes transmitting a first DL NAS message to a UE based on congestion control of a first network or network slice, where the DL NAS message indicates a timer value for a back-off timer is deactivated. The method further includes transmitting a second DL NAS message that includes update information regarding network congestion of the first data network or network slice. Additionally, or alternatively, the second DL NAS message can include retry parameters that indicate when the UE is permitted to retry the first SM request via one or more subsequent UL NAS messages after the back-off timer is stopped or expired.

[0013] Another innovative aspect of the subject matter described in this disclosure can be implemented as an apparatus that includes a communication unit and a processing systemconfigured to control the communication unit to implement any one of the above-referenced methods.

[0014] Details of one or more implementations of the subject matter described in this disclosure are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages will become apparent from the description, the drawings, and the claims.BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Like reference numbers and designations in the various drawings indicate like elements. Note that the relative dimensions of the figures may not be drawn to scale. To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced.

[0016] FIG. 1A illustrates an example wireless communication system implementing a deactivated back-off timer for session management congestion control.

[0017] FIG. IB illustrates an example wireless communication system supporting various networks and network slices.

[0018] FIG. 2A illustrates an example control plane protocol stack in which the example wireless communication system of FIG. 1A is a 5th generation system (5GS).

[0019] FIG. 2B illustrates an example control plane protocol stack in which the example wireless communication system of FIG. 1A is a 4th generation system evolved packet system (EPS).

[0020] FIG. 3 shows an example message flow diagram and example problems with existing back-off timer handling.

[0021] FIG. 4A shows an example message flow diagram and example operations for backoff timer maintenance in which the core network can update a back-off timer.

[0022] FIG. 4B shows an example message flow diagram and example operations in which the core network can provide retry parameters with an initial congestion notification.

[0023] FIG. 5A shows example operations for back-off timer maintenance in which the core network can update a back-off timer, such as described with reference to FIG. 4A.

[0024] FIG. 5B shows example operations for back-off timer maintenance in which the core network provides retry parameters, such as described with reference to FIG. 4A or FIG. 4B.

[0025] FIG. 6 shows example operations of a core network in which the core network can update a back-off timer.

[0026] FIG. 7A shows an example message flow diagram and example operations for backoff timer handling in which the back-off timer is restored after the UE restarts.

[0027] FIG. 7B shows an example message flow diagram and example operations in which a timer applicability indication informs the UE whether to restore the back-off timer.

[0028] FIG. 8 shows example operations for back-off timer maintenance after a UE restart, such as described with reference to FIG. 7A and FIG. 7B.

[0029] FIG. 9 is a block diagram of an example wireless communication system showing hardware features and communication interfaces.DETAILED DESCRIPTION

[0030] The following description is directed to certain implementations for the purpose of describing innovative aspects of this disclosure. However, a person having ordinary skill in the art will readily recognize that the teachings herein can be applied in a multitude of different ways. Some of the examples in this disclosure are based on wireless communication according to the 3rd Generation Partnership Project (3GPP) wireless standards, such as the 4th generation (4G) Long Term Evolution (LTE) and 5th generation (5G) New Radio (NR) standards. However, the described implementations can be implemented in any device, system, or network that is capable of transmitting and receiving radio frequency signals according to any of the wireless communication standards, including any of the Institute of Electrical and Electronics Engineers (IEEE) 802.11 or 802.16 wireless standards, or other known signals that are used to communicate within a wireless, cellular, or internet of things (loT) network, such as a system utilizing 4G, 5G, WiFi, or future radio technology.

[0031] As stated above, session management (SM) congestion control enables a core network to mitigate non-access stratum (NAS) signaling congestion for a data network or a network slice. A data network can be identified by a Data Network Name (DNN) or Access Point Name (APN). A network slice can be identified based on Single Network Slice Selection Assistance Information (S-NSSAI). The core network can send a downlink (DL) NASmessage to a user equipment (UE) to instruct the UE to refrain from sending NAS signaling for a DNN / APN or S-NSSAI. The DL NAS message includes congestion control information (such as a cause code and / or a timer value) to cause the UE to start a back-off timer for a DNN / APN or S-NSSAI. The DL NAS message can indicate a timer value for the back-off timer. If the core network communicates a timer value for the back-off timer, either due to congestion or due to a reason other than congestion, the UE applies the received timer value to one of various SM back-off timers (such as the T3396, T3584 or T3585 back-off timers). In some cases, the core network can indicate the timer value “deactivated” for a back-off timer to cause the UE to deactivate the back-off timer for a DNN / APN and / or S-NSSAI. While the back-off timer is running or deactivated, the UE does not send another request for that DNN / APN and / or S-NSSAI.

[0032] A running back-off timer expires after a duration of an indicated timer value. A deactivated back-off timer might run indefinitely, until the back-off timer is reset. When a UE deactivates a back-off timer, some documents refer to the deactivated back-off timer as being running (or started) because the UE is prevented from transmitting uplink (UL) NAS messages for a DNN / APN or S-NSSAI when the back-off timer is running. Alternatively, or additionally, the back-off timer is referred to as being deactivated which has the same effect as a running back-off timer except that a deactivated back-off timer runs indefinitely without an expiration time. Conversely, when a UE resets a deactivated back-off timer, the UE stops the back-off timer, which has the effect of allowing the UE to proceed with subsequent UL NAS messages that would otherwise be prevented during a running back-off timer.

[0033] The current techniques for handling a back-off timer can lead to unexpected problems. For example, a user of a UE might attempt to manually reset a running or deactivated back-off timer. The back-off timer might be reset following a manual user action, such as a power cycle, universal subscriber identity module (USIM) removal and reinsertion, change of USIM, or turning on and off the airplane mode. After restarting the UE to reset the back-off timer, the UE might attempt additional SM NAS signaling, possibly resulting in additional congestion. This user behavior might be repeatedly performed, or performed by users of multiple UEs, causing further congestion and delaying recovery of network congestion. Another problem can occur when a UE has a deactivated back-off timer that cannot be reset by manual interaction, including power cycling, removing and replacing aUSIM, or cycling an airplane mode. Some types of UEs may be unable to trigger such events due to lack of user interaction. For example, some UEs (e.g., Machine Type Communication (MTC) type devices or Internet of Things (loT) devices) are designed to run autonomously and may not have a removeable USIM nor the ability to cycle through an airplane mode or a power mode. A UE running a deactivated back-off timer might be unable to send another SM request to the same DNN / APN and / or S-NSSAI until a manual intervention to reset the deactivated back-off timer (e.g., by removing and reinserting a power source such as a battery or capacitor). Yet another problem is that some existing techniques for a core network to update or stop a deactivated back-off timer require the UE to already have a previously established session connection with the DNN / APN or S-NSSAI. The core network can reset a deactivated back-off timer by transmitting a DL NAS message for an already-established protocol data unit (PDU) session or packet data network (PDN) connection to the DNN / APN or S-NSSAI. However, if the UE does not have a previously established PDU session or PDN connection before the back-off timer is deactivated, there is no existing technique for the core network to inform the UE to stop or update the back-off timer for the DNN / APN or S- NSSAI. These, and other problems, are a result of inadequate or inconsistent implementations of back-off timer handling.

[0034] This disclosure provides systems, methods and apparatuses for back-off timer handling. In some aspects, a UE resumes a running or deactivated back-off timer following an attempt to manually reset the back-off timer by restarting the UE. The UE can maintain the back-off timer state in non-volatile memory so that the UE can restore the back-off timer(s) that were running or deactivated before the UE is restarted. By maintaining the backoff timer state regardless of power cycling or other attempted manual circumvention, the UE can prevent contributing to congestion. Some aspects of this disclosure enable a core network to control how the UE can update or stop a back-off timer. After congestion is resolved, the core network can send a DL NAS message to cause the UE to update or stop a back-off timer.

[0035] In some aspects, the core network can provide retry parameters to the UE in a DL NAS message (such as the DL NAS message that initially triggers a back-off timer or that updates / stops the back-off timer). The retry parameters control how the UE proceeds with subsequent SM messaging after a back-off timer stops. When the back-off timer expires or is stopped by a core network DL NAS message, the UE can assess the retry parameters todetermine whether, or when, to initiate subsequent SM operations. As an example, the retry parameters might indicate whether the UE can proceed with SM operations A) immediately after the back-off timer expires, B) based on an exponentially increasing wait time for each retry, C) based on a linearly increasing wait time, or D) after a random time period following each previous retry or back-off timer expiration. In some implementations, the retry parameters indicate a time range such that the UE can retry SM operations after a random time within the indicated time range.

[0036] Particular implementations of the subject matter described in this disclosure can be implemented to realize one or more of the following potential advantages. A network operator can achieve congestion control without the potentially adverse impacts of one or multiple UEs repeatedly restarting to circumvent the desired congestion management. UE can have better information and guidance from the core network regarding when to perform retry attempts and how to handle SM operations after back-off timers expire. A core network can also provide update information to update or stop a back-off timer based on changes to network congestion. In some implementations, the disclosed techniques provide a mechanism for stopping or updating a deactivated back-off timer that might run indefinitely for some types of UEs, such as for MTC or loT devices that cannot be readily manually reset.

[0037] In this disclosure, several example scenarios are discussed with reference to various figures. Generally speaking, similar events in the figures are labeled with the same or similar reference numbers, with differences discussed where appropriate. With the exception of the differences shown in the figures and discussed below, any of the alternative implementations discussed with respect to a particular event (e g., for messaging and processing) may apply to events labeled with similar reference numbers in other figures. Some examples of this disclosure are based on a 5G Session Management (5GSM) protocol for a 5G system. However, the techniques can also be used in a 4G system or earlier, including Evolved Packet System (EPS) and EPS Session Management (ESM).

[0038] FIG. 1A illustrates an example wireless communication system 100 implementing a deactivated back-off timer for session management congestion control. While FIG. 1A describes an example architecture of a wireless communication system, other architectures are possible. The example wireless communication system 100 includes a UE 102, a base station (BS 106), and a core network (CN 110). The CN 110 can be an evolved packet core(EPC 1 1 1) or a fifth generation (5G) core (5GC 1 12), for example. Alternatively, the CN110 might be a sixth generation (6G) core. The BS 106 operates a radio access network (RAN) and is connected to the CN 110. The BS 106 and the CN 110 belong to a Public Land Mobile Network (PLMN). The BS 106 can be a terrestrial base station, and the PLMN may be referred to as a terrestrial network (TN). Alternatively, the PLMN can be a non-terrestrial network (NTN) and the BS 106 might employ NTN technology. For example, the BS 106 can be communicatively coupled, or integrated, with an airborne or spaceborne vehicle.

[0039] In general, a RAN can include any number of base stations, and each of the base stations can cover one, two, three, or any other suitable number of cells. The BS 106 operates a cell (not shown) providing wireless signal coverage for the UE 102. If the BS 106 is a gNodeB (gNB), the cell is an NR cell. If the BS 106 is a next generation evolved node B (ng- eNB) or eNB, the cell is an evolved universal terrestrial radio access (E-UTRA) cell. The UE 102 can support at least a 5G NR (or simply, “NR”) or E-UTRA air interface to communicate with the BS 106. The base station 106 can connect to the CN 110 via an interface (e.g., SI or NG interface 107). The BS 106 and other base stations (not shown) in a RAN also can be interconnected via an interface (e.g., X2 or Xn interface) for interconnecting RAN nodes. The UE 102 can have a radio connection to the BS 106 via a user interface (e.g., Uu interface 105). The Uu interface 105 also can be referred to as an access stratum (AS). The non-access stratum (NAS) includes communications between the UE 102 and the CN 110, where the communications traverse both the Uu interface 105 and the Sl / NG interface 107.

[0040] Among other components, the EPC 111 may include a Serving Gateway (SGW) 115, a Mobility Management Entity (MME) 113, and a Packet Data Network Gateway (PGW) 117. The SGW 115 in general is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., and the MME 113 is configured to manage authentication, registration, paging, and other related functions. The PGW 117 provides connectivity from the UE to one or more external packet data networks, e.g., an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. The EPC111 may include other MME, SGW and / or PGW not shown in FIG. 1A. The 5GC 112 includes a User Plane Function (UPF) 1 18 and an Access and Mobility Management Function (AMF) 114, and / or Session Management Function (SMF) 116. The UPF 118 is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., the AMF 114 isconfigured to manage authentication, registration, paging, and other related functions, and the SMF 116 is configured to manage PDU sessions. The 5GC 112 may include other AMF, SMF and / or UPF not shown in FIG. 1A.

[0041] Generally speaking, a base station operating a RAN communicates with a UE using a certain radio access technology (RAT) and multiple layers of a protocol stack. For example, the physical layer (PHY) of a RAT provides transport channels to the Medium Access Control (MAC) sublayer, which in turn provides logical channels to the Radio Link Control (RLC) sublayer, and the RLC sublayer in turn provides data transfer services to the Packet Data Convergence Protocol (PDCP) sublayer. The Radio Resource Control (RRC) sublayer is disposed above the PDCP sublayer. The RRC sublayer specifies an RRC IDLE state, in which a UE does not have an active radio connection with a base station and does not store a UE access stratum context; an RRC_CONNECTED state, in which the UE has an active radio connection with the base station; and an RRC INACTIVE state to allow a UE to more quickly transition back to the RRC_CONNECTED state due to Radio Access Network (RAN)-level base station coordination and RAN-paging procedures. Depending on different implementations or scenarios, the base station can configure Small Data Transmission (SDT) for the UE operating in the RRC INACTIVE state to transmit one or more small packets.

[0042] After the UE 102 registers with CN 110, a CN node of the CN 110 manages UE parameters while the UE 102 is registered to the CN 110. In case of the EPS, the CN node is MME 113; and in case of the 5GS, the CN node is AMF 114. In addition to the AMF 114, the SMF 116 can serve as a CN node to implement part of a NAS layer. For brevity, this disclosure refers to operations of the CN node (or just core network) to represent operations that might be performed by the MME 113, the AMF 114, or the SMF 116. The CN node uses a Tracking Area Update (TAU) procedure as described in 3GPP TS 24.301 for the Evolved Packet System (EPS), or Registration procedure and UE Configuration Update (UCU) procedure as described in 3GPP TS 24.501 for 5G System (5GS). If the UE is in idle mode, the CN node pages the UE for a transition to connected mode. While the UE is in connected mode, the CN node updates the UE parameter during the TAU procedure (EPS) or the registration procedure (5GS) by including updated parameters in a NAS accept message. In the case of the EPS, NAS accept message is a TAU Accept message, and in case of the 5GS the NAS accept message is a Registration Accept message. The CN node also triggers the UEto initiate the TAU procedure by sending a globally unique temporary identity (GUTI) reallocation command message with non-broadcast tracking area identity (TAI) (EPS), or provides updated parameters using UCU procedure while the UE is in connected mode (5GS).

[0043] 5th generation system (5GS) networks are packet-switched internet protocol (IP) networks. The 5GS supports network slicing to manage distributed resources from multiple network elements. Each 5GS network slice dynamically includes isolated resources from various subnets (such as a 5G new radio (NR) radio access network (RAN) subnet, 5G core network subnet, transport subnet, and so on) to create a logical end-to-end network with specific network capabilities. The 3GPP technical specification (TS) 22.261 recites network slicing requirements. Each network slice serves a particular service type with an agreed upon Service-level Agreement (SLA). Single network slice selection assistance information (S- NSSAI) identifies a network slice.

[0044] The CN 110 (e.g., CN Node) can implement a session management (SM) protocol to coordinate access between a UE and a PDN (not shown). For example, in the 5GS, the UPF 118 connects the CN 110 to a PDN. The AMF 114 and the SMF 116 implement NAS layer to manage PDU sessions between the UE 102 and the PDN or a network slice that includes a connection to the PDN. In an EPS, the PGW 117 provides connectivity to a PDN and the MME 113 implements the NAS layer at the EPC 111. FIG. 2A and FIG. 2B provide additional detail regarding the NAS layer implementations in a 5GC 112 and EPC 111, respectively.

[0045] Congestion control mechanisms are designed to mitigate NAS signaling congestion associated with SM messages. When the network determines that one or more entities related to a specific DNN (APN), e.g., SMF or P-GW, are congested or overloaded, the CN node might take one of the following actions:• reject an SM request received from the UE (e.g., PDU session establishment request or PDU session modification request) with a cause value and optionally a back-off (BO) timer value.• release the PDU session (e.g., sending a PDU session release command) with a cause value and optionally a back-off timer value.• send a DL NAS TRANSPORT message indicating 5GSM message was not forwarded due to congestion control (i.e., 5GMM cause #22 "Congestion," #67 "insufficientresources for specific slice and DNN," cause #69 "insufficient resources for specific slice") and optionally a back-off timer value.

[0046] The back-off timer value can be set to:• A period (i.e., neither zero nor “deactivated”): In this case the UE is not allowed to send the corresponding 5GSM messages (i.e., PDU session establishment request, PDU session modification request) until the timer is expired / stopped. The UE still maintains the timer during the power cycle.• Zero: In this case the UE may retry sending the corresponding 5GSM message immediately.• Deactivated: In this case the UE is not allowed to send the corresponding 5GSM messages until o The UE is switched off, o The USIM is removed (or Standalone Non-Public Network (SNPN) entry is updated), or o The UE receives a corresponding 5GSM message (e.g., PDU session modification command, PDU session authentication command, PDU session release command).

[0047] If the back-off timer is not provided by the network, the UE behavior is the same as when the back-off timer value is set to zero.

[0048] In the example shown in FIG. 1A, the CN 110 rejects any SM request message for the congested DNN or APN from the UE with a DL NAS message 150 that includes a cause code (such as cause value #26 representing “insufficient resources”). In some implementations, the DL NAS message 150 is a PDU session establishment reject message, a PDU session modification reject message, or a PDU session release command (collectively referred to as “PDU session management message”) or any NAS message that includes a cause code or back-off timer value indicating the NAS signaling congestion. The DL NAS message 150 causes the UE to start a back-off timer (which may be referred to as a session management timer) to prevent the UE from communicating NAS signaling while the back-off timer is active. The DL NAS message 150 can indicate a DNN / APN and / or an S-NSSAI information element to prompt the UE to start a back-off timer for a particular data network or network slice.

[0049] The CN node can store an APN / DNN congestion back-off time on a per UE and congested APN / DNN basis. In the UE 102, a backoff timer (such as NAS timer T3396) for APN based congestion control is started and stopped on a per APN basis. The UE shall not send another SM request message for an existing session or to establish a new session associated with the congested APN / DNN, while the timer T3396 is running. There are some exceptions, including emergency, high priority access or PS data off status report.

[0050] For S-NSSAI based congestion control, similar principles apply, i.e., the network provides a timer value for back-off and the UE is prohibited to send an SM request while the back-off timer is running. The difference from DNN / APN based congestion control is that S- NSSAI based congestion control associates an S-NSSAI and optionally a DNN with the backoff mechanism. When S-NSSAI based congestion control applies, the network provides a back-off timer value for a back-off timer which is associated with an S-NSSAI, or a back-off timer value associated with an S-NSSAI and a DNN. When the network determines that one or more entities related to a specific S-NSSAI are congested or overloaded, the network node might reject any SM request message associated with the congested S-NSSAI from the UE with the SM cause value #69 "insufficient resources for specific slice". In the UE, 5GSM timers T3585 for the S-NSSAI based congestion control are started and stopped on a per S- NSSAI and PLMN or SNPN basis. When the network determines that one or more entity related to a specific S-NSSAI and DNN combination is congested or overloaded, the network node might reject any SM request message associated with the congested S-NSSAI and DNN from the UE with the SM cause value #67 “insufficient resources for specific slice and DNN.” In the UE, 5GSM timers T3584 for the S-NSSAI based congestion control are started and stopped on a per S-NSSAI, DNN, and PLMN or SNPN basis.

[0051] The CN node can include a back-off timer value in a session management reject message to regulate the time interval at which the UE may retry the same procedure for a variety of SM cause values: #26 “insufficient resources,” #28 “unknown PDU session type,” #39 “reactivation requested,” #46 “out of LADN service area,” #50 “PDU session type IPv4 only allowed,” #51 “PDU session type IPv6 only allowed,” #54 “PDU session does not exist,” #57 “PDU session type IPv4v6 only allowed,” #58 “PDU session type Unstructured only allowed,” #61 “PDU session type Ethernet only allowed,” #67 “insufficient resources forspecific slice and DNN,” #68 “not supported SSC mode,” and #69 “insufficient resources for specific slice.”

[0052] For 5GSM cause values other than #26 “insufficient resources,” #28 “unknown PDU session type,” #39 “reactivation requested,” #46 “out of LADN service area,” #54 “PDU session does not exist,” #67 “insufficient resources for specific slice and DNN,” #68 “not supported SSC mode,” #69 “insufficient resources for specific slice,” and #86 “UAS services not allowed,” the network may also include the re-attempt indicator to indicate whether the UE is allowed to re-attempt the corresponding session management procedure for the same DNN in SI mode after inter-system change. The UE 102 can maintain various back-off timers associated with a DNN or an APN, which are started and stopped on a per DNN and / or S- NSSAI basis based on the cause value or time values included in the DL NAS message 150.

[0053] The CN node can indicate a timer value for one of the back-off timers (e.g., the Backoff timer, T3396, T3584 or T3585) using an information element (IE) in the DL NAS message 150. The coding of timer values can follow a “GPRS timer3" type defined in 3GPP TS 24.008 (section 10.5.7.4a). The purpose of the GPRS Timer 3 IE is to specify GPRS specific timer values, e.g., for the timer T3396. The GPRS timer 3 is a type 4 information element with 3 octets length. The GPRS timer 3 information element is coded as shown below (Table 1 and Table 2, from 3GPP TS 24.008, Figure 10.5.147a and table 10.5.163a, respectively):8 7 6 5 4 3 2 1 octet 1 octet 2 octet 3Table 1Table 2

[0054] Based on a DL NAS message 150, the UE 102 starts a back-off timer for a DNN / S- NSSAI. While the back-off timer is running the UE 102 refrains 160 from transmitting SM signaling to the CN 110 for that DNN / S-NSSAI. In some scenarios, the DL NAS message150 can include a cause or back-off timer value that causes the UE 102 to “deactivate” a backoff timer. A deactivated back-off timer might also be referred to as “running” with a deactivated time value. In some implementations, the DL NAS message 150 includes a backoff timer value that represents “deactivated.” In some implementations, the cause code in the DL NAS message 150 is sufficient to inform the UE 102 to start the back-off timer with a “deactivated” timer value.

[0055] If the UE 102 receives a timer value in the DL NAS message 150 from the CN node, the UE 102 starts one of the back-off timers according to the cause value, e.g., start T3396 for SM cause #26, start T3584 for SM cause #67, start T3585 for SM cause #69, or Back-off timer for other SM causes. If the received timer value is 0, the UE can retry to send SM request without any back-off. If the received value is any binary value, the UE sets the timer with the value and starts the timer, and is prohibited to send another request for the same DNN and / or S-NSSAI. If the received timer value indicates that the timer is “deactivated,” the UE shall not send another request for the same DNN and / or S-NSSAI, until the timer is reset due to some events, e.g., power cycle, USIM removal and reinsert, change of USIM, or turning on and off the airplane mode. If the UE receives specific cause code that requires back-off but without a timer value, the UE may start a timer with a default value, or a random value within a pre-defined range.

[0056] Typically, the running (or deactivated) back-off timer is stopped when the UE 102 receives a subsequent DL NAS message that indicates the same DNN / S-NSSAI. For example, the subsequent DL NAS message might be a PDU SESSION AUTHENTICATION COMMAND message, a PDU SESSION MODIFICATION COMMAND message, a PDU SESSION MODIFICATION REJECT message or a PDU SESSION RELEASE COMMAND message. In each of these examples, the subsequent DL NAS message assumes that the UE 102 already has an established PDU session. However, that might not always be the case, such as when the DL NAS message 150 is a PDU SESSION ESTABLISHMENT REJECT message and the UE 102 does not have a previously established PDU session.

[0057] In accordance with aspects of this disclosure, the UE 102 maintains a status of a running or deactivated back-off timer for a DNN / S-NSSAI even when the UE has a restart operation, such as when a user attempts to manually reset the UE. Examples of restart operations include powering up the UE after a power cycle, initializing a radio interface afterinsertion of a USIM, or reinitializing the radio interface after having the radio interface disabled by a user interface. In some implementations, the UE maintains the status of the back-off timer in a non-volatile memory and resumes a previously stored state after the restart operation. The UE 102 reinitializes the back-off timer for a DNN / S-NSSAI based on the stored status (which might be a remaining duration of the backoff timer value or might indicate the timer value of “deactivated”). In the example shown in FIG. 1A, the back-off timer resumes (170) in the deactivated state after the restart operation.

[0058] In some aspects, the CN 110 can send a second DL NAS message 180 to update a running or deactivated back-off timer. For example, the second DL NAS message 180 can include a new timer value for the back-off timer. Alternatively, the DL NAS message 180 can indicate the same timer value but update the back-ff timer to restart with the timer value. For example, if the first DL NAS message 150 indicated a timer value of 1 hour, and after some period of time (such as 45 minutes) the CN 110 determines that the congestion will continue for yet another hour, the CN 110 can indicate 1 hour as the timer value in the second DL NAS message 180 to cause the UE 102 to restart the back-off timer with a 1 hour timer value.

[0059] In the example of FIG. 1A, the first DL NAS message 150 indicated a timer value of “deactivated” so the UE 102 might indefinitely have the back-off timer deactivated until receiving the second DL NAS message 180 with a different timer value other than “deactivated.” Thus, the CN 110 can use the second DL NAS message 180 to cause the UE 102 to stop the deactivated back-off timer and resume SM operations for the data network or network slice.

[0060] In some aspects, the CN 110 can send retry parameters 186 (either in the DL NAS message 180 or the DL NAS message 150) that inform the UE 102 when it can retry an SM request that was previously rejected. The retry parameters might be based on a fixed or random time after the back-off timer is stopped or expired. In some implementations, the retry parameters include variable time durations that increase depending on the quantity of retries that the UE 102 has performed.

[0061] FIG. IB illustrates an example wireless communication system supporting various networks and network slices. As described with reference to FIG. 1 A, a CN 110 can operate a PLMN associated with one or more RANs. One PLMN might be referred to as a HomePLMN (HPLMN). In the example illustrated in FIG. IB, the UE 102 can have a subscription for HPLMN 103 that includes one or more base stations (such as BS 106 of FIG. 1A). The mobile network operator (MNO) 101 can also permit roaming on other PLMNs, referred to as a Visited PLMN (VPLMN). Thus, the UE 102 might roam to other VPLMNs (for example, VPLMNs 109A to 109N). Additionally, the UE 102 can be configured for operation using one or more network slices provisioned by the MNO 101 on VPLMNs 109A-109N and / or HPLMN 103. During roaming situations, available / authorized slices may be specified by a CN node (such as the AMF 114 of FIG. 1A).

[0062] During operation of UE 102, the RAN to which UE 102 is currently registered may experience congestion, and begin congestion control procedures. Each of the VPLMNs 109A- 109N and / or HPLMN 103 can be associated with the data network 140 or different data networks. Each data network can be identified by a different DNN or APN. In a 5GS, the VPLMNs 109A-109N and / or HPLMN 103 can operate various network slices, each of which are identified by a different S-NSSAI. Using the congestion control mechanisms of this disclosure, a CN 110 can cause the UE 102 to start or deactivate a back-off timer for a particular DNN, APN, or S-NSSAI.

[0063] FIG. 2A illustrates an example control plane protocol stack in which the example wireless communication system of FIG. 1A is a 5GS. FIG. 2 A shows the control plane protocol stack 200 A for the UE 102, the BS 106, the AMF 114 and the SMF 116. The 5G access network can include 5GNR (where the BS 106 is referred as a gNB) or EUTRA (where the BS 106 is referred to as an eNB).

[0064] The protocol layers between the UE 102 and the BS 106 include a physical (PHY) sub-layer that provides transport channels. A media access control (MAC) sub-layer provides logical channels for a radio link control (RLC) sub-layer. The RLC sublayer in turn provides data transfer services to the PDCP sublayer. The PDCP sublayer in turn can provide data transfer services to a radio resource control (RRC) sublayer. For a 5GC, the protocol layers between the BS 106 and the core network include a layer 1 (LI) sub-layer, layer 2 (L2) sublayer, an Internet protocol (IP) sub-layer, Stream Control Transmission Protocol (SCTP) sublayer, and Next Generation Application Protocol (NGAP) sub-layer. The AMF 114 and the SMF 116 can implement any variety of protocol layers (shown as Ni l) to manage communication via the Ni l interface between them.

[0065] Aspects of this disclosure are related to the NAS communications between the UE 102 and the core network (such as a 5GC). Generally speaking, a NAS protocol manages the UE’s mobility, session, and control plane signaling between the UE 102 and the CN 110, transparent to any 5G access network node (e.g., BS 106). In some aspects, the core network implements various discrete control plane functions (shown as the AMF 114 and the SMF 116). Together the AMF 114 and the SMF 116 can implement portions of the NAS layer. The AMF 114 can provide mobility management (MM) aspects of the NAS layer while the SMF 116 can provide SM aspects of the NAS layer. The UE 102 communicates with a SMF 116 via NAS messages that are first sent to the AMF 114. The AMF 114 is responsible for managing the UE’s mobility and connection to the CN 110. Also, any upper layer control signal can be delivered over the NAS layer between the AMF 114 and the UE 102, which is also called the NAS-MM layer. The SMF 116 is responsible for managing PDU sessions, and a UE 102 can be associated with one or more SMFs 116 at the same time. The NAS protocol between the UE 102 and the SMF 116 is also called NAS-SM layer. The AMF 114 and the UE 102 communicate with each other via a logical interface referred to as the N1 control interface. The N1 control interface is a logical interface that traverses the Uu interface 105 (Nr-Uu when the BS 106 is a gNB) and the Sl / NG interface 107 (sometimes referred to as the NG-C or N2 interface in a 5GC).

[0066] FIG. 2B illustrates an example control plane protocol stack in which the example wireless communication system of FIG. 1A is a 4th generation system evolved packet system (EPS). The control plane protocol stack 200B of the EPS is similar to the control plane protocol stack 200 A described with reference to FIG. 2B. Some nomenclature differences between FIG. 2B and FIG. 2A include: the BS 106 is shown as a EUTRA base station (eNB), the Uu interface 105 is labeled as an LTE-Uu interface, and the S l / NG interface 107 is referred to as an SI -MME interface. In the EPS, the MME 113 serves as a single endpoint for the NAS protocol in the core network. The MME 113 is responsible for both mobility management and session management aspects, although SM related protocols are assumed to be upper to MM related protocols.

[0067] Aspects of this disclosure are related to the NAS protocol and can be applied to either the 5GS (FIG. 2A) or EPS (FIG. 2B). For avoidance of doubt, in this disclosure when referring to UL NAS messages, the UL NAS message is communicated from the UE 102 toany of the NAS endpoints in the core network (such as the SMF 1 16, the AMF 1 14, or the MME 113). DL NAS messages are communicated to the UE 102 from the AMF 114, the SMF 116, or the MME 113. The SMF 116 is responsible for handling SM requests and responses and can implement congestion control based on a DNN / S-NSSAI managed by the SMF 116. In some instances, the AMF 114 can also identify a congestion of a DNN / S-NSSAI and can implement congestion control by responding to the UE 102 without relaying an SM request to the SMF 116.

[0068] FIG. 3 shows an example message flow diagram 300 and example problems with existing back-off timer handling. The flow diagram 300 shows NAS signaling between a UE 102 and CN 110. Here, the functions and messages of the CN 110 can include any type of CN Node, such as an AMF, SMF, or MME, or a new entity for a later generation of wireless communication system. FIG. 3 is provided to explain some example problems 301 and 302 with current back-off timer handling procedures.

[0069] The CN 110 might determine that an SM congestion control is needed for a DNN and / or S-NSSAI, e.g., the relevant data network entity is overloaded or about to be overloaded (e.g., the load level comes over a threshold). At the outset of FIG. 3, the CN 110 has already determined to apply the SM congestion control mechanism for the DNN and / or S-NSSAI. Whilst under this condition, if the UE 102 sends a UL NAS message 340 (such as an UL SM NAS request) for the DNN and / or S-NSSAI under the congestion control, the CN 110 might reject the SM request by sending a DL NAS message 350 indicating congestion information. For example, the DL NAS message 350 might include a cause value and / or back-off timer value to inform the UE 102 about the congestion and to cause the UE 102 to back off from SM signaling for the congested data network or network slice. For some cause value, the CN 110 might include a timer value for a back-off timer. In addition to enumerated back-off timer values (e.g., 10 minutes, 1 hour, 10 hours, 2 seconds, 30 seconds, 1 minute, 320 hours), a timer value might be set to “deactivated” to deactivate a back-off timer for an indefinite period.

[0070] In some implementations, the CN 110 might determine to reject the UL SM NAS request for reasons other than congestion, as specified in 3GPP TS 24.301 or 3GPP TS 24.501. The CN 110 might reject the SM request by sending a DL SM NAS message (DL NASmessage 350), with an SM cause value. For some cause values, the CN 110 might include a timer value for a back-off timer, which might be set to “deactivated.”

[0071] In some implementations, if the CN 110 is a 5GC 112, the AMF of the CN 110 might reject an SM request by sending an DL MM NAS message, with a MM cause value due to the congestion in DNN and / or S-NSSAI. Thus, the DL NAS message 350 might be a DL SM NAS message (from an SMF) or a DL MM NAS message (from the AMF). In some implementations, the DL NAS message 350 is a DL NAS TRANSPORT message. In some implementations, the CN 110 might proactively send a DL NAS message 350, e.g., PDU session release command, with a cause value and / or a timer value for a back-off timer due to congestion.

[0072] After the UE 102 receives the DL NAS message 350 which is a reject message with a SM cause value or an MM cause value, the UE can start a back-off timer (block 352). If the DL NAS message 350 includes a back-off timer value, the UE 102 applies the back-off timer value to the corresponding NAS back-off timer. In some implementations, the NAS timer is timer T3396, T3584, or T3585 if the cause value is the 5GSM cause value #26 “insufficient resources,”, #67 “insufficient resources for specific slice and DNN,” or #69 “insufficient resources for specific slice,” respectively. In some implementations, the NAS timer is timer T3396, T3584, or T3585 if the cause value is the 5GMM cause value #22 “Congestion,” #67 “insufficient resources for specific slice and DNN,” cause #69 “insufficient resources for specific slice,” respectively. In other implementations, the NAS timer is the back-off timer if the SM cause value is different from #26 “insufficient resources,” #28 “unknown PDU session type,” #39 “reactivation requested,” #46 “out of LADN service area,” #50 “PDU session type IPv4 only allowed,” #51 “PDU session type IPv6 only allowed,” #54 “PDU session does not exist,” #57 “PDU session type IPv4v6 only allowed,” #58 “PDU session type Unstructured only allowed,” #61 “PDU session type Ethernet only allowed,” #67 “insufficient resources for specific slice and DNN,” #68 “not supported SSC mode,” #69 “insufficient resources for specific slice,” #86 “UAS services not allowed,” and #33 “requested service option not subscribed,” when the CN 110 is a 5GC. In yet other implementations, the NAS timer is the Back-off timer if the SM cause value is different from #26 “insufficient resources,” #28 “unknown PDN type,” #50 “PDN type IPv4 only allowed,” #51 “PDN type IPv6 only allowed,” #54 “PDN connection does not exist,” #57 “PDN type IPv4v6 only allowed,” #58“PDN type non TP only allowed,” #61 “PDN type Ethernet only allowed,” #65 “maximum number of EPS bearers reached,” and #66 “requested APN not supported in current RAT and PLMN combination,” when the CN 110 is an EPC.

[0073] After the UE 102 starts (or deactivates) the back-off timer, the UE refrains (block 360) from sending any SM request to same DNN and / or S-NSSAI while the back-off timer is running. If the back-off timer is “deactivated” (i.e., running with deactivated state), the UE 102 does not send any request for the DNN and / or S-NSSAI until the back-off timer is reset. Traditional techniques for resetting the back-off timer might include manual intervention, such as power cycle, USIM removal and reinsert, change of USIM, or turning on and off the airplane mode. However, such techniques might not be convenient or even possible for some types of UEs such devices designed for MTC or loT applications.

[0074] FIG. 3 shows some example problems that can occur with the current back-off timer handling. In a first example problem 301, the UE 102 might have a back-off timer remain in deactivated state for an indefinite (or infinite) period of time (arrow 364 shows the UE 102 loops to block 360 without a possibility of the deactivated back-off timer expiring - particularly when manual UE restart is not possible or ineffective and when the UE does not have an existing PDU session with the SMF. As an example, if the congestion indication is received in a PDU session establishment reject message (DL NAS message 350), the PDU session has not been established. As a result, the UE 102 might never receive a subsequent 5GSM message to stop the deactivated back-off timer. When the back-off timer value is set to deactivated and a PDU session is not established, absent the techniques of this disclosure, a user would need to switch off / on the UE 102 in order to resume the SM operations. This user action is not trivial and impacts user experience.

[0075] In a second example problem 302, the user might restart the UE (block 390) in an attempt to manually reset the deactivated back-off timer. Assuming the UE 102 is a type of UE that is accessible by a user (which might not be the case), restarting the UE might include power cycling the UE, toggling airplane mode on / off, removing / reinserting a USIM, or other manual action to cause the UE 102 to restart a radio interface. Absent the techniques of this disclosure, after the user switches off and on the UE 102 in block 390, the UE 102 might attempt to send additional 5GSM requests (shown as UL NAS message 394) for the same DNN / S-NSSAI that is congested. The UL NAS message 394 might add additional networkcongestion 396. Shown at arrow 398, the CN 110 might respond to the UL NAS message 394 by sending another DL NAS message 350. The additional network congestion 396 can prolong the congestion condition. Furthermore, it's possible that a user might repeatedly (again and again) restart the UE 102 (block 390) causing more congestion.

[0076] Having described the example problems 301 and 302 with reference to FIG. 3, this disclosure provides some example solutions to these problems. FIG. 4A and FIG. 4B show example solutions to the first example problem 301. FIG. 7A and FIG. 7B show example solutions to the second example problem 302.

[0077] FIG. 4A shows an example message flow diagram 400A and example operations for back-off timer maintenance in which the core network can update a back-off timer. The first portion of FIG. 4A is the same as described with reference to FIG. 3, including the UL NAS message 340, the first DL NAS message 350, starting / deactivating the back-off timer (block 352), and refraining from SM operations for a DNN / S-NSSAI having a running / deactivated back-off timer (block 360). FIG. 4A differs from FIG. 3 in that the illustrated example solution 401 overcomes the first example problem 301. In the first example problem 301, the UE 102 might be stuck perpetually with a deactivated back-off timer.

[0078] In the example solution 401, the CN 110 sends a DL NAS message 480 to the UE 102 to update the congestion control information (also referred to as update information), such as the back-off timer value or cause value. In one example, the back-off timer is set to “deactivated” in block 352, while the second DL NAS message 480 can indicate a new nonzero timer value to cause the back-off timer to run for an indicated time period. Alternatively, the second DL NAS message 480 can indicate a “zero” value or other indicator to cause the UE 102 to stop the back-off timer. In some implementations, the second DL NAS message 480 is a 5GSM message (e.g., 5GSM STATUS message), a 5GMM message (e.g., 5GMM STATUS message), or a CONFIGURATION UPDATE COMMAND message. The second DL NAS message 480 can include an updated back-off timer value and an indication whether the back-off timer is applied to the registered PLMN or all PLMNs. In some implementations, the DL NAS message 480 indicates an expected back-off mechanism (referred to as retry parameters).

[0079] At block 482, the UE 102 updates (or stops) the back-off timer based on the update information in the second DL NAS message 480. At block 484, the back-off timer expires orhas been stopped. After the expiration of the back-off timer, the UE 102 is permitted to resume SM operations with the CN 110, such as retry a previous SM request.

[0080] In FIG. 4A, the second DL NAS message 480 optionally includes the retry parameters. The retry parameters inform the UE 102 of an expected back-off mechanism or when to retry a SM request. For example, the retry parameters can indicate one of the following potential back-off mechanisms:• legacy back-off timer with specific time value o the network may also indicate whether the UE should retry immediately upon timer expiry, or further wait for a specific / random timer in a range.• exponentially increasing backoff timer (or wait time after back-off timer expiration) after each retry (e.g., Is, 2s, 4s, 8s, etc.)• linearly increasing backoff timer (Im, 2m, 3m, 4m, etc.)• random value (optional within a range) after each retry

[0081] At block 486, the UE 102 assesses the retry parameters to determine whether it can proceed with a subsequent UL NAS message 394 to retry an SM request. In some instances, the UE 102 might have a series of retry attempts, such as when the CN 110 responds to a UL NAS message 394 (SM request) with a DL NAS message 498 that rejects the SM request. For each retry attempt, the retry parameters might indicate a different condition to control when the UE 102 is permitted to send the retry. For example, the retry parameters might indicate an exponentially or linearly increasing backoff (or wait) time such that the retry time depends on how many previous retries have been performed.

[0082] This disclosure contemplates a variety of retry parameters and example retry mechanisms. Generally described, the retry parameters indicate when the UE is permitted to retry a previous SM request via the one or more UL NAS messages 394 after the back-off timer is stopped or expired. In some implementations, the retry parameters indicate that the UE is permitted to retry the SM request: A) immediately after an expiration of the back-off timer, B) after an exponentially increasing wait time following each previous retry, C) after a linearly increasing wait time following each previous retry, or D) after a random time period following each previous retry or the expiration of the back-off timer. The retry parameters can include a time range such that that the UE is permitted to retry the first SM request after a random time in the time range following a previous attempt of the first SM request.

[0083] Although FIG. 4A shows the retry parameters being provided by the second DL NAS message 480 with update information, other implementations of the retry parameters can be used without the update information. For example, FIG. 4B shows a message flow diagram 400B and example operations in which the core network can provide retry parameters with an initial congestion notification (shown as DL NAS message 450). The rest of FIG. 4B is the same as described with reference to FIG. 4A, except that FIG. 4B does not require the second DL NAS message 480 or update information.

[0084] In FIG. 4B, the initial DL NAS message 450 might include a non-zero back-off timer value to indicate a time duration (rather than a value representing “deactivated”). When the back-off timer expires (block 484), the UE 102 can assess the retry parameters 186 (block 486) to determine whether, and when, the UE 102 can proceed with the subsequent UL NAS message 394 for the DNN / S-NSSAI corresponding to the expired back-off timer.

[0085] Several example methods that can be implemented in a UE (e.g., the UE 102) or a CN node such as an MME or an AMF are discussed with reference to FIG. 5A, FIG. 5B, FIG. 6, and FIG. 8. Each of these methods can be implemented using processing hardware such as one or more processors to execute instructions stored on a non-transitory computer-readable medium such as computer memory. Although FIG. 5A, FIG. 5B, FIG. 6, and FIG. 8 depict a particular sequence of operations, the sequence may be altered without departing from the scope of the present disclosure. For example, some of the operations depicted may be performed in parallel or in a different sequence that does not materially affect the function of the routine. In other examples, different components of an example device or system that implements the routine may perform functions at substantially the same time or in a specific sequence.

[0086] FIG. 5A shows example operations 500A for back-off timer maintenance by a UE. In FIG. 5A, the core network updates a back-off timer, such as described with reference to FIG. 4A.

[0087] At block 550, the UE receives a DL NAS message containing a reject cause value and a back-off timer value (e.g., "deactivated") for a DNN or S-NSSAI. At block 552, the UE starts (or deactivates) a back-off timer associated with the DNN or S-NSSAI. At block 560, the UE refrains from sending SM requests to associated DNN and / or S-NSSAI.

[0088] At block 580, the UE receives a DL NAS message that includes update information regarding the DNN / S-NSSAI. Alternatively, or additionally, the DL NAS message in block 580 can identify an existing PDU session or include an indication of the back-off timer affected by the update information. At block 582, the UE updates (or stops) the back-off timer based on the update information.

[0089] In some implementations, the DL NAS message in block 580 includes retry parameters. The operations at reference A 583 (shown in FIG. 5B) are relevant to scenarios in which the UE has obtained retry parameters.

[0090] FIG. 5B shows example operations for back-off timer maintenance in which the core network provides retry parameters, such as described with reference to FIG. 4A or FIG. 4B. FIG. 5B includes operations 500B that the UE might perform when it has obtained retry parameters from the core network. The retry parameters can be obtained in a DL NAS message (such as the DL NAS messages 350, 450, or 480). Alternatively, or additionally, the core network can provide retry parameters in a separate configuration message. In yet another alternative, the retry parameters can be preconfigured in the UE or obtained from a management object, memory element, or other network entity.

[0091] Starting from reference A 583, the flow chart begins with the UE having a running back-off timer. At block 584, the back-off timer expires or is stopped (such as by an updated back-off timer value). At block 585, the UE determines whether it has a pending SM request that was previously rejected and not available to retry. If there is no pending SM request to retry, the flow chart proceeds to block 599, where no further action is needed. Otherwise, if the UE has a pending SM request to retry, the flow chart proceeds to block 586A.

[0092] At block 586A, the UE determines whether the core network provided retry parameters that are relevant to the pending SM request. For example, the UE might determine whether the retry parameters are related to the same DNN and / or S-NSSAI for which the retry parameters are configured. If the retry parameters are not relevant to the pending SM request, or the UE has not obtained retry parameters, the flow chart proceeds to block 594, where the UE can proceed with sending the SM request in an UL NAS message to the core network. Otherwise, if the UE has obtained relevant retry parameters per block 586A, the flow chart proceeds to block 586B. At block 586B, the UE determines whether the retry parameters are satisfied. For example, the UE might check whether the current time is more than a timeperiod (delay or wait time) indicated in the retry parameters. When the retry parameters are satisfied at block 586B, the flow chart proceeds to block 594, where the UE sends a UL NAS message to communicate the SM request to the core network. Otherwise, if the retry parameters are not yet satisfied at block 586B, the flow chart proceeds to block 589, where the UE waits for the retry parameters to be satisfied.

[0093] It should be apparent that the retry parameters can be dependent on the number of previous attempts for the same SM request. For example, the operations 500B might be performed more than once, such as when the SM request (block 594) results in a rejection from the core network. When assessing the retry parameters (block 586B), the UE might determine how many previous attempts have been performed and adjust the retry parameters according to the number of previous attempts.

[0094] FIG. 6 shows example operations 600 of a core network in which the core network can update a back-off timer. The operations 600 correspond to the features described with reference to FIG. 4A. At block 644, the CN determines that an SM congestion control is needed for a DNN and / or S-NSSAI. At block 650, the CN rejects the SM request from the UE with cause value and / or back-off timer value. At block 654, the CN might determine that the congestion is resolved for a DNN and / or s-NSSAI. At block 680, the CN sends a DL NAS message indicating an update to the back-off timer associated with DNN and / or S-NSSAI. At block 694, the CN might receive an SM request from the UE as a result of the back-off timer being expired or stopped by the DL NAS message in block 680.

[0095] FIG. 7A shows a message flow diagram 700 and example operations for back-off timer handling in which the back-off timer is restored after the UE restarts. In the second example problem 302 of FIG. 3, when the restart operation is performed (block 390), the UE 102 would transmit a UL NAS message 394 contrary to the purpose of the back-off timer started in block 352. FIG. 7A shows an example solution 702 to the second example problem 302.

[0096] The events 340, 350, 352, 360, 390 are the same as described with reference to FIG. 3. At block 352, when the back-off timer is started or set to deactivated, the UE 102 can maintain a status of the back-off timer from before the UE 102 is switched off or the USIM is removed in block 390. For example, at block 762, the UE 102 can store the status of the back-off timer in a non-volatile memory in the UE 102 or the USIM. In someimplementations, the UE 102 stores the back-off timer with the Subscription Permanent Identifier (SUPI) from the USIM. These parameters can only be used if the SUPI from the USIM matches the SUPI stored in the non-volatile memory. Otherwise, if the SUPI stored with the back-off timer status does not match the SUPI from the USIM, the UE can delete the stored back-off timer information.

[0097] At block 770A, after the UE 102 is switched on or the radio interface is restarted, the UE 102 can restore the back-off timer state. In some implementations, the UE 102 can update the remaining time of the back-off timer based on how much time has elapsed since the backoff timer was started and the original back-off timer value. Thus, restoring the back-off timer might include resuming the back-off timer as if the back-off timer were continuously counting while the UE was restarted. As shown in FIG. 7A, because the back-off timer is restored, the UE 102 does not send the UL NAS message 394 (as described in FIG. 3) that would otherwise have been sent if the back-off timer was not restored. Therefore, the restoring the back-off timer provides the potential technical advantage of mitigating additional network congestion that might otherwise occur.

[0098] In some implementations, when the back-off timer is running as a countdown of remaining time starting from the timer value, the UE periodically updates the non-volatile memory based on the remaining time of the back-off timer. Although block 390 has been described as a restart, the restart operation in block 390 can be any variety of operations that would normally reset a running back-off timer. Example restart operations include: powering up the UE after a power cycle, initializing a radio interface after insertion of a USIM, and reinitializing the radio interface after having the radio interface disabled by a user interface.

[0099] FIG. 7B shows an example message flow diagram and example operations in which a timer applicability indication informs the UE whether to restore the back-off timer. The events 340, 352, 360, 762, and 390 are the same as described with reference to FIG. 3 and FIG. 7A, respectively. The differences between FIG. 7A and FIG. 7B are based on a timer applicability indication. The timer applicability indication can be any type of indication included in the DL NAS message 750 that initially prompts the UE 102 to start a back-off timer, where the timer_applicability indication informs the UE 102 whether the backoff timer should be maintained (or not) following a UE restart. In some implementations, the timer applicability indication can be included in an information element. Alternatively, oradditionally, the timer applicability indication can be a bit indicator or field value. Example values of the timer applicability indication can include: “applicable after restart,” “applicable after power cycle,” “not applicable after restart / power cycle,” “not applicable for X services” (where X is a particular service such as MTC), among other examples. The name, format, and values for the timer applicability indication in this disclosure are examples, and other names, formats, or values can be used.

[0100] The CN 110 can include the timer applicability indicator with the back-off timer value in the DL NAS message 750, or in another DL NAS message (not shown). In some implementations, the timer applicability indication is specific to a particular back-off timer started based on a specific congestion condition. Alternatively, or additionally, the timer applicability indication can be a configuration setting that applies to multiple back-off timers or for particular RATs. For example, the timer applicability indication can be preconfigured in the UE 102, such as in a management object, USIM, or by an earlier network configuration message. In some implementations, the CN 110 can inform one or more UEs (or a class of UEs) of the timer applicability indication. For example, the timer applicability indication might be set to “applicable after power cycle” for some UEs based on UE access class or access category, while the timer_applicability indication might be set to “not applicable after power restart” for other UEs based on those UEs having a higher priority, access class, or access category (such as UEs for emergency services).

[0101] The timer applicability indicator can inform the UE 102 whether the back-off timer should be restored after a power cycle or other type of restart operation. In some implementations, the timer_applicability indication is included whenever the DL NAS message 750 includes the back-off timer value set to “deactivated.” Alternatively, or additionally, the timer applicability indication can be included regardless of whether the back-off timer value is set to “deactivated” or a time period. Furthermore, the timer applicability indication might be required for some types of back-off timer value (such as “deactivated”) and might be optional for other types of back-off timer values (such as those with a particular duration or any durations).

[0102] At block 770B, the CN 110 restores the back-off timer (as described with block 770A) if the timer_applicability indication is set to a particular value (such as “applicable after restart” or “applicable after power cycle”). A potential technical advantage of thetimer_applicability indication is that the CN 110 can control whether the UE 102 maintains the back-off timer past a power cycle or USIM replacement,

[0103] FIG. 8 shows example operations for back-off timer maintenance after a UE restart, such as described with reference to FIG. 7A and FIG. 7B. The operations at blocks 550, 552, and 560 are the same as described with reference to FIG. 5A. At block 550, the UE receives, from the CN, a DL NAS message containing a reject cause value and a back-off timer value (e g., “deactivated”) for a congested DNN and / or S-NSSAI. The DL NAS message may include a timer applicability indication as described with reference to FIG. 7B. At block 552, the UE starts (or deactivate) the back-off timer corresponding to the congested DNN and / or S-NSSAI. At block 560, the UE refrains from sending a SM request to the congested DNN and / or s-NSSAI.

[0104] At block 862, the UE stores a status of back-off timer in non-volatile memory. At block 890, the UE is restarted, such as any of the restart operations described with reference to FIG. 7A. At block 891, the UE determines whether to restore the back-off timer following the restart operation. For example, the UE might determine whether the non-volatile memory has stored relevant status or information for back-off timer that corresponds to a particular DNN and / or S-NSSAI. Alternatively, or additionally, at block 891, the UE might verify whether a stored status of a back-off timer is accurate and stored with the same SUPI as in the USIM.

[0105] In another alternative, at block 891, the UE might determine whether to restore the back-off timer based on a quantity of UE restarts that have occurred or based on a time stamp stored with the back-off timer information. For example, the UE might prevent a restoring of the back-off timer if a long time (such as hours or days) has elapsed or when the UE has attempted multiple UE restarts to reset a deactivated back-off timer.

[0106] In yet another alternative, at block 891, the UE might determine whether to restore the back-off timer based on a timer applicability indication as described with reference to FIG. 7B. If the timer applicability indication is set to a first value (such as "not applicable after restart") then the UE determines not to restore the back-off timer and the flow chart proceeds to block 599. If the timer applicability indication is set to a second value (such as "applicable after restart"), then the UE determines to restore the backoff timer and the flow chart proceeds to block 870.

[0107] From block 891 , for any of the reasons described above, if the UE determines to not to restart the back-off timer, the flow chart proceeds to block 599 where the UE takes no further action to restore the back-off timer (and optionally, deletes the back-off timer information from the non-volatile memory). Otherwise, if the UE determines to restart the back-off timer for any of the reasons described above, the flow chart proceeds to block 870. At block 870, the UE restores back-off timer based on status in non-volatile memory.

[0108] FIG. 9 is a block diagram of an example wireless communication system 900 showing hardware features and communication interfaces. The depicted hardware configurations may omit certain components well-understood to be frequently implemented in such electronic devices, such as displays, peripherals, power supplies, and the like. The example wireless communication system 900 includes the same elements as described with reference to FIG. 1A, including the UE 102, the BS 106, and the CN 110. The UE 102 can support at least a 5G NR (or simply, “NR”) or E-UTRA air interface to communicate with the BS 106. The BS 106 connects to the CN 110 via an interface (e.g., SI or NG interface). The BS 106 can connect to other base stations (including the BS 904) via an interface (e.g., X2 or Xn interface) for interconnecting NG RAN nodes.

[0109] The CN 110 can be an Evolved Packet Core (EPC) and / or a 5G core (5GC). Among other components, the EPC can include a Serving Gateway (SGW), a Mobility Management Entity (MME), and a Packet Data Network Gateway (PGW). The SGW in general is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., and the MME is configured to manage authentication, registration, paging, and other related functions. The PGW provides connectivity from the UE to one or more external packet data networks, e.g., an Internet network and / or an Internet Protocol (IP) Multimedia Subsystem (IMS) network. The 5GC includes a User Plane Function (UPF) and an Access and Mobility Management Function (AMF), and / or Session Management Function (SMF). Generally speaking, the UPF is configured to transfer user-plane packets related to audio calls, video calls, Internet traffic, etc., the AMF is configured to manage authentication, registration, paging, and other related functions, and the SMF is configured to manage PDU sessions.

[0110] The base station 106 is equipped with processing hardware 906 that can include a receiver 907B configured to receive data in the uplink direction. The processing hardware 906 can also include a transmitter 907A configured to transmit data in the downlink direction.The processing hardware further can one or more general -purpose processor(s) 907C (e g., CPUs) and a non-transitory computer-readable memory 907D storing instructions that the one or more general-purpose processors execute. Additionally, or alternatively, the processing hardware 906 can include special-purpose processing units. The processor 907C may include, for example, one or more central processing units, graphics processing units (GPUs), or other application-specific integrated circuits (ASIC), and the like. CRM 907D may include any suitable memory or storage device such as random-access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM (NVRAM), read-only memory (ROM), or Flash memory usable to store device data of the BS 106.[OHl] The UE 102 is equipped with processing hardware 902 that can include one or more general-purpose processors such as CPUs and non-transitory computer-readable memory 903D storing machine-readable instructions executable on the one or more general-purpose processors, and / or special-purpose processing units. The processing hardware 902 can also include a transmitter 903 A configured to transmit data in the downlink direction. The processing hardware further can include a receiver 903B configured to receive data in the uplink direction. The processing hardware 902 in an example implementation includes a processor 903 C to process data that the UE 102 will transmit in the uplink direction, or process data received by UE 102 in the downlink direction. The processor(s) 903 C may include, for example, one or more central processing units, graphics processing units (GPUs), or other application-specific integrated circuits (ASIC), and the like. To illustrate, the processor(s) 903 C may include an application processor (AP) utilized by the UE 102 to execute an operating system and various user-level software applications, as well as one or more processors utilized by modems or a baseband processor. The computer readable media / memory (CRM) 903D may include any suitable memory or storage device such as randomaccess memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM (NVRAM), read-only memory (ROM), Flash memory, solid-state drive (SSD) or other massstorage devices, and the like useable to store one or more sets of executable software instructions and associated data that manipulate the one or more processor(s) 903 C and other components of the processing hardware 902 to perform the various functions described herein and attributed to the UE 102. The sets of executable software instructions include, for example, an operating system (OS) and various drivers (not shown), and various softwareapplications (not shown), which are executable by processor(s) 903C to enable user-plane communication, control -plane signaling, and user interaction with the UE 102.

[0112] FIG. 1A through FIG. 9 and the operations described herein are examples meant to aid in understanding example implementations and should not be used to limit the potential implementations or limit the scope of the claims. Some implementations may perform additional operations, fewer operations, operations in parallel or in a different order, and some operations differently.

[0113] The foregoing disclosure provides illustration and description but is not intended to be exhaustive or to limit the aspects to the precise form disclosed. Modifications and variations may be made in light of the above disclosure or may be acquired from practice of the aspects. While the aspects of the disclosure have been described in terms of various examples, any combination of aspects from any of the examples is also within the scope of the disclosure. The examples in this disclosure are provided for pedagogical purposes. Alternatively, or in addition to the other examples described herein, examples include any combination of the following implementation options (enumerated as clauses for clarity).

[0114] Clause 1. A method for wireless communication by a user equipment (UE) (102), including: receiving (150, 350, 550) a first downlink (DL) non-access stratum (NAS) message for congestion control of a first data network or network slice; starting (352, 552) a back-off timer for the first network or network slice based on the DL NAS message; refraining (160, 360, 560) from communicating session management (SM) requests for the first data network or network slice while the back-off timer is running; receiving (180, 480, 580) a second DL NAS message that includes update information regarding the first data network or network slice; and updating (482, 582) the back-off timer based on the update information.

[0115] Clause 2. The method of clause 1, where the first DL NAS message includes a first back-off timer value, and the update information in the second DL NAS message includes a second back-off timer value.

[0116] Clause 3. The method of clause 1 or 2, where the update information includes an indicator to stop the back-off timer, and where the updating the back-off timer includes stopping the back-off timer.

[0117] Clause 4. The method of any one of clauses 1 to 3, where the first back-off timer value indicates a “deactivated” time value such that the back-off timer is started and runs indefinitely to deactivate SM requests until the back-off timer is updated or stopped as a result of the second DL NAS message.

[0118] Clause 5. The method of any one of clauses 1 to 4, further including: transmitting (340) a first uplink (UL) NAS message having a first SM request for the first data network or network slice, where the first DL NAS message is in response to the first SM request.

[0119] Clause 6. The method of clause 5, further including: determining (394, 594) whether to transmit one or more subsequent UL NAS messages to retry the first SM request after expiration of the back-off timer based on whether retry parameters are satisfied.

[0120] Clause 7. The method of clause 6, further including: receiving the retry parameters (186, 486) from the core network via at least one of the first DL NAS message (350, 450) or the second DL NAS message (480).

[0121] Clause 8. The method of clause 6 or 7, where the retry parameters indicate when the UE is permitted to retry the first SM request via the one or more subsequent UL NAS messages after the back-off timer is stopped or expired.

[0122] Clause 9. The method of clause 8, where the retry parameters indicate that the UE is permitted to retry the first SM request: A) immediately after an expiration of the back-off timer, B) after an exponentially increasing wait time following each previous retry, C) after a linearly increasing wait time following each previous retry, or D) after a random time period following each previous retry or the expiration of the back-off timer.

[0123] Clause 10. The method of clause 8, where the retry parameters include a time range and indicate that the UE is permitted to retry the first SM request after a random time in the time range following a previous attempt of the first SM request.

[0124] Clause 11. The method of any one of clauses 1 to 10, further including: storing a status of the back-off timer in a non-volatile memory of the UE while the back-off timer is running with a timer value or deactivated state.

[0125] Clause 12. The method of clause 11, further including, when the back-off timer is running as a countdown of remaining time starting from the timer value: periodically updating the non-volatile memory based on the remaining time.

[0126] Clause 13. The method of clause 11 or 12, further including: restoring the back-off timer to the status in the non-volatile memory following a restart operation of the UE, the restart operation including at least one of: powering up the UE after a power cycle; initializing a radio interface after insertion of a Universal Subscriber Identity Module (USIM); or reinitializing the radio interface after having the radio interface disabled via a user interface.

[0127] Clause 14. The method of clause 13, where the restoring the back-off timer includes: determining whether restore the back-off timer based, at least in part, on: how much time has passed between when the status was stored in the non-volatile memory and when the restart operation occurs, how many restart operations have occurred since the back-off timer was first started.

[0128] Clause 15. The method of any one of clauses 11 to 14, further including: receiving a timer applicability indication, where the storing the status and restoring the back-off timer are based, at least in part, on the timer applicability indication set to a value informing the UE that the back-off timer is applicable after the restart operation.

[0129] Clause 16. The method of clause 15, where the receiving the timer applicability indication includes receiving the timer_applicability indication via at least one of: the first DL NAS message, a different DL NAS message, a configuration message, a management object, or a memory element of the UE.

[0130] Clause 17. A method for wireless communication by a user equipment (UE) (102), including: receiving (150, 350, 550) a first downlink (DL) non-access stratum (NAS) message in response to a first session management (SM) request for a first data network or network slice, where the first DL NAS message includes congestion control information for the first data network or network slice; starting a (352, 552) back-off timer for the first network or network slice based on the DL NAS message; refraining (160, 360, 560) from communicating session management (SM) requests for the first data network or network slice while the backoff timer is running; and transmitting one or more UL NAS messages (394, 694) to retry the first SM request after expiration of the back-off timer based on retry parameters being satisfied.

[0131] Clause 18. The method of clause 17, further including: receiving the retry parameters (186, 486) from the core network via at least one of the first DL NAS message (550) or adifferent DL NAS message (480), where the retry parameters indicate when the UE is permitted to retry the first SM request via the one or more UL NAS messages after the backoff timer is stopped or expired.

[0132] Clause 19. The method of clause 17 or 18, where the retry parameters indicate that the UE is permitted to retry the first SM request: A) immediately after an expiration of the back-off timer, B) after an exponentially increasing wait time following each previous retry, C) after a linearly increasing wait time following each previous retry, or D) after a random time period following each previous retry or the expiration of the back-off timer.

[0133] Clause 20. The method of any one of clauses 17 to 19, where the retry parameters include a time range and indicate that the UE is permitted to retry the first SM request after a random time in the time range following a previous attempt of the first SM request.

[0134] Clause 21. The method of any one of clauses 17 to 20, further including: receiving (180, 480, 580) a second DL NAS message that includes update information regarding the first data network or network slice; and updating (482, 582) the back-off timer based on the update information.

[0135] Clause 22. The method of clause 21, where the first DL NAS message includes a first back-off timer value, and the update information in the second DL NAS message includes a second back-off timer value.

[0136] Clause 23. The method of clause 21 or 22, where the update information includes: a back-off timer value to update the back-off timer, or an indicator to stop the back-off timer.

[0137] Clause 24. The method of any one of clauses 17 to 23, further including: storing a status of the back-off timer in a non-volatile memory of the UE while the back-off timer is running with a timer value or deactivated state.

[0138] Clause 25. The method of clause 24, further including, when the back-off timer is running as a countdown of remaining time starting from the timer value: periodically updating the non-volatile memory based on the remaining time.

[0139] Clause 26. The method of clause 24 or 25, further including: restoring the back-off timer to the status in the non-volatile memory following a restart operation of the UE, the restart operation including at least one of: powering up the UE after a power cycle; initializinga radio interface after insertion of a Universal Subscriber Identity Module (USIM); or reinitializing the radio interface after having the radio interface disabled by a user interface.

[0140] Clause 27. A method for wireless communication by a user equipment (UE) (102), including: receiving (150, 350, 550) a first downlink (DL) non-access stratum (NAS) message for congestion control of a first data network or network slice; starting (352, 552) a back-off timer for the first network or network slice based on the DL NAS message; refraining (160, 360, 560) from communicating session management (SM) requests for the first data network or network slice while the back-off timer is running; storing a status of the back-off timer in a non-volatile memory of the UE while the back-off timer is running with a timer value or deactivated state; and restoring the back-off timer to the status in the non-volatile memory following a restart operation of the UE.

[0141] Clause 28. The method of clause 27, further including, when the back-off timer is running as a countdown of remaining time starting from the timer value: periodically updating the non-volatile memory based on the remaining time.

[0142] Clause 29. The method of clause 27 or 28, where the restart operation including at least one of: powering up the UE after a power cycle; initializing a radio interface after insertion of a Universal Subscriber Identity Module (USIM); or reinitializing the radio interface after having the radio interface disabled by a user interface.

[0143] Clause 30. The method of any one of clauses 27 to 29, where the restoring the backoff timer includes: determining whether to restore the back-off timer based, at least in part, on: how much time has passed between when the status was stored in the non-volatile memory and when the restart operation occurs, or how many restart operations have occurred since the back-off timer was first started.

[0144] Clause 31. The method of any one of clauses 27 to 30, further including: receiving a timer applicability indication, where the storing the status and restoring the back-off timer are based, at least in part, on the timer applicability indication set to a value informing the UE that the back-off timer is applicable after the restart operation.

[0145] Clause 32. The method of clause 31, where the receiving the timer applicability indication includes receiving the timer applicability indication via at least one of: the firstDL NAS message, a different DL NAS message, a configuration message, a management object, or a memory element of the UE.

[0146] Clause 33. The method of any one of clauses 27 to 32, further including: receiving (180, 480, 580) a second DL NAS message that includes update information regarding the first data network or network slice; and updating (482, 582) the back-off timer based on the update information.

[0147] Clause 34. The method of clause 33, where the update information includes: a backoff timer value to update the back-off timer, or an indicator to stop the back-off timer.

[0148] Clause 35. The method of clause 33 or 34, where the first back-off timer value indicates a “deactivated” time value such that the back-off timer is started and runs indefinitely to deactivate SM requests until the back-off timer is updated or stopped as a result of the second DL NAS message.

[0149] Clause 36. The method of any one of clauses 27 to 35, further including: transmitting (340) a first uplink (UL) NAS message having a first SM request for the first data network or network slice, where the first DL NAS message is in response to the first SM request; and determining (394, 594) whether to transmit one or more subsequent UL NAS messages to retry the first SM request after expiration of the back-off timer based on whether retry parameters are satisfied, where the retry parameters indicate when the UE is permitted to retry the first SM request via the one or more subsequent UL NAS messages after the back-off timer is stopped or expired.

[0150] Clause 37. The method of clause 36, further including: receiving the retry parameters (186, 486) from the core network via at least one of the first DL NAS message (350, 450) or the second DL NAS message (480).

[0151] Clause 38. The method of clause 36 or 37, where the retry parameters indicate that the UE is permitted to retry the first SM request: A) immediately after an expiration of the back-off timer, B) after an exponentially increasing wait time following each previous retry, C) after a linearly increasing wait time following each previous retry, or D) after a random time period following each previous retry or the expiration of the back-off timer.

[0152] Clause 39. The method of any one of clauses 36 to 38, where the retry parameters include a time range and indicate that the UE is permitted to retry the first SM request after a random time in the time range following a previous attempt of the first SM request.

[0153] Clause 40. A method for wireless communication by a core network ( 110), including: transmitting (150, 350, 450, 650) a first downlink (DL) non-access stratum (NAS) message to a user equipment (UE) (102) based on congestion control of a first network or network slice, where the DL NAS message indicates a timer value for a back-off timer is deactivated; and transmitting (180, 680) a second DL NAS message that includes update information regarding network congestion of the first data network or network slice.

[0154] Clause 41. The method of clause 40, where the transmitting the second DL NAS message is based on a determination that the network congestion of the first data network or network slice is resolved.

[0155] Clause 42. The method of clause 40 or 41, where the first DL NAS message includes a first back-off timer value, and the update information in the second DL NAS message includes a second back-off timer value.

[0156] Clause 43. The method of clause 42, where the first back-off timer value indicates a “deactivated” time value, and where the second back-off timer value is a value to stop the back-off timer.

[0157] Clause 44. The method of any one of clauses 40 to 43, further including: receiving, from the UE, a first uplink (UL) NAS message having a first SM request for the first data network or network slice, where the first DL NAS message is an SM rejection in response to the first SM request; and providing retry parameters that indicate when the UE is permitted to retry the first SM request after the back-off timer is stopped or expired.

[0158] Clause 45. The method of clause 44, where the providing the retry parameters includes: transmitting the retry parameters via at least one of the first DL NAS message or the second DL NAS message.

[0159] Clause 46. The method of clause 44 or 45, where the retry parameters indicate that the UE is permitted to retry the first SM request: A) immediately after an expiration of the back-off timer, B) after an exponentially increasing wait time following each previous retry,C) after a linearly increasing wait time following each previous retry, or D) after a random time period following each previous retry or the expiration of the back-off timer.

[0160] Clause 47. The method of any one of clauses 44 to 46, where the retry parameters include a time range and indicate that the UE is permitted to retry the first SM request after a random time in the time range following a previous attempt of the first SM request.

[0161] Clause 48. The method of any one of clauses 44 to 47, further including: transmitting a timer applicability indication to the UE, where the timer applicability indication includes a first value that informs the UE whether to restore the back-off timer after a restart operation.

[0162] Clause 49. A method for wireless communication by a user equipment (UE) (102), including: receiving (150, 350, 550) a first downlink (DL) non-access stratum (NAS) message for congestion control of a first data network or network slice; starting (352, 552) a back-off timer for the first data network or network slice based on the DL NAS message; refraining (160, 360, 560) from communicating session management (SM) requests for the first data network or network slice while the back-off timer is running; storing a status of the back-off timer in a non-volatile memory of the UE while the back-off timer is running with a timer value or deactivated state; and restoring the back-off timer to the status in the non-volatile memory following a restart operation of the UE.

[0163] Clause 50. The method of clause 49, where the restart operation including at least one of: powering up the UE after a power cycle; initializing a radio interface after insertion of a Universal Subscriber Identity Module (USIM); or reinitializing the radio interface after having the radio interface disabled via a user interface.

[0164] Clause 51. The method of clause 49 or 50, further including, when the back-off timer is running as a countdown of remaining time starting from the timer value: periodically updating the non-volatile memory based on the remaining time.

[0165] Clause 52. The method of any one of clauses 49 to 51, further including: determining whether restore the back-off timer based, at least in part, on: how much time has passed between when the status was stored in the non-volatile memory and when the restart operation occurs, or how many restart operations have occurred since the back-off timer was first started. Clause 53. The method of any one of clauses 49 to 52, where the storing the statusand the restoring the back-off timer are based, at least in part, on a timer applicability indication that indicates that the back-off timer is applicable after the restart operation.

[0166] Clause 54. The method of clause 53, further including: receiving the timer applicability indication via at least one of: the first DL NAS message, a different DL NAS message, a configuration message, a management object, or a memory element of the UE.

[0167] Clause 55. An apparatus, including: a communication unit; and a processing system configured to control the communication unit to implement any one of the methods of any one of clauses 1-54.

[0168] Another innovative aspect of the subject matter described in this disclosure can be implemented as a computer-readable medium having stored therein instructions which, when executed by a processor, causes the processor to perform any one of the above-mentioned functionalities.

[0169] Another innovative aspect of the subject matter described in this disclosure can be implemented as a system having means for implementing any one of the above-mentioned functionalities.

[0170] Another innovative aspect of the subject matter described in this disclosure can be implemented as an apparatus having one or more processors configured to perform one or more operations from any one of the above-mentioned methods.

[0171] The following description may be applied to the description above.

[0172] Generally speaking, description for one of the above figures can apply to another of the above figures. Examples, implementations and methods described above can be combined, if there is no conflict. An event or block described above can be optional or omitted. For example, an event or block with dashed lines in the figures can be optional. In some implementations, “message” is used and can be replaced by “information element (IE),” and vice versa. In some implementations, “IE” is used and can be replaced by “field,” and vice versa. In some implementations, “configuration” can be replaced by “configurations” or “configuration parameters,” and vice versa. In some implementations, “some” means “one or more.” In some implementations, “at least one” means “one or more.”

[0173] A user device in which the techniques of this disclosure can be implemented (e.g, the UE 102) can be any suitable device capable of wireless communications such as a smartphone, a tablet computer, a laptop computer, a mobile gaming console, a point-of-sale (POS) terminal, a health monitoring device, a drone, a camera, a media-streaming dongle or another personal media device, a wearable device such as a smartwatch, a wireless hotspot, a femtocell, or a broadband router. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, the user device can operate as an internet-of-things (loT) device or a mobile-internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, a computer-readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0174] Certain embodiments are described in this disclosure as including logic or a number of components or modules. Modules can be software modules (e.g., code, or machine-readable instructions stored on non-transitory machine-readable medium) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. A hardware module can comprise dedicated circuitry or logic that is permanently configured (e.g, as a special-purpose processor, such as a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC), a digital signal processor (DSP), etc.) to perform certain operations. A hardware module may also comprise programmable logic or circuitry (e.g., as encompassed within a general -purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations. The decision to implement a hardware module in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g, configured by software) may be driven by cost and time considerations.

[0175] When implemented in software, the techniques can be provided as part of the operating system, a library used by multiple applications, a particular software application, etc. The software can be executed by one or more general-purpose processors or one or more special-purpose processors.

[0176] Upon reading this disclosure, those of skill in the art will appreciate additional and alternative structural and functional designs for handling mobility between base stations through the principles disclosed herein. Thus, while particular embodiments and applicationshave been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those of ordinary skill in the art, may be made in the arrangement, operation and details of the method and apparatus disclosed herein without departing from the scope defined in the appended claims.

[0177] As used herein, the terms “component” and “module” are intended to be broadly construed as hardware, firmware, or a combination of hardware and software. As used herein, a processor is implemented in hardware, firmware, or a combination of hardware and software. As used herein, the phrase “based on” is intended to be broadly construed to mean “based at least in part on.”

[0178] As used herein, a phrase referring to a list of items separated by “or” refers to any combination of those items, including single members. For example, “a, b, or c” is intended to cover the possibilities of: a only, b only, c only, a combination of a and b, a combination of a and c, a combination of b and c, and a combination of a and b and c.

[0179] In this disclosure, an expression of “X / Y” may include meaning of any of the following: “X or Y” or “X and Y” or “X and / or Y." An expression of “(A) B” or “B (A)” may include concept of “only B.” An expression of “(A) B” or “B (A)” may include the concept of“A+B” or “B+A.”

[0180] In this disclosure, the term "can" indicates a capability, or alternatively indicates a possible implementation option. The term "may" indicates a permission or a possible implementation option.

[0181] Some aspects are described herein in connection with thresholds. As used herein, satisfying a threshold may refer to a value being greater than the threshold, greater than or equal to the threshold, less than the threshold, less than or equal to the threshold, equal to the threshold, not equal to the threshold, or the like.

[0182] The various illustrative components, logic, logical blocks, modules, circuits, operations and algorithm processes described in connection with the implementations disclosed herein may be implemented as electronic hardware, firmware, software, or combinations of hardware, firmware or software, including the structures disclosed in this specification and the structural equivalents thereof. The interchangeability of hardware,firmware and software has been described generally, in terms of functionality, and illustrated in the various illustrative components, blocks, modules, circuits and processes described above. Whether such functionality is implemented in hardware, firmware or software depends upon the particular application and design constraints imposed on the overall system.

[0183] The hardware and data processing apparatus used to implement the various illustrative components, logics, logical blocks, modules and circuits described in connection with the aspects disclosed herein may be implemented or performed with a general purpose single- or multi-chip processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device (PLD), discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, or any conventional processor, controller, microcontroller, or state machine. A processor also may be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. In some implementations, particular processes, operations and methods may be performed by circuitry that is specific to a given function.

[0184] As described above, some aspects of the subject matter described in this specification can be implemented as software. For example, various functions of components disclosed herein, or various blocks or steps of a method, operation, process or algorithm disclosed herein can be implemented as one or more modules of one or more computer programs. Such computer programs can include non-transitory processor-executable or computer-executable instructions encoded on one or more tangible processor-readable or computer-readable storage media for execution by, or to control the operation of, a data processing apparatus including the components of the devices described herein. By way of example, and not limitation, such storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store program code in the form of instructions or data structures. Combinations of the above should also be included within the scope of storage media.

[0185] As used herein, the terms “user device”, “user equipment” (for example, UE 102), “wireless communication device”, “mobile communication device”, “communication device”, or “mobile device” refer to any one or all of cellular telephones, smartphones, portable computing devices, personal or mobile multi-media players, laptop computers, tablet computers, smartbooks, Internet-of-Things (loT) devices, palm-top computers, wireless electronic mail receivers, multimedia Internet enabled cellular telephones, wireless gaming controllers, display sub-systems, driver assistance systems, vehicle controllers, vehicle system controllers, vehicle communication system, infotainment systems, vehicle telematics systems or subsystems, vehicle display systems or subsystems, vehicle data controllers, point- of-sale (POS) terminals, health monitoring devices, drones, cameras, media-streaming dongles or another personal media devices, wearable devices such as smartwatches, wireless hotspots, femtocells, broadband routers or other types of routers, and similar electronic devices which include a programmable processor and memory and circuitry configured to perform operations as described herein. Further, the user device in some cases may be embedded in an electronic system such as the head unit of a vehicle or an advanced driver assistance system (ADAS). Still further, a mobile-internet device (MID). Depending on the type, the user device can include one or more general-purpose processors, a computer- readable memory, a user interface, one or more network interfaces, one or more sensors, etc.

[0186] Various modifications to the implementations described in this disclosure may be readily apparent to persons having ordinary skill in the art, and the generic principles defined herein may be applied to other implementations without departing from the scope of this disclosure. Thus, the claims are not intended to be limited to the implementations shown herein but are to be accorded the widest scope consistent with this disclosure, the principles and the novel features disclosed herein.

[0187] Additionally, various features that are described in this specification in the context of separate implementations also can be implemented in combination in a single implementation. Conversely, various features that are described in the context of a single implementation also can be implemented in multiple implementations separately or in any suitable subcombination. As such, although features may be described above as acting in particular combinations, and even initially claimed as such, one or more features from aclaimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

[0188] Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. Further, the drawings may schematically depict one or more example processes in the form of a flowchart or flow diagram. However, other operations that are not depicted can be incorporated in the example processes that are schematically illustrated. For example, one or more additional operations can be performed before, after, simultaneously, or between any of the illustrated operations. In some circumstances, multitasking and parallel processing may be advantageous. Moreover, the separation of various system components in the implementations described above should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products. Additionally, other implementations are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results.

Claims

CLAIMSWhat is claimed is:

1. A method for wireless communication by a user equipment (UE) (102), comprising: receiving (150, 350, 550) a first downlink (DL) non-access stratum (NAS) message for congestion control of a first data network or network slice; starting (352, 552) a back-off timer for the first data network or network slice based on the first DL NAS message; refraining (160, 360, 560) from communicating session management (SM) requests for the first data network or network slice while the back-off timer is running; receiving (180, 480, 580) a second DL NAS message that includes update information regarding the congestion control of the first data network or network slice; and updating (482, 582) the back-off timer based on the update information.

2. The method of claim 1, wherein the first DL NAS message indicates a timer value for a back-off timer is “deactivated” such that the back-off timer is started and runs indefinitely to prevent the UE from transmitting SM requests until the back-off timer is updated or stopped based on the update information.

3. The method of claim 1 or 2, wherein the update information includes an indicator to stop the back-off timer, and wherein the updating the back-off timer includes stopping the backoff timer.

4. The method of claim 1 or 2, wherein the first DL NAS message includes a first back-off timer value for the back-off timer, the update information in the second DL NAS message includes an updated back-off timer value for the back-off timer, and the updating the back-off timer includes setting the back-off timer to the updated backoff timer value.

5. The method of any one of claims 1 to 4, further comprising: prior to receiving the first DL NAS message, transmitting (340) a first session management (SM) request for a first data network or network slice;receiving (150, 3 0, 550) the first DL NAS message in response to the first SM request, wherein the first DL NAS message or the second DL NAS message includes retry parameters (186, 486) that indicate when the UE is permitted to retry the first SM request following the back-off timer being stopped or expired; and transmitting one or more UL NAS messages (394, 694) to retry the first SM request after expiration of the back-off timer based on the retry parameters being satisfied.

6. The method of claim 5, further comprising: determining (394, 594) whether to retry the first SM request after expiration of the back-off timer based on whether the retry parameters are satisfied.

7. The method of claim 5 or 6, wherein the retry parameters indicate that the UE is permitted to retry the first SM request based on at least one of: immediately after an expiration of the back-off timer, after an exponentially increasing wait time following each previous retry, after a linearly increasing wait time following each previous retry, or after a random time period following each previous retry or the expiration of the backoff timer.

8. The method of claim 5 or 6, wherein the retry parameters include a time range and indicate that the UE is permitted to retry the first SM request after a random time in the time range following a previous attempt of the first SM request.

9. The method of any one of claims 1 to 8, storing a status of the back-off timer in a non-volatile memory of the UE while the back-off timer is running with a timer value or deactivated state; and restoring the back-off timer based on the status in the non-volatile memory following a restart operation of the UE, wherein the restart operation including at least one of: powering up the UE after a power cycle, initializing a radio interface after insertion of a Universal Subscriber Identity Module (USIM), or reinitializing the radio interface after having the radio interface disabled via a user interface.

10. A method for wireless communication by a core network (110), comprising: transmitting (150, 350, 450, 650) a first downlink (DL) non-access stratum (NAS) message to a user equipment (UE) (102) based on congestion control of a first data network or network slice, wherein the DL NAS message indicates a timer value for a back-off timer is deactivated such that the back-off timer is started and runs indefinitely to prevent the UE from transmitting session management (SM) requests until the back-off timer is updated or stopped based on update information; and transmitting (180, 680) a second DL NAS message that includes the update information regarding the congestion control of the first data network or network slice.

11. The method of claim 10, wherein the transmitting the second DL NAS message is based on a determination that network congestion of the first data network or network slice is resolved.

12. The method of claim 10 or 11, wherein the update information includes at least one of an indicator to stop the back-off timer, or an updated timer value for the back-off timer.

13. The method of any one of claims 10 to 12, further comprising: providing retry parameters that indicate when the UE is permitted to retry a first SM request following the back-off timer being stopped or expired.

14. An apparatus, comprising: a communication unit; and a processing system configured to control the communication unit to implement any one of the methods of any one of claims 1 to 13.

Images