Error handling during IMS registration

In instances where a user equipment (UE) encounters an issue during an attempt to register for Internet Protocol Multimedia Subsystem (IMS) service, the UE is configured with improved logic for handling the encountered issue. For instance, the UE may transmit a multiple unprotected registration requests to multiple different IMS nodes, and may receive multiple registration responses from the multiple different IMS nodes that each specify a type of error in a particular error category, all the while evaluating whether a criterion is met. Upon the criterion being met, the UE can refrain from transmitting any additional unprotected registration requests, thereby alleviating network bandwidth consumption, yet giving the UE a fair chance to successfully register for IMS service.

BACKGROUND

Internet Protocol Multimedia Subsystem (IMS) is an architectural framework defined by the 3rdGeneration Partnership Project (3GPP) for delivering Internet Protocol (IP) multimedia to user equipment (UE) of the IMS network. An IMS core network (sometimes referred to as the “IMS core”, the “Core Network (CN),” or the “IM CN Subsystem”) permits wireless and wireline devices to access IP multimedia, messaging, and voice applications and services. IMS allows for peer-to-peer communications, as well as client-to-server communications over an IP-based network.

Before a UE can utilize IMS-based services, the UE performs a registration procedure, which involves transmitting registration requests to, and receiving registration responses from, the IMS core. During this registration procedure, if there is an issue with registering the UE for service, the IMS core may send the UE a registration response that specifies an error, such as a 403 Forbidden error. Pursuant to 3GPP standards, if the UE receives a 403 Forbidden response to a registration request, the UE is to re-attempt registration. However, this is a suboptimal approach to handling a 403 Forbidden registration response because it may be the case that the issue causing the registration failure will never be resolved, and the UE will never be registered for service, regardless of how many times the UE reattempts registration. Repeated attempts at registration place an undue burden on network resources, especially when many UE's are engaged in the same type of repeated registration reattempts.

Another approach to handling a 403 Forbidden response to a registration request is to refrain from re-attempting registration altogether if the UE receives such an error in a registration response. This is also suboptimal because it may prevent UEs from reattempting registration when these UEs would otherwise successfully register if registration was reattempted. Accordingly, at least some UEs will unduly go without service using this approach. The difficulty in devising a suitable approach to handling a 403 Forbidden response to a registration request lies in the inability of the UE and the IMS core to discern the exact issue that is causing the registration failure, as there may be many possible issues causing a 403 Forbidden registration response.

DETAILED DESCRIPTION

Described herein are techniques and systems for improved handling, by a UE, of issues encountered during registration for IMS-based service. Before establishing a communication session (e.g., a voice call), a UE is configured to carry out a registration procedure by transmitting a registration request(s) to the IMS core. This registration procedure involves the UE initially obtaining a list of IMS nodes (e.g., a list of proxy call session control function (P-CSCF) nodes) that are available to the UE. Such a list of available IMS nodes may be provided by a mobility management entity (MME) as part of a node discovery procedure. The UE can then select a first IMS node in the list of available IMS nodes, and transmit an initial unprotected registration request, such as a SIP request using the REGISTER method.

In response to the unprotected registration request, the UE can receive various types of registration responses from the IMS node. If a requirement exists to send information “integrity protected,” and barring any other issues that cause registration failure, the UE typically receives a 401 Unauthorized challenge (or sometimes a 407 Proxy Authentication Required challenge) in a registration response to the initial unprotected registration request. Upon being challenged, the UE can send an integrity protected registration request with information responding to the challenge. If the information transmitted by the UE in the integrity protected registration is determined by a node in the IMS core to be compliant with existing procedures, the UE may receive a 200 OK registration response from the IMS node and proceed to establish a communication session over the IMS core.

However, in some instances, the UE receives a registration response to the initial unprotected registration request that specifies a particular type of error, such as a 403 Forbidden error, or any similar type of error that can be included in a particular error category. Disclosed herein are techniques and systems for improved handling of such errors in a registration response to an unprotected registration request. In general, the UE, in response to a registration response specifying a type of error in a particular error category, is configured to retry registration for a limited duration such that, upon a criterion being met, the UE refrains from transmitting any additional unprotected registration requests until the occurrence of a trigger event. In other words, if the UE receives a first registration response from a first IMS node that specifies a type of error in a particular error category, such as a 403 Forbidden error, the UE is configured to respond by selecting a second IMS node among the IMS nodes available to the UE, and transmitting a second unprotected registration request to the second IMS node in an attempt to re-register for service. The UE is configured to re-attempt registration in this manner for the additional IMS nodes in the list of IMS nodes available to the UE until a criterion is met. If, during these multiple re-attempts at registration, the UE receives a 401 Unauthorized challenge (or a 407 Proxy Authentication Required challenge) from one of the IMS nodes, the UE can respond to the challenge, and if the correct information is provided, the UE will ultimately receive a 200 OK response to proceed with a desired IMS-based service. However, if, after re-attempting registration multiple times, a criterion is met, the UE ceases any future reattempts at registration until the occurrence of a trigger event, thereby reducing network bandwidth consumption.

In some embodiments, the criterion evaluated for ceasing future registration attempts can comprise determining whether there is an IMS node in the list of available IMS nodes that the UE has not already sent an unprotected registration request to. In this embodiment, if the UE has already sent unprotected registration requests to all of the IMS nodes available to the UE, the UE determines that the criterion is met, and thereafter, the UE ceases transmitting any future registration requests until the occurrence of a trigger event.

In another embodiment, the criterion evaluated for ceasing future registration attempts can comprise determining whether a predetermined period of time has lapsed since initiating the registration procedure. In this embodiment, when the time period has lapsed, the UE determines that the criterion is met, and thereafter, the UE ceases making any future registration requests until the occurrence of a trigger event. In some embodiments, multiple criteria can be evaluated, such as the criteria discussed above, and upon determining that any one criterion of the evaluated criteria is met, the UE can cease making any future registration requests until the occurrence of a trigger event.

By configuring the UE to re-attempting registration for a limited duration with respect to different IMS nodes available to the UE, the UE is given a fair chance to successfully register for service if the UE should be able to register for service. If the UE is unsuccessful after reattempting registration for the limited duration, however, transmission of any additional registration requests may be halted, which reduces network bandwidth consumption in the carrier network. In other words, if the UE were configured to reattempt registration indefinitely without stopping, network bandwidth would be needlessly consumed by the UE. By contrast, the techniques and systems described herein pertain to a UE that is configured to refrain from transmitting any additional registration requests after the UE has re-attempted registration for the limited duration, which reduces network bandwidth consumption and increases network bandwidth that can be made available for other processes and applications.

In general, processes are disclosed herein for implementation on a UE with improved handling of issues encountered during IMS registration. Also disclosed herein are systems and devices comprising one or more processors and one or more memories, as well as non-transitory computer-readable media storing computer-executable instructions that, when executed, by one or more processors perform various acts and/or processes disclosed herein.

FIG. 1is a diagram illustrating example signaling between a UE100and various network nodes.FIG. 1illustrates a scenario where the UE100encounters an example issue(s) during the UE's100attempt at registering for service with an IMS core, as well as the UE's100implementation of improved logic for responding to the issue(s).

In accordance with various embodiments described herein, the terms “user equipment (UE),” “wireless communication device,” “wireless device,” “communication device,” “mobile device,” and “client device,” may be used interchangeably herein describe any UE (e.g., the UE100) that is capable of transmitting/receiving data wirelessly using any suitable wireless communications/data technology, protocol, or standard, such as Global System for Mobile Communications (GSM), Time Division Multiple Access (TDMA), Universal Mobile Telecommunications System (UMTS), Evolution-Data Optimized (EVDO), Long Term Evolution (LTE), Advanced LTE (LTE+), Generic Access Network (GAN), Unlicensed Mobile Access (UMA), Code Division Multiple Access (CDMA), Orthogonal Frequency Division Multiple Access (OFDM), General Packet Radio Service (GPRS), Enhanced Data GSM Environment (EDGE), Advanced Mobile Phone System (AMPS), High Speed Packet Access (HSPA), evolved HSPA (HSPA+), Voice over IP (VoIP), VoLTE, Institute of Electrical and Electronics Engineers' (IEEE) 802.1x protocols, WiMAX, Wi-Fi, Data Over Cable Service Interface Specification (DOCSIS), digital subscriber line (DSL), and/or any future IP-based network technology or evolution of an existing IP-based network technology. The UE100may be implemented as any suitable type of computing device configured to communicate over a wireless network, including, without limitation, a mobile phone (e.g., a smart phone), a tablet computer, a laptop computer, a portable digital assistant (PDA), a wearable computer (e.g., electronic/smart glasses, a smart watch, fitness trackers, etc.), an in-vehicle (e.g., in-car) computer, and/or any similar mobile device, as well as situated computing devices including, without limitation, a television (smart television), set-top-box (STB), desktop computer, and the like.

In general, a user can utilize the UE100to communicate with other users and associated UEs via an IMS core (sometimes referred to as the “IMS core network,” the “IMS network,” the “Core Network (CN),” or the “IM CN Subsystem”). IMS is an architectural framework defined by 3GPP for delivering Internet Protocol (IP) multimedia to a UE, such as the UE100. The IMS core can be maintained and/or operated by one or more service providers, such as one or more wireless carriers (“carriers”), that provide IMS-based services to users (sometimes called “subscribers”) who are associated with UEs, such as the UE100. For example, a service provider may offer multimedia telephony services that allow a subscribed user to call or message other users via the IMS core using his/her UE. A subscriber can also utilize an associated UE to receive, provide, or otherwise interact with various different IMS-based services by accessing the IMS core.FIG. 1illustrates multiple example IMS nodes102(1),102(2), . . . ,102(N) (collectively102) that the UE100can communicate with for these purposes. In some embodiments, the IMS nodes102represent multiple different P-CSCF nodes. A P-CSCF node is one of many nodes of the IMS core, and is merely an example of an IMS node102. The P-CSCF node is typically the first point of contact for the UE100, and as such, the P-CSCF node is utilized predominantly for providing a user-to-network interface. It is to be appreciated that the IMS nodes102ofFIG. 1can represent any other suitable type of IMS node other than a P-CSCF node.

Accordingly, an operator of the IMS core may offer any type of IMS-based service, such as, telephony services, emergency services (e.g., E911), gaming services, instant messaging services, presence services, video conferencing services, social networking and sharing services, location-based services, push-to-talk services, and so on. In order to access these services (e.g., telephony services), a UE is configured to request establishment of a communication session. In the case of telephony services, the communication session can comprise a call (i.e., a voice-based communication session, such as a VoLTE call, or a Wi-Fi call).

The UE100is also configured to utilize various radio access networks (RANs) in order to access the IMS core, such as via one or more of the IMS nodes102. In general, the IMS core is agnostic to the access technology that is used to connect a UE to the IMS core. In this manner, the UE100can connect to the IMS core via a 3GPP RAN, such a GSM/EDGE RAN (GERAN), a Universal Terrestrial RAN (UTRAN), or an evolved UTRAN (E-UTRAN), or alternatively, via a “non-3GPP” RAN, such as a Wi-Fi RAN, or another type of wireless local area network (WLAN) that is based on the IEEE 802.11 standards. Accessing the IMS core through a Wi-Fi access network typically involves the UE100communicating with the IMS core through a Wi-Fi access point (AP). Providing access to the IMS core through non-3GPP RANs has opened the door to recent advancements in IMS-based services, such as the introduction of Wi-Fi calling, which allows users to initiate and receive calls over an available Wi-Fi AP.

When the subscriber of a carrier's service powers on the UE100, the UE100is configured to execute boot code and perform various initialization procedures. Eventually, the UE100will try to “attach” to the carrier's network in order to transmit data to, and receive data from, the IMS core. To do this, the UE100can initiate an IP connectivity access network (IP-CAN) session by sending a Create Packet Data Protocol (PDP) Context Request or a Create Bearer Request message to a Mobility Management Entity (MME)104, or a component or subsystem of the MME104. In general, the MME104may be configured to assist with attachment and activation procedures, as well as perform idle mode UE tracking, paging procedures, and so on. In response to the communication from the UE100, the MME104can provide a list106of IMS nodes (e.g., a list of P-CSCF addresses) available to the UE100as shown inFIG. 1. The example list106shown inFIG. 1includes the IMS nodes102(1)-102(N), which may represent any number of IMS nodes102. For example, the list106can include a single IMS node102, or any number of multiple IMS nodes102. Often, the UE100obtains a list of about two or three IMS nodes102, such as two or three P-CSCF nodes. Obtaining the list106of available IMS nodes102by the UE100is sometimes referred to herein as a “node discovery procedure.” When the IMS nodes102represent P-CSCF nodes, this is referred to as a “P-CSCF discovery procedure.”

At108, after the UE100receives the list106of available IMS nodes102, the UE100can select a first IMS node102(1) among the available IMS nodes102in the list106to attempt registration through the selected IMS node102(1). The UE100can implement any suitable node selection approach, such as a top-down approach by selecting the first IMS node102(1) in the list106. However, node selection at108is not limited to using a top-down approach. Alternative node selection approaches may comprise random selection of an IMS node102from the list106, a bottom-up approach that selects the last IMS node102(N) in the list106, where after the UE100traverses the list106from the bottom up, or any other suitable approach for selecting one IMS node102from multiple available IMS nodes102. Furthermore, the available IMS nodes102do not have to be provided in the form of a list106. In the example ofFIG. 1, the first IMS node102selected at108happens to be the IMS node102(1), which is the first IMS node102in the list106.

The UE100can initiate registration by transmitting a first unprotected registration request110(1) to the selected, first IMS node102(1), which, as noted above, may represent a first P-CSCF node. An “unprotected” registration request, as used herein, means “integrity unprotected” in terms of the unprotected registration request not including “integrity protected” information pursuant to the 3GPP standards (See 3GPP Technical Specification (TS) 33.203). An “unprotected” registration request may also be defined as a registration request that does not prompt a 401 (or 407) challenge response from the IMS core (See 3GPP TS 24.229).

Session Initiation Protocol (SIP) may be used for transmitting messages, such as registration messages (e.g., registration requests), subscription messages, communication session messages, and the like, to the IMS core (e.g., to the IMS nodes102), and for receiving messages (e.g., registration responses) therefrom. SIP is a signaling protocol that can be used to establish, modify, and terminate multimedia sessions (e.g., a multimedia telephony call) over packet networks, and to authenticate access to IMS-based services. As used herein, a “SIP request” is a message that is sent from a UE, such as the UE100, to the IMS core (e.g., to any of the IMS nodes102inFIG. 1) using SIP protocol, and a “SIP response” is a message that is sent from the IMS core (e.g., from any of the IMS nodes102inFIG. 1) to a UE, such as the UE100, using SIP protocol.

Accordingly, the first unprotected registration request110(1) can comprise a SIP request using the SIP REGISTER method. The first unprotected registration request110(1) is sometimes referred to as an “INIT REGISTER” request to indicate that the registration status of the UE100is initially designated as an initial registration status, prior to its designation as either an active registration status or a terminated registration status. The selected, first IMS node102(1), upon receipt of the first unprotected registration request110(1), can send a first registration response112(1). Depending on the circumstances at the time the first unprotected registration request110(1) is received by the first IMS node102(1), the first registration response112(1) can take various forms. For example, the first registration response112(1) can specify a 401 Unauthorized challenge, a 407 Proxy Authentication Required challenge, or a particular type of error, such as a 403 Forbidden error. In the example ofFIG. 1, the first IMS node102(1) is shown as sending a first registration response112(1) that specifies a particular type of error in a particular error category; namely, a 403 Forbidden error. This type of error (perhaps along with other types of errors within the particular error category) may be treated using improved error handling logic at the UE100, as described herein. That is, the UE100may be configured to carry out the example procedures shown the Figures, such as the procedures shown inFIG. 1, in response to receiving a particular type of error (e.g., the 403 Forbidden error) in the first registration response112(1) from the first IMS node102(1).

According toFIG. 1, in response to receiving the first registration response112(1) from the first IMS node102(1) and determining that the first registration response112(1) specifies a type of error in a particular error category, the UE100can determine whether a criterion is met at114(1). In the example ofFIG. 1, the criterion is met when the UE100has traversed the entire list106of available IMS nodes102by individually transmitting unprotected registration requests to all of the IMS nodes102in the list106. Said another way, the criterion is met (in the example ofFIG. 1) when there are no additional (or remaining) IMS nodes102among the multiple available IMS nodes102in the list106to which the UE100has not already transmitted an unprotected registration request. Thus, when this criterion is evaluated at114(1) ofFIG. 1, and assuming the list106includes at least the IMS nodes102(1),102(2), and102(N), the UE100has not yet transmitted unprotected registration requests to the IMS nodes102(2)-102(N). Accordingly, the UE100determines, at114(1), that the criterion is not met, as indicated by “Traversed List? No” inFIG. 1.

At116(1), in response to determining, at114(1), that the criterion is not met, the UE100selects a second IMS node102(2) in the list106in order to re-attempt registration with the second IMS node102(2). Again, any suitable node selection approach (e.g., top-down, bottom-up, random, etc.) can be used to select a different IMS node102of the remaining IMS nodes102in the list106at116(1).

FIG. 1also shows, at116(1), that the UE100can wait until a lapse of a first time period before transmitting a subsequent unprotected registration request to the selected, second IMS node102(2). The first time period that the UE100waits at116(1) can be determined “on the fly” in response to receiving the first registration response112(1) from the first IMS node102(1). In some embodiments, the first time period can be determined based at least in part on a number of unprotected registration requests (e.g., the first unprotected registration request110(1)) that have been transmitted by the UE100to an IMS node102. In the example ofFIG. 1, at the time that the UE100receives the first registration response112(1) that specifies the 403 Forbidden error, there has been one unprotected registration request (i.e., the unprotected registration request110(1)) transmitted by the UE100. Using this number as “P” in the following Equation (1), the UE100can determine the first time period to wait at116(1) as follows:
T1=0.5W˜W(Random); whereW=Base Time×2P(1)

Equation (1) indicates that the first time period, T1, can comprise a randomly selected time that falls within a time range of 0.5 W to W, where W is calculated using a Base Time and a number, P, which, as noted above, represents a number of unprotected registration requests that have been transmitted from the UE100to an IMS node102during the registration procedure. For example, if the Base Time=30 seconds, and the number, P, of previously-transmitted unprotected registration requests is equal to 1, then W=60 seconds, and the first time period, T1, is a randomly selected value within a time range of 30 seconds and 60 seconds, according to Equation (1). Thus, the first time period, T1, is based at least in part on the value of P, which can represent the number of unprotected registration requests that have been transmitted at a time after transmitting the first unprotected registration request110(1) and before transmitting a subsequent unprotected registration request.

The time period (e.g., the first time period, T1) calculated pursuant to Equation (1) can be superseded, in some instances, by a wait time value that is indicated in a header field (e.g., a Retry-After header field) of the first registration response112(1). Instances where the header field value in a registration response112may supersede the time period calculated with Equation (1) is when the wait time value specified in the header field of a registration response112is greater than the time period calculated pursuant to Equation (1). For example, if the first time period, T1, is a randomly selected value within a time range of 30 seconds and 60 seconds, according to Equation (1), and the UE100receives a registration response (e.g., the first registration response112(1)) with a Retry-After header field value of 300 seconds, then the UE100can wait until a lapse of the wait time value of 300 seconds specified in the Retry-After header field due to 300 seconds being greater than a value within the range of 30 seconds and 60 seconds. However, in instances where the time period calculated with Equation (1) is greater than or equal to the wait time value specified in a Retry-After header field of the registration response112, the UE100may be configured to wait until lapse of the time period calculated with Equation (1) instead of the wait time value specified in the Retry-After header field of the registration response112.

Continuing with the example ofFIG. 1, the UE100is configured to wait until the first time period has lapsed before transmitting a second unprotected registration request110(2) to the selected, second IMS node102(2). This technique of waiting for a lapse of the first time period, as opposed to immediate transmission of the second unprotected registration request110(2), gives components of the carrier network time to recover from an issue that may be resolved with time, such as high network congestion.

In response to the second unprotected registration request110(2), the UE100may receive a second registration response112(2) from the second IMS node102(2). The second registration response112(2) can specify the same type of error (e.g., a 403 Forbidden error) as the error that was specified in the first registration response112(1), or a different type of error in the same error category as the type of error specified in the first registration response112(1).FIG. 1shows an example where the type of error is the same in both the first and second registration responses112(1) and112(2).

In response to receiving the second registration response112(2) from the second IMS node102(2) and determining that the second registration response112(2) specifies the type of error in the particular error category (here, the 403 Forbidden error), the UE100can determine whether the criterion is met at114(2). For example, the UE100can determine, at114(2) whether the entire list106of available IMS nodes102has been traversed by individually transmitting unprotected registration requests to all of the IMS nodes102in the list106. According to the example ofFIG. 1, the UE100determines, at114(2), that the criterion is not met, as indicated by “Traversed List? No” inFIG. 1(i.e., the UE100has not yet sent an unprotected registration request to the IMS node102(N) in the list106, and therefore, the criterion is not met at114(2).

At116(2), in response to determining, at114(2), that the criterion is not met, the UE100selects a third IMS node102(e.g., an IMS node102(3)) in the list106in order to re-attempt registration with the third IMS node102(3). Again, any suitable node selection approach (e.g., top-down, bottom-up, random, etc.) can be used to select a different IMS node102of the remaining IMS nodes102in the list106at116(2).

FIG. 1also shows, at116(2), that the UE100can wait until a lapse of a second time period before transmitting a subsequent unprotected registration request to the selected, third IMS node102(3). The second time period can be determined on-the-fly at116(2), and can be different than the first time period determined at116(1) in that the second time period can be greater (or longer) than the first time period. For example, utilizing Equation (1), above, and noting that P=2 at the time of receiving the second registration response112(2)—because there have been two unprotected registration requests (110(1) and110(2)) transmitted by the UE100—the second time period, T2, can be calculated as T2=0.5˜W (Random); where W=Base Time×22. For a Base Time=30 seconds, the second time period, T2, is a randomly selected value between 60 seconds and 120 seconds. Thus, in the above example, the first time period determined at116(1), T1, is selected as a time period between 30 seconds and 60 seconds, while the second time period determined at116(2), T2, is selected as a time period between 60 seconds and 120 seconds.

FIG. 1illustrates that this technique of waiting a longer and longer period of time before transmitting a subsequent unprotected registration request110can be performed for any suitable number of iterations to an Nthattempt at registering for service through a NthIMS node102(N) where the criterion is determined to be met at114(N), as shown by “Traversed List? Yes” inFIG. 1. In response to determining that the criterion is met at114(N)—e.g., in response to determining, at114(N), that there are no additional IMS nodes102among the multiple available IMS nodes102in the list106to which the UE100has not already sent an unprotected registration request110—the UE100is configured to stop (or refrain from) transmitting any additional unprotected registration requests at118until an occurrence of a trigger event. Example trigger events will be described in more detail below. Refraining from transmitting any additional unprotected registration requests to the IMS core at118avoids needlessly consuming network bandwidth in the face of an issue that is unlikely to resolve itself with more time.

In some embodiments, in addition to ceasing any future transmissions of unprotected registration requests, at118, the UE100may also disconnect from an IMS access point name (APN), pursuant to the 3GPP packet data network (PDN) disconnection mechanism. In some embodiments, the UE100can maintain a circuit switched (CS) domain registration throughout the signaling shown inFIG. 1, such as maintaining a CS domain registration between transmission of the successive unprotected registration requests110. This may be useful for enabling CS fallback procedures, or otherwise providing service to the UE100on a CS network where the UE100is experiencing registration failure on a packet switched network.

Of course, the technique of refraining from transmitting any additional registration requests at118upon determining that the criterion is met at114(N) can be implemented without also implementing the wait times at116. That is, the UE100may transmit subsequent unprotected registration requests110without waiting for any time period, but still evaluating the criterion at114along the way.

FIG. 2is a diagram illustrating example signaling between a UE200and various network nodes202when the UE200encounters an example issue(s) during a registration procedure in a similar fashion to the issue(s) encountered in the example ofFIG. 1.FIG. 2, however, illustrates another embodiment of implementing improved UE logic for responding to the issue(s). Specifically, a different criterion is evaluated in the example ofFIG. 2; namely a lapse of a predetermined period of time.

InFIG. 2, the UE200obtains a list206of available IMS nodes202from an MME204, and initiates a registration procedure by starting a timer at208, and by selecting a first IMS node202(1) among the available IMS nodes202in the list206. The timer started at208may be set to run for a predetermined period of time that is continually evaluated throughout the signaling shown inFIG. 2to determine when to stop transmitting additional unprotected registration requests210at218. The predetermined period of time may be any suitable period measured in any suitable units of time, such as a period of 5 minutes. It is to be appreciated that the operations and signaling shown inFIG. 2may be implemented in a similar manner to that described with reference toFIG. 1, such as by using any suitable node selection approach at208to select the first IMS node202(1). Furthermore, the entities shown inFIG. 2may represent entities similar to those described above with respect toFIG. 1, such as the IMS nodes202representing P-CSCF nodes of the IMS core.

After selecting the first IMS node202(1), the UE100transmits a first unprotected registration request210(1) to the selected, first IMS node202(1). The first IMS node202(1), upon receipt of the first unprotected registration request210(1), can send a first registration response212(1) that specifies a type of error in a particular error category; in this example, a 403 Forbidden error. This indicates that there is an issue(s) preventing successful registration of the UE200, but it is unknown as to the exact issue causing the registration failure. Thus, the techniques shown inFIG. 2can be carried out to give the UE200a fair chance at registering for IMS-based services, but limiting the re-attempts at registration to the period of time since the timer was started at208.

Accordingly, in response to receiving the first registration response212(1) from the first IMS node202(1) and determining that the first registration response212(1) specifies a type of error in a particular error category (e.g., the 403 Forbidden error), the UE200can determine whether a criterion is met at214(1). In the example ofFIG. 2, the criterion is met when the UE100determines that the predetermined period of time has lapsed (or expired) since the timer was started at208. Accordingly, the UE200determines, at214(1), that the criterion is not met, as indicated by “Timer Expired? No” inFIG. 2.

At216(1), in response to determining, at214(1), that the criterion is not met, the UE200selects a second IMS node202(2) in the list206in order to re-attempt registration with the second IMS node202(2).FIG. 2also shows, at216(1), that the UE200is configured to wait until a lapse of a first time period at216(1) before transmitting a subsequent unprotected registration request210(2) to a second IMS node202(2), similar to the technique described with reference toFIG. 1. Thus, the UE200, after waiting for the first period of time to lapse, transmits a second unprotected registration request210(2) to a selected, second IMS node202(2) among the remaining IMS nodes202in the list206to which the UE200has not already transmitted an unprotected registration request210. In response to the second unprotected registration request210(2), the UE200may receive a second registration response212(2) from the second IMS node202(2). The second registration response212(2) can also specify the type of error in the particular error category (e.g., the 403 Forbidden error) if the issue causing registration failure is unresolved.

In response to receipt of the second registration response212(2) where the UE200encounters the 403 Forbidden error, the UE200can evaluate the criterion at214(2) to determine whether the predetermined period of time has lapsed since starting the timer at208. The example ofFIG. 2shows that the predetermined period of time has not yet lapsed at214(2), so the UE200, in response, selects a third IMS node202(e.g., a third IMS node202(3)), and waits until a lapse of a second time period before transmitting a subsequent unprotected registration request to the third IMS node202(3).

FIG. 2shows that this technique of re-attempting registration can iterate any number of “M” times until the criterion is determined to be met at214(M) in response to receipt of an Mthregistration response212(M) that specifies the type of error in the particular error category (e.g., the 403 Forbidden error). In the example ofFIG. 2, the criterion is met at214(M) when the predetermined period of time has lapsed since starting the timer at208, as shown by “Timer Expired? Yes” inFIG. 2. Upon determining that the criterion is met at214(M), the UE200is configured to stop (or refrain from) transmitting any additional unprotected registration requests at218until an occurrence of a trigger event. Example trigger events will be described in more detail below.

It is to be appreciated that, depending on the number of IMS nodes202in the list206, evaluating a lapse of a predetermined period of time as the criterion may mean that the UE200does not traverse the entire list206(i.e., does not send unprotected registration requests210to one or more IMS nodes202in the list206), or that the UE200sends multiple unprotected registration requests210to a single IMS node202in the list206before ceasing transmission of future unprotected registration requests210at218. That is, for a short list206, the UE200may traverse the list206multiple times before the predetermined period of time expires at214(M), and for long lists206, the UE200may only get through some of the IMS nodes202in the list206before the predetermined period of time expires at214(M).

Other criteria can be evaluated in addition to, or as an alternative to, the example criteria described with reference toFIGS. 1 and 2. For example, instead of evaluating whether the UE100has traversed the list106(as inFIG. 1), or whether predetermined time period has lapsed (as inFIG. 2), the UE100/200can monitor the number, P, of unprotected registration requests110/210transmitted from the UE100/200to an IMS node102/202, and the criterion is met when the number, P, of unprotected registration requests110/210meets or exceeds a threshold (e.g., maximum) number of unprotected registration requests. Thus, the limited duration of re-attempts at registration may be implemented by ceasing future transmissions of unprotected registration requests110/210when the UE100/200has reached a threshold number of registration attempts.

In addition, a combinatorial criteria approach can be utilized where multiple criteria are evaluated while the UE100/200attempts and re-attempts registration in the face of a registration failure. In this combinatorial criteria approach, determining whether the criterion is met may comprise determining whichever criterion of multiple criteria is met first. For example, the predetermined period of time described with reference toFIG. 2can be monitored along with the criterion of whether the UE100/200has traversed the entire list106/206, and/or along with the criterion of whether the UE100/200has met or exceeded a threshold number of registration attempts, and whichever criterion occurs first causes the UE100/200to cease transmitting any future unprotected registration requests110/210.

It is also to be appreciated that the particular error category that triggers the UE's100/200responsive logic, as described herein, can include any suitable error type(s). This is due to possible differences in network configuration from one provider to another and the different uses for different error types. For example, a first carrier may be interested in monitoring 403 Forbidden errors to implement the techniques described herein, while a second carrier may be interested in monitoring another 4xx type of error.

FIG. 3illustrates a flowchart of an example process300for responding to issues encountered during registration for IMS-based service. For purposes of discussion, the process300is described with reference to the UEs100/200ofFIGS. 1-2.

At302, the UE100/200may obtain a list106/206of IMS nodes102/202that are available to the UE100/200. The IMS nodes102/202in the list106/206may represent P-CSCF nodes of the IMS core. The list106/206may be obtained at302from a MME104/204as part of a node discovery procedure.

At304, a timer can be started for evaluating a lapse of a period of time as a criterion for ceasing transmission of registration requests. It is noted that starting the timer at304is optional where such a predetermined period of time is not evaluated in lieu of a different criterion that is evaluated. The timer can be a local timer started by the UE100/200, or a remote timer that is remotely located from the UE100/200and triggered to start in response to a signal from the UE100/200.

At306, the UE100/200can select a first IMS node102(1)/202(1) in the list106/206of available IMS nodes102/202. The block306inFIG. 3indicates “selecting (another) IMS node in the list,” with “another” in parentheses because the first iteration of the process300will select a first IMS node102/202at306, and subsequent iterations of block306will select “another” different IMS node102/202in the list106/206.

At308, the UE100/200can transmit an initial unprotected registration request110/210, such as a SIP request using the REGISTER method, to the selected IMS node102(1)/202(1). A first instance of operation308can transmit a first unprotected registration request110(1)/210(1), as shown inFIGS. 1 and 2.

At310, the UE100/200can receive a registration response112/212from the selected IMS node102(1)/202(1).

At312, the UE100/200can determine, based on the registration response112/212received at310, whether the registration response112/212specifies a 401 Unauthorized challenge or a 407 Proxy Authentication Required challenge. If, at312, it is determined that the registration response112/212received at310specifies the 401 or 407 challenge, the process300follows the “yes” route from312to314, where the UE100/200can respond to the 401 or 407 challenge. For example, the UE100/200may transmit information “integrity protected” in a protected registration request at314. A “protected” registration request may be defined as a registration request that is transmitted in response to a 401 challenge or a 407 challenge. The information may be calculated, or otherwise derived, by the UE100/200to send a secret key only derivable by the UE100/200and a node of the IMS core.

The UE100/200receives a response to the protected registration request, and at316, the UE100/200can determine whether the response to the protected registration request comprises a 200 OK response. For example, if the UE100/200derived and transmitted the correct information at314that matches information independently obtained or derived by the IMS core, the UE100/200will receive a 200 OK response. Following a 200 OK response, the UE100/200can proceed to establish a communication session at block318. The establishment of a communication session at318can comprise the UE100/200transmitting a SIP request using the SIP INVITE method to establish a communication session (e.g., a voice call), or any similar type of session using any suitable IMS-based service. In other words, if the process300performs blocks302-318in sequence the first time the process300is performed, then the UE100/200does not encounter an issue during registration, and the remaining blocks shown inFIG. 3need not be performed.

If, at316, the response to the protected registration request sent at314does not comprise a 200 OK response (e.g., the response to the protected registration request specifies a 403 Forbidden error), the process300follows the “no” route from316to320where an attempt counter is incremented. At block320, an attempt (or registration attempt) may correspond to the transmission of the protected registration request at314. Thus, the first protected registration request transmitted at block314causes the attempt counter to increment to 1 attempt at block320.

At322, the UE100/200can determine a time period based at least in part on the number of previous protected registration requests transmitted from the UE100/200to an IMS node102/202at block314, which is tracked by the attempt counter incrementing at block320. For example, the period of time can be determined at322according to Equation (1), above, where the period of time is a randomly selected value within a time range, the time range being calculated using a Base Time value and the number, P, of previous protected registration requests transmitted from the UE100/200to an IMS node102/202. For example, with one previously transmitted protected registration request (i.e., P=1), and a Base Time=30 seconds, the time period determined at322can comprise a randomly selected time period between a range of 30 seconds and 60 seconds.

At324, the UE100/200can wait until a lapse of the time period determined at block322before proceeding back to block314. Once the time period has lapsed, the process300iterates by returning to block314and sending another protected registration request to a different IMS node102/202in the list106/206. This loop from blocks314-324may iterate indefinitely. In some embodiments, the process300can proceed from decision block316directly to block314without performing blocks320-324(i.e., without waiting between sequential protected registration requests).

Returning to decision block312, if it is determined that the registration response112/212to the unprotected registration request110/210received at block310does not specify a 401 or 407 challenge, the process300follows the “no” route from312to326where an attempt counter is incremented. The attempt counter at block326can represent a count of a number of previous unprotected registration requests110/210transmitted from the UE100/200to an IMS node102/202at the time the process300reaches block326. In the first iteration of the process300that proceeds from312to326, the attempt counter is incremented from P=0 to P=1 at block326because one unprotected registration request110/210has been transmitted at308.

At328, the UE100/200determines whether the registration response112/212received at block310specifies a type of error in a particular error category, such as a 403 Forbidden error. If such an error is specified in the registration response112/212received at block310, the process300proceeds along the “yes” route from decision block328to decision block330where a criterion (or multiple criteria) is evaluated to determine whether the criterion is met. For example, the criterion may be met at330if the UE100/200determines that there are no additional IMS nodes102/202among the multiple available IMS nodes102/202in the list106/206to which the UE100/200has not already sent an unprotected registration request110/210. As another example, the criterion may be met at330if the UE100/200determines that the predetermined period of time has lapsed since the starting of the timer at block304. As yet another example, the criterion may be met at330if the UE100/200determines that a number, P, of unprotected registration requests110/210transmitted from the UE100/200to the IMS nodes102/202is equal to a threshold number (e.g., a maximum number) of unprotected registration requests. The number, P, of unprotected registration requests110/210evaluated at block330can correspond to the value of the attempt counter after block326. In some embodiments, multiple of these criteria are evaluated at decision block330, and the UE100/200may determine whether any single criterion (or a predetermined number of multiple criteria) among the multiple criteria is met.

In a first iteration of the process300, assume that the criterion is not met at330. In this case, the process300follows the “no” route from decision block330to block332where the UE100/200determines a time period based at least in part on the number, P, of previous unprotected registration requests110/210transmitted from the UE100/200to the IMS nodes102/202in the list106/206. For example, the period of time can be determined at block332according to Equation (1), above, where the period of time is a randomly selected value within a time range, the time range being calculated using a Base Time value and the number, P, of previous unprotected registration requests110/210transmitted from the UE100/200to the IMS nodes102/202in the list106/206.

At334, the UE100/200can wait until a lapse of the time period determined at332before proceeding back to block306, where another IMS node102/202in the list106/206is selected, and blocks306-312iterate. How the process300proceeds from decision block312depends on the registration response112/212received at310to a subsequent unprotected registration request110/210, such as a second unprotected registration request110(2)/210(2) for a second iteration of block308. Alternatively, the process300can proceed from decision block330directly to block306without performing blocks332and334(i.e., transmitting a subsequent unprotected registration request110(2)/210(2) without waiting).

The process300can iterate by traversing the blocks306,308,310,312,326,328,330,332, and334, and the attempt counter is incremented at326on each iteration, causing the UE100/200to wait longer and longer periods of time at334before transmitting a subsequent unprotected registration request110/210at block308. These iterations occur until the UE100/200determines that the criterion is met at330.

In response to the criterion being met at decision block330, the process300follows the “yes” route from decision block330to block336where the UE100/200refrains from transmitting any additional unprotected registration requests110/210to the IMS nodes102/202in the list106/206. This reduces network bandwidth consumption by avoiding the transmission of needless unprotected registration requests that are unlikely to result in successful registration for the UE100/200.

Once the UE100/200determines to stop further transmissions of unprotected registration requests at block336, the attempt counter that was incremented at block326can be reset (e.g., by setting P=0) at block338, and the UE100/200can wait for an occurrence of a trigger event at decision block340.

In some embodiments, the trigger event evaluated at decision block340is whether the UE100/200has been powered down and subsequently powered up (e.g., by the user of the UE100/200power cycling the UE100/200). In some embodiments, the trigger event evaluated at decision block340is whether a subscriber identification module (SIM) card has been changed (or swapped) for another SIM card in the UE100/200. In some embodiments, the trigger event evaluated at decision block340is whether the UE100/200has moved within range of a different RAN, or moved from roaming coverage to non-roaming coverage, or vice versa. For example, the UE100/200may initially attach to the carrier network via a 3GPP RAN, and when the process300is carried out until decision block340is reached, the UE100/200may move into range of (or attaches to the carrier network via) a Wi-Fi (non-3GPP) RAN, which is determined as an occurrence of the trigger event at block340. The trigger event at block340may work similarly when the UE100/200is determined to have moved between any two different RANs in any direction, such as from a 3GPP RAN to a Wi-Fi (non-3GPP) RAN, or vice versa, from a first 3GPP RAN to a second, different 3GPP RAN, from a first Wi-Fi RAN to a second, different Wi-Fi RAN. Similarly, the trigger event may occur at block340when the UE100/200(initially attached to a roaming partner's carrier network via a first RAN) attaches to a home carrier's network through a second RAN, or vice versa (i.e., roaming-to-home network, or home-to-roaming network).

Until the trigger event is detected at decision block340, the process300can iterate at340by following the “no” route from340and continually monitoring for occurrence of the trigger event at340. However, once a trigger event occurs at340, the process300follows the “yes” route back to block302where the UE100/200obtains a new list106/206of IMS nodes102/202. In other words, when the UE100/200power cycles, swaps SIM cards, or moves between RANs or between roaming and non-roaming networks, it may make sense to attempt registration procedures again, so the process300is re-initiated with the attempt counter reset to zero.

Returning to decision block328, if it is determined that the registration response112/212received at block310does not specify a type of error in a particular error category (e.g., does not specify the 403 Forbidden error), the process300follows the “no” route from decision block328to block332, and proceeds as described above to block334, and then to block306. In other words, for other types of errors that are not included in the particular error category of interest, it may make sense for the UE100/200to retry registration with the IMS nodes102/202in the list106/206indefinitely.

Thus, the process300illustrates techniques for responding to issues encountered during registration for IMS-based service(s) that are improved over existing UE procedures. For instance, the implementation of re-attempting registration by transmitting multiple unprotected registration requests110/210for a limited duration reduces network bandwidth consumption by refraining from transmitting needless unprotected registration requests110/210once it is determined that additional attempts are unlikely to resolve a currently encountered issue.

FIG. 4is a block diagram of an example UE400with logic for responding to issues encountered during registration. The UE400may be representative of the UE100ofFIG. 1, or the UE200ofFIG. 2, and may be configured to implement the signaling shown inFIGS. 1 and/or 2, as well as the process300shown inFIG. 3.

As shown, the UE400may include one or more processors402and one or more forms of computer-readable memory404. The UE400may also include additional storage devices. Such additional storage may include removable storage406and/or non-removable storage408.

The UE400may further include input devices410and output devices412communicatively coupled to the processor(s)402and the computer-readable memory404. The UE400may further include communications interface(s)414that allow the UE400to communicate with other computing devices416(e.g., IMS nodes102/202) such as via a network(s). The communications interface(s)414may facilitate transmitting and receiving wired and/or wireless signals over any suitable communications/data technology, standard, or protocol, as described herein. For example, the communications interface(s)414can comprise one or more of a cellular radio, a wireless (e.g., IEEE 802.1x-based) interface, a Bluetooth® interface, and so on. In some embodiments, the communications interface(s)414may allow for attachment to a carrier network (e.g., an LTE network) via a non-3 GPP RAN (e.g., a Wi-Fi AP and the Internet). The communications interface(s)414may further enable the UE400to communicate over circuit-switch domains and/or packet-switch domains.

In various embodiments, the computer-readable memory404comprises non-transitory computer-readable memory404that generally includes both volatile memory and non-volatile memory (e.g., random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EEPROM), Flash Memory, miniature hard drive, memory card, optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium). The computer-readable memory404may also be described as computer storage media and may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Computer-readable memory404, removable storage406and non-removable storage408are all examples of non-transitory computer-readable storage media. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the UE400. Any such computer-readable storage media may be part of the UE400.

The memory404can include error handling module418(i.e., computer-executable instructions (or logic) that, when executed, by the processor(s)402, perform the various acts and/or processes disclosed herein). For example, the error handling module418can be configured to determine how best to respond to a registration response received from an IMS node102/202that specifies a type of error in a particular error category causing registration failure. For instance, the error handling module418can implement a detector420, which is configured to detect the type of registration error at block328of the process300, and whether it falls into a particular error category. The detector420may also be configured to determine when a 401 challenge or a 407 challenge is specified in the registration response at block312, and/or whether a registration response to a protected registration request comprises a 200 OK response at block316.

For example, when the detector420a registration response that specifies something other than a 401 challenge or a 407 challenge at block312, error handling module418can increment the attempt counter422at block326, and the detector420may further determine the type of error in the registration response112/212and whether the error falls in a particular error category.

The error handling module418may further include a fixed registration attempt module424to implement the logic for evaluating the criterion (or multiple criteria) at block330and for halting the transmission of any additional unprotected registration request at block336until a trigger event occurs at340. This fixed registration attempt module424is particularly useful when the UE400encounters an unrecoverable error in response to an unprotected registration request110/210.

The error handling module418may further include a wait time module426that is configured to dynamically determine a randomly selected wait time for purposes of staggering sequentially transmitted registration requests (e.g., sequential unprotected registration requests110/210). The wait time module426can utilize Equation (1) to determine a period of time at any given iteration of the process300based on the value of the attempt counter422. For example, as the number of previous unprotected registration requests counted by the attempt counter422increases, the time period calculated by the wait time module426increases, thereby configuring the UE400to wait longer and longer periods of time before transmitting any subsequent registration requests to the IMS nodes102/202.

The environment and individual elements described herein may of course include many other logical, programmatic, and physical components, of which those shown in the accompanying figures are merely examples that are related to the discussion herein.

The various techniques described herein are assumed in the given examples to be implemented in the general context of computer-executable instructions or software, such as program modules, that are stored in computer-readable storage and executed by the processor(s) of one or more computers or other devices such as those illustrated in the figures. Generally, program modules include routines, programs, objects, components, data structures, etc., and define operating logic for performing particular tasks or implement particular abstract data types.