WO2001065779A2

WO2001065779A2 - Quality or service profile negotiation in a data packet communications system

Info

Publication number: WO2001065779A2
Application number: PCT/EP2001/002201
Authority: WO
Inventors: George Eleftheriadis
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2000-02-29
Filing date: 2001-02-28
Publication date: 2001-09-07
Also published as: AU2001240659A1; WO2001065779A3

Abstract

Requesting a Quality of Service for use in a system such as a mobile communication system is performed by using an input/output device to receive information from an end-user, and generating a user Quality of Service profile from the information. The Quality of Service profile is stored in a list of user Quality of Service profiles. When it is time to generate a Requested Quality of Service parameter, one of the Quality of Service profiles is retrieved from the list of Quality of Service profiles, and is used as the Requested Quality of Service parameter. Automatically negotiating a Quality of Service involves generating a Requested Quality of Service parameter, and transmitting the Requested Quality of Service parameter to a service provider. After receiving a proposed Quality of Service Negotiated parameter, one or more threshold parameters are retrieved from a stored list of threshold parameters. One or more of these are compared with a present parameter state. The proposed Quality of Service negotiated parameter is rejected if the present parameter state is not wihin a range that is defined by the one or more retrieved threshold parameters. The process is further facilitated by providing the mobile terminal with a list of Quality of Service profiles that are supported by the PLMN. The mobile terminal can store these for later use, either manually by the end-user, or automatically by the mobile terminal.

Description

QUALITY OF SERVICE PROFILE NEGOTIATION IN A DATA PACKET COMMUNICATIONS SYSTEM

BACKGROUND

The present invention relates to packet data communications systems, and more particularly to methods and apparatuses that assist the user in negotiating with the service provider for a particular quality of service.

Data packet communications systems are well known. In such systems, data (which may represent numerical or any other type of information) is divided into discrete units, called "packets". The packets are supplied individually to the communications system, which conveys these to the intended recipient's communication equipment. On the receiver side of the communication, the original data is reconstructed from the received packets, and then supplied to the intended recipient.

Data packet communications systems have traditionally been implemented by means of a wire-based connection (e.g. , electrical cable or optical fiber).

However, more recently the principles of data packet communications have been applied in wireless applications, thereby providing the user with even greater flexibility with respect to the use of such a system. The General Packet Radio System (GPRS) is a GSM-based standard that defines one such wireless system. Data packet communications systems, including GPRS systems, offer a variety of service levels to the user. The particular Quality of Service (QoS) that a user experiences may be related to parameter settings that determine such things as data throughput, delay, packet connection establishment priority, retention priority, transmission medium, channel security, and the like. Different users may have different QoS settings, and these are usually determined at the time of packet connection establishment. With respect to GPRS systems, relevant QoS-related requirements are defined in GSM Specification 03.60 v.6.2.0 Rel. 1997. which is hereby incorporated herein by reference. The following are defined for GPRS:

PDP Address A GPRS subscriber identified by an International Mobile Subscriber

Identity (IMSI) shall have one or more network layer addresses temporarily and/or permanently associated with it that conforms to the standard addressing scheme of the respective network layer service used. Network layer addresses are, for example, Packet Data Protocol (PDP) addresses, such as: - Internet Protocol (IP) version 4 addresses;

IP version 6 addresses; or X.121 addresses. A GPRS subscription contains the subscription of one or more PDP addresses.

PDP Context

Each PDP address in a GPRS subscription is described by an individual PDP context in the Mobile Station (MS), the Serving GPRS Support Node (SGSN), and the Gateway GPRS Support Node (GGSN). Every PDP context exists independently in one of two PDP states: ACTIVE and INACTIVE. The PDP state indicates whether the PDP address is activated for data transfer or not.

The PDP Context information is described in GSM Specification 03.60 v.6.2.0 Rel. 1997 section 13.2.

QoS Profile

A QoS profile is associated with each PDP context. The QoS profile is considered to be a single parameter with multiple data transfer attributes. It defines the quality of service expected in terms of the following attributes: precedence class; delay class; reliability class; peak throughput class; and - mean throughput class.

There are many possible QoS profiles defined by the various combinations of the attributes. However, a Public Land Mobile Network (PLMN) is not required to support all possible profiles; it may instead support only a limited subset of the possible QoS profiles.

QoS Subscribed

The QoS Subscribed parameter, which is part of the GPRS Subscription data stored in the Home Location Register (HLR), denotes a default quality of service level associated with a particular subscription. The default is selected if the MS does not request a particular QoS profile. It is also included in the PDP Context information.

QoS Requested

The QoS Requested parameter denotes the QoS profile requested by the MS at the time of PDP Address activation. This parameter indicates the desired profile for a particular data transfer. It is included in the PDP Context information.

QoS Negotiated

The QoS Negotiated parameter denotes the outcome of the negotiation between the QoS Requested and the available GPRS resources. It is included in the PDP Context information. A conventional solution to the problem of performing QoS profile negotiation for a particular data transfer between the MS and the GPRS network is described in the GPRS standard (GSM 03.60 version 6.2.0 Release 1997 As described therein, in order to initiate a data transfer a GPRS MS must first activate the corresponding PDP Context (and the related PDP Address). At PDP Context activation, the MS is allowed to request a specific QoS profile (i.e., QoS Requested) for this particular data transfer. The MS requests a value for each of the QoS attributes, including the HLR-stored default values (QoS Subscribed). For each PDP Address, a different quality of service profile may be requested. For example, some PDP addresses may be associated with E-mail, which can tolerate lengthy response times. Other applications cannot tolerate delay and demand a very high level of throughput, interactive applications being one example. These different requirements are reflected in the QoS profile. If a QoS requirement is beyond the capabilities of a PLMN (i.e., the QoS profiles which are supported by the PLMN and the available GPRS resources), the PLMN negotiates the QoS profile as close as possible to the requested QoS profile. The MS either accepts the negotiated QoS profile, or deactivates the PDP context. If the MS has accepted the QoS Negotiated, the network shall always attempt to provide adequate resources to support the negotiated QoS profiles. The above-described conventional technique suffers from a number of drawbacks:

First, in order to set up the QoS Requested, the GPRS end-user has to decide and identify a desired value for each of the attributes of the QoS profile. In some cases this process may be quite complicated (the user has to think and decide the attribute values of the QoS Requested) and may decrease the usability of the

QoS negotiation function. The end-user needs a user-friendly tool to assist with this task.

Also, when setting up a QoS Requested, the end-user does not know whether the requested QoS is supported by the PLMN (a PLMN may support only a limited subset of the possible QoS profiles), and if so, whether it is available at this time. In the event that the QoS Requested is not supported and/or available by/from the PLMN, the GPRS end-user has wasted time and effort on the identification and the set-up of the desired QoS. For example, the end-user could instead have simply used the default QoS Subscribed profile. Moreover, the request of a QoS that is not supported and/or available by the PLMN increases the delays and the processor load in the system because the system has to identify which of the supported/available QoS profiles is closer to the requested one; the result of this process is the QoS Negotiated parameter. Furthermore, when the QoS Negotiated is received by the end-user, he or she has to decide whether it is acceptable or not. In some cases, this process may be quite complicated (the user has to think about the QoS Negotiated and decide whether it is good enough and acceptable). This added complication may decrease the usability of the QoS negotiation function. The end-user needs a user-friendly tool to assist him or her.

Thus, there is the need for improved methods and apparatuses for enabling an end-user to more easily and quickly negotiate a quality of service in connection with data packet communications.

SUMMARY It is therefore an object of the present invention to provide improved techniques relating to QoS negotiation.

In accordance with one aspect of the present invention, a Requested Quality of Service parameter is generated by using an input/output device to receive information from an end-user, and generating a user Quality of Service profile from the information. The Quality of Service profile is then stored in a list of user

Quality of Service profiles. When the Requested Quality of Service parameter is to be generated, one of the Quality of Service profiles is retrieved from the list of Quality of Service profiles, and used as the Requested Quality of Service parameter.

In other aspects of the invention, the information includes a threshold parameter that indicates when the generated Quality of Service profile is a preferred Quality of Service profile. The threshold parameter may be, but is not limited to, any one or combination of the following: a day of the week threshold parameter; a day category threshold parameter; a time of day threshold parameter; and a type of service threshold parameter.

In another aspect of the invention, step of using the retrieved Quality of Service profile as the Requested Quality of service parameter comprises comparing a threshold parameter associated with the retrieved Quality of Service profile with a present parameter state; and using the retrieved Quality of Service profile as the Requested Quality of service parameter only if the present parameter state is within a range that is defined by the threshold parameter associated with the retrieved Quality of Service profile.

In yet another aspect of the invention, if the present parameter state is not within a range that is defined by the threshold parameter associated with the retrieved Quality of Service profile, then a second one of the Quality of Service profiles is retrieved from the list of Quality of Service profiles. The second retrieved Quality of Service profile may then be used as the Requested Quality of

Service parameter.

In still another aspect of the invention, one or more supported Quality of Service profiles are retrieved from a list of supported Quality of Service profiles. In such embodiments, the step of using the retrieved Quality of Service profile as the Requested Quality of service parameter comprises: comparing the retrieved

Quality of Service profile with at least one of the retrieved one or more supported Quality of Service profiles; and using the retrieved Quality of Service profile as the Requested Quality of service parameter only if the retrieved Quality of Service profile matches at least one of the retrieved one or more supported Quality of Service profiles.

In yet another aspect of the invention, a Quality of Service Negotiated parameter is automatically negotiated by generating a Requested Quality of Service parameter, and transmitting the Requested Quality of Service parameter to a service provider. A proposed Quality of Service Negotiated parameter is then received. One or more threshold parameters are also retrieved from a stored list of threshold parameters. These are compared with a present parameter state. The proposed Quality of Service negotiated parameter is then rejected if the present parameter state is not within a range that is defined by the one or more retrieved threshold parameters.

In other aspects of the invention, the one or more threshold parameters may include, but are not limited to, any one or combination of the following: a day of the week threshold parameter; a day category threshold parameter; a time of day threshold parameter; a type of service threshold parameter; and an importance of attribute threshold parameter.

In yet another aspect of the invention, a mobile terminal is supplied with information about Quality of Service profiles supported by a PLMN. This includes transmitting a list of supported Quality of Service profiles from the PLMN to the mobile terminal; and in the mobile terminal, storing the list of supported Quality of Service profiles in a memory device.

In still another aspect of the invention, a revised list of supported Quality of Service profiles is generated in the PLMN. In such instances, the transmitting step may be performed in response to the revised list of supported Quality of Service profiles being generated.

In yet another aspect of the invention, the mobile terminal is a roaming terminal in the service area of the PLMN; and the step of transmitting the list of supported Quality of Service profiles from the PLMN to the mobile terminal is performed in response to the mobile station registering for the first time in the PLMN.

In still another aspect of the invention, the step of transmitting the list of supported Quality of Service profiles from the PLMN to the mobile terminal comprises using a point-to-point message between the PLMN and the mobile terminal to transmit the list of supported Quality of Service profiles from the PLMN to the mobile terminal.

BRIEF DESCRIPTION OF THE DRAWINGS

The objects and advantages of the invention will be understood by reading the following detailed description in conjunction with the drawings in which:

FIG. 1 is a block diagram of a mobile station and a public land mobile network embodying the various aspects of the invention; and

FIG. 2 is a flow chart depicting the operation of a QoS negotiator, in accordance with an aspect of the invention.

DETAILED DESCRIPTION

The various features of the invention will now be described with respect to the figures, in which like parts are identified with the same reference characters.

In one aspect of the invention, the end-user of a Mobile Station (MS) is provided with a tool that facilitates the creation of one or more desired QoS profiles, each being tailored for use under particular conditions (e.g., present day of the week, time of day, type of service). The QoS profiles may be stored within the MS.

In another aspect of the invention, the MS may store a list of QoS configurations that are available in the service area of a PLMN. This list may be useful under several circumstances. First, it may be useful to the end-user for use as a reference when the user is creating and/or modifying his QoS profiles. Moreover, the list of available QoS configurations provides the MS and/or end- user with the information necessary to avoid unnecessarily setting up a QoS Requested parameter that requests a QoS that is not supported or available from the PLMN. In another aspect of the invention, whenever the operator of the PLMN updates the list, the system sends a system information broadcast message to inform the MSs of these updates.

In yet another aspect of the invention, the MS is provided with an automated QoS negotiator. The automated QoS negotiator uses information about the PLMN's available QoS configurations, the end-user's QoS profiles, and relevant parameters (e.g., present day of the week, time of day, type of service) to automatically generate a QoS Requested parameter that is suitable for the existing conditions, and to automatically decide whether the QoS Negotiated proposed by the system is acceptable by the end-user.

These and other aspects of the invention will now be described in greater detail in connection with a number of exemplary embodiments. To facilitate an understanding of the invention, many aspects of the invention are described in terms of sequences of actions to be performed by elements of a computer or other type of processor. It will be recognized that in each of the embodiments, the various actions could be performed by specialized circuits (e.g. , discrete logic gates interconnected to perform a specialized function), by program instructions being executed by one or more processors, or by a combination of both.

Moreover, the invention can additionally be considered to be embodied entirely within any form of computer readable storage medium having stored therein an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein. Thus, the various aspects of the invention may be embodied in many different forms, and all such forms are contemplated to be within the scope of the invention. For each of the various aspects of the invention, any such form of embodiment may be referred to herein as "logic configured to" perform a described action. Referring now to FIG. 1, a block diagram of an MS 101 and PLMN 103 embodying the various aspects of the invention is shown. The MS 101 communicates with a PLMN 103 by means of radio signals 105 in accordance with any of a number of well known radio communication standards, such as GPRS. This is performed by means of transceiver circuitry 107, which is well-known in the art. Within the MS 101 , the transceiver circuitry 107 exchanges signals with a number of components, including end-user input/output components 109 (henceforth referred to as "I/O components 109") which may include, but are not limited to, any or all of the following: a loudspeaker, a display device and a keyboard device (not shown).

In accordance with one aspect of the invention, the MS 101 further includes a setup tool 111 that is coupled to the I/O components 109. The setup tool 111 provides information to the end-user (via one or more output elements of the I/O components 109) that enables the user to more easily decide upon and enter (via one or more input elements of the I/O components 109) desired values for one or more QoS profiles. The user may wish to establish more than one QoS profile, with each one being particularly adapted for use under a particular set of conditions. Such conditions, or threshold parameters, may include, but are not limited to, such considerations as day of the week, day category (e.g. , to permit QoS differentiation on the basis of weekdays versus weekends), time of day, type of service (e.g. , E-mail, interactive data services), and the like.

To allow the setup tool 111 to perform these functions, the MS 101 further includes one or more memory components for storing a list of user QoS profiles 113 and various threshold values 115. The setup tool 111 is coupled to these one or more memory components to enable it to store new user QoS profiles and threshold values and also to retrieve and modify (including deleting) existing ones. Existing user QoS profiles and threshold values may be supplied to the end-user (via the I/O components 109) to ease the task of creating one or more new ones, or modifying existing ones. In another aspect of the invention, the setup tool 111 may further have access to a list of supported QoS profiles 117, which may also be stored in the one or more memory components mentioned above, or in another memory component. The MS 101 may be supplied with an initial list of supported QoS profiles 117 at the time that the end-user subscribes to a specific service. However, to accommodate the fact that these lists do not remain static, each time the operator updates the list (e.g. , adds, removes, or updates a supported QoS configuration), the PLMN 103 sends a system information broadcast message to inform the MSs 101 of any updates in the QoS list. This system information broadcast message is supplied to a component within the MS 101 referred to herein as the supported

QoS profile updater 119, which interprets the broadcast message and modifies the list of supported QoS profiles 117.

This facility may further be made available to roaming MSs as well. When a roaming MS 101 is registered for the first time in the operator's PLMN 103, the PLMN 103 can transmit the list of supported QoS configurations to it with a point- to-point message, which can also be processed and acted upon by the supported QoS profile updater 119.

The setup tool 111 may supply the list of supported QoS profiles 117 to the end-user via the I/O components 109 so that whenever the end-user wants to negotiate the QoS for a specific data transfer, he may use this list as a basis for deciding which of the available QoS profiles (stored as the list of user QoS profiles 113) will be used as the QoS Requested. This greatly increases the efficiency of the process because a user can easily avoid selecting a QoS profile that specifies a level of QoS that he knows will not be supported by the PLMN 103. In yet another aspect of the invention, the negotiation of a quality of service can be automated. For this purpose, the MS 101 may further be equipped with a QoS negotiator 121 that is coupled to the transceiver circuitry 107, the list of user QoS profiles 113, the list of threshold parameters 115, and the list of supported QoS profiles 117. FIG. 2 is a flowchart depicting the operation of the QoS negotiator 121. When the MS 101 initiates the PDP Context Activation, the QoS negotiator 121 list of user QoS profiles, and selects one. This selection may take into account none, some or all of the following: the threshold parameters 115 coupled with present threshold values; and the list of supported QoS profiles 117. The selected user QoS profile is then included in the QoS Requested field of the

PDP Context Activation message (step 201). The PDP Context Activation message is then transmitted to the PLMN 103 (step 203).

The MS 101 then receives a response from the PLMN 103 in the form of a proposed QoS Negotiated parameter (step 205). In response, the QoS negotiator 121 decides whether the proposed QoS Negotiated parameter is acceptable. Of course, this decision may simply be made on the basis of whether the proposed QoS Negotiated parameter matches the QoS Requested parameter. However, if there is some difference between the two, it may still be acceptable for the end- user's purposes. Thus, the decision whether the proposed QoS Negotiated parameter is acceptable may be further based on the list of threshold parameters

115 (step 207). For example, these threshold parameters may associate a binary value with each QoS attribute, with the binary value indicating whether the proposed QoS Negotiated attribute must exactly match the requested one, or whether alternatively any proposed value would be acceptable. If the proposed attribute does not match, then the QoS Negotiated parameter should be rejected.

Alternatively, a threshold parameter may define a range of attribute values that would be acceptable. The threshold in this case may specify the acceptable (or unacceptable) values themselves, or it may indicate an amount of deviation from a requested attribute value (e.g., requested attribute +/- 1). In this specification, the term "range" is used to define the acceptable (or unacceptable) attribute values, regardless of whether that range is a single acceptable (or unacceptable) value (e.g. , in the case of a binary threshold parameter) or whether it is a number of acceptable (or unacceptable) values. If the proposed QoS Negotiated parameter is within certain threshold boundaries, as defined by the list of threshold parameters 115, then the proposed QoS Negotiated parameter may be acceptable. Threshold parameters may include, but are not limited to, day of the week, day category (e.g., to permit QoS differentiation on the basis of weekdays versus weekends), time of day, type of service (e.g. , E-mail, interactive data services), and the importance of a QoS attribute (e.g. , associate weights to each of the possible QoS attributes).

The QoS negotiator 121 then generates a suitable response and transmits this to the PLMN 103 (step 209). The response may either accept or reject the PLMN's proposal.

The invention provides a number of advantages. The setup tool 111 simplifies and speeds up the user's ability to establish one or more QoS Requested profiles. QoS negotiator 121 further simplifies the process by automating the QoS negotiation procedure, taking into account the supported QoS profiles, as well as whether the QoS Negotiated that is proposed by the PLMN falls within acceptable limits (as set by the threshold parameters 115).

The invention has been described with reference to a particular embodiment. However, it will be readily apparent to those skilled in the art that it is possible to embody the invention in specific forms other than those of the preferred embodiment described above. This may be done without departing from the spirit of the invention.

For example, the above-described embodiments utilize parameters as specified in accordance with the GPRS standards. However, this is not an essential feature of the invention, which can easily be adapted for use with Quality of Service parameters as defined in accordance with other standards.

Thus, the preferred embodiment is merely illustrative and should not be considered restrictive in any way. The scope of the invention is given by the appended claims, rather than the preceding description, and all variations and equivalents which fall within the range of the claims are intended to be embraced therein.

Claims

WHAT IS CLAIMED IS:

1. A method of generating a Requested Quality of Service parameter, comprising: using an input/output device to receive information from an end-user; generating a user Quality of Service profile from the information; storing the Quality of Service profile in a list of user Quality of Service profiles; retrieving one of the Quality of Service profiles from the list of Quality of Service profiles; and using the retrieved Quality of Service profile as the Requested Quality of

Service parameter.

2. The method of claim 1 , wherein the information includes a threshold parameter that indicates when the generated Quality of Service profile is a preferred Quality of Service profile.

3. The method of claim 2, wherein the threshold parameter is a day of the week threshold parameter.

4. The method of claim 2, wherein the threshold parameter is a day category threshold parameter.

5. The method of claim 2, wherein the threshold parameter is a time of day threshold parameter.

6. The method of claim 2, wherein the threshold parameter is a type of service threshold parameter.

7. The method of claim 1, wherein the step of using the retrieved Quality of Service profile as the Requested Quality of service parameter comprises: comparing a threshold parameter associated with the retrieved Quality of Service profile with a present parameter state; and using the retrieved Quality of Service profile as the Requested Quality of service parameter only if the present parameter state is within a range that is defined by the threshold parameter associated with the retrieved Quality of Service profile.

8. The method of claim 7, further comprising: if the present parameter state is not within a range that is defined by the threshold parameter associated with the retrieved Quality of Service profile, then retrieving a second one of the Quality of Service profiles from the list of Quality of Service profiles; and using the second retrieved Quality of Service profile as the Requested Quality of Service parameter.

9. The method of claim 1, further comprising: retrieving one or more supported Quality of Service profiles from a list of supported Quality of Service profiles, and wherein the step of using the retrieved Quality of Service profile as the Requested Quality of service parameter comprises: comparing the retrieved Quality of Service profile with at least one of the retrieved one or more supported Quality of Service profiles; and using the retrieved Quality of Service profile as the Requested Quality of service parameter only if the retrieved Quality of Service profile matches at least one of the retrieved one or more supported Quality of Service profiles.

10. A method of automatically negotiating a Quality of Service Negotiated parameter, comprising: generating a Requested Quality of Service parameter; transmitting the Requested Quality of Service parameter to a service provider; receiving a proposed Quality of Service Negotiated parameter; retrieving one or more threshold parameters from a stored list of threshold parameters; comparing the one or more retrieved threshold parameters with a present parameter state; and rejecting the proposed Quality of Service negotiated parameter if the present parameter state is not within a range that is defined by the one or more retrieved threshold parameters.

11. The method of claim 10, wherein the one or more threshold parameters comprise a day of week threshold parameter.

12. The method of claim 10, wherein the one or more threshold parameters comprise a day category threshold parameter.

13. The method of claim 10, wherein the one or more threshold parameters comprise a time of day threshold parameter.

14. The method of claim 10, wherein the one or more threshold parameters comprise a type of service threshold parameter.

15. The method of claim 10, wherein the one or more threshold parameters comprise an importance of attribute threshold parameter.

16. A method of supplying a mobile terminal with information about Quality of Service profiles supported by a PLMN, comprising: transmitting a list of supported Quality of Service profiles from the PLMN to the mobile terminal; and in the mobile terminal, storing the list of supported Quality of Service profiles in a memory device.

17. The method of claim 16, further comprising: generating a revised list of supported Quality of Service profiles in the PLMN, and wherein the transmitting step is performed in response to the revised list of supported Quality of Service profiles being generated.

18. The method of claim 16, wherein: the mobile terminal is a roaming terminal in the service area of the PLMN; and the step of transmitting the list of supported Quality of Service profiles from the PLMN to the mobile terminal is performed in response to the mobile station registering for the first time in the PLMN.

19. The method of claim 18, wherein the step of transmitting the list of supported Quality of Service profiles from the PLMN to the mobile terminal comprises using a point-to-point message between the PLMN and the mobile terminal to transmit the list of supported Quality of Service profiles from the PLMN to the mobile terminal.

20. An apparatus for generating a Requested Quality of Service parameter, comprising: logic configured to use an input/ output device to receive information from an end-user; logic configured to generate a user Quality of Service profile from the information; logic configured to store the Quality of Service profile in a list of user

Quality of Service profiles; logic configured to retrieve one of the Quality of Service profiles from the list of Quality of Service profiles; and logic configured to use the retrieved Quality of Service profile as the Requested Quality of Service parameter.

21. The apparatus of claim 20, wherein the information includes a threshold parameter that indicates when the generated Quality of Service profile is a preferred Quality of Service profile.

22. The apparatus of claim 21 , wherein the threshold parameter is a day of the week threshold parameter.

23. The apparatus of claim 21, wherein the threshold parameter is a day category threshold parameter.

24. The apparatus of claim 21, wherein the threshold parameter is a time of day threshold parameter.

25. The apparatus of claim 21, wherein the threshold parameter is a type of service threshold parameter.

26. The apparatus of claim 20, wherein the logic configured to use the retrieved Quality of Service profile as the Requested Quality of service parameter comprises: logic configured to compare a threshold parameter associated with the retrieved Quality of Service profile with a present parameter state; and logic configured to use the retrieved Quality of Service profile as the Requested Quality of service parameter only if the present parameter state is within a range that is defined by the threshold parameter associated with the retrieved Quality of Service profile.

27. The apparatus of claim 26, further comprising: logic configured to retrieve a second one of the Quality of Service profiles from the list of Quality of Service profiles if the present parameter state is not within a range that is defined by the threshold parameter associated with the retrieved Quality of Service profile; and logic configured to use the second retrieved Quality of Service profile as the Requested Quality of Service parameter.

28. The apparatus of claim 20, further comprising: logic configured to retrieve one or more supported Quality of Service profiles from a list of supported Quality of Service profiles, and wherein the logic configured to use the retrieved Quality of Service profile as the Requested Quality of service parameter comprises: logic configured to compare the retrieved Quality of Service profile with at least one of the retrieved one or more supported Quality of Service profiles; and logic configured to use the retrieved Quality of Service profile as the Requested Quality of service parameter only if the retrieved Quality of Service profile matches at least one of the retrieved one or more supported Quality of

Service profiles.

29. An apparatus for automatically negotiating a Quality of Service Negotiated parameter, comprising: logic configured to generate a Requested Quality of Service parameter; logic configured to transmit the Requested Quality of Service parameter to a service provider; logic configured to receive a proposed Quality of Service Negotiated parameter; logic configured to retrieve one or more threshold parameters from a stored list of threshold parameters; logic configured to compare the one or more retrieved threshold parameters with a present parameter state; and logic configured to reject the proposed Quality of Service negotiated parameter if the present parameter state is not within a range that is defined by the one or more retrieved threshold parameters.

30. The apparatus of claim 29, wherein the one or more threshold parameters comprise a day of week threshold parameter.

31. The apparatus of claim 29, wherein the one or more threshold parameters comprise a day category threshold parameter.

32. The apparatus of claim 29, wherein the one or more threshold parameters comprise a time of day threshold parameter.

33. The apparatus of claim 29, wherein the one or more threshold parameters comprise a type of service threshold parameter.

34. The apparatus of claim 29, wherein the one or more threshold parameters comprise an importance of attribute threshold parameter.

35. An apparatus for supplying a mobile terminal with information about Quality of Service profiles supported by a PLMN, comprising: logic configured to transmit a list of supported Quality of Service profiles from the PLMN to the mobile terminal; and in the mobile terminal, logic configured to store the list of supported

Quality of Service profiles in a memory device.

36. The apparatus of claim 35, further comprising: logic configured to generate a revised list of supported Quality of Service profiles in the PLMN, and wherein the logic configured to transmit operates in response to the revised list of supported Quality of Service profiles being generated.

37. The apparatus of claim 35, wherein: the mobile terminal is a roaming terminal in the service area of the PLMN; and the logic configured to transmit the list of supported Quality of Service profiles from the PLMN to the mobile terminal operates in response to the mobile station registering for the first time in the PLMN.

38. The apparatus of claim 37, wherein the logic configured to transmit the list of supported Quality of Service profiles from the PLMN to the mobile terminal comprises logic configured to use a point-to-point message between the PLMN and the mobile terminal to transmit the list of supported Quality of Service profiles from the PLMN to the mobile terminal.