WO2015193727A1

WO2015193727A1 - Method, apparatus and readable medium for an api notifying an application that qos will change in future

Info

Publication number: WO2015193727A1
Application number: PCT/IB2015/001176
Authority: WO
Inventors: John Benko; Akshay Jain; Dachuan Yu
Original assignee: Orange
Priority date: 2014-06-19
Filing date: 2015-06-18
Publication date: 2015-12-23

Abstract

An application programming interface (API) receives a request from an application on a mobile device to be notified when a Quality of Service (QoS) for communications with the mobile device is predicted to change. The API contacts a server to request a QoS map indicating predicted Quality of Service values for the mobile device. The API receives the QoS map from the server and determines that the QoS map indicates a predicted change in QoS associated with the mobile device. The API sends a notification to the application that the QoS for the mobile device will change in the future.

Description

METHOD, APPARATUS AND READABLE MEDIUM FOR AN API NOTIFYING AN APPLICATION THAT QOS WILL CHANGE IN FUTURE

BACKGROUND

[0001] In networks, the ability for two nodes to communicate with each other can be assessed on various Quality of Service (QoS) metrics. The metrics include throughput or data rate, number of dropped packets, number of packets corrupted by errors, the latency or delay in delivering packets, jitter or variations in the delay in delivering packets, and the number of packets delivered out of order.

[0002] Wireless cellular networks utilize dispersed antennae to communicate with mobile devices. Each antenna is associated with a cell. Ideally, the cells should work together to provide a uniform QoS regardless of where a mobile device is positioned. However, due to obstructing objects, differences in equipment or insufficient numbers of antennae, certain locations have lower QoS or no network connectivity.

[0003] In general, cellular network providers know the average QoS of their network and are aware of locations that have lower average QoS metrics or no connectivity. In addition, network providers generally monitor the amount of traffic on their network and know when the traffic at a particular cell is causing a reduction in QoS for the cell.

[0004] The discussion above is merely provided for general background information and is not intended to be used as an aid in determining the scope of the claimed subject matter. The claimed subject matter is not limited to implementations that solve any or all disadvantages noted in the background.

SUMMARY

[0005] An application programming interface (API) receives a request from an application on a mobile device to be notified when a Quality of Service (QoS) for communications with the mobile device is predicted to change. The API contacts a server to request a QoS map indicating predicted Quality of Service values for the mobile device. The API receives the QoS map from the server and determines that the QoS map indicates a predicted change in QoS associated with the mobile device. The API sends a notification to the application that the QoS for the mobile device will change in the future.

[0006] A server includes a session initiator that initiates a session with an application programming interface (API) on a mobile device in response to a request from the API. A location predictor in the server predicts a future location of the mobile device. A Quality of Service map locator in the server retrieves Quality of Service values for at least the future location of the mobile device and returns a Quality of Service map and the future location to the mobile device. A Quality of Service map monitor in the server monitors Quality of Service values for an area corresponding to the returned Quality of Service map and sends an additional notification to the application programming interface if a Quality of Service value in the area changes.

[0007] A processor-readable medium having stored thereon instructions that when executed by the processor cause the processor to receive a request from a first application to be notified of predicted Quality of Service changes and receiving a request from a second application to be notified of predicted Quality of Service changes. The processor sends a request for a Quality of Service map to a server and receives the Quality of Service map from the server. The processor then sends a notification to at least one of the first application and the second application that a Quality of Service metric is predicted to change in the future.

[0008] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] FIG 1 provides a flow diagram of a method of predicting QoS changes in a mobile network.

[0010] FIG 2 is a block diagram of a system that implements the method of FIG. 1.

[0011] FIG 3 is a flow diagram of a method of requesting new QoS predictions.

[0012] FIG 4 is a flow diagram of a method of pushing an updated QoS map from a server.

[0013] FIG 5 is a flow diagram of a method implemented when an application closes.

[0014] FIG 6 is a block diagram of a mobile device.

[0015] FIG 7 is a block diagram of a computing device that can be used to implement a server. DETAILED DESCRIPTION

[0016] In the embodiments described below, an Application Programming Interface (API) is provided that simplifies application writing by allowing applications to make a single call to the API to receive predictions of network communication Quality of Service (QoS) changes without having to understand where those predictions come from and without predicting the future location of the mobile device. The API is designed to accept requests from multiple applications at the same time and to notify multiple applications when network communication QoS is predicted to change. In addition, the API is able to create a session with a server such that the API can request predictions of QoS changes from the server and receive predicted changes in a QoS map when the QoS provided by a network provider is predicted to change.

[0017] FIG. 1 provides a flow diagram of a method of requesting notification of predicted QoS changes and receiving such notifications. FIG. 2 provides a block diagram of a system used to implement the flow diagram of FIG. 1.

[0018] System 200 of FIG. 2 includes a mobile device 201 and a server 206. Mobile device 201 contains applications 202, and API 204. In the flow diagram of FIG. 1, an application column 100, an API column 102 and a server column 104 are provided to indicate which steps are performed by applications 202, API 204 and server 206.

[0019] In step 106, an application 202 registers with API 204 for Quality of Service forecast notifications by calling an application registration method 208 provided by API 204. In accordance with one embodiment, application registration method 208 is called with input parameters including an application notification handle 210, application data types 212 and application QoS thresholds 214. As shown in FIG. 2, each of these input parameters are stored in an application list 216 for each application that registers with API 204.

[0020] Application notification handle 210 is a method exposed by application 202 that can be called by API 204 to notify application 202 that the Quality of Service available to mobile device 201 is predicted to change. Application data types 212 include one or more data types that the application intends to use when communicating with the network such as streaming video, images, and text. Application QoS thresholds 214 indicate values for one or more QoS metrics that should trigger API 204 to notify application 202. The QoS metrics in QoS thresholds 214 can include one or more of an available data rate, an error rate, a dropped packet rate, a jitter, a latency and a number of packets delivered out of order, for example. If a QoS threshold is provided, API 204 will only notify an application when the QoS predicted for the mobile device in the future will drop below at least one of the QoS values.

[0021] Different applications can set different QoS thresholds. If a first application has a QoS threshold above a QoS threshold of a second application, it is possible that the first application will be notified of a QoS change but the second application will not be notified of the QoS change if the QoS change results in a QoS that is between the QoS threshold of the first application and the QoS threshold of the second application.

[0022] After API registration method 208 stores application notification handle 210, application data types 212 and the application QoS thresholds 214 at step 108, it calls a position requestor 218, which tries to obtain coordinates for the current location of mobile device 201 at step 110. In accordance with one embodiment, position requestor 218 tries to obtain longitude and latitude values by making a call to a GPS/positioning service 220 in mobile device 201. GPS/positioning service 220 determines a position of mobile device 201 using either Global Positioning Satellites or signals from one or more cell antennae in the network to determine the coordinates of mobile device 201. At times, GPS/positioning service 220 will not be able to provide coordinates for mobile device 201. For example, this can occur if mobile device 201 is not receiving a signal from the global positioning satellites.

[0023] If GPS/positioning service 220 is able to provide a longitude and latitude for mobile device 201, it will return the coordinates to position requestor 218, which will store the coordinates as a first position of the mobile device in position information 222. Position requestor 218 will then make a second request for the position of mobile device 201 to GPS/positioning service 220. Upon receiving the position information generated by GPS/positioning service 220 based on the second request, position requestor 218 will store the coordinates as a second position for the mobile device in position information 222, together with a time value representing the amount of time between when the first and second positions were determined. The two position values and the time value are then provided to future position predictor 224, which uses these values to predict a future position for mobile device 201 at step 112. Future position predictor 224 uses the two position values and the time value to generate a vector representing the direction and speed at which mobile device 201 is moving from the first position. This vector is then multiplied by a second time value representing a time in the future. By multiplying the vector by the second time value, and adding the result to the second position value, it is possible to identify a predicted future location for the mobile device. The second time value is selected by balancing a desire to obtain a large amount of Quality of Service information for the path that the mobile device appears to be headed along with a recognition that the longer the second time value, the less accurate the prediction of the future location of mobile device 201 will be. Step 112 for predicting the future location of the mobile device is an optional step that does not need to be performed by API 204, but instead may be performed on server 206.

[0024] In alternative embodiments, step 112 can involve plotting a trajectory of the mobile device on a map and inferring that the mobile device is likely travelling on a certain road. In this case, the above simple projection can be improved by assuming the device should stay on the road, rather than in the current direction. Other contextual information such as the user's Calendar may be applicable to determine the user's future location, e.g., based on meeting time and place. In other embodiments, machine learning is applied to a history of user locations and related contextual information for future location prediction.

[0025] At step 114, a session requestor 226 makes a call to a session initiator 228 on server 206 to request a forecast session. In the request, session requestor 226 includes a unique identifier for the mobile device, position information 222 for the mobile device (if available), and a future position prediction for the mobile device (if available). In response, session initiator 228 creates a session at step 116. Creating the session involves storing the device identifier 230 in a session record 232. As described further below, once a forecast session is created in server 206, server 206 will monitor a QoS map generated for mobile device 201 to determine if any QoS metrics within the QoS map have changed due to network traffic or external interference.

[0026] After creating session record 232, session initiator 228 calls a QoS map retriever 234, which is responsible for producing a QoS map that provides QoS metric values at various locations within a coverage area. The coverage area is selected as an area within a radius around a predicted future location for the mobile device. At step 118, if the predicted future location for mobile device 201 was not provided by session requestor 226, QoS or coverage map retriever 234 calls location predictor 236 to generate the predicted future location for mobile device 201. If session requestor 226 provided the predicted future location of mobile device 201, step 118 is skipped.

[0027] If API 204 did not provide the predicated future location of mobile device 201, location predictor 236 determines if API 204 provided position information 222 to the server. When location predictor 236 determines that API 204 provided position information 222, location predictor 236 predicts the future location of mobile device 201 using position information 222 including the past position and the current position of mobile device 201 identified by position requestor 218 and the time between those positions to generate a vector representing the direction and velocity of mobile device 201. This vector is then multiplied by a time value and the resulting product is added to the second position to predict the future location of the mobile device at a future time set by the time value. In alternative embodiments, the future location is predicted by plotting a trajectory of the mobile device on a map and inferring that the mobile device is likely travelling on a certain road. In this case, the above simple projection can be improved by assuming the device should stay on the road, rather than in the current direction. Other contextual information such as the user's Calendar may be applicable to determine the user's future location, e.g., based on meeting time and place. In other embodiments, machine learning is applied to a history of user locations and related contextual information to predict the mobile device's future lcoation.

[0028] Alternatively, when location predictor 236 determines that API 204 did not provide position information 222, location predictor 236 can determine a current position for mobile device and a vector indicating the direction and velocity of mobile device 201 using the locations of antennae (towers) that are communicating with mobile device 201. In particular, the locations of the antennae that are in communication with mobile device 201 can be retrieved from a communication network (not shown) and can be used to determine two or more positions for mobile device 201 and the time between when mobile device 201 was at those positions can be used to determine a vector indicating a direction and velocity for mobile device 201. This vector is multiplied by a time value and the resulting product is added to the later of the positions to predict the future location of the mobile device at a future time set by the time value.

[0029] At step 120, QoS map retriever 234 uses a QoS map locator 238 and the predicted future location to generate a QoS map 240 for an area around the future location. QoS map locator 238 accesses a data service map 242, which provides QoS metric values for all locations serviced by the network provider. Such QoS metrics can include one or more of an available data rate, an error rate, a dropped packet rate, a jitter, a latency and a number of packets delivered out of order, for example. The resulting QoS map 240 includes the values of the QoS metrics for each location within the coverage area surrounding the predicted future location of the mobile device. The QoS map 240 and the future location are then returned to QoS map retriever 234, which stores the predicted future location 244 and the QoS map 246 in session record 232. QoS map retriever 234 then returns QoS map 240 to session initiator 228, which in turn returns QoS map 240 to session requestor 226 at step 122. Session requestor 226 stores the returned QoS map as QoS map 250 and calls a QoS metrics identifier 252 to determine the values of QoS metrics along a path between the current position of mobile device 201 and the predicated future location of the mobile device. Thus, QoS metrics identifier 252 receives the predicted future location of the mobile device determined either by API 204 or by server 206 as well as the current position of mobile device 201. QoS metrics identifier 252 examines QoS map 250 to determine if there are any QoS changes along the path between the current position of mobile device 201 and the predicted future location of mobile device 201 at step 124. QoS metrics identifier 252 provides these QoS changes to an application notifier 254.

[0030] At step 126, for each QoS change along the path, application notifier 254 identifies applications that must notified of the QoS change. To do this, application notifier 254 retrieves the application QoS thresholds 214 for each application that has registered with API 204. For each QoS metric change, application notifier 254 compares the resulting QoS metric value due to the QoS metric change to the application QoS threshold. If the resulting QoS metric value is below the QoS threshold, the associated application must be notified of the QoS change. If the resulting QoS metric value is not below the QoS threshold, the application does not have to be notified of the QoS change.

[0031] At step 128, application notifier 254 notifies each application that it determined at step 126 must be notified. To notify the applications, application notifier 254 retrieves the application notification handle 210 of each application that is to be notified. In accordance with some embodiments, each notification indicates the amount of time that will pass before the QoS change occurs given the mobile device's current trajectory. If there are multiple QoS changes along the path, application notifier 254 will determine if any of the QoS changes return the QoS above the QoS threshold. If later QoS changes return the QoS above the QoS threshold, application notifier 254 will determine the amount of time that the mobile device is expected to spend in an area with a QoS below the QoS threshold and provide that information in the notification. In some embodiments, the notification includes time windows indicating a start time and an end time for each window and the QoS metric values associated within each window between the current position for mobile device 201 and the future predicted location of mobile device 201. This information allows the application to know what QoS metric values to expect at what times as mobile device 201 moves toward the predicted future location.

[0032] At step 130, applications 202 receive the notifications about the future QoS changes and takes steps to mitigate data interruption. These steps can include increasing the rate at which information is being buffered to buffer additional information before reaching a lower QoS area, reducing the quality of video or audio being buffered so that a longer time period of video or audio data may be buffered but at a lower quality, accelerating the downloading of certain data such as attachments and/or providing a user interface to the user so that the user may select an action to perform in light of the predicted change in the QoS.

[0033] As long as one application is present in application list 216, a position monitor and coverage requestor 260 in API 204 will track the movement of mobile device 201 to determine if a new QoS map is needed.

[0034] FIG. 3 provides a flow diagram of a process of requesting and utilizing a new QoS map.

[0035] In step 300, position monitor and coverage requestor 260 tracks the movement of mobile device 201 using position requestor 218 to request position coordinates of mobile device 201 and comparing the new position coordinates to the last known position of mobile device 201 stored in position information 222. Position monitor and coverage requestor 260 can also utilize future position predictor 224 to determine a predicted future position of mobile device 201. Based on the change in the current position of mobile device 201 or a change in the predicted future position of mobile device 201, position monitor and coverage requestor 260 can determine whether a new QoS map is needed at step 302. If a new QoS map is not needed, the process returns to step 300 to continue the tracking of the movement of mobile device 201. [0036] If position monitor and coverage requestor 260 determines that a new QoS map is needed, position monitor and coverage requestor 260 requests a new QoS map at step 304 by calling QoS map retriever 234 in server 206. At step 306, QoS map retriever 234 uses location predictor 236 to predict a future location for mobile device 201 if position monitor and coverage requestor 260 does not provide such a future location. Location predictor 236 can predict the future location of mobile device 201 from position information provided by position monitor and coverage requestor 260 such as the last two determined coordinates of mobile device 201 and the time period between when those coordinates were determined. If position monitor and coverage requestor 260 does not provide such coordinates, location predictor 236 can use the locations of towers or antennae over which signals from mobile device 201 have been received by server 206 to determine the location and movement of mobile device 201 and the location and movement of mobile device 201 can be used to predict the future location of mobile device 201.

[0037] At step 308, QoS map locator 238 accesses data service map 242 to construct a QoS map 240 for the new predicted location of mobile device 201. At step 310, QoS map retriever 234 returns the QoS map to position monitor and coverage requestor 260, which stores the QoS map as QoS map 250.

[0038] At step 312, QoS metrics identifier 252 determines QoS metric values along the path from mobile device 201's current location to the predicted future location. At step 314, application notifier 254 identifies applications 202 that must be notified for each QoS change along the path. This involves comparing the QoS metric values along the path to the application QoS thresholds 214 for each application in application list 216 and identifying those applications that are to be notified because one or more QoS metrics will drop below one of the application's QoS thresholds.

[0039] At step 316, application notifier 254 notifies the applications 202 that it determined at step 314 must be notified. At step 318, each notified application mitigates data interruption using one of the techniques described above.

[0040] As noted above, once a session is created on server 206 for mobile device 201, server 206 will monitor the QoS provided in the coverage area of QoS map 246 to determine if an updated QoS map should be pushed to API 204. FIG. 4 provides a flow diagram of one method for pushing updated QoS maps. [0041] In step 400 of FIG. 4, a QoS map monitor 270 begins executing a monitoring function that can be triggered by a timer set within server 206. The monitoring function includes retrieving QoS map 246 from session record 232 and comparing the contents of QoS map 246 to the current QoS metrics provided by data service map 242 for the coverage area corresponding to QoS map 246. Data service map 242 is continually updated or refreshed based on data provided by one or more service providers that reflects the latest QoS information for one or more communication networks. If there have been any changes to any of the QoS metrics in the coverage area corresponding to QoS map 246, QoS map monitor 270 generates an updated QoS map that includes the latest QoS metric values for the coverage area and pushes the updated QoS map to a QoS change event handler 272 in API 204 at step 402. In addition, QoS map monitor 270 stores the new QoS map in place of QoS map 246 in session record 232.

[0042] QoS change event handler 272 stores the new QoS map as QoS map 250 and at step 404 calls QoS metrics identifier 252, which uses new QoS map 250 to determine QoS metric values along a path from the current location of mobile device 201 to the future location of mobile device 201. At step 406, an application notifier 254 examines each QoS change along the path to identify which application in application list 216 must be notified. In particular, the QoS metric values are compared to the QoS thresholds set for each application and if a QoS metric value along the path is below a QoS threshold, application notifier 254 will determine that the associated application must be notified.

[0043] In some embodiments, application notifier 254 keeps track of prior notifications sent to each application. In such embodiments, the application notifier 254 will not notify an application of a QoS change if the application was previously notified of the change.

[0044] In step 408, application notifier 254 notifies the applications identified at step 406 that the QoS will be changing and the times at which these values will change given mobile device 201's current trajectory. In accordance with some embodiments, a collection of timespans are sent in the notification together with a value for each QoS metric during each timespan.

[0045] Server 206 will continue to provide QoS map updates through QoS map monitor 270 until the session with the mobile device 201 is closed. The session will remain open as along as at least one application is in application list 216. [0046] FIG. 5 provides a flow diagram of a method that is performed as an application closes. In FIG. 5, one of applications 202 closes at step 500. API 204 receives an application closing event through application closing event handler 290. At step 502, application closing event handler 290 removes the application from application list 216 by removing the application notification handle 210, the application data types 212 and the application QoS thresholds 214. At step 504, application closing event handler 290 determines if there are any active applications in application list 216. If at least one active application remains in application list 216, application close event handler 290 ends at step 506. If there are no further applications in application list 216, application closing event handler 290 calls session closer 292 on server 206 to close the session between server 206 and mobile device 201. In response, session closer 292 closes the session at step 508 by removing the device identifier 230, future location 244 and QoS map 246 for mobile device 201 from session record 232.

[0047] FIG. 6 provides a block diagram of a mobile device 601, which is an example implementation of mobile device 201 above. Mobile device 601 includes one or more processors 600, such as a central processing unit or image processors, and a memory 602. Processor(s) 600 and memory 602 are connected by one or more signal lines or buses. Memory 602 can take the form of any processor-readable medium including a disk or solid-state memory, for example. Memory 602 includes an operating system 606 that includes instructions for handling basic system services and performing hardware-dependent tasks. In some implementations, operating system 606 can be a kernel. Memory 602 also includes various instructions representing applications that can be executed by processor(s) 600 including communication instructions 608 that allow processor 600 to communicate through peripherals interface 604 and wireless communication subsystems 618 to a wireless cellular telephony network and/or a wireless packet switched network. Memory 602 can also hold applications 202, API 204 and GPS/Positioning instructions 220.

[0048] Peripherals interface 604 also provides access between processor(s) 600 and one or more of a GPS receiver 650, motion sensors 652, and input/output subsystems 656. GPS receiver 650 receives signals from Global Positioning Satellites and converts the signals into longitudinal and latitude information describing the location of mobile device 601. The position of mobile device 601 may also be determined using other positioning systems such as Wi-Fi access points, television signals and cellular grids. Motion sensors 652 can take the form of one or more accelerometers, a magnetic compass, a gravity sensor and/or a gyroscope. Motion sensors 652 provide signals indicative of movement or orientation of mobile device 601. I/O subsystems 656 control input and output for mobile device 601. I/O subsystems 656 can include a touchscreen display 658, which can detect contact and movement or break thereof using any of a plurality of touch sensitivity technologies including, but not limited to capacitive, resistive, infrared and surface acoustic wave technologies as well as other proximity sensor arrays or other elements for determining one or more points of contact with display 658. Other inputs can also be provided such as one or more buttons, rocker switches, thumb wheel, infrared port, USB port and/or pointer device such as a stylus.

[0049] Mobile device 601 also includes a subscriber identity module, which in many embodiments takes the form of a SIM card 660. SIM card 660 stores an ICCID 662 and an IMSI 664. ICCID 662 is the Integrated Circuit Card Identifier, which uniquely identifies this card on all networks. IMSI 664 is the international mobile subscriber identity, which identifies the SIM card on an individual cellular network. When communicating through wireless communication subsystems 618, processor(s) 600 can use identifiers 662 and/or 664 to uniquely identify mobile device 601 during communications. In accordance with many embodiments, SIM card 660 is removable from mobile device 601 and may be inserted in other devices.

[0050] An example of a computing device 10 that can be used as a server in the various embodiments is shown in the block diagram of FIG. 7. For example, computing device 10 may be used as server 410. Computing device 10 of FIG. 7 includes a processing unit 12, a system memory 14 and a system bus 16 that couples the system memory 14 to the processing unit 12. System memory 14 includes read only memory (ROM) 18 and random access memory (RAM) 20. A basic input/output system 22 (BIOS), containing the basic routines that help to transfer information between elements within the computing device 10, is stored in ROM 18.

[0051] Embodiments of the present invention can be applied in the context of computer systems other than computing device 10. Other appropriate computer systems include handheld devices, multi-processor systems, various consumer electronic devices, mainframe computers, and the like. Those skilled in the art will also appreciate that embodiments can also be applied within computer systems wherein tasks are performed by remote processing devices that are linked through a communications network (e.g., communication utilizing Internet or web-based software systems). For example, program modules may be located in either local or remote memory storage devices or simultaneously in both local and remote memory storage devices. Similarly, any storage of data associated with embodiments of the present invention may be accomplished utilizing either local or remote storage devices, or simultaneously utilizing both local and remote storage devices.

[0052] Computing device 10 further includes a hard disc drive 24, a solid state memory 25, an external memory device 28, and an optical disc drive 30. External memory device 28 can include an external disc drive or solid state memory that may be attached to computing device 10 through an interface such as Universal Serial Bus interface 34, which is connected to system bus 16. Optical disc drive 30 can illustratively be utilized for reading data from (or writing data to) optical media, such as a CD-ROM disc 32. Hard disc drive 24 and optical disc drive 30 are connected to the system bus 16 by a hard disc drive interface 32 and an optical disc drive interface 36, respectively. The drives, solid state memory and external memory devices and their associated computer-readable media provide nonvolatile storage media for computing device 10 on which computer-executable instructions and computer-readable data structures may be stored. Other types of media that are readable by a computer may also be used in the exemplary operation environment.

[0053] A number of program modules may be stored in the drives, solid state memory 25 and RAM 20, including an operating system 38, one or more application programs 40, other program modules 42 and program data 44. For example, application programs 40 can include instructions for QoS map retriever 234, location predictor 236, QoS map locator 238, QoS map monitor 270, Session Initiator 228 and Session Closer 292. Program data 44 can include data in session records 232 and data service map 242.

[0054] Input devices including a keyboard 63 and a mouse 65 are connected to system bus 16 through an Input/Output interface 46 that is coupled to system bus 16. Monitor 48 is connected to the system bus 16 through a video adapter 50 and provides graphical images to users. Other peripheral output devices (e.g., speakers or printers) could also be included but have not been illustrated. In accordance with some embodiments, monitor 48 comprises a touch screen that both displays input and provides locations on the screen where the user is contacting the screen.

[0055] Computing device 10 may operate in a network environment utilizing connections to one or more remote computers, such as a remote computer 52. The remote computer 52 may be a server, a router, a peer device, or other common network node. Remote computer 52 may include many or all of the features and elements described in relation to computing device 10, although only a memory storage device 54 has been illustrated in FIG. 7. The network connections depicted in FIG. 7 include a local area network (LAN) 56 and a wide area network (WAN) 58. Such network environments are commonplace in the art.

[0056] Computing device 10 is connected to the LAN 56 through a network interface 60. Computing device 10 is also connected to WAN 58 and includes a modem 62 for establishing communications over the WAN 58. The modem 62, which may be internal or external, is connected to the system bus 16 via the I/O interface 46.

[0057] In a networked environment, program modules depicted relative to computing device 10, or portions thereof, may be stored in the remote memory storage device 54. For example, application programs may be stored utilizing memory storage device 54. In addition, data associated with an application program may illustratively be stored within memory storage device 54. It will be appreciated that the network connections shown in FIG. 7 are exemplary and other means for establishing a communications link between the computers, such as a wireless interface communications link, may be used.

[0058] Although elements have been shown or described as separate embodiments above, portions of each embodiment may be combined with all or part of other embodiments described above.

[0059] 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 above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

WHAT IS CLAIMED IS:

1. A method comprising:

receiving at an application programming interface a request from an application on a mobile device to be notified when a Quality of Service for communications with the mobile device is predicted to change;

the application programming interface contacting a server to request a Quality of Service map indicating predicted Quality of Service values for the mobile device;

the application programming interface receiving the Quality of Service map from the server;

the application programming interface determining that the Quality of Service map indicates a predicted change in Quality of Service associated with the mobile device; and

the application programming interface sending a notification to the application that the Quality of Service for the mobile device will change in the future.

2. The method of claim 1 wherein the application programming interface receives requests from multiple applications to be notified when a Quality of Service for communications with the mobile device is predicted to change.

3. The method of claim 2 wherein the request from the application indicates a Quality of Service value such that the application is requesting to be notified when the Quality of Service for communications with the mobile device is predicted to drop below the Quality of Service value.

4. The method of claim 3 wherein the requests from two different applications include two different Quality of Service values such that one application is requesting to be notified when the Quality of Service for communications with the mobile device is predicted to drop below a first Quality of Service value and a second application is requesting to be notified when the Quality of Service for communications with the mobile device is predicted to drop below a second Quality of Service value.

5. The method of claim 1 wherein contacting a server to request a Quality of Service map comprise establishing a session with the server such that the session remains open after the server returns the Quality of Service map.

6. The method of claim 5 wherein after receiving the Quality of Service map, the application programming interface receives a new Quality of Service map pushed from the server in response to a change in the Quality of Service map.

7. The method of claim 6 wherein the Quality of Service map comprises Quality of Service information for locations in a radius of a predicted future location of the mobile device.

8. The method of claim 7 wherein the predicted future location of the mobile device is determined based on a past location of the mobile device and a current location of the mobile device.

9. The method of claim 8 wherein the application programming interface provides the past location and the current location of the mobile device to the server and the server provides the predicted future location based on the past location and the current location provided by the application programming interface.

10. The method of claim 8 wherein the server provides the predicted future location of the mobile device without receiving a past location or a current location of the mobile device from the application programming interface.

11. A server comprising: a session initiator that initiates a session with an application programming interface on a mobile device in response to a request from the application programming interface;

a Quality of Service map locator that retrieves Quality of Service values for at least one location of the mobile device and returns a Quality of Service map to the mobile device;

a Quality of Service map monitor that monitors Quality of Service values for an area corresponding to the returned Quality of Service map and that sends an additional notification to the application programming interface if a Quality of Service value in the area changes.

12. The server of claim 11 wherein the area corresponding to the Quality of Service map comprises a future location for the mobile device and all locations within a radius of the future location.

13. The server of claim 12 further comprising a location predictor wherein the location predictor determines if the application programming interface provided position information for the mobile device and when the application programming interface is determined to have provided position information for the mobile device, the location predictor determines the future location of the mobile device based on the position information provided by the application programming interface.

14. The server of claim 13 wherein when the application programming interface is determined to have not provided position information for the mobile device, the location predictor determines the future location of the mobile device based on position information provided by a communication network.

15. A processor-readable medium having stored thereon instructions that when executed by the processor cause the processor to perform steps comprising: receiving a request from a first application to be notified of predicted Quality of Service changes;

receiving a request from a second application to be notified of predicted Quality of

Service changes;

sending a request for a Quality of Service map to a server;

receiving the Quality of Service map; and

sending a notification to at least one of the first application and the second application that a Quality of Service metric is predicted to change in the future.

16. The processor-readable medium of claim 15 wherein sending a notification to at least one of the first application and the second application comprises sending a notification to both the first application and the second application.

17. The processor-readable medium of claim 15 wherein the Quality of Service map is centered on a predicted future position of a mobile device housing the processor.

18. The processor-readable medium of claim 17 wherein the steps further comprise determining a predicted future position of the mobile device and sending the predicted future position with the request for the Quality of Service map.

19. The processor-readable medium of claim 17 wherein the steps further comprise determining two positions of the mobile device and sending the two positions with the request for the Quality of Service map.

20. The processor-readable medium of claim 15 further comprising receiving a push notification from the server that the Quality of Service map previously received has changed.