Patent Description:
When the mobile network has a core network disruption (e.g., unavailable serving call session control function (S-CSCF) server), or otherwise unavailable, soft-client services (e.g., OTT services) for a mobile terminating (MT) UE may be disrupted, as the mobile network may not have current information to be able to route an OTT service (e.g., a call, text message, etc.) to the corresponding OTT application. As a result, a call or service may be routed to voicemail for an OTT application when there is a core network service disruption. Even if hardware (e.g., UE with mobile station international subscriber directory number (MSISDN)), by way of the IMEI is reregistered, the corresponding UUIDs of the OTTs associated with the MSISDN may not be reregistered with the mobile network. Since, the OTT applications reregister with the mobile network relatively infrequently, routing disruptions due to an unavailable S-CSCF may not be repaired in a timely way. <CIT> relates to systems and methods for facilitating communications with an operating system suspended, OTT, application on a user device.

The disclosure herein addresses some of the infirmities discussed above.

The invention is defined by an Application Server according to independent claim <NUM>, a computer-implemented method performed by a Secure Push Proxy according to independent claim <NUM> and an Application Server according to independent claim <NUM>. Further embodiments are set out in the dependent claims.

Techniques for restoring over-the-top (OTT) services or soft-client application associated with an MSISDN corresponding to one or more mobile terminating (MT) user equipment (UE) when components of a mobile network are not available in its previous configuration are discussed herein. Under normal operations, when an OTT service (e.g., a voice call, a text message, etc.) is to be provided to the MT UE, a variety of mobile network entities, such as a proxy call session control function (P-CSCF) server (hereinafter referred to as P-CSCF), an interrogating serving call session control function (I-CSCF) server (hereinafter referred to as I-CSCF), a serving call session control function (S-CSCF) server (hereinafter referred to as S-CSCF), an application server, etc., cooperate to open a session with the MT UE on which the OTT application corresponding to the OTT service is running. Opening this session includes routing a terminating (or term) invite to the MT UE via its corresponding P-CSCF and S-CSCF. However, if the S-CSCF is down, not functioning, or is otherwise unavailable, the protocols as currently defined in the Third Generation Partnership Project (3GPP), such as in technical section <NUM>, may not allow for restoration of services to enable a session invite and subsequent routing of the OTT service to the MT UE. In this case, the OTT services (e.g., voice call, test message, etc.) that were initially registered for a relatively long duration may be routed to voicemail. These types of failures may result in unsatisfactory customer experience.

According to examples of the disclosure, to prevent failures in routing of a term invite, such as a session initiation protocol (SIP) invite, to the MT UE when the MT UE's corresponding S-CSCF is unavailable, an out of band message (e.g., a push proxy message, HTTP message, etc.) may be sent to the MT UE to cause the MT UE to reregister its OTT applications with the mobile network. In this way, the MT UE and the OTT applications operating thereon are able to reregister the OTT applications to restore corresponding OTT services to the MT UE. A push notification to cause an OTT application to reregister with the mobile network may be sent to each OTT application that is associated with a UE, such as the MT UE. An application server may determine that registration information has been lost for a particular user and/or MT UE and, in cooperation with a secure push proxy (SPP) server (hereinafter referred to as SPP), cause the push notifications to be sent to the corresponding OTT applications associated with the MT UE.

The application server, in some cases, may identify that OTT service is to be provided to a particular OTT application and identify that the corresponding universally unique identifiers (UUID) of the OTT application and/or an international mobile equipment identity (IMEI) of the MT UE is not registered with the mobile network. The application server, before attempting to send a service invite to the OTT application, may instruct the SPP to send a push notification to each of the OTT applications associated with the MT UE and/or the corresponding MSISDN to cause those OTT applications to reregister with the mobile network. Alternatively, the application server may receive a registration message associated with an IMEI of a UE and identify that the corresponding MSIDSDN is associated with one or more OTT services. Based at least in part on identifying that the MT UE and/or the corresponding MSISDN is associated with the one or more OTT services, the application server may instruct the SPP to send a push notification to each of the OTT applications associated with the MT UE to cause those OTT applications to reregister with the mobile network. In this way, the reregistration of an OTT application, for which there is incomplete or stale routing information within the mobile network, can be prompted by an OTT service to be offered to that OTT or when an associated hardware (e.g., by way of the corresponding IMEI) registers.

To enable the functionality, as described herein, the application server may have information about whether a particular MT UE, and an IMEI where both the IMEI and the MT UE are associated with the same MSISDN, have OTT services. In some cases, the application server may not have information about which or how many OTT applications are associated with a particular IMEI, but the application server may have information about whether the IMEI has any OTT applications associated therewith. The association of the IMEI and OTT applications, in this sense and throughout this disclosure, refers to the IMEI and the OTT applications being associated with a common MSISDN. The application server may send a push notification, such as a hypertext transfer protocol (HTTP) message, to the SPP. The SPP may have information and/or be able to access information about which and/or how many OTT applications are associated with a particular MSISDN or related IMEI. The SPP, based at least in part on receiving the push notification from the application server, may generate a push notification, such as an HTTP message, for each of the OTT applications associated with the particular MSISDN or related IMEI to reregister with the mobile network. In this way, each of the OTT applications receive an out of band message (e.g., a push notification/HTTP message) from the SPP to cause the OTT applications to reregister with the mobile network. When the OTT applications reregister with the mobile network, their respective OTT services are restored, as the elements of the mobile network are able to route services and/or control functions to the individual OTT applications.

OTT applications and/or other soft clients with UUIDs, unlike MT UE with their IMEI, reregister relatively infrequently, such as days, and up to <NUM> days or more. Thus, without the mechanisms as described herein, OTT services could experience extended periods of downtime when an S-CSCF associated with the MT UE is rendered unavailable. In some cases, these OTT service may pertain to messaging, such as in the form of a soft-phone or text message application. Therefore, service disruptions to OTT services may result in ineffectual core communications and messaging functions.

Certain implementations of the disclosure will now be described more fully below with reference to the accompanying figures, in which various aspects are shown. However, the various aspects may be implemented in many different forms and should not be construed as limited to the implementations set forth herein. It will be appreciated that the disclosure encompasses variations of the examples, as described herein.

<FIG> illustrates a schematic diagram of an example environment <NUM> with a mobile network infrastructure including a MT UE <NUM> to which OTT services may be provided, in accordance with examples of the disclosure. The environment <NUM> shows a normal process flow when all relevant portions of the mobile network are functional and terminating OTT services are properly being provided to MT UE <NUM>. The MT UE <NUM> with various hardware and/or applications may have a variety of identifiers <NUM> associated therewith. For example, as disclosed herein, the MT UE <NUM> may have a mobile station international subscriber directory number (MSISDN) and/or a related international mobile subscriber identity (IMSI). The MT UE <NUM> may further have a voice over long term evolution (VoLTE) service with an associated IMEI. The MT UE <NUM> may still further have one or more OTT applications OTT <NUM>, OTT <NUM>,. OTT N (hereinafter referred to individually or in combination as OTT or OTTs) operating thereon, each having its own UUID UUID <NUM>, UUID <NUM>,. UUID N (hereinafter referred to individually or in combination as UUID or UUIDs). Although depicted as operating on a single MT UE <NUM>, the OTTs associated with a particular MSISDN may operate on a variety of different UEs associated with the subscriber identified by the MSISDN.

The MT UE <NUM> may have a communications application and/or software installed thereon that allows the MT UE <NUM> to interact with users to conduct and/or provide communications services and/or OTT services. Before services are provided to the MT UE <NUM> in a terminating fashion, other elements of environment <NUM> attempt to open a service session with the MT UE <NUM>, such that the MT UE <NUM> has a data plane and/or a control plane connection with elements of the mobile network. While for an mobile originating (MO) UE (not shown), the MO UE will commence the process of establishing the data plane and/or the control plane connection with elements of the mobile network, in the case of the MT UE <NUM> other elements of environment <NUM> will commence the process of establishing the data plane and/or the control plane connection with elements of the mobile network, such as in response to a service (e.g., connecting an incoming call) that is to be provided to the MT UE <NUM>. In receiving services, the MT UE <NUM> and the mobile network may establish (e.g., open) a session via any variety of protocols, such as those involving a service or term invite. Opening a session may further entail establishing radio links between the MT UE <NUM> and the mobile network, such as via radio nodes (e.g., eNodeB, gNodeB, etc.), using any suitable messaging protocols, such as SIP messages and/or message session relay protocol (MSRP) messages. The MT UE <NUM> may interact with mobile network infrastructure via any variety of communications protocols and/or communications generations, such as third generation (<NUM>), fourth generation (<NUM>), long-term evolution (LTE), fifth generation (<NUM>), <NUM> new radio (5GNR), any variety of millimeter wave standards, or the like.

The MT UE <NUM> may further be configured to identify that a user wishes to accept communications services, such as by interaction with the user via one or more user interfaces (e.g., touch screen), and may cooperate with one or more mobile network infrastructure to provide those communications services, such as OTT-based services. The OTTs operating on the MT UE <NUM> may provide any variety of services, such as rich communications service (RCS), virtual/soft-phone service, data service, voice service, short message service (SMS), A/V call service, and/or any other suitable mobile communications services. Although the MT UE <NUM> is depicted as a smartphone, the MT UE <NUM> may be any suitable communications device configured to send and/or receive OTT services, such as a laptop computer, a tablet computer, a voice device, combinations thereof, or the like. MT UE <NUM> may further include, but are not limited to, televisions, set-top boxes, computers, computing devices, servers, notebook computers, netbook computers, personal digital assistants (PDAs), smartphones, telephones, tablets, in-vehicle infotainment systems (IVIs), Internet of Things (IoT) devices, combinations thereof, or the like. It should be understood, that in some cases an individual subscriber of network telecommunications/data services may have more than one corresponding MT UE <NUM> with which he or she can access the long-duration services (e.g., OTT services) discussed herein.

When a terminating OTT service is to be provided to the MT UE <NUM>, a term invite <NUM> may be received by an I-CSCF <NUM>. The term invite may be a control message using DIAMTER and/or session initiation protocol (SIP). The term invite <NUM> may have identifying information of the MT UE <NUM>, such as the MSISDN of the MT UE <NUM>. The I-CSCF <NUM>, based at least in part on receiving the term invite <NUM>, may interact with a home subscriber server (HSS) <NUM> to query the MSISDN <NUM>. Based at least in part on querying the MSISDN <NUM>, the HSS <NUM> may provide registration information <NUM> to the I-CSCF <NUM>. The registration information may include identification of a corresponding S-CSCF <NUM> associated with the MT UE <NUM>. Although one S-CSCF <NUM> is depicted here for the purpose of explanation, typically a mobile network will have many S-CSCF. Therefore, to be able to properly route a term/session invite to the MT UE <NUM> the I-CSCF <NUM> would need to know the current S-CSCF <NUM> that is associated with the MT UE <NUM>.

The I-CSCF <NUM> may then route the term invite <NUM> to the serving S-CSCF <NUM> associated with the MT UE <NUM>, as identified by the HSS <NUM>. The S-CSCF <NUM> may then send to an application server <NUM> the term invite <NUM> and receive a service invite <NUM>. The application server <NUM> may be of any suitable form, such as a telephony application server (TAS), and provide a variety of service functions within the mobile network. The S-CSCF <NUM> may route, to a P-CSSF associated with the MT UE <NUM>, the service invite <NUM>. The P-CSCF <NUM>, in turn, may route the service invite <NUM> to the MT UE <NUM> to open a session to receive OTT services from the application server <NUM>. When the MT UE <NUM> receives the service invite <NUM>, the MT UE establishes a session with the mobile network, via the P-CSCF <NUM>, to receive OTT service, as provided by the application server <NUM>. In some cases, the service invite <NUM> may include two separate service invites, where one invite is directed to the hardware (e.g., IMEI instance) and the other invite is directed to the OTT (e.g., UUID instance).

The process of routing the term/service invites from the I-CSCF <NUM> through various nodes to the MT UE <NUM> successfully is enabled by the S-CSCF being aware of the correct P-CSCF <NUM> with which the MT UE <NUM> is associated. In the environment <NUM>, the HSS <NUM>, the I-CSCF <NUM>, or the application server <NUM> is not aware of the P-CSCF <NUM> that is associated with the various OTT applications operating on the MT UE <NUM>. The S-CSCF <NUM> is aware of the P-CSCF <NUM> associated with the OTTs operating on the MT UE <NUM>. Thus, if a different S-CSCF was to be sent the term invite <NUM> from the I-CSCF <NUM>, rather than S-CSCF <NUM>, then the that S-CSCF would not know which P-CSCF of a plurality of P-CSCFs within the mobile network to use to route the service invite <NUM> to the MT UE <NUM>. Although in <FIG>, the IMEI and the UUIDs are depicted as registering with the same P-CSCF <NUM>, it should be understood that in some cases, the UUIDs may be registered with a different P-CSCF <NUM> than the P-CSCF <NUM> with which the IMEI and/or MT UE <NUM> is registered. Furthermore, a particular OTT application may not be installed on the same MT UE <NUM> as with which it shares a common MSISDN.

<FIG> illustrates a schematic diagram of an example environment <NUM> where OTT services to the MT UE <NUM> of <FIG> is disrupted due to an unavailable S-CSCF <NUM>, in accordance with examples of the disclosure. In this scenario, the S-CSCF <NUM> (hereinafter the first S-CSCF <NUM>) may be down or otherwise unavailable. When the term invite <NUM> is received by the I-CSCF <NUM>, the I-CSCF <NUM> interacts with the HSS <NUM> to query the MSISDN <NUM> and, in response, receives registration information <NUM> from the HSS, as described in conjunction with <FIG>. The registration information <NUM> indicates that the first S-CSCF is associated with the MT UE <NUM>. As a result, the I-CSCF <NUM> attempts to route the term invite <NUM> to the first S-CSCF <NUM>, but fails, since the first S-CSCF <NUM> is unavailable. The I-CSCF <NUM> receives and/or generates an indication of a timeout <NUM>. This timeout <NUM> may be by any suitable protocol, such as DIAMETER/SIP. Responsive to the timeout <NUM>, the I-CSCF <NUM> may request new routing information <NUM> from the HSS <NUM>. The HSS <NUM> may assign a new S-CSCF <NUM>, shown as a second S-CSCF <NUM>, to the MT UE <NUM>. However, at this point, the second S-CSCF <NUM> is not aware of the P-CSCF <NUM> that is associated with the MT UE <NUM>.

The I-CSCF <NUM>, after receiving an indication of the second S-CSCF <NUM>, may route the term invite <NUM> to the second S-CSCF <NUM>. The second S-CSCF <NUM> then routes the term invite <NUM> to a application server <NUM>. Although a new application server <NUM> is depicted here as receiving the term invite <NUM>, in other cases, the second S-CSCF <NUM> may send the term invite to the original application server <NUM>. The second S-CSCF <NUM> may receive a service invite <NUM> from the application server <NUM>. As discussed herein, the first S-CSCF <NUM>, which is now unavailable, had the routing information (e.g., the P-CSCF <NUM> association) of the MT UE <NUM>. However, without the OTTs of the MT UE reregistering with the mobile network, the second S-CSCF <NUM> may not have routing information for the MT UE <NUM>. As a result, the S-CSCF <NUM> may be unable to route the service invite <NUM> to the MT UE <NUM> via the P-CSCF <NUM>. As a result, the OTT service may be routed to voicemail. In this case, by not being able to route a service invite <NUM> to an OTT associated with the MT UE <NUM>, due to an unavailable S-CSCF <NUM>, the user of the MT UE <NUM> may not be able to receive the OTT services that he or she would otherwise receive.

<FIG> illustrates a schematic diagram of an example environment <NUM> where OTT services to the MT UE of <FIG> is restored when a session is to be opened with the MT UE <NUM>, in accordance with examples of the disclosure. In a manner similar to the environment <NUM> of <FIG>, in this scenario, the first S-CSCF <NUM> may be down or otherwise unavailable. When the term invite <NUM> is received by the I-CSCF <NUM>, the I-CSCF <NUM> interacts with the HSS <NUM> to query the MSISDN <NUM> and, in response, receives registration information <NUM> from the HSS, as described in conjunction with <FIG>. The registration information <NUM> indicates that the first S-CSCF is associated with the MT UE <NUM>. As a result, the I-CSCF <NUM> attempts to route the term invite <NUM> to the first S-CSCF <NUM>, but fails, since the first S-CSCF <NUM> is unavailable. The I-CSCF <NUM> receives and/or generates an indication of a timeout <NUM>. Responsive to the timeout <NUM>, the I-CSCF <NUM> may request new routing information <NUM> from the HSS <NUM>. The HSS <NUM> may assign the second S-CSCF <NUM>, to the MT UE <NUM>. However, similar to the scenario described in conjunction with <FIG>, at this point, the second S-CSCF <NUM> is not aware of the P-CSCF <NUM> that is associated with the MT UE <NUM>.

The I-CSCF <NUM>, after receiving an indication of the second S-CSCF <NUM>, may route the term invite <NUM> to the second S-CSCF <NUM>. The second S-CSCF <NUM> may then route the term invite <NUM> to the application server <NUM>. Although a new application server <NUM> is depicted here as receiving the term invite <NUM>, in other cases, the second S-CSCF <NUM> may send the term invite to the original application server <NUM>. The term invite may include an identity, such as the IMEI and/or the MSISDN, associated with the MT UE <NUM>. The application server <NUM> may identify and/or determine, from the term invite, the identity of the MT UE <NUM>, such as by way of the IMEI associated with the MT UE <NUM>. The application server <NUM> may further identify and/or determine that the MSISDN and/or the related IMEI is associated with one or more OTTs. In other words, the application server <NUM> may have information that indicates whether the MT UE <NUM> is associated with OTT services.

If the application server <NUM> determines that the MSISDN associated with the term invite is unregistered and further determines that the MSISDN is associated with OTT services, the application server <NUM> may send, to a secure push proxy server <NUM> (hereinafter referred to as SPP <NUM>), a push notification for reregistration <NUM>. In other words, the application server <NUM> may generate the push notification for registration <NUM> based at least in part on identifying that an MSISDN associated with a term invite is unregistered and further based at least in part on an indication that the MT UE <NUM> associated with the MSISDN is associated with a OTT services. The push notification for reregistration <NUM> may include an indication of an identity of the MT UE <NUM>, such as the corresponding IMEI and/or the MSISDN. It should be understood that in some cases, the application server <NUM> may not have information about which ones and/or types of OTTs (e.g., WHATSAPP, TWITTER, WECHAT, etc.) and/or how many OTTs are associated with the MSISDN indicated in the term invite <NUM>. Rather, in these cases, the application server <NUM> may have information that indicate whether the MSISDN indicated in the term invite <NUM> has any OTT services associated therewith or not.

The push notification <NUM> may be in the form of a hypertext transfer protocol (HTTP) message that is sent to the SPP <NUM>. In some cases, the push notification for registration <NUM> may be a HTTP secure (HTTPS) message that is sent to the SPP <NUM>. In other cases, the push notification for registration may be in the form of any other suitable format. The push notification for registration <NUM>, in some cases, may include any suitable type of transport layer security (TLS) encryption, secure socket layer (SSL) encryption, or the like. In some cases, the push notification for reregistration <NUM> may be sent directly from the application server <NUM> to the SPP <NUM>. In other cases, there may be one or more intermediary nodes and/or servers/systems that relay the push notification for registration <NUM> from the application server <NUM> to the SPP <NUM>.

While the application server <NUM> is generating and sending the push notification for reregistration <NUM> to the SPP <NUM>, the application server <NUM> may not act upon the term invite <NUM>, which prompted the mechanism of generating and sending the push notification for registration <NUM>, that the application server <NUM> received from the second S-CSCF <NUM>. In other words, the application server <NUM> may not generate and/or send a service invite <NUM>, responsive to the received term invite <NUM>, as was the case in environment <NUM> of <FIG>, where OTT services could not be provided to the MT UE <NUM>. Instead, the application server <NUM> may wait to send the service invite <NUM> until the application server <NUM> identifies that at least one of the OTT applications operating on the MT UE <NUM> have been reregistered with the mobile network. The reregistration mechanism and subsequent issuance of a service invite by the application server <NUM> is described in greater detail with conjunction with <FIG>.

The SPP <NUM>, based at least in part on receiving the push notification for reregistration <NUM> from the application server <NUM>, may generate one or more push notifications for UUID reregistration <NUM>. The SPP <NUM> may have information about which OTT applications, as referenced by corresponding respective UUIDs, are associated with and/or operating on the MT UE <NUM>. The SPP <NUM> may identify the MT UE <NUM>, such as by the IMEI and/or MSISDN indicated in the push notification for reregistration <NUM> received from the application server <NUM>. The SPP <NUM> may identify each of the OTTs, such as by corresponding UUIDs of the respective OTTs, such as by accessing a table and/or database of associations between IMEI and/or MSISDN to UUIDs, as maintained by the SPP <NUM>. The table and/or database of these correspondences between the IMEI and/or MSISDN to UUIDs may be maintained and updated by the SPP <NUM> whenever new OTTs are set up and/or registered with the HSS <NUM> of the mobile network.

After identifying individual ones of the OTTs/UUIDs associated with the MT UE <NUM>, the SPP may generate a push notification for UUID reregistration <NUM> for individual ones of the OTTs. Each of the push notification for UUID reregistrations <NUM> may indicate the OTT to which it corresponds, such as by including an indication of the corresponding UUID. The SPP <NUM> may send each of the push notification for UUID reregistration <NUM> to the MT UE <NUM> to cause the corresponding OTTs to reregister with the mobile network (e.g., with the elements on environment <NUM>). The push notification for UUID reregistration <NUM> may include any variety of mechanisms to cause the corresponding OTT application operating on the MT UE <NUM> to reregister. For example, the push notification for UUID reregistration <NUM> may include an instruction to the corresponding OTT to reregister immediately. As another example, the push notification for UUID reregistration <NUM> may cause a time-to-live (TTL) setting corresponding to an OTT to be set to zero (or near zero) to cause the OTT to reregister with the mobile network. Indeed, any other suitable mechanism may be employed to cause the push notification for UUID reregistration <NUM> to compel the corresponding OTT to reregister.

Similar to the push notification <NUM>, each of the push notification for UUID reregistration <NUM> may be in the form of a HTTP message that is sent to the MT UE <NUM>. In some cases, the push notification for UUID registration <NUM> may be a HTTPS message that is sent from the SPP <NUM> to the MT UE <NUM>. In other cases, the push notification for UUID registration <NUM> may be in the form of any other suitable format. The push notification for UUID registration <NUM>, in some cases, may include any suitable type of TLS encryption, SSL encryption, or the like.

It should be appreciated that the mechanism disclosed herein, uses an out-of-band notification mechanism (e.g., the push notification mechanism) to communicate to the MT UE <NUM> and/or the OTTs operating thereon to reregister. Without reregistration of the OTTs, services cannot be provided to those OTTs operating on the MT UE <NUM>. The reregistration of the OTTs, therefore, allows for restoration the OTT services associated with the MT UE <NUM>, according to examples of the disclosure. In this case, the out-of-band push notifications to enable restoration of OTT services are generated responsive to an attempt to open a session with the MT UE <NUM> to provide OTT services to the user of the MT UE <NUM>. Thus, this may be considered a passive mechanism, where restoration of the OTT services is not performed until there is a need to provide those services to the MT UE <NUM> and/or the OTT application. In this example, the application server <NUM> may wait to provide the requested OTT services, by opening a session with the MT UE <NUM>, until the corresponding OTT reregisters, as will be described in more detail in correspondence to <FIG>. As a result, of waiting for the reregistration of the corresponding OTT, there may be a relatively slight delay in providing the OTT service to the user of the MT UE <NUM>. In some cases, this delay may be imperceptible to the user of the MT UE <NUM>. In other cases, the user of the MT UE <NUM> may perceive the delay, but the relative inconvenience of that perceived delay may be substantially less than the inconvenience of not receiving the OTT services at all.

<FIG> illustrates a schematic diagram of an example environment <NUM> where one or more OTTs reregister with the mobile network of <FIG>, in accordance with examples of the disclosure. It should be noted that although a specific mechanism for the OTT applications to reregister is described herein, there may be any number of suitable mechanisms for the OTT to reregister with the mobile network, according to examples of the disclosure. For example, different mobile networks may have slight variations in the processes and/or the order of processes used to reregister OTT applications, with their corresponding UUIDs, on the mobile network.

As described in conjunction with <FIG>, an OTT application operating on MT UE <NUM> may receive a corresponding push notification for UUID reregistration <NUM> from the SPP <NUM>. Responsive to receiving the push notification for UUID reregistration <NUM>, the OTT application may generate and/or send a request to reregister <NUM> to the P-CSCF <NUM>. The P-CSCF <NUM> may route the request to reregister <NUM> to the I-CSCF <NUM>. The I-CSCF <NUM> may generate and send a user authentication request (UAR) <NUM> to the HSS <NUM>. Responsive to the UAR <NUM>, the HSS may identify the OTT and/or the MT UE <NUM>, verify services and/or network permissions associated with the OTT and/or the MT UE <NUM>, and generate and send a user authentication answer (UAA) <NUM> to the I-CSCF <NUM>. The I-CSCF <NUM> may forward reregistration information <NUM> to the second S-CSCF <NUM>. The S-CSCF <NUM>, by receiving this registration information is now aware of the P-CSCF <NUM> that is associated with the MT UE <NUM> and, therefore, the S-CSCF <NUM> can now route messages, such as service invites, to the MT UE <NUM>.

The S-CSCF <NUM> may send reregistration information <NUM> to the application server <NUM>. This process, in some cases, may be a third party registration (TPR) process. This type of TPR process may be initiated by the second S-CSCF <NUM> after the new S-CSCF (the second S-CSCF <NUM>) has been registered, such as by SIP: Registration procedures. The reregistration information <NUM> may include an identity (e.g., UUID) of the OTT that is reregistered and may further include the identity (MSISDN and/or IMEI) of the MT UE <NUM>. The reregistration information may still further include an identity of the second S-CSCF <NUM> that is now serving the MT UE <NUM> and the OTTs operating thereon. The reregistration information may yet further include authorized permissions and/or services that are to be provided to the MT UE and/or OTTs operating on the MT UE <NUM>. Based on the reregistration information <NUM>, the application server <NUM> is now aware that the OTT to which it is to provide services has been reregistered. As a result, the application server <NUM> may generate and send a service invite <NUM> to the second S-CSCF <NUM>.

The second S-CSCF <NUM>, now that it is aware of the P-CSCF <NUM> associated with the MT UE <NUM>, may send the service invite <NUM> to the P-CSCF <NUM>. The P-CSCF <NUM> may then route the service invite <NUM> to the MT UE <NUM> to provide to the OTT application with which the incoming OTT service is associated. The routing of the service invite <NUM> to the MT UE <NUM> may cause the MT UE <NUM> to open a session with the mobile network to receive OTT services. Thus, the operations of the application server <NUM> and the SPP <NUM> enable the reregistration of the OTTs operating on the MT UE <NUM> so that those OTTs can receive services from the mobile network.

<FIG> illustrates a schematic diagram of an example environment <NUM> where OTT services to the MT UE of <FIG> is restored when a corresponding international mobile equipment identity (IMEI) and/or MSISDN of the MT UE is reregistered, in accordance with examples of the disclosure. In this example, unlike in the scenario of environment <NUM> of <FIG>, the reregistration of the OTTs operating on the MT UE <NUM> may not be prompted by needing to immediately provide OTT services to the user of the MT UE <NUM>. Rather, the prompt for causing the OTTs to reregister may be when the associated IMEI is reregistered for the MT UE <NUM>. As discussed herein, the IMEI may reregister on a relatively frequent basis (e.g., every <NUM> minutes, every hour, every <NUM> hours, etc.) compared to the OTT time between registration (e.g., <NUM> days, <NUM> days, <NUM> days, etc.). As a result, it is likely that the MSISDN and/or IMEI will be reregistered before any OTT services are to be provided to the OTT applications operating on the MT UE <NUM>.

The MT UE <NUM> may initiate the IMEI reregistration process by generating and sending an IMEI reregistration request <NUM> to the P-CSCF <NUM>. The P-CSCF <NUM> may forward the IMEI reregistration request to the first S-CSCF <NUM>, which is now unavailable. As a result, the first S-CSCF <NUM> either sends a message indicating that it is unavailable or timeout (e.g., SIP: 4xx/5xx/timeout, etc.) <NUM> back to the P-CSCF <NUM>. The P-CSCF <NUM> may send a message indicating unavailability <NUM> (e.g., SIP: <NUM>) to the MT UE <NUM>. In response, the MT UE <NUM> may initiate a new registration by sending an initiate registration request <NUM> to the P-CSCF <NUM>. The P-CSCF <NUM> may route the initiate registration request <NUM> to the I-CSCF <NUM>. The I-CSCF <NUM> may proceed with the UAR <NUM> / UAA <NUM> process with the HSS <NUM>, as described in conjunction with <FIG>. The I-CSCF <NUM> may then provide IMEI registration information <NUM> to the second S-CSCF <NUM>, which now serves the MT UE <NUM>. The registration information <NUM> may include user profile information, as received from the HSS <NUM>, such as services offered to the MSISDN and/or IMEI associated with the MT UE <NUM>. This IMEI registration information may prompt a TPR on the application server <NUM> and the MT UE <NUM>, with its IMEI, is now registered with the application server <NUM>. In some cases, the processes of <NUM> may not be performed, and instead, the P-CSCF <NUM> may initiate a the new registration on behalf of the MT UE <NUM> without the MT UE <NUM> having to explicitly send the initiate registration request <NUM>.

The application server <NUM>, based at least in part on receiving the IMEI registration information <NUM>, may identify that the MT UE <NUM> is associated with at least one OTT service. If the application server <NUM> determines that the IMEI is associated with OTT services, then the application server <NUM> may perform similar operations as described in conjunction with <FIG> herein. For example, the application server <NUM> may generate and send, to the SPP <NUM>, a push notification for reregistration <NUM> based at least in part on identifying an indication that the MT UE <NUM> associated with the IMEI is associated with a OTT services. The push notification for reregistration <NUM> may include an indication of an identity of the MT UE <NUM>, such as the corresponding IMEI and/or the MSISDN. It should be understood that in some cases, the application server <NUM> may not have information about which ones and/or types of OTTs (e.g., FACEBOOK MESSENGER, TWITTER, TELEGRAM, etc.) and/or how many OTTs are associated with the IMEI indicated in the IMEI registration information <NUM>. Rather, in these cases, the application server <NUM> may have information that indicate whether the IMEI indicated in the IMEI registration information <NUM> has any OTT services associated therewith or not.

The push notification <NUM> may be in the form of an HTTP message that is sent to the SPP <NUM>. In some cases, the push notification for reregistration <NUM> may be a HTTPS message that is sent to the SPP <NUM>. In other cases, the push notification for registration may be in the form of any other suitable format. The push notification for reregistration <NUM>, in some cases, may include any suitable type of TLS encryption, SSL encryption, or the like. In some cases, the push notification for reregistration <NUM> may be sent directly from the application server <NUM> to the SPP <NUM>. In other cases, there may be one or more intermediate nodes and/or servers/systems that relay the push notification for reregistration <NUM> from the application server <NUM> to the SPP <NUM>.

After identifying individual ones of the OTTs/UUIDs associated with the MT UE <NUM>, the SPP <NUM> may generate a push notification for UUID reregistration <NUM> for individual ones of the OTTs. Each of the push notification for UUID reregistrations <NUM> may indicate the OTT to which it corresponds, such as by including an indication of the corresponding UUID. The SPP <NUM> may send each of the push notification for UUID reregistration <NUM> to the MT UE <NUM> to cause the corresponding OTTs to reregister with the mobile network (e.g., with the elements on environment <NUM>). The push notification for UUID reregistration <NUM> may include any variety of mechanisms to cause the corresponding OTT application operating on the MT UE <NUM> to reregister. For example, the push notification for UUID reregistration <NUM> may include an instruction to the corresponding OTT to reregister immediately. As another example, the push notification for UUID reregistration <NUM> may cause a TTL setting corresponding to an OTT to be set to zero (or near zero) to cause the OTT to reregister with the mobile network. Indeed, any other suitable mechanism may be employed to cause the push notification for UUID reregistration <NUM> to compel the corresponding OTT to reregister.

Similar to the push notification <NUM>, each of the push notification for UUID reregistration <NUM> may be in the form of a HTTP message that is sent to the MT UE <NUM>. In some cases, the push notification for UUID registration <NUM> may be a HTTPS message that is sent from the SPP <NUM> to the MT UE <NUM>. In other cases, the push notification for UUID registration <NUM> may be in any other suitable format. The push notification for UUID registration <NUM>, in some cases, may include any suitable type of TLS encryption, SSL encryption, or the like.

As in the example described in conjunction with <FIG>, it should be appreciated that the mechanism disclosed herein, uses an out-of-band notification mechanism (e.g., the push notification mechanism) to communicate to the MT UE <NUM> and/or the OTTs operating thereon to reregister. Without reregistration of the OTTs, services cannot be provided to those OTTs operating on the MT UE <NUM>. The reregistration of the OTTs, therefore, allows for restoration the OTT services associated with the MT UE <NUM>, according to examples of the disclosure. In this case, the out-of-band push notifications to enable restoration of OTT services are generated responsive to the MT UE <NUM> trying to reregister its IMEI and failing, and then having to initiate a new registration. Thus, this may be considered a active mechanism, where restoration of the OTT services is performed even though there is no current need to provide OTT services to the MT UE <NUM> and/or the OTT application. The OTT reregistration process may be substantially similar to that described in conjunction with <FIG> and will not be repeated here.

<FIG> illustrates a flow diagram of an example method <NUM> by which an application server <NUM> causes an OTT to reregister with the mobile network of <FIG> when a session is to be opened with the OTT, in accordance with examples of the disclosure. The operations of method <NUM> may be performed by the application server <NUM>, individually or in conjunction with one or more other entities of the mobile network. In some examples, the operations of method <NUM> may be the operations described in conjunction with <FIG> that are performed by the application server <NUM>.

At block <NUM>, an invite for a service associated with an OTT application associated with an MSISDN may be received. This invite may be a terminating invite to enable opening a session with the MT UE <NUM> to provide OTT services to the MT UE <NUM>. As discussed herein, the term invite may include an identity, such as the IMEI and/or the MSISDN, associated with the MT UE <NUM>.

At block <NUM>, it may be identified that the MSISDN is unregistered. The application server <NUM> may extract the MSISDN and/or related IMEI information from the received term invite. This application server <NUM> will have an indication of those MSISDNs and/or IMEIs that have current registrations on the mobile network. This type of information may be provided to the application servers <NUM> of the mobile network from previous registrations and/or from the HSS <NUM>. In the cases where the MSISDN is registered, the application server would proceed normally to provide OTT services to the OTT application corresponding to the term invite received. However, in this case, the application server <NUM> identifies that the MSISDN is not registered and, therefore, the mobile network may lack fresh information on how to route any OTT services to any of the OTTs associated with the MSISDN.

At block <NUM>, it may be determined that the MSISDN is associated with OTT services. It should be understood that the application server <NUM> may not have information about which ones and/or types of OTTs and/or how many OTTs are associated with the MSISDN indicated in the term invite. Instead, the application server <NUM> may have information that indicates whether the MSISDN indicated in the term invite <NUM> has any OTT services associated with it. In this case, the application server <NUM> determines that the MSISDN is indeed associated with at least one OTT application.

At block <NUM>, a push notification instructing reregistration of OTT services associated with the IMEI is generated based at least in part on identifying that the IMEI is associated with OTT services. The push notification may further be generated based at least in part on identifying that the IMEI is currently unregistered. This push notification <NUM> may provide instructions to the SPP <NUM> to generate and send another push notification corresponding to each of the OTT applications associated with the IMEI to cause those OTT applications to reregister with the mobile network.

At block <NUM>, the push notification may be sent to a SSP. The push notification <NUM> may be in the form of a HTTP message that is sent to the SPP <NUM>. In some cases, the push notification for registration <NUM> may be a HTTPS message that is sent to the SPP <NUM>. In other cases, the push notification for registration may be in the form of any other suitable format. The push notification for registration <NUM>, in some cases, may include any suitable type of TLS encryption, SSL encryption, or the like.

The SPP <NUM>, upon receiving the push notification <NUM>, may send additional push notifications to individual ones of the OTTs associated with the MT UE <NUM> to cause them to reregister with the mobile network. This reregistration enables the restoration of the OTT services. In the meantime, the application server <NUM> may wait for the reregistration of the OTT application for which it received a term invite, before the application server <NUM> sends that OTT a service invite to open a session with the mobile network to receive OTT services.

It should be noted that some of the operations of method <NUM> may be performed out of the order presented, with additional elements, and/or without some elements. Some of the operations of method <NUM> may further take place substantially concurrently and, therefore, may conclude in an order different from the order of operations shown above.

<FIG> illustrate a flow diagram of an example method <NUM> by which an application server <NUM> causes an OTT to reregister with the mobile network of <FIG> when a corresponding IMEI and/or MSISDN of the MT UE <NUM> on which the OTT operates is reregistered, in accordance with examples of the disclosure. The operations of method <NUM> may be performed by the application server <NUM>, individually or in conjunction with one or more other entities of the mobile network. In some cases, the operations of method <NUM> may be the operations described in conjunction with <FIG> that are performed by the application server <NUM>.

At block <NUM>, a registration request associated with an IMEI may be received. This registration request may be prompted by the MT UE <NUM> requesting registration with the mobile network after discovering that its previous registration is stale and/or ineffectual. It should be noted that the IMEI of the MT UE <NUM> is usually reregistered with a relatively high frequency relative to the OTTs associated with the same MT UE <NUM>.

At block <NUM>, it may be identified that the IMEI is associated with an MSISDN with which OTT services are also associated. It should be understood that the application server <NUM> may not have information about which ones and/or types of OTTs and/or how many OTTs are associated with the IMEI and/or MSISDN indicated in the term invite. Instead, the application server <NUM> may have information that indicates whether the IMEI and/or MSISDN indicated in the term invite <NUM> has any OTT services associated with it. In this case, the application server <NUM> determines that the IMEI and/or MSISDN is indeed associated with at least one OTT application.

At block <NUM>, a push notification instructing reregistration of OTT services associated with the MSISDN may be generated based at least in part on identifying that the MSISDN is associated with OTT services. This push notification <NUM> may provide instructions to the SPP <NUM> to generate and send another push notification corresponding to each of the OTT applications associated with the MSISDN to cause those OTT applications to reregister with the mobile network.

<FIG> illustrates a flow diagram of an example method by which a secure push proxy (SPP) system causes an OTT to reregister with the mobile network of <FIG>, in accordance with examples of the disclosure. The operations of method <NUM> may be performed by the SPP <NUM>, individually or in conjunction with one or more other entities of the mobile network. In some cases, the operations of method <NUM> may be the operations described in conjunction with <FIG> and <FIG> that are performed by the SPP <NUM>.

At block <NUM>, a push notification instructing reregistration of OTT services associated with an MSISDN may be received. The push notification <NUM> may be in the form of a HTTP message that is received from the application server <NUM>. In some cases, the push notification for registration <NUM> may be a HTTPS message. In other cases, the push notification for registration may be in any other suitable format. The push notification for registration <NUM>, in some cases, may include any suitable type of TLS encryption, SSL encryption, or the like. The received push notification <NUM> may not include any indication or particular OTT services and/or OTT applications. Instead, the push notification <NUM> may instruct the SPP <NUM> to instruct all OTT applications associated with the MSISDN to reregister.

At block <NUM>, the MSISDN may be identified based at least in part on the push notification. The MSISDN may be indicated in the push notification <NUM> itself, as received from the application server <NUM>.

At block <NUM>, one or more UUIDs associated with the MSISDN may be identified. These individual UUIDs may be associated with corresponding respective OTT applications operating on the MT UE <NUM>. The SPP <NUM> may include a database that stores the associations between the MSISDN and/or IMEI and the corresponding UUIDs. The SPP <NUM> may access this database to identify individual ones of the UUIDs associated with the MSISDN, as indicated in the received push notification <NUM>.

At block <NUM>, one or more second push notifications corresponding to each UUID may be generated, where each of the one or more second push notifications instruct the corresponding OTT application to reregister with the mobile network. Each of the push notification for UUID reregistrations <NUM> may indicate the OTT to which it corresponds, such as by including an indication of the corresponding UUID. The one or more push notification for UUID reregistration <NUM> may include any variety of mechanisms to cause the corresponding OTT application operating on the MT UE <NUM> to reregister. For example, the push notification for UUID reregistration <NUM> may include an instruction to the corresponding OTT to reregister immediately. As another example, the push notification for UUID reregistration <NUM> may cause a TTL setting corresponding to an OTT to be set to zero (or near zero) to cause the OTT to reregister with the mobile network. Indeed, any other suitable mechanism may be employed to cause the push notification for UUID reregistration <NUM> to compel the corresponding OTT to reregister.

At block <NUM>, each of the second push notifications may be sent to a UE associated with each of the one or more UUIDs, where each of the second push notifications cause its corresponding OTT to reregister with the mobile network. This reregistration allows for OTT services to be restored after a disruption due to a S-CSCF <NUM>, <NUM> becoming unavailable. The SPP <NUM> may send each of the push notification for UUID reregistration <NUM> to the MT UE <NUM> and the OTT applications cooperate with the MT UE <NUM> to reregister with the mobile network (e.g., with the elements in environment <NUM>).

<FIG> illustrates a block diagram of an example application server <NUM>, <NUM> that may enable a restoration of OTT services, in accordance with examples of the disclosure. The application server <NUM>, <NUM> may include one or more processor(s) <NUM>, one or more input/output (I/O) interface(s) <NUM>, one or more network interface(s) <NUM>, one or more storage interface(s) <NUM>, and computer-readable media <NUM>.

In some implementations, the processors(s) <NUM> may include a central processing unit (CPU), a graphics processing unit (GPU), both CPU and GPU, a microprocessor, a digital signal processor or other processing units or components known in the art. Alternatively, or in addition, the functionally described herein can be performed, at least in part, by one or more hardware logic components. For example, and without limitation, illustrative types of hardware logic components that may be used include field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip systems (SOCs), complex programmable logic devices (CPLDs), etc. Additionally, each of the processor(s) <NUM> may possess its own local memory, which also may store program modules, program data, and/or one or more operating systems. The one or more processor(s) <NUM> may include one or more cores.

The one or more input/output (I/O) interface(s) <NUM> may enable the application server <NUM>, <NUM> to detect interaction with other mobile network components and/or with operators of the mobile network. The network interface(s) <NUM> may enable the application server <NUM>, <NUM> to communicate via the one or more network(s). The network interface(s) <NUM> may include a combination of hardware, software, and/or firmware and may include software drivers for enabling any variety of protocol-based communications, and any variety of wireline and/or wireless ports/antennas. For example, the network interface(s) <NUM> may comprise one or more of a cellular radio, a wireless (e.g., IEEE <NUM>. 1x-based) interface, a Bluetooth® interface, and the like. The storage interface(s) <NUM> may enable the processor(s) <NUM> to interface and exchange data with the computer-readable medium <NUM>, as well as any storage device(s) external to the application server <NUM>, <NUM>. The storage interface(s) <NUM> may further enable access to removable media.

The computer-readable media <NUM> may include volatile and/or nonvolatile memory, 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. Such memory includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile discs (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, RAID storage systems, or any other medium which can be used to store the desired information and which can be accessed by a computing device. The computer-readable media <NUM> may be implemented as computer-readable storage media (CRSM), which may be any available physical media accessible by the processor(s) <NUM> to execute instructions stored on the computer-readable media <NUM>. In one basic implementation, CRSM may include random access memory (RAM) and Flash memory. In other implementations, CRSM may include, but is not limited to, read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), or any other tangible medium which can be used to store the desired information and which can be accessed by the processor(s) <NUM>. The computer-readable media <NUM> may have an operating system (OS) and/or a variety of suitable applications stored thereon. The OS, when executed by the processor(s) <NUM> may enable management of hardware and/or software resources of the application server <NUM>, <NUM>.

Several components such as instruction, data stores, and so forth may be stored within the computer-readable media <NUM> and configured to execute on the processor(s) <NUM>. The computer readable media <NUM> may have stored thereon an IMEI registration manager <NUM>, a UE manager <NUM>, a session manager <NUM>, and a push proxy manager <NUM>. It will be appreciated that each of the components <NUM>, <NUM>, <NUM>, <NUM>, may have instructions stored thereon that when executed by the processor(s) <NUM> may enable various functions for restoring OTT services after a failure of one or more S-CSCF <NUM>, <NUM>.

The instructions stored in the IMEI registration manager <NUM>, when executed by the processor(s) <NUM>, may configure the application server <NUM>, <NUM> to receive IMEI and/or MSISDN registration information and register a corresponding MT UE <NUM> within the application server <NUM>, <NUM> to enable providing services to the MT UE <NUM>, including OTT services. The processor(s) <NUM> may further be configured to identify whether there are any OTT services associated with a particular IMEI and/or MSISDN. This correspondence information of MSISDN to an indication of any OTT services may be stored on the IMEI registration manager <NUM> on the computer-readable media <NUM>. Alternatively, the MSISDN to OTT service correspondence information may be stored in an a separate datastore. As described herein, when a MT UE <NUM> attempts to register its IMEI, the processor(s) <NUM> may identify whether the related MSISDN has corresponding OTT services, and if it does, then the processor(s) <NUM> may generate a push notification to cause the OTT services to reregister with the mobile network.

The instructions stored in the UE manager <NUM>, when executed by the processor(s) <NUM>, may configure the application server <NUM>, <NUM> to cooperate with other elements of environments <NUM>, <NUM>, <NUM> to provide services, such as OTT services to any variety of MT UEs <NUM> that are registered with the mobile network. The processor(s) in some cases, may be configured to determine if an OTT to which services are to be provided is currently not registered. In some cases, the processor(s) <NUM> may be configured to make this determination by determining whether corresponding IMEI and/or MSISDN of the MT UE <NUM> is currently registered with the application server <NUM>, <NUM> and/or the rest of the mobile network.

The instructions stored in the session manager <NUM>, when executed by the processor(s) <NUM>, may configure the application server <NUM>, <NUM> to open a session with an MT UE <NUM> to provide any variety of services to the MT UE <NUM>, including OTT services. The processor(s) <NUM> may be configured to identify when a particular OTT application and/or its corresponding MSISDN is not properly registered with the application server <NUM>, <NUM> or the rest of the mobile network. In this case, the processor(s) <NUM> may be configured to delay issuing a service invite (e.g., an SIP: Invite) until the associated OTT application reregisters with the application server <NUM>, <NUM>, such as by a third party registration process. The processor(s) <NUM> may further be configured to initiate the process of causing unregistered OTT applications to reregister with the mobile network.

The instructions stored in the push proxy manager <NUM>, when executed by the processor(s) <NUM>, may configure the application server <NUM>, <NUM> to identify when OTT applications associated with a particular IMEI and/or MSISDN is to be prompted to reregister with the mobile network to restore OTT services. The processor(s) <NUM> may identify, such as based on determining that a particular IMEI registering and further based on identifying that the corresponding MSISDN has associated OTT services, for a MT UE <NUM> that OTT applications are to be reregistered. The processor(s) <NUM> may firther determine that OTT applications associated with a MT UE <NUM> are to reregister with the mobile network based at least in part on the OTT service that is to be provided to the corresponding OTT application and/or its corresponding IMEI/MSISDN being unregistered with the application server <NUM>, <NUM> and/or the rest of the mobile network. The processor(s) <NUM> may generate a push notification (e.g., HTTP message, HTTPS message, etc.) to cause the OTT applications associated with a MT UE <NUM> to reregister with the application server <NUM>, <NUM> and/or the mobile network. The push notification may be sent to the SPP <NUM> to prompt the SPP <NUM> to generate additional individual push notifications for each OTT application associated with the MT UE <NUM>.

<FIG> illustrates a block diagram of an example SPP system <NUM> that may enable a restoration of OTT services, in accordance with examples of the disclosure. The SPP <NUM> may include one or more processor(s) <NUM>, one or more input/output (I/O) interface(s) <NUM>, one or more network interface(s) <NUM>, one or more storage interface(s) <NUM>, and computer-readable media <NUM>. The descriptions of the one or more processor(s) <NUM>, the one or more input/output (I/O) interface(s) <NUM>, the one or more network interface(s) <NUM>, the one or more storage interface(s) <NUM>, and the computer-readable media <NUM> may be substantially similar to the descriptions of the one or more processor(s) <NUM>, the one or more input/output (I/O) interface(s) <NUM>, the one or more network interface(s) <NUM>, the one or more storage interface(s) <NUM>, and the computer-readable media <NUM>, respectively, as described in <FIG> with respect to the application server <NUM>, <NUM>, and in the interest of brevity, will not be repeated here.

Several modules such as instruction, data stores, and so forth may be stored within the computer-readable media <NUM> and configured to execute on the processor(s) <NUM>. The computer readable media <NUM> may have stored thereon a push proxy manager <NUM>, a UUID manager <NUM>, a UE manager <NUM>, and an OTT manager <NUM>. It will be appreciated that each of the modules <NUM>, <NUM>, <NUM>, <NUM>, may have instructions stored thereon that when executed by the processor(s) <NUM> may enable various functions pertaining to the operations of the SPP <NUM>.

The instructions stored in the push proxy manager <NUM>, when executed by the processor(s) <NUM>, may configure the SPP <NUM> to receive a receive a push proxy message from the application server <NUM>, <NUM> that instructs the SPP <NUM> to request individual OTT applications associated with a particular MT UE <NUM> to reregister with the mobile network to restore OTT services to those individual OTT applications. The processor(s) <NUM> may be configured to identify a IMEI and/or MSISDN of a MT UE <NUM> from the push notification received from the application server <NUM>, <NUM>. The processor(s) <NUM> may further be configured to generate push notifications for each of the OTT applications that are to be instructed to reregister to cause those OTT applications to reregister with the mobile network.

The instructions stored in the UUID manager <NUM>, when executed by the processor(s) <NUM>, may configure the SPP <NUM> to identify the UUIDs of OTT applications that are associated with an IMEI and/or MSISDN of a MT UE <NUM> for which OTT services are to be restored. The UUIDs may be stored in a table that associates those UUIDs to their corresponding MSISDN. In some cases, the UUID correspondence table may be stored in the UUID manager <NUM> on the computer-readable media <NUM>. In other cases, the UUID correspondence table may be stored on a separate datastore.

The instructions stored in the UE manager <NUM>, when executed by the processor(s) <NUM>, may configure the SPP <NUM> to update a correspondence table that relates an MSISDN of a MT UE <NUM> with its UUIDs of corresponding OTT applications. This may be updated every time a new OTT application is used and/or downloaded onto a MT UE <NUM>.

The instructions stored in the OTT manager <NUM>, when executed by the processor(s) <NUM>, may configure the SPP <NUM> to generate a push notification associated with each OTT application associated with a MT UE <NUM> to cause those OTT applications to reregister with the mobile network to restore OTT services. The processor(s) <NUM> may generate and send the push notifications for reregistration to the OTT applications of the MT UEs <NUM> for which OTT services are to be restored.

<FIG> illustrates a block diagram of an example MT UE <NUM> that may be configured to reregister with a mobile network to restore OTT services corresponding to OTT application running on the MT UE <NUM>, in accordance with examples of the disclosure.

In accordance with various examples disclosed herein, the terminating user equipment (UE), communication device, device, wireless communication device, wireless device, mobile device, terminal, wireless terminal, mobile terminal, and client device, may be used interchangeably herein to describe the MT UE <NUM>. The MT UE <NUM> may be configured for transmitting/receiving data, wirelessly and/or over wired networks, using any suitable 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+), New Radio (NR), 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), Voice over LTE (VoLTE), IEEE <NUM>. 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 MT UE <NUM> may include one or more processor(s) <NUM>, one or more input/output (I/O) interface(s) <NUM>, one or more network interface(s) <NUM>, one or more storage interface(s) <NUM>, and computer-readable media <NUM>. The descriptions of the one or more processor(s) <NUM>, the one or more input/output (I/O) interface(s) <NUM>, the one or more network interface(s) <NUM>, the one or more storage interface(s) <NUM>, and the computer-readable media <NUM> may be substantially similar to the descriptions of the one or more processor(s) <NUM>, the one or more input/output (I/O) interface(s) <NUM>, the one or more network interface(s) <NUM>, the one or more storage interface(s) <NUM>, and the computer-readable media <NUM>, respectively, as described in <FIG> with respect to the application server <NUM>, <NUM>, and in the interest of brevity, will not be repeated here.

Several modules such as instruction, data stores, and so forth may be stored within the computer-readable media <NUM> and configured to execute on the processor(s) <NUM>. The computer readable media <NUM> may have stored thereon an OTT manager <NUM>, an HTTP manager <NUM>, a registration manager <NUM>, and a service manager <NUM>. It will be appreciated that each of the modules <NUM>, <NUM>, <NUM>, <NUM>, may have instructions stored thereon that when executed by the processor(s) <NUM> may enable various functions pertaining to the operations of the MT UE <NUM>.

The instructions stored in the OTT manager <NUM>, when executed by the processor(s) <NUM>, may configure the MT UE <NUM> to operate a number of OTT applications thereon, with each OTT application having its own corresponding UUID. The processor(s) <NUM> also enable receiving services for the OTT applications running on the MT UE <NUM>.

The instructions stored in the HTTP manager <NUM>, when executed by the processor(s) <NUM>, may configure the MT UE <NUM> to receive push notification(s), such as from the SPP <NUM>. These push notifications may include instructions, such as instructions to cause an OTT application to reregister on the mobile network.

The instructions stored in the registration manager <NUM>, when executed by the processor(s) <NUM>, may configure the MT UE <NUM> to register with the mobile network, such as by sending one or more requests to register. The processor(s) <NUM> may also enable OTT applications operating on the MT UE <NUM> to reregister with the mobile network, such as for the purpose of restoring mobile services to the MT UE <NUM>.

The instructions stored in the service manager <NUM>, when executed by the processor(s) <NUM>, may configure the MT UE <NUM> to provide one or more services to the user of the MT UE <NUM>, including OTT services, as provided by the application server <NUM>, <NUM> in association with a variety of other elements of the mobile network.

The illustrated aspects of the claimed subject matter may also be practiced in distributed computing environments where certain tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as illustrative forms of implementing the claims.

The disclosure is described above with reference to block and flow diagrams of systems, methods, apparatuses, and/or computer program products according to examples of the disclosure. It will be understood that one or more blocks of the block diagrams and flow diagrams, and combinations of blocks in the block diagrams and flow diagrams, respectively, can be implemented by computer-executable program instructions. Likewise, some blocks of the block diagrams and flow diagrams may not necessarily need to be performed in the order presented or may not necessarily need to be performed at all, according to some examples of the disclosure.

Computer-executable program instructions may be loaded onto a general-purpose computer, a special-purpose computer, a processor, or other programmable data processing apparatus to produce a particular machine, such that the instructions that execute on the computer, processor, or other programmable data processing apparatus create means for implementing one or more functions specified in the flowchart block or blocks. These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means that implement one or more functions specified in the flow diagram block or blocks. As an example, the disclosure may provide for a computer program product, comprising a computer usable medium having a computer readable program code or program instructions embodied therein, said computer readable program code adapted to be executed to implement one or more functions specified in the flow diagram block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational elements or steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions that execute on the computer or other programmable apparatus provide elements or steps for implementing the functions specified in the flow diagram block or blocks.

It will be appreciated that each of the memories and data storage devices described herein can store data and information for subsequent retrieval. The memories and databases can be in communication with each other and/or other databases, such as a centralized database, or other types of data storage devices. When needed, data or information stored in a memory or database may be transmitted to a centralized database capable of receiving data, information, or data records from more than one database or other data storage devices. In other examples, the databases shown can be integrated or distributed into any number of databases or other data storage devices.

Claim 1:
An application server (<NUM>, <NUM>) comprising:
one or more processors; and
one or more computer-readable media storing computer-executable instructions that, when executed by the one or more processors, cause the one or more processors to perform acts comprising:
receiving (<NUM>) a registration request associated with a user equipment, UE (<NUM>);
determining (<NUM>), based at least in part on the registration request, that the UE is associated with over-the-top, OTT, services;
generating (<NUM>), based at least in part on the determining that the UE is associated with OTT services, a push notification (<NUM>); and
sending (<NUM>), to a secure push proxy, SPP (<NUM>) system, the push notification, wherein the push notification instructs to the SPP system to generate one or more second push notifications (<NUM>) to instruct one or more OTT applications associated with the UE to reregister with a mobile network.