Adaptive handling of network session cause codes

Abstract

A user equipment (UE) (102) in a mobile cellular network (100) implements one or more techniques to adaptatively handle cause codes received from the cellular network in response to network session requests. For example, the UE receives a first network session reject message (403, 503, 603, 703, 803) from the cellular network including a first cause code in response to sending a first network session request (401, 501, 601, 701. 801, 901) to the cellular network specifying a first session type. The UE prohibits (408, 508, 608, 708, 808) sessions of the first session type based on the first cause code. Then, the UE prohibits sessions of the second session type and allows sessions (424, 524, 718, 818) of the first session type that were previously prohibited in response to a management condition for a network session type being satisfied for at least a second session type.

Description

ADAPTIVE HANDLING OF NETWORK SESSION CAUSE CODESBACKGROUND

[0001] In cellular networks, data sessions are components that facilitate mobile data communication. Examples of data sessions include Packet Data Protocol (PDP), Packet Data Network (PDN), and Protocol Data Unit (PDU) sessions. PDP sessions are implemented in networks, such as General Packet Radio Service (GPRS) networks, to define the type of data transmission (such as Internet Protocol version 4 (IPv4) or IPv6) and establish a virtual connection between the mobile device and the PDP network for enabling the transfer of data packets. As technology evolved, PDN sessions became prominent in Long Term Evolution (LTE) networks, which serve a similar purpose to PDP sessions but with enhanced capabilities, including support for multiple PDN connections for varied services, such as Internet access or Voice over IP (VoIP). PDU sessions were introduced with 5G technology, which further advanced this concept by managing data transmission packets more granularly.PDU sessions facilitate efficient network slicing and support a wide range of Internet of Things (loT) applications. PDU sessions help manage the lifecycle of data transmission from session establishment and data transfer to session termination and allow for the seamless delivery of high-speed and reliable mobile data services.SUMMARY OF EMBODIMENTS

[0002] In accordance with one aspect, a method at a user equipment (UE) in a cellular network includes receiving a first network session reject message from the cellular network including a first cause code in response responsive to sending a first network session request to the cellular network specifying a first session type. Sessions of the first session type are prohibited based on the first cause code. In response to a management condition for a network session type being satisfied for at least a second session type, sessions of the second session type are prohibited and sessions of the first session type that were previously prohibited are allowed.

[0003] In at least some embodiments, a third network session request is sent to the cellular network specifying the first session type in response to allowing sessions of the first session type.

[0004] In at least some embodiments, the method further includes sending a second network session request to the cellular network specifying the second session type, receiving a second network session reject message (420, 520) from the cellular network including a second cause code, and determining that the management condition is satisfied based on the second cause code.

[0005] In at least some embodiments, determining that the management condition is satisfied is further based on receiving the second cause code after sessions of the first session type have been prohibited.

[0006] In at least some embodiments, determining that the management condition is satisfied is further based on sessions of the first session type being prohibited and the second cause code indicating that only sessions of the first session type are allowed.

[0007] In at least some embodiments, determining that the management condition is satisfied is further based on sessions of the first session type being prohibited and the second cause code indicating that a requested service option is unavailable or the UE is not subscribed to the requested service requested service option.

[0008] In at least some embodiments, determining that the management condition is satisfied is further based on the first cause code and the second cause code being different cause codes but having the same cause code type.

[0009] In at least some embodiments, the method further includes sending the second network session request in response to one or more session re-establish conditions.

[0010] In at least some embodiments, prohibiting sessions of the first session type includes updating network management settings to indicate that sessions of the first session type are prohibited, and prohibiting sessions of the second session type and allowing sessions of the first session type includes updating the network management settings to indicate that sessions of the second session type are prohibited and sessions of the first session type are allowed.

[0011] In at least some embodiments, the method further includes establishing a first network session having the second session type with the cellular network, and determining that the management condition is satisfied after establishing the first network session and in response to receiving an indication from the cellular network that a network protocol deployment configuration has changed.

[0012] In at least some embodiments, the indication received from the cellular network indicates that the network protocol deployment configuration has changed from the second session type to the first session type.

[0013] In at least some embodiments, the method further includes determining that the management condition is satisfied after establishing a first network session having the second session type with the cellular network and in response to detecting a capability change of the UE or the cellular network.

[0014] In at least some embodiments, the capability change of the UE or the cellular network is a radio access technology change.

[0015] In at least some embodiments, the method further includes selecting a predefined session type for the second session type from a plurality of session types in response to receiving the first network session reject message including the first cause code, and sending a second network session request to the cellular network specifying the second session type.

[0016] In accordance with another aspect, a user equipment device includes one or more radio frequency (RF) modems configured to wirelessly communicate with atleast one network, one or more processors coupled to the one or more RF modems, and at least one memory storing executable instructions, the executable instructions configured to manipulate at least one of the one or more processors or the one or more RF modems to perform the methods described above and herein.BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The present disclosure may be better understood, and its numerous features and advantages made apparent to those skilled in the art, by referencing the accompanying drawings. The use of the same reference symbols in different drawings indicates similar or identical items.

[0018] FIG. 1 is a diagram illustrating an example wireless system employing a UE configured to implement adaptive cause code handling techniques in accordance with some embodiments.

[0019] FIG. 2 is a block diagram illustrating example configurations for adaptive cause code handling employed by the UE of FIG. 1 in accordance with some embodiments.

[0020] FIG. 3 is a diagram illustrating an example hardware configuration of a UE of FIG. 1 in accordance with some embodiments.

[0021] FIG. 4 is a sequence diagram illustrating an example sequence of operations between the UE and the network of FIG. 1 , including the UE implementing a first adaptive cause code handling configuration in accordance with some embodiments.

[0022] FIG. 5 is a sequence diagram illustrating an example sequence of operations between the UE and the network of FIG. 1 , including the UE implementing a second adaptive cause code handling configuration in accordance with some embodiments.

[0023] FIG. 6 is a sequence diagram illustrating an example sequence of operations between the UE and the network of FIG. 1 , including the UE implementing a third adaptive cause code handling configuration in accordance with some embodiments.

[0024] FIG. 7 is a sequence diagram illustrating an example sequence of operations between the UE and the network of FIG. 1, including the UE implementing a fourth adaptive cause code handling configuration in accordance with some embodiments.

[0025] FIG. 8 is a sequence diagram illustrating an example sequence of operations between the UE and the network of FIG. 1, including the UE implementing a fifth adaptive cause code handling configuration in accordance with some embodiments.

[0026] FIG. 9 is a flow diagram illustrating an example method for adaptively handling cause codes at the UE of FIG. 1 in accordance with some embodiments.

[0027] FIG. 10 is a flow diagram illustrating another example method for adaptively handling cause codes at the UE of FIG. 1 in accordance with some embodiments.DETAILED DESCRIPTION

[0028] In mobile data networks, as defined by the Third Generation Partnership Project (3GPP) across technologies including Second Generation (2G), Third Generation (3G), Fourth Generation (4G), and Fifth Generation (5G) technologies, a user equipment (UE) establishes specific network sessions to access services, such as the Internet or voice and video calls. These sessions are known as PDP contexts in 2G / 3G, PDN sessions in 4G, or PDU sessions in 5G, and are collectively referred to herein as "mobile data network sessions" or just "network sessions" for brevity. Within these network sessions, data is transferred through specific connections tailored to the network's protocol requirements, such as an IPv4 or IPv6 connection, in any given session type, depending on the network’s current configuration and the session’s protocol settings. The type and nature of these network sessions and connections are regulated by the network’s deployment, including whether the gateway supports IPv4, IPv6, or both (IPv4v6), as specified in, for example, 3GPP technical specifications TS 24.008, TS 24.301 , and TS 24.501. These standards delineate the “allowed causes” that specify the limitations on the type of IP connectivity permitted.

[0029] However, real-world network operations can present challenges beyond these standard protocols. For example, network operators may dynamically adjustthe deployment of the GPRS Support node (GGSN) or PDN-Gateway based on resource management, altering the network’s supported IP type from, for example, IPv4 only to IPv6 only, IPv6 only to IPv4 only, or other configurations. This dynamic nature of network IP support can create connectivity issues for UEs, particularly when a UE receives a cause code such as “IPv4 only allowed”, “IPv6 only allowed”, or “IPv4v6 only allowed”. Following such a rejection, the UE is barred from reattempting to establish another session with a non-supported IP type under the same network conditions. According to 3GPP technical specifications, the UE should only retry under specific circumstances, including registration to a new Public Land Mobile Network (PLMN), device switch-off, Subscriber Identity Module (SIM) or Universal SIM (USIM) changes, or a change in the Packet Data Protocol (PDP) type used to access the Access Point Name (APN). Moreover, the network may enforce a single IP type even if a UE requests a dual IP type (IPv4v6), overriding the request and allowing only the supported type.

[0030] The challenges that arise from dynamically changing network configurations, along with the condition that UEs are to strictly adhere to current network policies, as stipulated by 3GPP technical specifications, present problems in both network management and UE functionality. Strict adherence to these policies, while as aspect of maintaining system integrity and security, introduces several disadvantages and practical challenges. For example, one issue is the lack of flexibility. UEs that rigidly follow network policies may not have the adaptability needed to respond effectively to rapid changes in network conditions or configurations. This inflexibility can result in connectivity problems or service interruptions, particularly in environments where network settings are frequently altered. Moreover, this strict adherence often necessitates manual intervention by users to maintain connectivity. Actions, such as restarting devices or swapping SIM cards, are typically performed when automated processes fail. This not only disrupts the user experience but also places an undue burden on users to actively manage their device's network settings.

[0031] Another problem arises from the delay in adapting to network improvements. As network technologies evolve and enhancements are implemented, UEs that strictly adhere to outdated policies may not immediately benefit from theseadvancements. This lag hampers the adoption of new technologies and diminishes the effectiveness of network upgrades designed to improve service quality or increase capacity. Additionally, for network operators, ensuring that all UEs strictly comply with current policies complicates the management and deployment of new network strategies or configurations. It also leads to increased operational overhead as each policy change requires extensive coordination and communication to ensure seamless service continuity.

[0032] As such, the following describes embodiments of systems and methods for a UE to adaptively adjust the handling of cause codes or network protocol deployment changes such that the UE is able to establish a network session using a previously prohibited IP or non-IP (e.g., Ethernet) session type. As described in greater detail below, when the UE attempts to establish an initial network session (e.g., a PDF, PDN, or PDU session), the UE, in some instances, receives a session rejection message including a cause code from the network. This cause code indicates that only a specific session type is allowed for the session (e.g., IPv4, IPv6, IPv4v6, Unstructured, or Ethernet) or that a requested service option is not available or subscribed to. In response to receiving the cause code, the UE updates its network management settings (e.g., local policies and configurations, session states, etc.) to align with the network’s current restrictions or capabilities as indicated by the cause code. Stated differently, the UE prohibits or bars all types of network sessions except for the session type identified or indicated by the cause code.

[0033] Upon receiving the initial cause code, the UE attempts to establish a new mobile data network session using the allowed session type indicated by the cause code or opts for another session type that is currently not subject to any restrictions based on the cause code. For instance, if the network sends a cause code that specifies “IPv6 only allowed”, the UE proceeds to establish a network session configured for I v6. However, if the network protocol deployment changes before the UE’s attempt to establish the new network session, the network rejects the UE’s session request due to a mismatch with its new configuration. In such instances, the network issues a new cause code reflecting the updated policy or capability. If the network protocol deployment change does not occur until after the new mobile datanetwork session has been established, any attempt by the UE to re-establish the network session will be similarly rejected.

[0034] As described above, in response to receiving the new cause code, a conventionally configured UE is typically unable to establish any network sessions until a specific condition is satisfied, such as registering to a new PLMN, device switch-off, SIM or USIM changes, or a change in the PDP type used to access the APN. However, when the UE of one or more embodiments receives a new cause code, the UE adaptively adjusts its cause code handling procedures such that the UE is able to establish a network session without having to meet the typical conditions required of conventionally configured UEs. In at least some embodiments, if the UE receives a new cause code from a first set of cause codes (e.g., TS 24.301 or TS 24.501 cause codes #50, #51 , #57, #58, and #61), the UE updates its network management settings to apply the network’s current restrictions or capabilities and remove the restrictions resulting from one or more previous cause codes. Stated differently, the UE allows session types previously prohibited as a result of a previous cause code(s). The UE then communicates with the network to establish a mobile data network session using the unbarred session type. For example, if the UE previously received a cause code indicating “IPv6 only allowed” such that IPv4 sessions were prohibited, the UE updates its network management settings to remove this restriction and proceeds with attempting to establish a network session with an IPv4 configuration.

[0035] In some instances, the UE communicates with a legacy network that does not implement cause codes explicitly indicating the allowed session type. Instead, the legacy network implements a second set of cause codes (e.g., TS 24.008 cause code #32 or #33) that indicate a requested service option is not supported or not subscribed to in response to the UE requesting a session type that does not match the current network protocol deployment configuration of the legacy network. In these instances, the UE performs similar operations to those described above. For example, the UE updates its network management settings to apply the network’s current restrictions or capabilities and to remove the restrictions resulting from one or more previous cause codes. The UE then communicates with the network toestablish a network session using a different connection type from the one that triggered the cause code.

[0036] In at least some embodiments, other events besides receiving a cause code in a session request rejection message trigger the UE to update its network management settings to remove the restrictions resulting from one or more previous cause codes. For example, in at least some embodiments, the UE receives an indication from the network that the network protocol deployment has changed. In response to receiving this indication from the network, the UE updates its network management settings to remove the restrictions resulting from one or more previous cause codes. In at least some embodiments, the UE also updates the network management settings to apply the network’s current restrictions or capabilities indicated by the received indication. The UE then communicates with the network to establish a network session using the unbarred session type.

[0037] The UE, in at least some embodiments, detects or anticipates a network protocol deployment change based on a UE capability change or network capability change. In these embodiments, when the UE detects a UE or network capability change that historically results in a network protocol deployment change, the UE updates its network management settings to remove the restrictions resulting from one or more previous cause codes. In at least some embodiments, the UE also updates the network management settings to apply the network’s current restrictions or capabilities indicated by the received indication. The UE then communicates with the network to establish a network session using the unbarred session type. In one or more of the embodiments described above, instead of selecting an unbarred session type for establishing a subsequent network session, the UE uses a predefined session type, such as a dual-stack (e.g., IPv4v6) session type, to establish the subsequent network session.

[0038] As such, the techniques described herein address the challenges of rigid adherence to 3GPP technical standards and dynamically changing network configurations, thereby enhancing both network management and UE functionality. These techniques allow UEs to automatically adjust their settings to match current network conditions, which minimizes connectivity issues and reduces the need formanual user intervention, such as device restarts or SIM swaps. This automation not only streamlines user experiences but also ensures that users can immediately benefit from network improvements and enhancements. Furthermore, the adaptive techniques described herein speed up the adoption of new technologies and maximize the impact of network upgrades aimed at improving service quality or increasing capacity. For network operators, this approach simplifies the deployment of new configurations and reduces operational overhead, facilitating smoother policy integration and enhancing service continuity. This efficient and responsive management ensures the network remains robust and adaptable to evolving demands.

[0039] For ease of illustration, the following techniques are described in an example context in which one or more UEs and one or more RANs implement at least a Fourth Generation (4G) Long-Term Evolution (3GPP LTE) standard (e.g., 3GPP Release 8, Release 9, Release 10, etc.) or a Fifth Generation (5G) New Radio (NR) standard (e.g., 3GPP Release 15, 3GPP Release 16, 3GPP Release 17, etc.) (hereinafter, "5G NR" or "5G NR standard"). However, it should be understood that the present disclosure is not limited to networks employing an LTE or 5G NR RAT configuration, but rather, the techniques described herein can be applied to any network that implements cause codes when rejecting a request from a UE to establish a mobile data network session. It should also be understood that the present disclosure is not limited to any specific network configurations or architectures described herein for adaptively adjusting the handling of cause codes at a UE. Instead, techniques described herein can be applied to any configuration of RANs. Also, the present disclosure is not limited to the examples and context described herein, but rather, the techniques described herein can be applied to any network environment where a UE implements techniques for adaptively adjusting cause code handling for establishing mobile data network sessions and connections.

[0040] FIG. 1 illustrates a mobile cellular network 100 (also referred to here as “cellular network 100 or “network 100”) in accordance with at least some embodiments. As shown, the mobile cellular network 100 includes a device, such as a user equipment (UE) 102, that is configured to communicate with one or more basestations (BSs) 104 (illustrated as BS 104-1 and BS 104-2) through one or more wireless communication links 106 (illustrated as wireless links 106-1 and 106-2). The UE 102, in at least some embodiments, includes any of a variety of wireless communication devices, such as a cellular phone, a cellular-enabled tablet computer or cellular-enabled notebook computer, a cellular-enabled wearable device, an automobile, or other vehicle employing cellular services (e.g., for navigation, provision of entertainment services, in-vehicle mobile hotspots, etc.), and so on. In at least some embodiments, the UE 102 employs a single RAT 108. In other embodiments, the UE 102 is a multi-mode UE that employs multiple RATs 108 (illustrated as RAT 108-1 and RAT 108-2). Examples of multiple RATs include cellular-based RATs, such as a 3GPP LTE RAT, a 3GPP 5G NR RAT, a wireless local-area network (WLAN) RAT, and the like. It should be understood that although FIG. 1 only shows the UE 102 implementing two different RATs 108, the UE 102, in at least some implementations, implements three or more different RATs 108. In at least some embodiments, one or more RAT modules 110 (illustrated as RAT module 110-1 and RAT module 110-2) manage the RAT s 108 and enable communication between the UE 102 and the radio access technology of the network 100. The one or more RAT modules 110, in at least some embodiments, include one or more of a modem chipset(s) of the UE 102, a protocol stack(s), driver software, and the like.

[0041] In at least some embodiments, the BSs 104 are implemented in a macrocell, microcell, small cell, picocell, and the like, or any combination thereof. Examples of base stations 104 include an Evolved Universal Terrestrial Radio Access Network Node B (E-UTRAN Node B), Evolved Node B (eNodeB or eNB), Next Generation (NG or NGEN) Node B (gNode B or gNB), and so on. The BSs 104 communicate with the UE 102 via the wireless links 106, which are implemented using any suitable type of wireless link. The wireless links 106, in at least some embodiments, include a downlink of data and control information communicated from the base stations 104 to the UE 102, an uplink of data and control information communicated from the UE 102 to the BSs 104, or both. In at least some embodiments, the wireless links 106 (or bearers), such as data radio bearers (DRBs) and signal radio bearers (SRBs), are implemented using any suitable communication protocol or standard, or combination of communication protocols or standards, such as 3GPP 4G LTE, 5G NR, and so on.In at least some embodiments, multiple wireless links 106 are aggregated in a carrier aggregation to provide a higher data rate for the UE 102. Also, multiple wireless links 106 from multiple BSs 104 are configured, in at least some embodiments, for coordinated multipoint (CoMP) communication with the UE 102, as well as dual connectivity, such as single-RAT LTE-LTE or NR-NR dual connectivity, or multi-radio access technology (Multi-RAT) dual connectivity (MR-DC) including E-UTRA-NR dual connectivity (EN-DC), NGEN radio access network (RAN) E-UTRA-NR dual connectivity (NGEN-DC), and NR E-UTRA dual connectivity (NE-DC).

[0042] The BSs 104 collectively form a Radio Access Network (RAN) 112, such as an E-UTRAN or 5G NR RAN. The base stations 104 are connected to a core network (CN) 114 (illustrated as CN 114-1 and ON 114-2) via control-plane and userplane interfaces through one or more links 116 (illustrated as link 116-1 and link 116- 2). Depending on the configuration of the mobile cellular network 100, the core network 114 is either an Evolved Packet Core (EPC) network 114-1 or a 5G Core Network (5GC) 114-2. For example, in an E-UTRAN configuration or a 5G non- standalone (NSA) EN-DC configuration, the core network 114 is an EPC network 114-1 that includes, for example, a Mobility Management Entity (MME) 118, a Serving Gateway (SGW) 120, and a Packet Data Network Gateway (PGW) 122. The MME 118 provides control-plane functions, such as registration and authentication of multiple UEs 102, authorization, mobility management, and so on. The SGW 120 transfers user-plane packets related to audio calls, video calls, Internet traffic, and the like. The PGW 122 provides connectivity from the UE 102 to external packet data networks 124, such as the Internet 126 and an Internet Protocol MultimediaSubsystem (IMS) network 128, by being the point of exit and entry of traffic for the UE 102. In a 5G standalone (SA) configuration or an NSA NE-DC or NGEN-DC configuration, the core network 114 is a 5GC network 114-2. The 5GC 114-2 includes, for example, an Access and Mobility Management function (AMF) 130, a User Plane Function (UPF) 132, and a Session Management Function (SMF) 134. The AMF 130 provides control-plane functions such as registration and authentication of multiple UEs 102, authorization, mobility management, and so on. The UPF 132 transfers user-plane packets related to audio calls, video calls, Internet traffic, and the like. The SMF 134 manages protocol data unit (PDU) sessions.

[0043] In at least some embodiments, the core network 114 communicatively couples the UE 102 to an IMS network 128 via the RAN 112. The IMS network 128 provides various IMS services to the UE 102, such as IMS short messages, IMS unstructured supplementary service data (USSD), IMS value-added service data, IMS supplementary service data, IMS voice calls, and IMS video calls. To this end, an entity (e.g., a server or a group of servers) operating in the IMS network 128 supports packet exchange with the UE 102. The packets convey signaling (such as session initiation protocol (SIP) messages, IP messages, or other suitable messages) as well as data (or media), such as voice or video. In at least some embodiments, the IMS network includes entities (not shown) such as a Proxy Call Session Control Function (P-CSCF), an Interrogating Call Session Control Function (l-CSCF), a Serving Call Session Control Function (S-CSCF), a Home Subscriber Server (HSS), a Media Gateway Control Function (MGCF), and the like.

[0044] The UE 102 establishes a network session (e.g, a PDP, PDN, or PDU session) with the network 100 to facilitate a managed and consistent connection for transferring data between itself and the network’s data services, such as the internet or other network applications. For example, the UE 102 sends a network session establish request (also referred to herein as “network session request”) for an indicated session type (e.g., IPv4, IPv6, or IPv4v6) to the network 100. If the network’s current protocol deployment configuration supports the requested session type, the network 100 responds with a network session accept message, and the UE 102 proceeds to establish data connections under the parameters set by the accepted network session, utilizing the specified IP (or non-IP) type for all subsequent data transfers.

[0045] However, in some instances, the network’s current protocol deployment does not support the session type being requested by the UE 102. For example, the UE 102 may request a PDU IPv4 session, but the current protocol deployment of the network 100 may only support IPv6 PDU sessions. In these instances, the network 100 responds to the UE’s network session request with a rejection message including a cause code, which typically is a numerical or symbolic value specified by the network 100 indicating the reason for a transaction failure, such as a session orconnection establishment rejection. Examples of cause codes, which are defined by 3GPP technical specifications such as TS 24.008, TS 24.301 , and TS 24.501 , include #32 (Service option not supported), #33 (Requested service option not subscribed), #50 (PDU session type IPv4 only allowed), #51 (PDU session type IPv6 only allowed), #57 (PDU session type IPv4v6 only allowed), #58 (PDU session type Unstructured only allowed), or #61 (PDU session type Ethernet only allowed). However, other cause codes are applicable as well. If the UE 102 receives multiple cause codes for various session types, under 3GPP standards and specifications, the UE 102, in many instances, is prevented from establishing any network sessions until one or more session reset actions (e.g., registering to a new PLMN, device switch-off, SIM or USIM changes, or a change in the PDP type used to access the APN) are performed. This strict adherence to the 3GPP standards and specifications results in extended connectivity disruptions and poor user experience.

[0046] Therefore, the UE(s) 102 of one or more embodiments employs at least one cause code handling mechanism 136 that dynamically handles cause codes or network protocol deployment changes such that the UE is able to establish a network session using a previously barred IP or non-IP (e.g., Ethernet) session type. For example, FIG. 2 illustrates various example configurations employed singularly or in various combinations by the UE 102 as part of the cause code handling mechanism 136 in accordance with at least some embodiments. These configurations, in at least some embodiments, include a normal or default configuration 202, a Latest_And_Forget (LAF) configuration 204, a Service_Option_Retry (SOR) configuration 206, a Dual_Stack (DS) configuration 208, an lndication_Based (IB) configuration 210, and a Capability_Detection (CD) configuration 212.

[0047] The cause code handling mechanism 136 implements one of these configurations depending on whether a management condition(s) for a network session type is satisfied or not satisfied. For example, if a received cause code is not of a specified type, such as an “only allowed” cause code (e.g., 3GPP cause codes #50, #51 , #57, #58, and #61) or an equivalent code (e.g., 3GPP cause codes #32 and #33), or is the first / initial cause code received for the current network conditions, the cause code handling mechanism 136 implements the normal cause codehandling configuration 202. In this configuration, the cause code handling mechanism 136 operations according to one or more 3GPP standards or specifications. For example, if the cause code indicates that the UE’s IPv4 network session request was rejected because only IPv6 sessions are allowed, the cause code handling mechanism 136 implements the normal cause code handling configuration 202 such that IPv4 network session and connection requests are barred until the current network conditions change or one or more session reset actions are performed by the UE 102.

[0048] The cause code handling mechanism 136 implements the LAF configuration 204 in response to one or more network session type management conditions being satisfied, such as receiving a new cause code from a first set of cause codes (e.g., 3GPP cause codes #50, #51 , #57, #58, and #61) after at least one cause code from the first set of cause codes was previously received for a different network session request. For example, if the UE 102 previously received a cause code (e.g., #51) indicating that only IPv6 sessions are allowed in response to requesting an IPv4 session and then receives a new cause code (e.g., #50) indicating that only IPv4 sessions are allowed in response to requesting an IPv4 session, the cause code handling mechanism 136 implements the LAF configuration 204. In this configuration, the cause code handling mechanism 136 applies the network’s current restrictions or capabilities and removes the restrictions resulting from one or more previous cause codes. Stated differently, the UE 102 allows session types previously prohibited as a result of receiving a previous cause code(s). In the example provided above, the cause code handling mechanism 136 prohibits IPv6 sessions and connections as stipulated by the new cause code (e.g., #51) but removes the restrictions for IPv4 sessions or connections resulting from previously received cause codes (e.g., #50). Stated differently, the UE 102 now allows the previously prohibited IPv4 sessions or connections.

[0049] The cause code handling mechanism 136 implements the SOR configuration 206 in response to one or more network session type management conditions being satisfied, such as receiving a new cause code from a second set of cause codes (e.g., 3GPP cause codes #32 and #33) after at least one cause code from thesecond set of cause codes was previously received for a different network session request. For example, in some instances, the network 100 is a legacy network that does not implement cause codes explicitly indicating the allowed session type. Instead, the network 100 implements the second set of cause codes indicating that a requested service option is not supported or not subscribed to in response to the UE 102 requesting a session type that does not match the current network protocol deployment configuration of the network 100. For example, if the UE 102 requests an IPv4 network session but the network 100 only supports an IPv6 network session, the network 100 responds with, for example, a cause code (#32) indicating the requested service option is not available. In this configuration, similar to the LAF configuration 204, the cause code handling mechanism 136 applies the network’s current restrictions or capabilities and removes the restrictions resulting from one or more previous cause codes.

[0050] The cause code handling mechanism 136, in at least some embodiments, implements the DS configuration 208 instead of, or in addition to, the other cause code configurations described herein in response to one or more network session type management conditions being satisfied, such as receiving a cause code from the first set of cause codes or second set of cause codes. In this configuration, when the UE 102 receives a cause code from the first set of cause codes or second set of cause codes in response to a current network session request, the cause code handling mechanism 136 uses a predefined session type, such as a dual-stack (e.g., IPv4v6) session type, when attempting to establish a subsequent network session.

[0051] The cause code handling mechanism 136 implements the IB configuration 210 in response to one or more network session type management conditions being satisfied, such as receiving an indication from the network 100 signaling a change in a network protocol deployment configuration. For example, the network 100 sends an indication to the UE 102 that it has changed from an IPv6 configuration to an IPv4 configuration. In this configuration, the cause code handling mechanism 136 applies the network’s current restrictions or capabilities and removes the restrictions resulting from one or more previous cause codes, as described above.

[0052] The cause code handling mechanism 136 implements the CD configuration 212 in response to one or more network session type management conditions being satisfied, such as detecting a UE or network capability change that historically triggers a modification of the network protocol deployment configuration at the network 100. Examples of UE capability changes include RAT switching (e.g., switching from LTE to 5G or vice-versa), software updates (e.g., firmware or operating system upgrades), hardware upgrades or replacements (e.g., network interface card (NIC) changes), SIM or USIM card updates, network setting adjustments, a combination thereof, and the like. Examples of network capability changes include infrastructure upgrades or downgrades, policy changes, vendor changes, resource management, security changes, client requirement changes, a combination thereof, and the like. In this configuration, the cause code handling mechanism 136 applies the network’s current or expected session type restrictions and removes the restrictions resulting from one or more previous cause codes, as described above.

[0053] FIG. 3 illustrates an example device diagram 300 of a UE 102. In at least some embodiments, the device diagram 300 describes a UE that implements the adaptive cause code handling techniques described herein. The UE 102 may include additional functions and interfaces that are omitted from FIG. 3 for the sake of clarity. The UE 102, in at least some embodiments, includes antennas 302, a radio frequency (RF) front end 304, and one or more RF transceivers 306 (e.g., a 3GPP 4G LTE transceiver 306-1 and a 3G NR transceiver 306-2) for communicating with one or more base stations 104 in a RAN 112, such as a 3G RAN, an E-UTRAN, a combination thereof, and so on. In at least some embodiments, the RF transceivers 306 are RF modems and, thus, are also referred to herein as “RF modem 306”. The RF front end 304, in at least some embodiments, includes a transmitting (Tx) front end 304-1 and a receiving (Rx) front end 304-2. The Tx front end 304-1 includes components such as one or more power amplifiers (PA), drivers, mixers, filters, and so on. The Rx front end 304-2 includes components such as low-noise amplifiers (LNAs), mixers, filters, and so on. The RF front end 304, in at least some embodiments, couples or connects the one or more RF transceivers 306, such as theLTE transceiver 306-1 and the 3G NR transceiver 306-2, to the antennas 302 to facilitate various types of wireless communication.

[0054] In at least some embodiments, the antennas 302 of the UE 102 include an array of multiple antennas configured similarly to or different from each other. The antennas 302 and the RF front end 304, in at least some embodiments, are tuned to or are tunable to one or more frequency bands, such as those defined by the 3GPP LTE, 3GPP 3G NR, IEEE wireless local area network (WLAN), IEEE wireless metropolitan area network (WMAN), or other communication standards. In at least some embodiments, the antennas 302, the RF front end 304, the LTE transceiver 306-1 , and the 3G NR transceiver 306-2 are configured to support beamforming (e.g., analog, digital, or hybrid) or in-phase and quadrature (l / Q) operations (e.g., I / Q modulation or demodulation operations) for the transmission and reception of communications with one or more base stations 104. By way of example, the antennas 302 and the RF front end 304 operate in sub-gigahertz bands, sub-6 GHz bands, above 6 GHz bands, or a combination of these bands defined by the 3GPP LTE, 3GPP 3G NR, or other communication standards.

[0055] In at least some embodiments, the antennas 302 include one or more receiving antennas positioned in a one-dimensional shape (e.g., a line) or a two- dimensional shape (e.g., a triangle, a rectangle, or an L-shape) for implementations that include three or more receiving antenna elements. While the one-dimensional shape enables the measurement of one angular dimension (e.g., an azimuth or an elevation), the two-dimensional shape enables two angular dimensions to be measured (e.g., both azimuth and elevation). Using at least a portion of the antennas 302, the UE 102 can form beams that are steered or un-steered, wide or narrow, or shaped (e.g., as a hemisphere, cube, fan, cone, or cylinder). The one or more transmitting antennas may have an un-steered omnidirectional radiation pattern or may produce a wide steerable beam. Either of these techniques enables the UE 102 to transmit a radio signal to illuminate a large volume of space. In some embodiments, the receiving antennas generate thousands of narrow steered beams (e.g., 2000 beams, 4000 beams, or 6000 beams) with digital beamforming to achieve desired levels of angular accuracy and angular resolution.

[0056] The UE 102, in at least some embodiments, includes one or more sensors 308 implemented to detect various properties such as one or more of temperature, supplied power, power usage, battery state, and the like. Examples of sensors include a thermal sensor, a battery sensor, a power usage sensor, and so on.

[0057] The UE 102 also includes at least one processor 310. The processor 310, in at least some embodiments, is a single-core processor or a multiple-core processor composed of a variety of materials, such as silicon, polysilicon, high-K dielectric, copper, and so on. In at least some embodiments, the processor 310 is implemented at least partially in hardware, including, for example, components of an integrated circuit or a system-on-a-chip (SoC), a digital-signal-processor (DSP), an applicationspecific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), other implementations in silicon or other hardware, or a combination thereof.

[0058] Examples of the processor(s) 310 include a communication processor, an application processor, microprocessors, DSPs, controllers, and so on. A communication processor, in at least some embodiments, is implemented as a modem baseband processor, software-defined radio module, configurable modem (e.g., multi-mode, multi-band modem), wireless data interface, wireless modem, or so on. In at least some embodiments, a communication processor supports one or more of data access, messaging, or data-based services of a wireless network, as well as various audio-based communication (e.g., voice calls). An application processor, in at least some embodiments, provides computing resources to applications executing on the UE 102. For example, an application provides a self-contained operating environment that delivers system capabilities (e.g., graphics processing, memory management, and multimedia processing) to support applications executing on the UE 102.

[0059] The UE 102 further includes a non-transitory computer-readable storage media 312 (CRM 312). The computer-readable storage media described herein excludes propagating signals. The CRM 312, in at least some embodiments, includes 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 useable to store device data 314 of the UE 102. In at least some embodiments, the device data 314 includes user data, multimedia data, beamforming codebooks, applications 316, a user interface(s) 318, an operating system of the UE 102, and so on, which are executable by the processor(s) 310 to enable user-plane communication, control-plane signaling, and user interaction with the UE 102. The user interface 318, in at least one embodiment, is configured to receive inputs from a user of the UE 102. In at least some embodiments, the user interface 318 includes a graphical user interface (GUI) that receives the input information via a touch input. In other instances, the user interface 318 includes an intelligent assistant that receives the input information via an audible input or speech. Alternatively, or additionally, the operating system of the UE 102 is maintained as firmware or an application on the CRM 312 and executed by the processor(s) 310.

[0060] The CRM 312, in at least some embodiments, includes either or both of a communication manager 320 or a network session manager 322, and also includes network management settings 324. Alternatively, or additionally, either or both of the communication manager 320 or the network session manager 322, in at least some embodiments, is implemented in whole or part as hardware logic or circuitry integrated with or separate from other components of the UE 102. In at least some embodiments, the communication manager 320 configures the RF front end 304, the LTE transceiver (modem) 306-1 , the 3G NR transceiver (modem) 306-2, or a combination thereof to perform one or more wireless communication operations. The network session manager 322, in at least some embodiments, implements the cause code handling mechanisms(s) 136 described above with respect to FIG. 1 and FIG. 2 to dynamically handle cause codes or network protocol deployment changes.

[0061] The network management settings 324, in at least some embodiments, include, for example, a set of network configurations and local policies, session states, and the like and govern the behavior of the UE 102 when interacting with the network 100 or other networks. These settings 324 are used by the UE 102 when establishing, managing, and terminating various types of network sessions. For example, the UE 102 uses the network management settings 324 to determine thetype of session to establish, how to manage the session once it is established, and which types of sessions are barred or prohibited based on specific cause codes.

[0062] The set of network configurations and local policies define the behavior of the UE 102 in response to various network events, such as changes in network availability, resource allocation, or service offerings. As an example, a local policy dictates that the UE 102 should always establish an IPv6 PDU session when connecting to a specific network operator, whereas another policy specifies that the UE 102 should only use IPv4 for certain types of traffic. The session states refer to the current state of an established network session, which is characterized by various parameters, such as a session identifier (ID), IP address, port numbers, and the like. The UE 102 uses session states to manage ongoing sessions, including maintaining connection-oriented relationships with the network 100, tracking changes in session availability or quality, and making decisions about when to terminate a session.

[0063] In the context of cause codes, the UE 102 uses the network management settings 324 to determine which types of sessions are barred or prohibited based on specific conditions. Cause codes are numerical values assigned to specific events or errors that occur during a network session, such as incorrect session type, errors in packet delivery or session timeouts. The UE 102 uses these cause codes to consult its local policies and configurations, determining whether the session should be terminated or re-established based on the specific cause code received. For instance, if the UE 102 receives a cause code indicating an error in IPv6 packet delivery, the UE 102, in some instances, uses this information to re-establish the session using IPv4 instead. Conversely, if the UE 102 receives a cause code indicating that the network is experiencing congestion, the UE 102, in some instances, uses its local policies and configurations to throttle or terminate the session to prevent further resource utilization.

[0064] Additionally, the UE 102, in some instances, receives an "only allowed" cause code, such as 3GPP cause code #50, #51 , #57, #58, or #61 , which indicates that only a specific type of traffic or service is permitted on the network, or an equivalent legacy cause code, such as 3GPP cause code #32 or #33. In response, the UE 102 uses its local policies and configurations to restrict the type of sessionbeing established to ensure compliance with the network's requirements. For example, if the UE 102 receives cause code #50 indicating that only IPv4 sessions are allowed, the UE 102 updates its network management settings 324 to prohibit the session type to only IPv4. Stated differently, the UE 102 updates the network management settings 324 to ensure that all subsequent session establishment attempts are configured for IPv4 compatibility. This involves, for example, adjusting the session establishment procedures to exclude IPv6 or dual-stack configurations and ensuring that all data transmissions conform to IPv4 protocol requirements. Similarly, if the UE 102 receives cause code #51 indicating that only IPv6 sessions are allowed, the UE 102 updates the network management settings 324 to restrict the session type to only permit IPv6. The UE 102, in at least some embodiments, similarly updates the network management settings 324 in response to receiving an indication from the network 100 signaling a change in a network protocol deployment configuration or detecting a UE or network capability change that historically triggers a modification of the network protocol deployment configuration at the network 100.

[0065] In at least some embodiments, the network management settings 324 also identify one or more network session type management conditions to be satisfied for adaptatively handling cause codes and affected network session types. An example of management condition for a network session type includes the UE 102 receiving a cause code for a network session request specifying a second session type after a first session type was prohibited as a result of receiving a first cause code. Another example includes a first session type being prohibited as a result of the UE 102 previously receiving a first cause code and the UE 102 subsequently receiving a second cause code indicating that the first session type is allowed. An additional example includes a first session type being prohibited as a result of the UE 102 receiving a first cause code and the UE 102 subsequently receiving a second cause code indicating that a requested service option is not available or the requested service option is not subscribed to in response requesting a network session specifying a second session type. A further example includes a first cause code prohibiting a first session type and a second cause code prohibiting a second session type being different cause codes but having the same cause code type (e.g., 3GPP TS 24.008 codes or 3GPP 24.501 codes). Another example includes the UE 102receiving an indication from the network 100 that its network protocol deployment configuration has changed. An additional example includes the UE 102 detecting a capability change of the UE 102 or the network 100.

[0066] FIG. 4 to FIG. 8 illustrate various transaction diagrams for the adaptively handling cause codes at the UE 102 based on one or more network session type management conditions being satisfied. For example, FIG. 4 illustrates a transaction diagram 400 showing an example of the network session manager 322 implementing a first cause code handling configuration, such as the LAF configuration 204, in response to management condition (s) for a network session type being satisfied, such as the UE 102 receiving multiple “only allowed” cause codes for various network session establish attempts. It should be understood that other transactional sequences than those illustrated in FIG. 4 are also applicable to the techniques described herein.

[0067] After the UE 102 has attached to and authenticated itself with the network 100, the UE 102 sends (402) a first network session request 401 to the network 100 for establishing a network session of a first type (e.g., IPv4). This request 401 includes, for example, details, such as the desired Quality of Service (QoS) and the network identifier (e.g., the Data Network Name (DNN) for PDU sessions or the Access Point Name (APN) for PDN and PDP sessions), that specify the network services the UE 102 wants to connect to. In this example, the network 100 responds (404) with a first network session reject message 403 including a first “only allowed” cause code (e.g., 3GPP TS 24.501 cause #51) indicating that only a network session of a second type (e.g., IPv6) is allowed.

[0068] In response to receiving the first reject message 403, the network session manager 322 of the UE 102 implements (406) the normal or default cause code handling configuration 202 as this is the first cause code received by the UE 102. Stated differently, the network session manager 322 determines that other session types are not currently prohibited. In the normal cause code handling configuration 202, the network session manager 322 operates according to one or more 3GPP standards or specifications, such as TS 24.008, TS 24.301 , and TS 24.501 . For example, the network session manager 322 blocks any attempts to establish networksessions or connections using at least the first session type and only allows attempts to establish network sessions or connections that use the second session type.

[0069] In at least some embodiments, the network session manager 322 restricts session types based on the received cause code by updating (408) the network management settings 324 to indicate that sessions of the first session type are prohibited. For example, the network session manager 322 updates one or more registers, sets one or more flags, modifies configuration parameters, updates policy rules, reconfigures network interfaces, updates application rules or policies, a combination thereof, and the like. In response to receiving the first reject message 403, the UE 102 sends (410) a second network session request 405 to the network 100 to establish a network session of the second type (e.g., IPv6). In this example, the network 100 responds (412) with a first network session accept message 407 and the network session is established between the UE 102 and the network 100.

[0070] At a later point in time, the UE 102 determines (416) that the current network should be re-established or a new network session should be requested. The network session manager 322 processes the network management settings 324 to determine the session types that are prohibited or allowed, if any. In the current example, the network session manager 322 determines that the second session type is the most recently allowed session type. Therefore, the UE 102 sends (418) a third network session request 409 to the network 100 for establishing a network session of the second type. However, prior to sending the third network session request 509, the network 100 changed or updated (414) its network protocol deployment configuration. In this example, the network protocol deployment configuration changed from the second session type (e.g., IPv6) back to the first session type (e.g., IPv4). Therefore, the network 100 responds (520) with a second network session reject message 411 including a second “only allowed” cause code (e.g., 3GPP TS 24.501 cause #50) indicating that only a network session of the first type (e.g., IPv4) is allowed.

[0071] In response to receiving the second “only allowed” cause code, a conventionally configured UE implementing a normal cause code handling configuration would typically be unable to initiate any additional network sessionssince the network 100 previously prohibited both the first session type (e.g., IPv4) and the second session type (IPv6). However, in response to receiving the second “only allowed” cause code, the UE 102 of one or more embodiments adapts (422) its handling of cause codes. For example, the network session manager 322 changes from the normal (or another) cause code handling configuration 202 to the LAF configuration 204 in response to receiving the second “only allowed” cause code. In this configuration 204, the network session manager 322 updates (424) the network management settings 324 to indicate that the sessions of the second session type are prohibited and to remove the restrictions previously applied to sessions of the first session type. Stated differently, the network session manager 322 allows sessions of the first session type in response to receiving the second “only allowed” cause code.

[0072] As such, in response to adapting its cause code handling configuration, the UE 102 does not need to wait for the network 100 to remove the previous session type restrictions or perform a session reset action. Instead, the UE 102 sends (426) a fourth network session request 413 to the network 100 for establishing a network session of the first type (e.g., IPv4). In this example, the network 100 responds (428) with a second network session accept message 415 and the network session is established between the UE 102 and the network 100 using the previously prohibited session type.

[0073] FIG. 5 illustrates a transaction diagram 500 showing an example of the network session manager 322 implementing a second cause code handling configuration, such as the SOR configuration 206, in response to a management condition(s) for a network session type being satisfied, such as the UE 102 receiving multiple legacy cause codes for various network session establish attempts. It should be understood that other transactional sequences than those illustrated in FIG. 5 are also applicable to the techniques described herein.

[0074] After the UE 102 has attached to and authenticated itself with the network 100, the UE 102 sends (502) a first network session request 501 to the network 100 for establishing a network session of a first type (e.g., IPv4). In this example, the network 100 responds (504) with a first network session reject message 503 including a first legacy cause code (e.g., 3GPP TS 24.008 cause #32) indicating thatthe requested service option (e.g., IPv4) is not supported. In response to receiving the first reject message 503, the network session manager 322 of the UE 102 implements (506) the normal or default cause code handling configuration 202, as this is the first cause code received by the UE 102. Stated differently, the network session manager 322 determines that other session types are not currently prohibited.

[0075] As described above with respect to FIG. 4, in the normal cause code handling configuration 202, the network session manager 322 operates according to one or more 3GPP standards or specifications, such as TS 24.008, TS 24.301 , and TS 24.501 , such that the network session manager 322 blocks any attempts to establish network sessions or connections using the first session type. For example, the network session manager 322 updates the network management settings 324 to indicate that sessions of the first session type are prohibited. In response to receiving the first reject message 503, the UE 102 sends (510) a second network session request 505 to the network 100 to establish a network session of the second type (e.g., IPv6). In this example, the network 100 responds (512) with a first network session accept message 507 and the network session is established between the UE 102 and the network 100.

[0076] At a later point in time, the UE 102 determines (516) that one or more session re-establish conditions have been satisfied or that a new network session should be requested, similar to that described above with respect to FIG. 4. In response, the network session manager 322 processes the network management settings 324 to determine the session types that are prohibited or allowed, if any. In the current example, the network session manager 322 determines that the second session type is the most recently allowed session type. Therefore, the UE 102 sends (518) a third network session request 509 to the network 100 for establishing a network session of the second type. However, prior to sending the third network session request 509, the network 100 changed or updated (514) its network protocol deployment configuration. In the current example, the network protocol deployment configuration changed from the second session type (e.g., IPv6) back to the first session type (e.g., IPv4). Therefore, the network 100 responds (520) with a secondnetwork session reject message 411 including a second legacy cause code (e.g., 3GPP TS 24.008 cause #32) indicating that the requested service option (e.g., IPv6) is not supported.

[0077] As described above with respect to FIG. 4, in response to receiving the second legacy cause code, a conventionally configured UE implementing a normal cause code handling configuration would typically be unable to initiate any additional network sessions since the network 100 previously prohibited both the first session type (e.g., IPv4) and the second session type (IPv6). However, in response to receiving the second legacy cause code, the UE 102 of one or more embodiments adapts (522) its handling of cause codes. For example, the network session manager 322 changes from the normal (or another) cause code handling configuration 202 to the SOR configuration 206 in response to receiving the second legacy cause code. In this configuration 206, the network session manager 322 updates (524) the network management settings 324 to indicate that sessions of the second session type are prohibited and to remove the restrictions previously applied to sessions of the first session type. Stated differently, the network session manager 322 allows sessions of the first session type in response to receiving the second legacy cause code.

[0078] As such, in response to adapting its cause code handling configuration, the UE 102 does not need to wait for the network 100 to remove the previous session type restrictions or perform a session reset action. Instead, the UE 102 sends (526) a fourth network session request 513 to the network 100 for establishing a network session of the first type (e.g., IPv4). In this example, the network 100 responds (528) with a second network session accept message 515 and the network session is established between the UE 102 and the network 100 using the previously prohibited session type.

[0079] FIG. 6 illustrates a transaction diagram 600 showing an example of the network session manager 322 implementing a third cause code handling configuration, such as the dual-stack configuration 208, in response to a management condition(s) for a network session type being satisfied, such as the UE 102 receiving a cause code for a network session establish attempt. It should beunderstood that other transactional sequences than those illustrated in FIG. 6 are also applicable to the techniques described herein. After the UE 102 has attached to and authenticated itself with the network 100, the UE 102 sends (602) a first network session request 601 to the network 100 for establishing a network session of a first type (e.g., IPv4). In this example, the network 100 responds (604) with a first network session reject message 503 including a cause code (e.g., 3GPP TS 24.501 cause #51 or 3GPP TS 24.008 cause #32) indicating, for example, that only a specific session type is allowed (e.g., IPv6) or the requested service option (e.g., IPv4) is not supported.

[0080] In response to receiving the reject message 603, the network session manager 322 of the UE 102 adaptively (606) manages the cause code by implementing the dual-stack configuration 208. In response (or prior) to implementing the dual-stack configuration 208, the network session manager 322 updates (608) the network management settings 324 to indicate that sessions of the first session type are prohibited, as described above with respect to FIG. 4 and FIG. 5. The UE 102 then proceeds to send (610) a second network session request 605 to the network 100 using a predefined session type (e.g., IPv4v6). In other words, instead of determining which session type(s) is allowed based on the received cause code and, in at least some embodiments, the network management settings 324, the UE 102 is configured to use a predefined session type for the next network session attempt after receiving a reject message with a cause code.

[0081] In the current example, the network 100 responds (612) with a network session accept message 607, and the network session is established between the UE 102 and the network 100. However, in some instances, the network 100 may respond with another network session rejection message and cause code. In these instances, the network session manager 322 adapts the handling of the cause code by entering into the normal cause code handling configuration 202, the LAF configuration 204, or the SOR configuration 206 and operates as described above with respect to FIG. 4 or FIG. 5.

[0082] FIG. 7 illustrates a transaction diagram 700 showing an example of the network session manager 322 implementing a fourth cause code handlingconfiguration, such as the IB configuration 210, in response to a management condition(s) for a network session type being satisfied, such as the UE 102 receiving an indication from the network 100 that its network protocol deployment configuration has changed. It should be understood that other transactional sequences than those illustrated in FIG. 7 are also applicable to the techniques described herein. After the UE 102 has attached to and authenticated itself with the network 100, the UE 102 sends (702) a first network session request 701 to the network 100 for establishing a network session of a first type (e.g., IPv4). In this example, the network 100 responds (704) with a first network session reject message 703 including a cause code (e.g., 3GPP TS 24.501 cause #51 or 3GPP TS 24.008 cause #32) indicating, for example, that only a specific session type is allowed (e.g., IPv6) or the requested service option (e.g., IPv4) is not supported. In response to receiving the reject message 703, the network session manager 322 of the UE 102 implements (706) the normal or default cause code handling configuration 202, as this is the first cause code received by the UE 102. Stated differently, the network session manager 322 determines that other session types are not currently prohibited.

[0083] As described above with respect to FIG. 4, in the normal cause code handling configuration 202, the network session manager 322 operates according to one or more 3GPP standards or specifications, such as TS 24.008, TS 24.301 , and TS 24.501 , such that the network session manager 322 blocks any attempts to establish network sessions or connections using the first session type. For example, the network session manager 322 updates the network management settings 324 to indicate that sessions of the first session type are prohibited. In response to receiving the reject message 703, the UE 102 sends (710) a second network session request 705 to the network 100 for establishing a network session of the second type (e.g., IPv6). In this example, the network 100 responds (712) with a first network session accept message 707 and the network session is established between the UE 102 and the network 100.

[0084] In the current example, after the UE 102 has established the network session, the network 100 sends (714) an indication 709 that its network protocol configuration has changed. For example, the indication 709 informs the UE 102 thatthe network protocol deployment configuration changed from the second session type (e.g., IPv6) back to the first session type (e.g., IPv4). Examples of the indication 709 include system information broadcasts (SIBs), Master Information Blocks (MIBs), Radio Resource Control (RRC) signals or messages, Non-Access Stratum (NAS) signals or messages, Mobility Management (MM) signals or messages, Session Management (SM) signals or messages, User Radio Session Policy (URSP) signals or messages, bearer modification requests, PDU session modification requests, rejection messages with cause codes over-the-air (OTA) updates, other 3GPP configuration protocols such as Open Mobile Alliance Device Management (OMADM) messages, push-type messages such as Short Message Service (SMS) messages, a combination thereof, and the like.

[0085] In response to receiving this indication 709, the UE 102 adapts (716) its handling of cause codes. For example, the network session manager 322 changes from the normal (or another) cause code handling configuration 202 to the IB configuration 210. In this configuration 210, the network session manager 322 updates (718) the network management settings 324 to indicate that sessions of the second session type are prohibited and to remove the restrictions previously applied to the first session type. Stated differently, the network session manager 322 allows sessions of the first session type in response to receiving the indication 709 that the network protocol configuration has changed. In at least some embodiments, in response to receiving the indication 709, the network session manager 322 automatically updates its handling of cause codes or prompts a user to provide input for updating its handling of cause codes.

[0086] As such, in response to adapting its cause code handling configuration, the UE 102 does not need to wait for the network 100 to remove the previous session type restrictions or perform a session reset action, as required of conventionally configured UEs. Instead, the UE 102 terminates (720) the current network session, if not already terminated, and sends (722) a third network session request 711 to the network 100 for establishing a network session of the first type (e.g., IPv4). In this example, the network 100 responds (724) with a second network session acceptmessage 713 and the network session is established between the UE 102 and the network 100 using the previously prohibited session type.

[0087] FIG. 8 illustrates a transaction diagram 800 showing an example of the network session manager 322 implementing a fifth cause code handling configuration, such as the CD configuration 212, in response to a management condition(s) for a network session type being satisfied, such as the UE 102 detecting a local capability change or a network capability change. It should be understood that other transactional sequences than those illustrated in FIG. 8 are also applicable to the techniques described herein. After the UE 102 has attached to and authenticated itself with the network 100, the UE 102 sends (802) a first network session request 801 to the network 100 for establishing a network session of a first type (e.g., IPv4). In this example, the network 100 responds (804) with a first network session reject message 803 including a cause code (e.g., 3GPP TS 24.501 cause #51 or 3GPP TS 24.008 cause #32) indicating, for example, that only a specific session type is allowed (e.g., IPv6) or the requested service option (e.g., IPv4) is not supported. In response to receiving the reject message 803, the network session manager 322 of the UE 102 implements (806) the normal or default cause code handling configuration 202, as this is the first cause code received by the UE 102. Stated differently, the network session manager 322 determines that other session types are not currently prohibited.

[0088] As described above with respect to FIG. 4, in the normal cause code handling configuration 202, the network session manager 322 operates according to one or more 3GPP standards or specifications, such as TS 24.008, TS 24.301 , and TS 24.501 , such that the network session manager 322 blocks any attempts to establish network sessions or connections using the first session type. For example, the network session manager 322 updates the network management settings 324 to indicate that the first session type is prohibited. In response to receiving the reject message 703, the UE 102 sends (810) a second network session request 805 to the network 100 for establishing a network session of the second type (e.g., IPv6). In this example, the network 100 responds (812) with a first network session acceptmessage 807 and the network session is established between the UE 102 and the network 100.

[0089] In the current example, after the UE 102 has established the network session, the network session manager 322 detects a local capability change or a network capability change that is associated with or typically results in a network protocol deployment change at the network 100. Examples of a local capability change at the UE 102 include RAT changes, supported frequency band changes, Multiple Input Multiple Output (MIMO) configuration changes, maximum data rate support changes, NIC upgrades, software or firmware updates, supported frequency band changes, Quality of Service (QoS) parameter changes, and the like. Examples of network capability changes include RAT changes, hardware or software updates, network capacity changes, policy changes, security changes, and the like. In at least some embodiments, the network session manager 322 detects a UE capability change based on an indication (e.g., message, interrupt, flag, register value, etc.) received from one or more components of the UE 102, such as an application, a protocol stack layer, and the like. Examples of a UE capability change include a WiFi state change (e.g., connecting or disconnecting to Wi-Fi), a power saving mode being enabled or disabled from a user interface, a gaming mode being enabled or disabled from a user interface, the RAT disabling information from the modem (e.g., the UE disables LTE or disables 5G in some abnormal conditions), an application preference (e.g., preference to use a specific IP version), or network operator data connection preference (e.g., a network operator requests that the UE uses IPv6 for the mobile data connection in home network).

[0090] The network session manager 322, in at least some embodiments, detects a UE capability change via one or more processes defined at, for example, the IP level. The network session manager 322, in at least some embodiments, detects a network capability change based on an indication (e.g., an over-the-air message, RRC signaling, SM signaling, MM signaling, and the like) received from the network, an indication (e.g., message, interrupt, flag, register value, etc.) received from one or more components (e.g., an application, a protocol stack layer, a combination thereof,and the like) of the UE 102, detecting different bands, detecting locations, network defined timelines (e.g., upgrade timelines), a combination thereof, and the like.

[0091] In at least some embodiments, when the network session manager 322 detects a UE capability change or network capability change, the network session manager 322 processes the network management settings 324 or other information to determine if the detected change is mapped to a network protocol deployment change at the network 100. Stated differently, the network session manager 322 determines if the detected change historically results in a network protocol deployment change at the network 100. The network session manager 322, in at least some embodiments, also determines how the network protocol deployment is typically changed by the network (e.g., from IPv4 to IPv6, from IPv6 to IPV6, etc.).

[0092] If the detected capability change typically results in a network protocol deployment change at the network 100, the network session manager 322 adapts (816) its handling of cause codes. For example, the network session manager 322 changes from the normal (or another) cause code handling configuration 202 to the CD configuration 212. In this configuration 212, the network session manager 322 updates (818) the network management settings 324 based on the expected (or detected) network protocol deployment change. In the current example, the network session manager 322 expects the network 100 to change its network protocol deployment change from IPv6 to IPv4 in response to a capability change detected at the UE 102. Therefore, in this example, the network session manager 322 updates the network management settings 324 to indicate that sessions of the second session type (e.g., IPv6) are prohibited and to remove the restrictions previously applied to the first session type. Stated differently, the network session manager 322 allows sessions of the first session type in response to detecting the UE or network capability change.

[0093] As such, in response to adapting its cause code handling configuration, the UE 102 is able to dynamically adapt to an expected network protocol deployment change at the network 100 and does not need to wait for the network 100 to remove the previous session type restrictions or perform a session reset action, as required of conventionally configured UEs. Instead, the UE 102 terminates (820) the currentnetwork session, if not already terminated, and sends (822) a third network session request 809 to the network 100 for establishing a network session of the first type (e.g., IPv4). In this example, the network 100 responds (824) with a second network session accept message 811 and the network session is established between the UE 102 and the network 100 using the previously prohibited session type.

[0094] FIG. 9 is a diagram illustrating an example method 900 of a UE 102 adaptively handling cause codes in accordance with at least some embodiments. The processes described below with respect to method 900 have been described above in greater detail with reference to FIG. 1 to FIG. 8. It should be understood that method 900 is not limited to the sequence of operations shown in FIG. 9, as at least some of the operations can be performed in parallel or in a different sequence. Moreover, in at least some embodiments, method 900 can include one or more different operations than those shown in FIG. 9.

[0095] At block 902, the UE 102 sends a network session request to the network 100 specifying a session type (e.g., IPv4). At block 904, the UE 102 determines if a network session reject message was received from the network 100 in response to the network session request. At block 906, if an accept message was received from the network 100, the requested network session having the specified session type is established between the UE 102 and the network 100. At block 908, if a reject message with a cause code was received from the network 100, the UE 102 determines if any network session type management conditions are satisfied, such as other session types being currently prohibited based on previous cause codes received from the network 100. At block 910, if other session types are not currently prohibited (e.g., a management condition is not satisfied), the UE 102 implements a normal cause code handling configuration 202 for handling the cause code, as described above with respect to FIG. 2 to FIG. 8. At block 912, the UE 102 updates its network management settings 324 based on the received cause code to prohibit sessions of the specified session type. The flow then returns to block 902, and the UE 102 sends a new network session request to the network specifying a different session type.

[0096] At block 914, if other session types are currently prohibited (e.g., a management condition is satisfied), the UE 102 implements an adaptive configuration for handling the cause code, as described above with respect to FIG. 2 to FIG. 8. For example, the UE 102 implements either the LAF configuration 204, the SOR configuration 206, or the DS configuration 208. At block 916, the UE 102 updates its network management settings 324 to prohibit sessions of the specified session type and remove any restrictions previously applied to other session types. Stated differently, the UE 102 allows sessions for previously prohibited session types in response to receiving the cause code. At block 918, the UE 102 sends a new network session request to the network 100 specifying one of the unbarred session types. The flow then returns to block 904, and the process described above is repeated.

[0097] FIG. 10 is a diagram illustrating another example method 1000 of a UE 102 adaptively handling cause codes in accordance with at least some embodiments. The processes described below with respect to method 1000 have been described above in greater detail with reference to FIG. 1 to FIG. 8. It should be understood that method 1000 is not limited to the sequence of operations shown in FIG. 10, as at least some of the operations can be performed in parallel or in a different sequence. Moreover, in at least some embodiments, method 1000 can include one or more different operations than those shown in FIG. 10.

[0098] At block 1002, the UE 102 sends a network session request to the network 100 specifying a session type (e.g., IPv4). At block 1004, the UE 102 receives an accept message from the network 100. It should be understood that if a reject message is received, the UE 102 performs the method described above with respect to FIG. 4 to FIG. 9 for managing the reject message. At block 1006, in response to receiving the accept message, the requested network session having the specified session type is established between the UE 102 and the network 100. At block 1008, the UE 102 determines if a management condition(s) for a network session type is satisfied, such as an indication being received from the network 100 that its network protocol deployment configuration has changed. At block 1010, if this indication has not been received, the UE 102 determines if another network session typemanagement condition(s) is satisfied, such as a UE capability or network capability change having been detected. If a UE or network capability change has not been detected, the flow returns to block 1008, and the UE 102 continues to monitor for a network protocol deployment configuration change indication.

[0099] At block 1012, if a network protocol deployment configuration change indication has been received or a UE or network capability change has been detected, the UE 102 implements an adaptive configuration for handling an expected cause code resulting from the network protocol deployment configuration change or the UE or network capability change, as described above with respect to FIG. 7 or FIG. 8. For example, the UE 102 implements either the IB configuration 210 or the CD configuration 212. At block 1014, the UE 102 updates its network management settings 324 to prohibit the session type for the current session and remove any restrictions previously applied to other session types. Stated differently, the UE 102 allows the first session type in response to receiving the deployment configuration change indication or detecting the UE or network capability change. At block 1016, the UE 102 terminates the current network session or maintains the current network session for an interval of time. At block 1018, the UE 102 sends a new network session request to the network 100 specifying one of the unbarred session types.

[0100] In some embodiments, certain aspects of the techniques described above may be implemented by one or more processors of a processing system executing software. The software comprises one or more sets of executable instructions stored or otherwise tangibly embodied on a non-transitory computer readable storage medium. The software can include the instructions and certain data that, when executed by the one or more processors, manipulate the one or more processors to perform one or more aspects of the techniques described above. The non-transitory computer readable storage medium can include, for example, a magnetic or optical disk storage device, solid state storage devices such as Flash memory, a cache, random access memory (RAM) or other non-volatile memory device or devices, and the like. The executable instructions stored on the non-transitory computer readable storage medium may be in source code, assembly language code, object code, orother instruction format that is interpreted or otherwise executable by one or more processors.

[0101] A computer readable storage medium may include any storage medium, or combination of storage media, accessible by a computer system during use to provide instructions and / or data to the computer system. Such storage media can include, but is not limited to, optical media (e.g., compact disc (CD), digital versatile disc (DVD), Blu-Ray disc), magnetic media (e.g., floppy disc, magnetic tape, or magnetic hard drive), volatile memory (e.g., random access memory (RAM) or cache), non-volatile memory (e.g., read-only memory (ROM) or Flash memory), or microelectromechanical systems (MEMS)-based storage media. The computer readable storage medium may be embedded in the computing system (e.g., system RAM or ROM), fixedly attached to the computing system (e.g., a magnetic hard drive), removably attached to the computing system (e.g., an optical disc or Universal Serial Bus (USB)-based Flash memory), or coupled to the computer system via a wired or wireless network (e.g., network accessible storage (NAS)).

[0102] Note that not all of the activities or elements described above in the general description are required, that a portion of a specific activity or device may not be required, and that one or more further activities may be performed, or elements included, in addition to those described. Still further, the order in which activities are listed are not necessarily the order in which they are performed. Also, the concepts have been described with reference to specific embodiments. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the present disclosure as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present disclosure.

[0103] Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any feature(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature of any or all the claims. Moreover, the particularembodiments disclosed above are illustrative only, as the disclosed subject matter may be modified and practiced in different but equivalent manners apparent to those skilled in the art having the benefit of the teachings herein. No limitations are intended to the details of construction or design herein shown, other than as described in the claims below. It is therefore evident that the particular embodiments disclosed above may be altered or modified and all such variations are considered within the scope of the disclosed subject matter. Accordingly, the protection sought herein is as set forth in the claims below.

Claims

WHAT IS CLAIMED IS:1 . A method at a user equipment (UE) (102) in a cellular network (100), the method comprising: responsive to sending a first network session request (401 , 501 , 601 , 701 . 801 , 901) to the cellular network specifying a first session type, receiving a first network session reject message (403, 503, 603, 703, 803) from the cellular network including a first cause code; prohibiting (408, 508, 608, 708, 808) sessions of the first session type based on the first cause code; and responsive to a management condition for a network session type being satisfied for at least a second session type, prohibiting sessions of the second session type and allowing sessions of the first session type that were previously prohibited (424, 524, 718, 818).

2. The method of claim 1 , further comprising: responsive to allowing sessions of the first session type, sending a third network session request (424, 524, 610, 722, 822) to the cellular network specifying the first session type.

3. The method of claim 1 , further comprising: sending a second network session request to the cellular network specifying the second session type (418, 518); receiving a second network session reject message (420, 520) from the cellular network including a second cause code; and determining that the management condition is satisfied based on the second cause code.

4. The method of claim 3, wherein determining that the management condition is satisfied is further based on receiving the second cause code after sessions of the first session type have been prohibited.

5. The method of claim 3, wherein determining that the management condition is satisfied is further based on sessions of the first session type being prohibited and the second cause code indicating that only sessions of the first session type are allowed.

6. The method of claim 3, wherein determining that the management condition is satisfied is further based on sessions of the first session type being prohibited and the second cause code indicating that a requested service option is unavailable or the LIE is not subscribed to the requested service requested service option.

7. The method of claim 3, wherein determining that the management condition is satisfied is further based on the first cause code and the second cause code being different cause codes but having the same cause code type.

8. The method of claim 3, further comprising: sending the second network session request in response to one or more session re-establish conditions.

9. The method of claim 1 , wherein: prohibiting sessions of the first session type includes updating network management settings to indicate that sessions of the first session type are prohibited; and prohibiting sessions of the second session type and allowing sessions of the first session type includes updating the network management settings to indicate that sessions of the second session type are prohibited and sessions of the first session type are allowed.

10. The method of claim 1 , further comprising: establishing a first network session having the second session type with the cellular network; and after establishing the first network session and in response to receiving an indication (714) from the cellular network that a network protocoldeployment configuration has changed, determining that the management condition is satisfied.11 . The method of claim 10, wherein the indication received from the cellular network indicates that the network protocol deployment configuration has changed from the second session type to the first session type.

12. The method of claim 1 , further comprising: after establishing a first network session having the second session type with the cellular network and in response to detecting a capability change (814) of the UE or the cellular network, determining that the management condition is satisfied.

13. The method of claim 12, wherein the capability change of the UE or the cellular network is a radio access technology change.

14. The method of claim 1 , further comprising: responsive to receiving the first network session reject message including the first cause code, selecting a predefined session type for the second session type from a plurality of session types; and sending a second network session request to the cellular network specifying the second session type.

15. A user equipment (102), comprising: one or more radio frequency (RF) modems (306) configured to wirelessly communicate with at least one network; one or more processors (310) coupled to the one or more RF modems; and at least one memory (312) storing executable instructions, the executable instructions configured to manipulate at least one of the one or more processors or the one or more RF modems to perform the method of any of the preceding claims.

Images