HK1109689B - Devices and methods for push message initiated service - Google Patents

Description

Apparatus and method for push message initiated services

Cross Reference to Related Applications

The present application is related to the following commonly assigned, co-pending international patent applications: international patent application PCT/SE04/______ entitled "Binding mechanisms for Quality of Service management a Communication Network" filed on 5.7.2004, International patent application PCT/SE04/_______ entitled "methods and Devices for Supplying requirements of Service Parameters in HTTP Message" filed on 5.7.2004, and International patent application PCT/SE04/______ entitled "Method and Devices for Changing Quality of Service" filed on 5.7.2004, the disclosures of which are incorporated herein by reference.

Technical Field

The present invention relates to an apparatus and method in a mobile communication system, and more particularly, to controlling a quality of service request for a transmission associated with a packet data service.

Background

Communication networks for the communication of information on a packet basis, in the form of data bits, are well known to those skilled in the art. The increasing importance of mobile communications has created a need to communicate data over wireless connections. The Wireless Application Protocol (WAP) defines a set of protocols that enable operators and manufacturers to provide applications that operate on wireless communication networks. One example of services that may be provided via the WAP architecture is WAP push, which is a service for pushing content to mobile devices.

The "push" technique means that the server in the client/server model transfers information to the client without getting an explicit request from the client. This technique differs from the "pull" technique, which is commonly used, for example, in web browsing, where a client requests a service or information from a server, which responds by transmitting the information to the client. In other words, a "drag" transaction of information is initiated by the client, while a "push" transaction is initiated by the server.

In WAP push operation, the Push Initiator (PI) transmits push content and delivery instructions to a Push Proxy Gateway (PPG), which then delivers the push content to a WAP client, which may be a mobile phone or some other WAP-capable terminal, in accordance with the delivery instructions.

The PI may be an application running on a common web server. The PI uses a Push Access Protocol (PAP) to communicate with the PPG, which uses a push over-the-air (OTA) protocol to deliver the push content to the client. More information about the WP push framework can be found in the document "WAP PushArchitectural Overview, Version 03-Jul-2001", published on the WAP Forum website (http:// www.wapforum.org).

As explained in the above-mentioned document, the client typically needs to activate a bearer (bearer) to deliver the push content. For this purpose, the client contains an application that listens to the Session Initiation Request (SIR) from the PPG and responds by activating the bearer service that the terminal considers appropriate, and then implements the intended PPG. Typically, the SIR is sent to the client using connectionless push, and is assembled, for example, in a separate SMS.

The WAP push framework allows any MIME media type to be passed between the PI and the client. Certain specific media types are also specifically defined herein to add capabilities not already provided by existing MIME types. One example of this particular media type is the Service Indication (SI) media type, which provides the ability to send notifications to clients in an asynchronous manner. The notification may relate to news, e-mail, stock price changes or scores of football matches, news headlines, advertisements, reminders such as low prepaid balances, etc., to name a few. The basic SI contains a short message and a Uniform Resource Identifier (URI) indicating a service. The message is sent to the appropriate application in the client and, once received, the message is displayed to the user. The user then has the option to immediately initiate the URI-indicated service or to defer the SI for later processing. When the user chooses to start the service indicated by the URI, the application will start the bearer service establishment process according to the requirements specified for the service in the terminal.

For media types specifically defined for push,another example of this is the Service Loading (SL) media type. Unlike SI, SL does not imply any user participation. SL contains a URL pointing to some content loaded by the client without end user confirmation and an instruction indicating whether the content should be executed/rendered or placed in a buffer memory. After receiving the SL in the application of the client terminal, the executing received application initiates the setup process of the bearer service to deliver the content from P I to the client. More information about the SL and how the SL coordinates with other activities in the client terminal may be published in the WAP Forum^TMWeb site (http:// www.wapforum.org) is found in the document "Service Loading, Version 31-Jul-2001".

One feature common to both SI and SL is that the setup procedure for a bearer service for content delivery is initiated by the client even in the case where the first service is initiated by the PI (i.e., the server according to the client/server model) informing the client of the service content that the PI wishes to deliver to the client by sending a service indication and a service load message to the client, and the client requests a specific quality of service (QoS) for the bearer service when requesting to setup the bearer service. The requested QoS for the bearer service is specified by a set of QoS parameters. The mapping from application level to requested bearer QoS is implemented in the client terminal, depending on the terminal vendor code of the terminal. Thus, when the same message is sent from different vendors to the terminal, the message may result in different bearer QoS. Furthermore, not all of the QoS requested by the client terminal is considered suitable for service content delivery from the point of view of the PI providing the service.

Disclosure of Invention

It is an object of the present invention to provide apparatus and methods that allow a service provider of a push message initiated service to influence the selection of quality of service parameters for a bearer service established for receiving service content from the service provider in a mobile client terminal.

The above object is achieved by a mobile communication terminal according to claims 1 and 10, a method in a mobile communication terminal according to claims 11 and 20, a network node according to claim 21 and a method in a network node according to claim 33.

The basic idea of the invention is: not only is an indication of the service content available for the service provider to initiate the service transmitted in the push message, but also a set of recommended quality of service parameters. The mobile terminal may thus retrieve this set of recommended quality of service parameters when receiving the message and take into account the set of recommended quality of service parameters when requesting a bearer service for receiving the service content indicated by the push message. The basic idea of implementing the invention requires a modified new mobile terminal, a modified new network node and methods in the mobile terminal and the network node, all of which are provided according to different aspects of the invention.

According to a first aspect of the present invention there is provided a mobile communication terminal comprising an application for receiving at least one packet data service from a service provider. The application is used to receive a push service indication message from a service provider containing information that the service provider has service content to be delivered to the terminal. The application is further arranged to initiate a setup procedure for a bearer service for receiving the service content. The mobile terminal further comprises processing means for retrieving the set of recommended quality of service parameters contained in the received service indication message. The recommended quality of service parameter set is a quality of service parameter recommended by the service provider for a bearer service requested by the terminal for receiving the service content. The processing means is further adapted to process the set of recommended quality of service parameters to determine a processed set of quality of service parameters based on the set of recommended quality of service parameters, and to request the processed set of quality of service parameters for a bearer service for receiving the service content.

According to a second aspect, the present invention provides a network node in a network for providing a set of packet data services from a service provider to a mobile client terminal. The network node comprises message creation means for creating a service indication message for a push transmission to the first client terminal, and an interface for pushing the service indication message to the first client terminal. The message creation means is arranged to include in the service indication message information that the service provider has service content to be delivered to the first client terminal and a set of recommended quality of service parameters that the service provider recommends for the bearer service that the first client terminal requests for receiving the service content.

According to the third and fourth aspects. The invention provides a method in a mobile communication terminal and a method in a network node.

The present invention is advantageous in that it allows a service provider to influence the quality of service parameters requested by a mobile terminal. This may be advantageous since the service provider knows the service content characteristics and can thus decide better than the mobile terminal on the appropriate quality of service parameters for delivering the service content, and furthermore the service provider may wish to influence those quality of service parameters used in connection with the service in order to maintain its image and reputation as a service provider for providing high quality services. If the terminal requests a service of too low quality, this may give a service content provider an undesirable impression even if the low quality service is due to the limitations of the terminal.

Another advantage of the invention is that a more uniform quality can be achieved for the same service and service type between different terminals. Since the mobile terminal according to the preferred embodiment of the present invention can be adapted to recommend a quality of service parameter set for a bearer service request, the impact of the mobile terminal encoding on the quality of service of the bearer service can be mitigated. In prior art solutions, the mobile terminal requests a predefined PDP context, typically by "hard coding". This coding may vary for different terminal vendors, which may result in different quality of service being used for terminals from different vendors.

Another advantage of the present invention is to allow flexible determination of quality of service parameters requested for a bearer service. By means of the present invention, the mobile terminal need not be limited to requesting only the quality of service of one or several predefined bearer services.

An embodiment of the invention provides a mobile communication terminal comprising an application for receiving at least one packet data service from a service provider, the application being arranged to receive a push service indication message from the service provider, the service indication message comprising information that the service provider has service content delivered to the terminal, and the application being further arranged to initiate a setup procedure for a bearer service for receiving said service content, characterized in that the terminal further comprises processing means for retrieving a set of recommended quality of service parameters contained in the received service indication message, the set of recommended quality of service parameters being a set of quality of service parameters recommended by the service provider for the bearer service the terminal requests for receiving the service content; processing a set of recommended quality of service parameters to determine a set of processed quality of service parameters based on the set of recommended quality of service parameters; and a set of quality of service parameters processed for a bearer service request for receiving the service content.

An embodiment of the invention provides a mobile communication terminal comprising an application for receiving at least one packet data service from a service provider, the application being arranged to receive a push service indication message from the service provider, the service indication message comprising information that the service provider has service content delivered to the terminal, and the application being further arranged to initiate a setup procedure for a bearer service for receiving said service content, characterized in that the terminal further comprises processing means for retrieving a set of recommended quality of service parameters contained in the received service indication message; and requesting the recommended quality of service parameter set for a bearer service for receiving the service content.

An embodiment of the present invention provides a method in a mobile communication terminal, wherein the terminal comprises an application for receiving at least one packet data service from a service provider, the method comprising the steps of: the application receiving a push service indication message from a service provider, the service indication message containing information that the service provider has service content for delivery to the terminal, characterized by the further steps of: retrieving a recommended service quality parameter set contained in the received service indication message, wherein the recommended service quality parameter set is a service quality parameter set recommended by a service provider for a bearer service requested by the terminal for receiving service content, and processing the recommended service quality parameter set so as to determine a processed service quality parameter set based on the recommended service quality parameter set; and the application starts the establishment process of the bearer service for receiving the service content and requests the processed quality of service parameter set for the bearer service.

An embodiment of the present invention provides a method in a mobile communication terminal, wherein the terminal comprises an application for receiving at least one packet data service from a service provider, the method comprising the steps of: the application receives a push service indication message from a service provider, the service indication message containing information that the service provider has service content to deliver to the terminal, wherein the method is characterized by the further steps of: retrieving a set of recommended quality of service parameters contained in the received service indication message, and the application starting a setup procedure for a bearer service for receiving the service content, and requesting the set of recommended quality of service parameters for the bearer service.

An embodiment of the present invention provides a network node for providing a set of packet data services from a service provider to a mobile client terminal in a network, the network node comprising: message creation means for creating a service indication message for push transmission to the first client terminal; and an interface for pushing a service indication message to the first client terminal, wherein the message creation means is arranged to include in the service indication message information that the service provider has service content delivered to the first client terminal, and wherein: the message creating means are arranged to include in the service indication message a set of recommended quality of service parameters recommended by the service provider for the bearer service requested by the first client terminal for receiving the service content.

An embodiment of the present invention provides a method in a network node providing a set of packet data services from a service provider to a mobile client terminal in a network, the method comprising: creating a service indication message for a push transmission to the first client terminal; and pushing a service indication message to the first client terminal, wherein the service indication message contains information that the service provider has service content delivered to the first client terminal, and the method is characterized by: the service indication message further comprises a set of recommended quality of service parameters, wherein the set of recommended quality of service parameters is recommended by the service provider for the bearer service requested by the first client terminal for receiving the service content.

Other advantages and features of embodiments of the present invention will become apparent from the following detailed description when read in conjunction with the accompanying drawings.

Drawings

Fig. 1 is a schematic block diagram depicting a general network architecture of a mobile communication system in which the present invention may be used.

Fig. 2 is a flow chart schematically describing a prior art service initiated by means of a push message from an application server.

Fig. 3 is a flow chart schematically illustrating a service corresponding to the service shown in fig. 2 but applicable to the present invention.

Fig. 4 is a schematic signalling/flow chart describing the functionality of an exemplary embodiment of a network node according to the present invention and an exemplary embodiment of a mobile communication terminal according to the present invention.

Fig. 5 is a schematic signalling/flow chart describing the functionality of an alternative exemplary embodiment of a network node according to the present invention and an alternative exemplary embodiment of a mobile communication terminal according to the present invention.

Fig. 6 is a schematic signalling/flow chart describing the functionality of another alternative exemplary embodiment of a network node according to the present invention and of another alternative exemplary embodiment of a mobile communication terminal according to the present invention.

Fig. 7 is a schematic signalling/flow chart describing the functionality of another alternative exemplary embodiment of a network node according to the present invention and of another alternative exemplary embodiment of a mobile communication terminal according to the present invention.

Detailed Description

The invention will be described in more detail hereinafter with reference to the accompanying drawings, in which preferred embodiments of the invention are shown. This invention may, however, be embodied in different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art. In the drawings, like numerals refer to like parts throughout.

The invention is applicable to packet-switched services in a mobile communication system, said services being initiated from a service provider by means of push messages. Such services involve packet-switched communication between the mobile client terminal of the end user and the application server. The mobile communication system includes a radio network in which the mobile client terminal is located, such as WCDMA, CDMA2000, wireless LAN, and GPRS networks.

Fig. 1 is a schematic block diagram depicting a general network architecture of a mobile communication system in which the present invention may be used. The mobile system 101 in fig. 1 comprises a mobile client terminal 102 which can communicate with a network node 106 of a service provider and thereby receive services provided by the service provider. The communication between the client terminal 102 and the network node 106 is implemented by means of the radio network 103, the core network 104 and the serving network 105. The radio network 103 may be, for example, a UTRAN (UMTS terrestrial radio access network) or a CDMA2000 network, the core network 104 may be a UMTS core network, and the serving network may be the internet or a service provider's private IP network. Further, the network node 106 of the service provider may be an application server or a push proxy gateway, for example.

Fig. 2 is a flow chart schematically illustrating a prior art service initiated by means of a push message from a service provider network node. The service may be, for example, allowing a mobile client terminal user to subscribe to pictures showing a football goal during a world cup. When new pictures of a soccer goal are available, the service provider will communicate these new pictures to the user by means of a push message. As shown in fig. 2, the network node 106 of the service provider initiates a service by sending a push message 209 to the mobile client terminal 102 in step 201. In this example, this push message 209 is a WAP push Service Loading (SL) message, where the message is sent to the mobile client terminal by means of WAP push and SMS, and the service content (i.e. picture) is indicated by a URL contained in the SL message. The SL message is addressed to an appropriate user agent or application 210 in the mobile client terminal. In this case we assume that the service is delivered over an MMS bearer, whereby the push message is addressed to the MMS proxy. When a SL message is received in the mobile client terminal, the message will be forwarded to the target user agent 210, which will then start in step 202, after which a preconfigured PDP context with MMS bearer will be requested in step 203. When the mobile client terminal receives confirmation that a PDP context has been established, the terminal may retrieve the service content by means of the received URI in step 204.

As is apparent from the illustration of fig. 2, it is the service provider that initiates the service and the client terminal 102 that requests the establishment of a bearer service for the delivery of the service content. Thus, the PDP context parameters, and hence the quality of service (QoS) of the bearer, are requested by the mobile client terminal. Today, each user agent or application is combined with a pre-configured PDP context with a selected QoS class that is "hard coded" in the mobile client terminal.

In UMTS (universal mobile telecommunications system), QoS is defined by a set of attributes that specify the UMTS bearer service. The UMTS QoS attributes are as follows:

traffic class

Maximum bit rate

Guaranteed bit rate

Delivery sequence

Maximum SDU size

SDU format information

SDU error Rate

Residual bit error rate

Delivery of erroneous SDUs

Propagation delay

Traffic handling priority

Allocation/reservation priority

Source statistics descriptor

Signaling indication

These attributes may be mapped to predefined UMTS QoS classes: a session stage, a streaming stage, an interaction stage, and a background stage. More detailed information on UMTS QoS can be found in the technical specifications 3GPP TS 23.107 V6.1.0(2004-03) and 3GPP TS 23.207 v6.2.0 (2004-03).

The QoS class may be negotiated and managed using PDP context management. In the mobile client terminal, the QoS requirements at the application level are mapped to PDP context parameters. In prior art solutions the pre-configuration of the PDP context is performed in the client terminal, such that when a packet switched application starts and connects to the network, a matching pre-configured PDP context is activated. This PDP context has a selected QoS level that should match the expected QoS requirements of the application. Also, if the application is a WAP browser or MMS client, for example, the QoS level of the activated PDP context is typically interactive.

Thus, in prior art solutions, for a bearer service established for service content delivery in the example shown in fig. 2, the selection of QoS parameters for the service depends on the terminal vendor configuration of the mobile client terminal. And the service provider is not able to influence the QoS parameter selection. In many cases, problems arise, particularly from a service provider perspective as well as a user perspective, when the above process results in the establishment of a bearer service using QoS that is not suitable for service content delivery. Service providers are generally concerned with being able to ensure that the services provided are delivered at some minimum quality. If the quality of service is poor, this may have a negative impact on the reputation of the service content provider, even if the quality difference is caused by the network operator or the end manufacturer. If the QoS is poor, the service user may be annoyed and the service provider may be blamed for poor quality. Furthermore, a user with one terminal may get an unacceptable QoS when receiving a certain service content, while another terminal with a terminal from another manufacturer gets an acceptable QoS when receiving the same service content.

In accordance with the present invention, a service provider may influence the selection of its QoS parameters for a bearer service used to deliver service content in a push message initiated service. This is achieved by modifying the push message to include recommended QoS parameters recommended by the service provider for the mobile client terminal to establish the bearer service.

Fig. 3 is a flow chart schematically illustrating a service corresponding to the service shown in fig. 2 but applicable to the present invention. As shown in fig. 3, the network node 106a of the service provider initiates the service by sending a push message 309 to the mobile client terminal 102a in step 301. In accordance with the present invention, the push message 309 contains a set of recommended QoS parameters. The push message 309 may be, for example, a WAP push Service Loading (SL) message modified by adding the set of recommended QoS parameters. When a push message 309 is received in the mobile client terminal, the message will be forwarded to the target user agent 310, which will then start up in step 302. The user agent 310 or supporting software in the mobile client terminal has processing means 311 which then retrieves and processes the set of recommended QoS parameters from the push message in order to determine the PDP context parameters corresponding to the set of recommended QoS parameters, step 303. Thereafter, in step 304, the user agent requests a PDP context with the PDP context parameters determined in step 303. When the mobile client terminal receives confirmation that a PDP context has been established, the terminal may obtain service content in step 305.

The process described in figure 3 allows a service provider to have an impact on the QoS of a bearer service without relying on "hard-coded" QoS parameters internal to the mobile client terminal. In order to implement the procedure of fig. 3, it is necessary to make modifications on the sender side of the push message in order to modify the push message to contain the set of recommended QoS parameters, and furthermore, on the terminal side, to interpret the modified push message.

The mobile terminal 102a according to the present invention is adapted to retrieve and process the set of recommended QoS parameters in a push message 309 indicating the service content delivered to the mobile terminal. Such a mobile terminal may be implemented by supplementing a prior art terminal with a processing means 311, wherein the processing means may retrieve the recommended set of QoS parameters from a push message, process the retrieved set of parameters, and request QoS for a bearer service based on the retrieved set of parameters. According to a preferred embodiment, the processing means 311 is a software code means of the application 310 to which the push message 309 is directed. Furthermore, the processing means may also be software code means supporting software functions outside the application, which functions are invoked by the application when receiving the push message. It is well known to those skilled in the art how to implement such software code means in a general purpose computer language so that they perform the functions described herein, and will not be described in further detail herein.

According to a preferred embodiment of the mobile terminal 102a according to the invention, the mobile terminal is adapted to request a recommended QoS for the service provider for the bearer service to be established, wherein said recommendation is performed by means of the recommended set of QoS parameters in the push message 309. However, the mobile terminal may also process the set of recommended QoS parameters and determine that a slightly different QoS is requested for the bearer service. For example, the terminal vendor may increase the bandwidth recommended by the service provider by a certain margin all the time by the mobile terminal. Further, for example, it is assumed that the push message contains a QoS parameter indicating that the service provider recommends a guaranteed bit rate of 64kb/s for the bearer service. The mobile terminal may then be implemented to add a margin of 2kb/s when processing the QoS parameter in the push message, so that the mobile terminal requests a guaranteed bit rate of 66kb/s for the bearer service. The idea of the invention thus underlies allowing a mobile terminal to base its QoS request on a QoS recommended by the service provider, but not entirely limited to the recommended QoS.

The push message 309 may be any type of push message from a service provider that initiates a service by including information that the service provider has service content delivered to the mobile terminal. In accordance with the present invention, the push message 309 also includes a set of recommended QoS parameters. The push message may be, for example, a WAP push service indication message or a WAP push service loading message with QoS information in the form of a set of recommended QoS parameters added. Further, to the information that the service provider has the service content delivered to the terminal, the information may be a URI (uniform resource identifier) indicating the service content.

The push message 309 may be pushed to the mobile terminal using different techniques. One such technique is to deliver push messages in SMS. If the mobile terminal has established a primary PDP context for another service, it may transmit a push message to the terminal 102a via the primary PDP context. The mobile terminal will then request a secondary PDP context to deliver the service content indicated by the push message 309.

In some cases, when a push message is received, it may be appropriate not to establish a bearer service for receiving the service content. This may occur, for example, in the following situations: the battery level of the terminal is low, the terminal is currently roaming or is in the foreign country, and the subscription of the user does not support foreign service delivery. In this case, the mobile terminal 102a may be arranged to reject the provided service without responding to the push message 309 or to delay receiving the provided service until the battery is charged or the terminal is no longer roaming.

On the network side, i.e. the side where push messages 309 are created and sent, there are a number of different possible embodiments of the invention. The different network nodes may be adapted to include the set of recommended QoS parameters in a message pushed to the terminal. The QoS information may be provided by, for example, an application server, a policy server, or a push proxy gateway.

Fig. 4 is a schematic flow chart describing one example of a case where QoS information is inserted into the push message 309 by the application server 409. In this example, the push message is a WAP push message created in an application server 409 providing the service content delivered to the terminal 102 a. According to this embodiment, the message 309 includes: a target User Agent (UA) indication, an indication of a conventional WAP push service loading message SL and a set of recommended QoS parameters. In step 401a, the push message 309 is sent to the push proxy gateway 410. And the message may be sent using a modified version of the PAP API (push access protocol application programming interface) as defined by the OMA/WAP standard of today, see for example WAP Forum published under^TMThe document "Push Access Protocol, Version 29-Apr-2001" of the website (http:// www.wapforum.org). The API needs to be modified to support the inclusion of the set of QoS parameters in the push message. Before forwarding the message to the terminal 102a, the push proxy gateway will check, step 402, together with the policy server 411, whether the application server 409 is allowed to send the message to the terminal 102a, step 402. After being acknowledged from the policy server 411, the push proxy gateway 410 will send a message 309 to the terminal 102a containing the set of recommended QoS parameters. In the present example, this forwarding is performed by means of SMS. The terminal 102a then initiates the designated user agent and processes the message as described above, after which the user agent initiates a PDP context by sending a request for activation of the PDP context to an SGSN (serving GPRS support node) 413 of the UMTS core network via an RNC (radio network controller) 414 of the UTRAN in step 403 a. Preferably, this request contains the set of recommended QoS parameters sent in the push message 309. The PDP context activation will then continue in steps 403b-d with a "create PDP context" request from the SGSN 413 to the GGSN (gateway GPRS support node), a "create PDP context" response from the GGSN to the SGSN and an "activate PDP context" acceptance from the SGSN to the terminal, as is well known to those skilled in the art. Upon establishment of the PDP context, the terminal may extract the service contents specified in the push message in step 404 and apply the service in step 405The server 409 will deliver the service content to the terminal.

Fig. 5 is a schematic flow chart diagram illustrating an alternative embodiment of providing QoS information in a push message 309 by policy server 411. In this case, the application server 409 sends a WAP push message to the push proxy gateway 410 in step 501 in the same way as in the prior art solutions. The push proxy gateway 410 will then check with the policy server whether the application server is allowed to send messages to the terminal in step 502. In response, the policy server sends the set of recommended QoS parameters to be forwarded to the terminal in a push message, step 503. The push proxy gateway 410 would then forward the message received from the application server to the terminal 102a via SMS, along with the additional set of QoS requirements, at step 504. The remaining steps 505a-d, 506 and 507 shown in fig. 5 are the same as steps 404a-d, 405 and 406 of fig. 4, described above.

Fig. 6 is a schematic flow chart diagram illustrating another alternative embodiment of providing and inserting QoS information into a push message 309 by the push proxy gateway 410. In this case, the application server 409 would send a WAP push message to the push proxy gateway 410 in step 601 in a manner equivalent to prior art solutions. The push proxy gateway 410 will then check with the policy server 411 if the application server is allowed to send messages to the terminal in step 602. After having been acknowledged by the policy server, the push proxy gateway determines the set of QoS parameters to send to the terminal and inserts this set in the push message received from the application terminal, step 603. The push proxy gateway may be implemented to determine the QoS parameters based on a set of rules, which may depend, for example, on the type of service content, the application providing the service content and/or the network in which the terminal is located. The push proxy gateway 410 will then forward the created push message with the set of QoS requirements to the terminal 102a by means of SMS in step 604. The remaining steps 605a-d, 606 and 607 of fig. 6 are the same as steps 404a-d, 405 and 406 of fig. 4, described above.

As is clear from the examples depicted in fig. 4, 5, 6, different network nodes may be adapted to determine the recommended QoS parameters and insert them into the message pushed to the terminal. Thus, for example, the network node 106a depicted in fig. 3 may represent an application server 409, a policy server 411, or a push proxy gateway 410. To insert the recommended QoS parameters into the push message 309, the network node is preferably implemented by means of software code means 312, which support the creation of push messages containing sets of recommended QoS parameters. The network node must also comprise an interface 313 in order to push messages to the terminal 102 a. The node responsible for determining the recommended QoS parameters must then have means 314 for doing this. For example, the means may be software code means defining rules or formulas for deriving recommended QoS parameters based on some particular criteria. Further, such specific criteria on which the QoS parameters are recommended may be, for example, the type of subscription of the terminal user, the type of content of the service delivered to the terminal, the application delivering the service, the time of day or some relevant network information, such as the network load or the geographical location of the terminal.

Different criteria may be considered depending on the node determining the QoS parameter. For example, if the service provider is a CNN, it is possible that the CNN has an agreement with the network operator to always receive its services at a guaranteed bit rate of 128 kb/s. In this case the node for determining the recommended QoS parameters may be arranged to determine that one of the recommended QoS parameters should be a guaranteed bit rate of 128kb/s when delivering service content at CNN. Another example occurs when the recommended QoS parameters depend on the end user subscription. Assume that a first user subscribes to a "gold subscription" with a network operator and a second user subscribes to a "silver subscription" with the network operator. In this case, the policy server may determine that the guaranteed bit rate of 128kb/s is a recommended QoS parameter, for example, if the message is sent to the first terminal, and that the guaranteed bit rate of 64kb/s is a recommended QoS parameter, for example, if the message is sent to the second user.

In addition, several network nodes may be involved in determining the set of recommended QoS parameters. For example, the application server may determine a first set of recommended QoS parameters, which the policy server then modifies after checking the end user subscription. The determination process of the recommended QoS parameters may be determined based on negotiations between several network nodes.

Furthermore, the set of recommended QoS parameters may also include a single parameter value or several parameter values. The set of recommended QoS parameters may take the form of explicit parameter values in the form of specified UMTS QoS attribute recommendations or PDP context parameters. The set of recommended QoS parameters may also be an indication of a recommended predetermined UMTS QoS class, where the QoS parameters for the QoS class are predetermined.

Fig. 7 is a schematic flow chart describing a situation where a primary PDP context 701 is present and a push message 309 is forwarded to the terminal 102a via the primary PDP context. By establishing a primary PDP context, an end user may be allowed to browse the internet. While browsing, the user may indicate that he wishes to listen to the MP3 file in step 702, which will cause the application server 409 to send a push message 309 to the push proxy gateway 410 in step 703a in order to initiate the secondary PDP context establishment procedure. The push proxy gateway may initiate a policy check process before forwarding the push message 309 to the terminal 102a, step 704. The push message 309 is forwarded to the GGSN412 using a conventional IP connection and is forwarded from the GGSN412 to the terminal 102a via the primary PDP context 701. After the push message 309 and the set of recommended QoS parameters have been processed in the terminal 102a, a secondary PDP context will be established in steps 705a-705 d. The service content is then delivered to the terminal 102a via the secondary PDP context, step 706, which allows the terminal user to listen to the MP file. As shown in the example of fig. 7 for message 309, the push message contains a TFT (traffic flow template). By sending the TFT, a mechanism may be provided to determine which of the two PDP contexts the payload is sent on, as is well known to those skilled in the art.

In the present application, the recommended QoS parameter set is referred to as a QoS parameter set recommended by a service provider for a bearer service requested by a terminal for receiving service content. It should be noted that this phrase is intended to encompass all of the above examples in which different network nodes determine the recommended QoS parameters based on different criteria. Thus, the term "service provider" is to be interpreted broadly and encompasses, for example, service content providers as well as network operators providing network bearer services.

As is clear from the exemplary embodiments of the present invention, the present invention allows a service provider to influence the QoS requested by a terminal for a bearer service delivering service content indicated in a push message from the service provider. The invention can thus include the set of recommended QoS parameters in the push message, so this is possible.

In the drawings and specification, there have been disclosed typical preferred embodiments of the invention and, although specific terms are employed, they are used in a generic and descriptive sense only and not for purposes of limitation, the scope of the invention being set forth in the following claims.

Claims (32)

1. A method in a mobile communication terminal (102a) comprising an application (310) for receiving at least one packet data service from a service provider (106a), the method comprising the steps of:

the application receives (301) a push service indication message (309) from a service provider, the service indication message containing information that the service provider has service content for delivery to the terminal, characterised by the further steps of:

retrieving (303) a set of recommended quality of service parameters contained in the received service indication message (309), the set of recommended quality of service parameters being a set of quality of service parameters recommended by the service provider for a bearer service requested by the terminal for receiving the service content,

processing (303) a set of recommended quality of service parameters to determine a set of processed quality of service parameters based on the set of recommended quality of service parameters; and

the application initiates (304) a setup procedure for a bearer service for receiving the service content and requests the set of processed quality of service parameters for the bearer service.

2. The method of claim 1, wherein the processed set of quality of service parameters and the recommended set of quality of service parameters are equal.

3. A method according to claim 1 or 2, wherein said bearer service is a packet data protocol context.

4. A method according to claim 1, wherein said push service indication message (309) is a WAP push service loading message modified by appending a set of recommended quality of service parameters.

5. The method according to claim 1, wherein said push service indication message is a WAP push service indication message modified by appending a set of recommended quality of service parameters.

6. A method according to claim 1, wherein said push service indication message is received via a pre-established primary packet data protocol context (701), and wherein said bearer service for receiving said service content is a secondary packet data protocol context.

7. The method of claim 1, wherein the information that the service provider has the service content delivered to the terminal includes a uniform resource identifier, URI, indicating the service content.

8. The method of claim 1, wherein the set of recommended quality of service parameters includes an indication of a predefined UMTS QoS class.

9. The method of claim 1, wherein the set of recommended quality of service parameters includes recommended values for at least one UMTS QoS attribute.

10. A method in a mobile communication terminal (102a) comprising an application (310) for receiving at least one packet data service from a service provider (106a), the method comprising the steps of:

the application receives (301) a push service indication message (309) from the service provider, the service indication message containing information that the service provider has service content to deliver to the terminal, wherein the method is characterized by the further steps of:

retrieving (303) a set of recommended quality of service parameters contained in the received service indication message, an

The application initiates (304) a setup procedure for a bearer service for receiving the service content and requests the set of recommended quality of service parameters for the bearer service.

11. A network node (106a) in a network for providing a set of packet data services from a service provider to a mobile client terminal, the network node comprising:

-message creating means (312) for creating a service indication message (309) for a push transmission to the first client terminal (102 a); and

an interface (313) for pushing a service indication message (309) to a first client terminal (102a), wherein the message creation means (312) is arranged to include in the service indication message (309) information about service providers having service content delivered to the first client terminal, and characterized by: the message creating means (312) are arranged to include in the service indication message (309) a set of recommended quality of service parameters recommended by the service provider for the bearer service requested by the first client terminal for receiving the service content.

12. The network node (106a) according to claim 11, wherein the network node further comprises parameter determining means (314) for determining the set of recommended quality of service parameters depending on at least one of the following types of input information: service content type, end user subscription type, information about the network establishing the bearer service, and service content provider.

13. The network node (106a) according to claim 11 or 12, wherein the set of recommended quality of service parameters is a set of recommended packet data protocol context quality of service parameters.

14. The network node (106a) according to claim 11, wherein the service indication message (309) is a WAP push service loading message modified by appending a set of recommended quality of service parameters.

15. The network node (106a) according to claim 11, wherein the service indication message (309) is a WAP push service indication message modified by appending a set of recommended quality of service parameters.

16. A network node (106a) according to claim 11, wherein the network node is arranged to push the service indication message to the first client terminal (102a) via a pre-established primary packet data protocol context (701), and wherein the set of recommended quality of service parameters is a set of recommended packet data protocol context quality of service parameters for a secondary packet data protocol context.

17. The network node (106a) of claim 11, wherein the information that the service provider has the service content delivered to the terminal comprises a uniform resource identifier, URI, indicating the service content.

18. The network node (106a) of claim 11, wherein the set of recommended quality of service parameters includes an indication of a predefined UMTS QoS class.

19. The network node (106a) of claim 11, wherein the set of recommended quality of service parameters includes recommended values for at least one UMTS QoS attribute.

20. The network node (106a) according to claim 11, wherein the network node is an application server (409) of a service provider.

21. A network node (106a) according to claim 11, wherein said network node is a policy server (411) further arranged to check whether the service provider is allowed to push the service indication message (309) to the first client terminal (102 a).

22. The network node (106a) according to claim 11, wherein the network node is a push proxy gateway (410) arranged to create the service indication message (309) based on a service message received from an application server (409).

23. A method in a network node (106a) providing a set of packet data services from a service provider to a mobile client terminal in a network, the method comprising:

creating a service indication message (309) for a push transmission to the first client terminal (102 a); and

-pushing (301) a service indication message (309) to the first client terminal (102a), wherein the service indication message (309) contains information that the service provider has service content delivered to the first client terminal, and the method is characterized by: the service indication message (309) further comprises a set of recommended quality of service parameters, wherein the set of recommended quality of service parameters is recommended by the service provider for the bearer service requested by the first client terminal for receiving the service content.

24. The method according to claim 23, wherein the method further comprises determining the set of recommended quality of service parameters from at least one of the following types of input information: service content type, end user subscription type, information about the network establishing the bearer service, and service content provider.

25. The method according to claim 23 or 24, wherein said set of recommended quality of service parameters is a set of recommended packet data protocol context quality of service parameters.

26. A method according to claim 23, wherein said service indication message (309) is a WAP push service loading message modified by appending a set of recommended quality of service parameters.

27. The method according to any of claims 23-24, wherein said service indication message (309) is a WAP push service indication message modified by appending a set of recommended quality of service parameters.

28. The method according to any of claims 23-24, wherein said service indication message (309) is pushed to the first client terminal (102a) via a pre-established primary packet data protocol context (701), and wherein said set of recommended quality of service parameters is a set of recommended packet data protocol context quality of service parameters for a secondary packet data protocol context.

29. A method according to any of claims 23-24, wherein the information that the service provider has service content delivered to the terminal comprises a uniform resource identifier, URI, indicating the service content.

30. A method according to any of claims 23-24, wherein said set of recommended quality of service parameters comprises an indication on a predefined UMTS QoS class.

31. A method according to any of claims 23-24, wherein said set of recommended quality of service parameters comprises recommended values for at least one UMTS QoS attribute.

32. A method according to claim 23, wherein the method further comprises checking whether the service provider is allowed to push the service indication message (309) to the first client terminal (102a) by checking a predetermined policy.