Predictive wakeup for push-to-talk-over-cellular (poc) call setup optimizations

ES 2 554 929 T3

DESCRIPTION

Predictive wake-up for push-to-talk call setup optimizations over cellular (PoC)

BACKGROUND OF THE INVENTION

1. Field of Invention

This invention relates generally to mobile phone networks and more specifically to predictive wake-up for push-to-talk call setup optimizations via cellular in a mobile phone network.

two. Description of Related Art

Advanced Voice Services (AVS), also known as Advanced Group Services (AGS), such as two-way semi-duplex voice calls within a group, also known as Push To Talk Over Cellular (PoC), Push To Talk (PTT - Push To Talk) or Push To Talk (P2T - Press To Talk), as well as other AVS functions, such as push to conference (P2C - Push To Conference, in English) or instant conference, push to message (P2M - Push To Message, in English), etc., are described for example in document WO2010 / 048217. These AVS features have enormous business potential for wireless communication systems, such as cellular networks and Personal Communications Systems (PCS) networks.

Currently, there are two main approaches used in providing advanced voice services in wireless communication systems. One approach is based on circuit switched technology, in which voice circuits are reserved for the entire AVS or PoC call. The circuit switched PoC system is deployed by many operators around the world with technologies such as NEXTEL's iDEN and Kodiak Network's RTX.

Another approach to PoC is based on Voice over Internet Platform (VolP) or packet technologies. This approach is based on the “bursty” nature of PoC conversations and makes network resources available only during conversational bursts, and is therefore highly efficient from a network resource and communication point of view. spectrum. This approach ensures compliance with the newest and emerging packet-based standards, such as GPRS (General Packet Radio Service), UMTS (Universal Mobile Telecommunications System). ), 3G, 4G, LTE, etc.

In either approach, an effective PoC implementation requires PoC session setup times of less than 2 seconds for acceptable performance. In practice, these setup times are difficult to achieve considering the inherent network parameters. For example, to conserve device battery life, the networks are adjusted such that the device terminals are put into battery conservation sleep mode and will periodically wake up to listen to the paging channel. This results in inherent delays of more than 2 seconds in establishing PoC sessions, which is unacceptably long.

Thus, there is a need in the industry to improve methods and systems for providing advanced voice services, such as PoC, that meet the standards of both existing circuit-based networks and emerging packet-based networks, even providing better. user experiences by reducing PoC call setup times to acceptable limits. The present invention satisfies this need.

COMPENDIUM OF THE INVENTION

To overcome the limitations of the prior art described above, and to overcome other limitations that will appear upon reading and understanding the present specification, the present invention describes a predictive wake-up for push-to-talk call setup optimizations via cellular ( PoC) for use in wireless communication networks, such as cellular mobile phone networks.

Predictive wake-up is a mechanism in which the originating and terminating parties in a PoC session go from a suspended radio channel state to an active channel for faster session establishment. The reactivation mechanisms are "predictive" since the actual participants in the session are not known at the time of initiation of the reactivation.

When predictive reactivation is performed for call establishment optimizations, a source mobile transmits an event trigger to a real-time exchange, and the real-time exchange transmits a reactivation message to one or more terminating mobiles of the participants in order to move the terminating mobiles of the predicted participants from a sleep state to an active state before they are

ES 2 554 929 T3 establish a PoC call with the mobile phones of the predicted participants. The event trigger can be transmitted from the home mobile on any of the following events, or a combination thereof, such as when: a user connects to a client on the home mobile; a user navigates a list of contacts; a user selects one or more contacts or groups from the contact list; a user navigates a call history; a user selects one or more call history entries, a user presses a PoC button on a device, a user performs some other activity on the device, and so on.

Predicted participants can be determined on the basis of static or dynamic information. In one embodiment, the participants can be determined based on heuristic patterns relative to real-time calls, including: most used contacts at any time, most recently used contacts, contacts used at a certain time of day, last contacts used, contacts involved in the long duration of the sessions, direction of entry or exit of the sessions with the contacts, incoming instant personal alerts , activity level of contacts or active participants in a group call.

The terminating mobiles of the predicted participants are identified by a predictive wake-up mechanism before the originating mobile sends a list of one or more actual participant terminating mobiles to the real-time exchange. When it receives the list of the terminating mobiles of the real participants, the real-time exchange establishes PoC sessions to the terminating mobiles of the real participants. Since the session participants have been moved from a suspended state to an active state by the earlier wake-up messages that were sent by the real-time exchange, the total setup time to establish PoC sessions is greatly reduced.

The predictive wake-up mechanism includes one or more algorithms executed by a processor that infers the predicted participant list, where these algorithms can be client-based or server-based. Client-based algorithms infer the participant list based on the client's actions on the mobile. Server-based algorithms can infer the same or a different list of predicted participants based on the same information or on server-based information not available for a client-based algorithm. Also, a server-based algorithm eliminates the need for the mobile client to implement complex algorithms, resulting in less complexity and therefore lower cost.

BRIEF DESCRIPTION OF THE DRAWINGS

Referring now to the drawings in which like reference numerals represent corresponding parts therein:

FIGURE 1 is a block diagram illustrating an example embodiment of a wireless communication network in accordance with a preferred embodiment of the present invention.

FIGURE 2 illustrates a proposed architecture for a real-time switch in accordance with the preferred embodiment of the present invention.

FIGURE 3 illustrates high-level functional components and their interfaces in a mobile phone station or mobile device in accordance with a preferred embodiment of the present invention.

FIGURES 4 and 5 are flowcharts illustrating end-to-end setup times for PoC call setup using predictive wake-up.

DETAILED DESCRIPTION OF THE INVENTION

In the following description of the preferred embodiment, reference is made to the accompanying drawings which form a part thereof, and in which the specific embodiment in which the invention may be practiced is shown by way of illustration. It should be understood that other embodiments that can be used as structural changes can be made without departing from the scope of the present invention.

General view

This invention relates generally to mobile phone networks and, more specifically, to predictive wake-up for call setup optimizations in a mobile phone network. In one embodiment, the predictive wake-up mechanism of the present invention is used with a push-to-talk call over cellular (PoC) for wireless networks, although it can also be used for other advanced voice services.

Network architecture

FIGURE 1 is a block diagram illustrating an example embodiment of a wireless communication network (also known as a mobile phone network or simply a mobile communication network) in accordance with a preferred embodiment of the present invention.

Within the network 100, an RTX (Real Time Exchange) 102, formerly known as a Dispatch Gateway (DG), also known as a PoC server, communicates with an MSC (Mobile Switching Center) 104 and with the PSTN (Public Switched Telephone Network, in English) 106 using SS7 messages - ISUP / WIN / CAMEL (Signaling System 7 - Digital Service Network User Part

ES 2 554 929 T3 Integrated / Wireless Intelligent Network / Customized Applications for Mobile Enhanced Logic (Signaling System 7 - Integrated Services Digital Network User Part / Wireless Intelligent Network / Customized Applications for Mobile Enhanced Logic, in English) in a signaling plane 108 . A bearer route 110 implements a TDM (Time Division Multiplexing) interface that carries PCM (Pulse Code Modulation) or TFO (No Tandem Tandem Operation) voice frames. Free Operation, in English). Support for TFO on this route 110 is negotiated between a BSC (Base Station Controller) 112 and the RTX 102 for each initiating and terminating side of an AVS call. Using TFO ensures high voice quality (since speech scrambler conversion is avoided) between mobile-to-mobile calls.

When a subscriber initiates an AVS call, MSC 104 routes the call to RTX 102. MSC 104 also requests BSC 112 through 116 to establish a radio traffic route 118 with a mobile 120 (also known as a station mobile phone, mobile unit, mobile phone, telephone or cellular device) via the BTS (Base Transceiver Station) 122 (as you do for a normal cellular call).

At the same time (after the MSC 104 terminates the group call request to the RTX 102), the RTX 102 identifies the terminating group users and their numbers, which may comprise an MS-ISDN (Station Station) number. mobile telephony - Integrated Services Digital Network - Mobile Station - Integrated Services Digital Network, an IMSI number (International Mobile Subscriber Identity, or an MDN (Mobile Directory Number).

The RTX 102 sends an ISUP call initiation request for each terminating mobile 120. It can send requests directly to the MSC 104, the PSTN 106 or the IP network 124 via a PDSN (Public Switched Data Network - Public Data Switched Network, in English) 126, router 128 and / or Internet / Intranet 130, depending on the routing table configuration for termination numbers. Once the bearer route 110 has been established, the RTX 102 initiates a negotiation with the far end (in this case, the terminating BSC 112) for each terminating side to a mobile 120.

Once the bearer routes 110 have been established for the originating and terminating sides for an AVS call, the RTX 102 switches (or duplicates) the voice or data from the originating mobile 120 to all terminating mobiles 120.

The RTX 102 can also use the IP network 124 or the Internet / Intranet 130. For example, the IP network 124 or the Internet / Intranet 130 can be used in a toll circumvention mode in which two RTX 102s can exchange voice and signaling traffic bypassing PSTN 106. However, each RTX 102 is responsible for terminating traffic to its nearest MSC 104. In this case, the IP network 124 or the Internet / Intranet 130 is used as the backbone transport of voice traffic between two RTX 102s.

The IP network 124 or the Internet / Intranet 130 may also be used for PoC, registration, presence, and other applications, such as predictive wake-up for PoC call setup, as described in more detail below. For example, such applications can run over an IP stack on mobile 120. After the mobile 120 registers for a data interface (that is, it obtains an IP address) with the PDSN 126 (or equivalently, with an SGSN (Serving GPRS Support Node, in English) or gGsN (Gateway GPRS Support Node - Gateway GPRS Support Node, in English) for GSM networks, or with a PDSN (Packet Data Service Node , in English) in the case of CDMA networks), or an MME (Mobility Management Entity) and the SAE (System Architecture Gateway) gateway for LTE networks, the application on mobile 120 it registers with the RTX 102 using its IP address. The RTX 102 also uses this IP interface during application sessions.

An alternative embodiment would use SMS (Short Message Service) transport to transport messages over a data channel. The RTX 102 interacts with the mobile 120 using predefined messages related to the application that are transported as SMS messages. The same messages can be carried over PDSN interfaces 126, or another IP network 124 or the Internet / Intranet (eg, SGSN, GGSN, MME interfaces), if such interfaces are supported.

While roaming, an HLR (Home Location Register) 132 and a VLR (Visitor Location Register) 134) can be accessed via the MsC 104 and an IS-41 link 136. The HLR 132 and VLR 134 are used to track the presence of members of a group on local or outside networks and to update mobiles 120 for the members with the network availability of other members of the group.

ES 2 554 929 T3

Real-time exchange

FIGURE 2 illustrates a proposed architecture for the RTX 102 in accordance with the preferred embodiment of the present invention.

The architecture includes a call processing system 200, a presence server 202, a real-time event processing system 204, one or more media managers 206, and an SMPP (Short Message Peer-to-Peer) transport. Peer to Peer, in English) 208, as well as modules for various SS7 protocols, such as the MTP-1 protocols (Message Transfer Part Level 1 - Message Transfer Part Level 1, in English) 210, MTP-2 (Level 2 Message Transfer Part) 212, MTP-3 (Level 3 Message Transfer Part) 214, ISUP (Integrated Services Digital Network User Part) 216, SCCP (Part Signaling Connection Control Part, in English) 218 ​​and TCAP (Transactions Capabilities Application Part, in English) 200. Alternatively, modules 210-220 may implement other protocols, such as IP protocols, for use in, for example, VoIP calls or sessions.

The call processing system 200, the presence server 202, the media managers 204, the SMPP transport 206, and other modules communicate over the IP network 222. The real-time event processing system 204 is connected. communicates directly with call processing system 200, presence server 202, and SS7 multi-protocol modules. Modules for various SS7 protocols communicate with other entities through an SS7 224 signaling link. The SMPP 206 transport communicates with a gateway of SMSC (Short Message Service Center, en English) using the SMPP protocol 226. The media managers 204 communicate with each other using the H.110 protocol 228 or other protocols, such as IP.

The operation of these different components is described in more detail below, as well as in the co-pending and commonly assigned patent applications referenced above and incorporated herein by reference.

The architecture also includes a predictive wake-up function 230, which is used to execute a predictive wake-up algorithm for PoC call setup optimizations, as described in more detail below.

The source rover 120 signals the RTX 102 over the wireless network 100, for example, transmitting one or more digits of DTMF (Dual Tone Multi Frequency) configured to the RTX 102 or include to guests as part of a SIP message exchange over pre-set SIP sessions. For circuit switched PoC, media manager systems 206 receive the DTMF digits and pass the DTMF digits to call processing system 200. In the case of packet switched PoC, call processing system 200 receives the protocol client guest list 120 using SIP signaling. The call processing system (CP-Call Processing) 200 determines whether the originating mobile 120 has subscribed to the AVS features before initiating the terminating AVS call. Upon confirmation, the call processing system 200 initiates a new terminating AVS call. The call processing system 200 interacts with the presence server 202 and with the real-time event processing system 204 to cause the wireless network 100 to make a call setup with the terminating mobiles 120 for the AVS call, and then handle the AVS call.

Call processing system 200 interacts with media manager systems 206 to maintain RTP ports or H.110 227 channels and allocates any additional H.110 228 channels or intermediate server ports required for the AVS call, which can span the multiple media manager systems 206. During the AVS call, the media manager systems 206 of the RTX 102 are used to mix audio streams between the originating mobile 120 and the terminating mobile 120 and then send these mixed audio streams to the mobile 120 of origin and mobile 120 of termination. The H.110 channels 228 or the inter-media server ports are used to pass the voice of unmixed audio streams between the media manager systems 200 as needed.

Call processing system 200 interacts with predictive wake-up function 230 to update call pattern information. The call pattern information, gathered as part of call processing, is used by the predictive wake-up function 230 to determine the list of terminating entities that need to be moved from a "suspended" state to an "active" state. as part of predictive wake-up for PoC call setup optimizations.

Mobile components

FIGURE 3 illustrates high-level functional components and their interfaces on mobile 120 in accordance with a preferred embodiment of the present invention.

Preferably, mobile 120 includes a Subscriber Identity Mobile (SIM) 300 that is inserted into mobile 120 to provide wireless telephony service. The SIM 300

ES 2 554 929 T3 stores some of the logic and data required from mobile 120 to provide a cellular service, including the functions necessary to support AVS functionality, namely both PoC calls and predictive wake-up for call calls. PoC, as well as other AVS functionality. In addition, SIM 132 stores contact and group information, and other user information for use by mobile 120.

The high-level functional components of the mobile 120 include an encoder / decoder 320, processing logic 304, and a user interface 306. In the SIM 300 there is a client application 308 that supports the AVS functionality for the mobile 120. In addition, SIM 300 stores a database 310, which includes an address book, AVS contacts, and / or group information.

During power-up, mobile 120 loads the client application 308 necessary to support AVS functionality. This provided functionality includes the "profile" of the menu screens of the mobile 120, as well as the interaction of a user with the menu screens.

During operation, encoder / decoder 302 decodes and encodes messages, and fills in specific data structures at mobile 120. Encoder / decoder 302 checks the validity of incoming messages by checking the mandatory parameters for each of the incoming messages. A message will receive no further processing if the encoder / decoder 302 fails to decode the message.

Processing logic 304 handles all the functionality of the AVS. The implementation of processing logic 304 is device-specific and vendor-specific, and interacts with the other components, including encoder / decoder 302, user interface 306, client application 308, and database 310 .

Processing logic 304 provides an automatic response mechanism for AVS functionality. Specifically, when a call is received, the processing logic 304 automatically answers the call. Processing logic 304 makes use of the call notification for incoming call detection and, based on various parameters received in the call notification, determines whether the call is an AVS call. If the call is an AVS call, then the processing logic 304 uses "AT" commands to answer the AVS call and turn on the speaker of the mobile 120. (All of this occurs over a certain period of time). On the other hand, if the call is not an AVS call, then the mobile 120 performs normal call processing.

Processing logic 304 also provides "speech ownership control" using DTMF tone control or MBCP (Media Burst Control Protocol) using RTCP (Inline Transport Control Protocols). real time). In PoC calls, which are half-duplex, the determination of who can speak is based on who “has the floor”. Using processing logic 304 provided on the mobile 120, appropriate DTMF tones or MBCP word possession control messages are sent to the RTX 102 according to specific key sequences (i.e., press and / or stop press a PoC key) that indicate whether "possession of the word" has been requested and / or released by the user.

In addition, the processing logic 304 provides SMS destination control based on the type of subscriber. At the time of subscriber data delivery, if it is determined that mobile 120 will use AVS-based logic, then the appropriate logic is invoked in RTX 102 to send presence messages over SMS to mobile 120 or using SIP messages. Similarly, mobile 120 is configured at delivery to receive / accept such SMS and to respond to the RTX appropriately.

Finally, the processing logic 304 also allows subscribers to track the presence of group members in the network 100 on their mobile 120, and provides a mechanism and API for conducting contacts and group management operations on the mobile 120, such as like adding a member, deleting a member, etc.

Since most of the presence information is stored in database 310, database 310 is tightly integrated with processing logic 304. Database 310 stores information regarding groups, contacts, presence, and availability. The information in the database 310 essentially contains group and member information along with presence information associated with each group and member. Aside from group and member information, database 310 also stores subscriber information, such as privileges, presence information, configuration parameters, and so on. The other components of the mobile 120 may interact with the database 310 to obtain / update group, member and presence information for various operations. Database 310 also has pointers to the native address book in mobile 120, to provide "alias" type names directly for contacts used with cell phone calls, as well as AVS features.

User interface 306 provides a mechanism for the user to view and manage groups, group members, contacts, presence, and availability. User interface 306 also makes it possible to invoke AVS features from group / contact list screens, as described in more detail below.

ES 2 554 929 T3

Predictive reactivation for PoC establishment optimization

An effective PoC implementation requires call or session setup times between participants to be on the order of approximately ~ 1 second. In practice, these setup times are difficult to achieve, as the underlying network parameters pose inherent (and natural) constraints on how quickly a call setup can be accomplished. For example, the networks 100 are set up to conserve the battery life of the mobiles 120 by indicating how often they reactivate to listen to the location channels. Furthermore, these settings of network 100 cannot be compromised to meet the needs of an application, such as PoC, at the cost of large impacts on network 100 on the experiences of all users. As a result, inherent delays are introduced in call setup.

The present invention implements a call setup for PoC based on "predictive wake-up" that enables faster call setup. Predictive wake-up is a mechanism in which the originating and terminating mobiles 120 on a PoC call can be moved from a sleep state to an active state prior to call establishment. The wake-up mechanisms are “predictive” since the actual participants in the call are not known at the time the predictive wake-up mechanism is executed, and thus the predictive wake-up mechanisms determine the predicted participants for the call, instead of the actual participants.

In one embodiment, the predictive wake-up mechanism is initiated as a result of any of the following trigger events on the originator side, including, but not limited to, the following trigger events:

• search or browse for contacts or groups or call history on mobile 120 • selection of contacts, groups or previous calls on mobile 120 (for example, select checkbox or equivalent on touch screen devices ) • launch client 308 on mobile 120 • press the PoC button on mobile 120 • perform any user activity on mobile 120.

During any of these trigger events, and on the basis of heuristics involving previous call patterns, or other dynamic or static information, a predicted set of participants for a particular PoC session can be inferred before the participants real are known, and "wake-up messages" can be sent to move the terminating mobiles for these predicted participants from a suspended state to an active state to handle any incoming call setup.

FIGURE 4 is a flow chart illustrating an end-to-end sequence for establishing the PoC call using predictive wake-up.

1. At T1, the user launches the PoC client 308 by pressing a PoC button on the home mobile 120, resulting in the PoC client 308 sending an event trigger, in this example a "wake up" message, to RTX 102, over the preset IP session. This wake-up message moves the home mobile 120 from a sleep state to an active state.

It should be noted, however, as mentioned above, that event triggering may comprise searching or browsing for contacts, groups, or call history on mobile 120, selecting contacts, groups, or previous calls on mobile 120, as well such as launching the PoC client 308 on mobile 120, or pressing the PoC button on mobile 120, or other user actions on mobile 120. In addition, the event trigger may comprise a message other than the wake-up message.

In response to the event trigger, the predictive wake-up function 230 of the RTX 102 executes a predictive wake-up algorithm to determine the predicted participants. Alternatively, the predictive wake-up function 230 of the RTX 102 receives a message with the predicted participants as determined by the mobile 120, which can execute a predictive wake-up algorithm. The predictive wake-up function 230 of the RTX 102 then sends a "wake-up" message to each of the terminating mobiles 120 for the predicted participants, so that the terminating mobiles 120 also go from a sleep state to a active status.

two. Between T1 and T2, the user searches or browses for contacts, groups or call history on mobile 120, selects the desired contacts, groups or calls, and presses the PoC button on mobile 120.

3. At T2, the PoC client 308 sends a "Set REFER / MBCP" message to the RTX 102, which includes a list of actual participants. The RTX 102 then sends a "Connect TBCP (MBCP)" (Connect Burst Call Control Protocol (Media Burst Control Protocol)) message to each of the terminating mobiles 120 for the actual participants.

Four. At some point after T2, a chirp tone is received at the home mobile 120 at T3, indicating that the user has "the floor" for the call, and thus the right to speak, and the user begins to speak.

ES 2 554 929 T3

FIGURE 5 is a flow chart illustrating an alternative end-to-end sequence for establishing the PoC call using predictive wake-up. The difference between this sequence and the sequence in FIGURE 4 is that the wake-up message in FIGURE 5 is transmitted to RTX 102 over a control channel on T1, instead of waiting for the traffic channel to be established. This allows the reactivation message to be transmitted to the RTX 102 more quickly, and allows the terminating mobiles 120 to be reactivated more quickly. It should be noted that a separate traffic channel wake-up message, transmitted by the PoC client 308 before or after the wake-up message at or about T1, transitions the home mobile 120 into a specific traffic channel state, while the PoC client 308 on the terminating mobile 120 also sends a traffic channel activation message to the RTX 102, in response to receipt of the reactivation message, between T1 and T2, to move the terminating mobile 120 into a traffic channel state. The remaining portions of FIGURE 5 are the same as FIGURE 4.

The predictive wake-up mechanism includes one or more algorithms executed by a processor that infers the predicted participant list, where these algorithms can be client-based (i.e., home mobile 120) or server-based (i.e. , on the RTX 102 or another server on the 100 network). Although both approaches are possible, server-based predictive wake-up algorithms have several advantages over client-based predictive wake-up algorithms:

(1) The server-based approach may include client-based information beyond the knowledge of the originating client 308 to predict the list of participants.

(2) The server-based approach eliminates the need for clients 308 to implement complex algorithms, and instead simply requires sending a wake-up message from mobile 120 to RTX 102 to initiate the predictive wake-up mechanism.

The following describes some proposed implementations of the predictive wake-up algorithms:

• Let C be the finite set of all contacts that belong to a subscriber.

• Then, T, a subset of C, is inferred by predictive algorithms, such that the cardinality of T <N, • where N is configured to limit the total use of network resources, • N can be an extended configuration of the system, or • N is a fraction of the size of the contact list (for example, | T | / | C | <N).

It should be noted that T can also be ordered based on the number of call occurrences to and / or from a particular contact, such that the first "i" entries in this ordered list correspond to a probability that the call is completed.

For example, a list of all called numbers and their frequency over some period of time (eg 7 days) can be stored in memory or on a data storage device. The processor can then calculate how many numbers and which numbers need to be "reactivated" to achieve a predefined probability of success (eg 95%) for the predictive reactivation mechanism.

Consider the example illustrated in the following table:

<td>Called number</td><td>Frequency of calls in a period of time</td>

<td> 1234</td><td> 11</td>

<td> 1235</td><td> 9</td>

<td> 1236</td><td> 8</td>

<td> 1237</td><td> 7</td>

<td> 1238</td><td> 6</td>

<td> 1239</td><td> 5</td>

<td> 1240</td><td> 4</td>

<td> 1241</td><td> 3</td>

<td> 1242</td><td> 1</td>

<td> 1243</td><td> 1</td>

<td></td><td>Total = 55</td>

To achieve a 95% probability of success, the predictive reactivation mechanism would need to reactivate the first 8 numbers called, that is, 95% * 55 = 52.25.

Generally, predictive wake-up algorithms can use any heuristics that involve patterns or other dynamic or static information:

ES 2 554 929 T3 • dynamic information • static information • heuristics involving call patterns:

• most used contacts at any time • most recently used contacts • last used contacts • contacts involved in long duration of sessions • direction (incoming or outgoing) of sessions with contacts • level of contact activity (independent of originator) • active participants in a group call, or • Instant Personal Alerts (IPA).

Other heuristics can be used as well, and the above list is not intended to be exhaustive.

The details of these heuristics are described in more detail below.

• Most used X at any time • Contacts or groups (accumulated over a PoC service life cycle for one user).

• Most recently used Xs • Contacts or groups (within a given time frame, for example one month).

• X most used at a certain time of day • Contacts or groups based on time of day (for example, X most used from 8 AM to 10 AM, 10 AM to 3 PM, 3 PM to 6 PM, 6 PM PM to 8 AM could be different).

• The number of day slots and the start / end of the time slot are configurable.

• This can be used in combination with the most used contacts at any time or with the most recently used contacts.

• Last X most used • Last X contacts or groups used.

• X most used • The criteria or rules to determine the X most used are configurable.

• The absolute minimum number of calls made to a contact or group. This can be an extended network configuration. Once the number of calls to a contact or group reaches this threshold, it enters the X most used.

• Usage and calls related to contacts or groups compared to other contacts or groups.

• Directionality of session establishment • Relative importance for contacts for incoming vs. outgoing call sessions.

• In this case, a supplementary reactivation list can be populated with the identity of the originator for the terminator on a call.

• Level of contact activity • Independent of the originator's involvement.

• Active participants in a group call • Inclusion of contacts who were active participants in a group call.

• Instant Personal Alerts (IPAs) • IPAs are alerts that typically request a callback.

• Statistical significance • The level of importance of call patterns is improved by applying thresholds such as a minimum number of call attempts.

A mix of different predictive wake-up algorithms can be implemented. For example, the predictive wake-up mechanism can be implemented using a mixture of both static and dynamic (ie, learning) predictive wake-up algorithms. This would allow the operators of the network 100 to deploy PoC services based on call patterns and optimize the resources of the network 100. In addition, operators of network 100 can decide which algorithms to use based on geographic area. Network 100 operators can also use the algorithm mix to serve a market segment or subscriber segment

ES 2 554 929 T3 particular, and decide how to profitably use the resource of the network 100 versus a PoC session establishment speed. An adaptive predictive wake-up algorithm can also result in a mix of algorithms that is selected based on the effectiveness of the algorithm.