Method and apparatus for providing end-to-end quality of service (QoS)

RELATED APPLICATIONS

This application is related to, and claims the benefit of the earlier filing date under 35 U.S.C. §119(e) of, U.S. Provisional Patent Application (Ser. No. 60/541,514) filed Feb. 3, 2004, entitled “Methods and Apparatus of Air Link QoS Control for End-to-End QoS Support”; the entirety of which is incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to communications, and more particularly, to providing Quality of Service (QoS) services.

BACKGROUND OF THE INVENTION

Radio communication systems, such as cellular systems, provide users with the convenience of mobility. This convenience has spawned significant adoption by consumers as an accepted mode of communication for business and personal uses. Cellular service providers, for example, have fueled this acceptance by developing more enhanced network services and applications. Because of the variety in the types of subscribers and their communication needs, service providers have concentrated on offering services that reflect differing levels of Quality of Service (QoS). For example, for personal use, a subscriber may be amenable to a lower QoS level (e.g., relatively higher delay, lower data rate, or lower availability) as trade off for lower fees. On the other hand, a business subscriber is likely to require a higher QoS level, as minimal delay, high speed and high availability are of primary import versus cost. Unfortunately, the developments in QoS support have varied greatly, resulting in inefficient use of network resources (stemming from higher overhead in implementing QoS services), among other concerns.

QoS support from one service provider's network to the next provider's system can be complex because of potential incompatibilities in their hardware and software platforms. This complexity is further magnified when QoS support is required from one end point to another end point. End-to-end QoS support poses additional challenges to service providers, as they have less control in deploying upgrades or changes to the end user terminals.

Therefore, there is a need for an approach for QoS control that minimizes use of network resources.

SUMMARY OF THE INVENTION

These and other needs are addressed by the present invention, in which an approach provides end-to-end quality of service (QoS) over a radio communication network.

According to one aspect of an embodiment of the present invention, a method for supporting quality of service (QoS) in a radio communication system is disclosed. The method includes receiving, at a first end station, a QoS profile identifier corresponding to a QoS parameter over the radio communication system. The method also includes determining the QoS parameter based on the received identifier, wherein the QoS parameter specifies a characteristic of a communication session established over the radio communication system between the first end station and a second end station.

According to one aspect of an embodiment of the present invention, an apparatus for supporting quality of service (QoS) in a radio communication system is disclosed. The apparatus includes a communication interface configured to receive a QoS profile identifier corresponding to a QoS parameter over the radio communication system. The apparatus also includes a processor configured to determine the QoS parameter based on the received identifier, wherein the QoS parameter specifies a characteristic of a communication session established over the radio communication system between the first end station and a second end station.

According to yet another aspect of an embodiment of the present invention, a method for supporting quality of service (QoS) in a radio communication system is disclosed. The method includes generating a QoS profile identifier that maps to a QoS parameter. Additionally, the method includes transmitting the identifier over the radio communication system to an end station, wherein the end station determines the QoS parameter based on the received identifier.

Still other aspects, features, and advantages of the present invention are readily apparent from the following detailed description, simply by illustrating a number of particular embodiments and implementations, including the best mode contemplated for carrying out the present invention. The present invention is also capable of other and different embodiments, and its several details can be modified in various obvious respects, all without departing from the spirit and scope of the present invention. Accordingly, the drawings and description are to be regarded as illustrative in nature, and not as restrictive.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:

<figref idref="DRAWINGS">FIG. 1</figref> is a diagram of a radio communication system capable of supporting an end-to-end Quality of Service (QoS), in accordance with an embodiment of the present invention;

<figref idref="DRAWINGS">FIG. 2</figref> is a diagram of a protocol architecture for providing end-to-end QoS, in accordance with an embodiment of the present invention;

<figref idref="DRAWINGS">FIG. 3</figref> is a diagram of a mobile station utilizing a QoS profile identifier to determine the QoS parameters, in accordance with an embodiment of the present invention;

<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart of a process for obtaining a QoS table storing QoS parameters, according to an embodiment of the present invention;

<figref idref="DRAWINGS">FIG. 5</figref> is a diagram showing a Packet Data Serving Node (PDSN)-centric QoS setup procedure, in accordance with an embodiment of the present invention;

<figref idref="DRAWINGS">FIG. 6</figref> is a diagram of a message flow for negotiating QoS parameters, in accordance with an embodiment of the present invention;

<figref idref="DRAWINGS">FIG. 7</figref> is a flowchart of a process for providing alerts to support QoS enforcement, in accordance with an embodiment of the present invention;

<figref idref="DRAWINGS">FIG. 8</figref> is a diagram showing a message flow for QoS enforcement, in accordance with an embodiment of the present invention; and

<figref idref="DRAWINGS">FIG. 9</figref> is a diagram of hardware that can be used to implement an embodiment of the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENT

An apparatus, method, and software for supporting end-to-end Quality of Service (QoS) signaling are described. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It is apparent, however, to one skilled in the art that the present invention may be practiced without these specific details or with an equivalent arrangement. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

Although the present invention is discussed with respect to a radio communication system, it is recognized by one of ordinary skill in the art that the present invention has applicability to any type of transport network, including terrestrial systems.

<figref idref="DRAWINGS">FIG. 1</figref> is a diagram of a radio communication system capable of supporting an end-to-end Quality of Service (QoS), in accordance with an embodiment of the present invention. A radio network <b>100</b> includes Mobile Stations (MS) <b>101</b>, <b>103</b> in communication with a Base Station (BS) <b>105</b>. According to one embodiment of the present invention, the radio network <b>100</b> supports Third Generation (3G) services as defined by the International Telecommunications Union (ITU) for International Mobile Telecommunications 2000 (IMT-2000). For the purposes of explanation, the end-to-end QoS capability of the radio network <b>100</b> is explained with respect to a cdma2000 architecture.

In this example, the base station <b>105</b> includes a Base Transceiver Station (BTS) <b>107</b> and Base Station Controller (BSC) <b>109</b>. Although a single BTS <b>107</b> is shown, it is recognized that multiple BTSs are typically are connected to the BSC <b>109</b> through, for example, point-to-point links. The BS <b>105</b> is linked to a Packet Data Serving Node (PDSN) <b>111</b> through a Packet Control Function (PCF) <b>113</b>. The PCF <b>113</b> is largely responsible for directing Point-to-Point Protocol (PPP) connection requests from the MS <b>101</b> to the PDSN <b>111</b>. The BS <b>105</b>, PCF <b>113</b>, and PSDN <b>111</b> constitute the Radio Access Network (RAN) <b>115</b>.

It is recognized that the QoS parameters need to be transmitted to an end station (e.g., MS <b>101</b> or MS <b>103</b>) to ensure proper enforcement of these parameters. To convey QoS parameters in support of end-to-end service guarantees, the system <b>100</b>, according to one embodiment of the present invention, utilizes a table that contains the QoS parameters, such that only table indices are exchanged over the radio link, as more fully described below in <figref idref="DRAWINGS">FIGS. 3 and 4</figref>.

Depending on the model used to establish the radio access bearer, the MS <b>101</b> or the PDSN <b>111</b> can map the QoS attributes for each data service instance from the QoS parameters. The two approaches are provided: a MS-centric approach, and a PDSN-centric approach. In the MS-centric approach, the MS <b>101</b> requests the required radio access QoS parameters it needs from the network <b>100</b> to support the application QoS. Under the PDSN-centric approach, the network <b>100</b> requests the radio access bearer after mapping the QoS parameters received from the MS <b>101</b> to the required radio access QoS parameters.

In contrast to the above approach, if the system <b>100</b> transmitted all the QoS parameters as a block of bits (BLOB), precious network capacity would have to be expended to transmit these QoS parameters over the radio link during the negotiation process. This entails wasting more network capacity than necessary. Also, another drawback is that the transmission of all the QoS parameters can be relatively slow, as the lengthy BLOB constrains the type of signaling protocol that can be employed.

The QoS approach of the system <b>100</b> advantageously permits a use of a QoS profile identifier, such as an index, to refer to a set of attributes, thereby avoiding a longer sized message containing a QoS BLOB. Because of the size reduction to transport these QoS parameters, Medium Access Control (MAC) protocol, Layer 3 (L3) signaling (Signaling Application) can be used to carry this identifier.

Unlike conventional systems in which enforcement QoS policy is problematic, the system <b>100</b> provides a QoS alert system for ensuring that the radio link satisfies negotiated QoS levels, as detailed with respect to <figref idref="DRAWINGS">FIGS. 7 and 8</figref>.

To better appreciate the present invention, it is instructive to describe an exemplary end-to-end QoS architecture used in the system <b>100</b> of <figref idref="DRAWINGS">FIG. 1</figref>.

<figref idref="DRAWINGS">FIG. 2</figref> is a diagram of a protocol architecture for providing end-to-end QoS, in accordance with an embodiment of the present invention. In this model, the MS <b>101</b>, <b>103</b>, as mobile nodes, can be viewed as possessing two components: a Terminal Equipment (TE) <b>201</b> and a Mobile Terminal (MT) <b>203</b>. As mentioned early, a Radio Access Network (RAN) <b>205</b> encompasses the part of the network from the MS <b>101</b> to the PDSN <b>207</b>.

A PDSN/AGW (Access Gateway) <b>207</b>, a Home Agent (HA) <b>209</b>, and a Border Router (BR) <b>211</b> constitute a Core network, which may enforce the service level agreements between the MS <b>101</b> and a Corresponding Node (CN) <b>213</b>. The CN <b>213</b> can reside in a peer network associated with a different administrative domain. Consequently, an end-to-end (E2E) QoS Service <b>215</b> can be defined as an application layer QoS between the end hosts (MS <b>101</b> and CN <b>213</b>). The end-to-end QoS Service <b>215</b> can identify the QoS requirements, for example, via multi-media protocols, such as SIP/SDP (Session Initiation Protocol/Session Description Protocol).

The MT <b>203</b> may then establish a link layer connection suitable for support of the network layer session. The QoS parameters received from the application layer are mapped to the corresponding Internet Protocol (IP) layer signaling parameters as well as the link layer parameters—provided by the IP QoS Service <b>217</b>. In particular, the IP QoS Service <b>217</b> can specify any number of Internet Engineering Task Force (IETF) QoS services, such as Integrated Services and Differentiated Services. A TE-MT Bearer Service <b>218</b> is provided between the TE <b>201</b> and the MT <b>203</b>.

A Radio Network Bearer Service <b>219</b> is the bearer service between the MT <b>203</b> and the PDSN <b>207</b>, and includes a Radio Access Bearer Service <b>221</b> and the R-P Bearer Service <b>223</b>. The Radio Network Bearer Service <b>219</b> includes a translation function for converting between the Radio Bearer Service attributes and QoS attributes of the external networks service control protocol. The Radio Network Bearer Service <b>219</b> also provides an admission control function which maintains information about all available resources in the PDSN <b>207</b>.

Further, the Radio Network Bearer Service <b>219</b> includes management functions in support of a negotiated QoS. Such management functions can include a classification/filtering function to classify data packets and a traffic conditioning function. The Radio Access Bearer Service <b>221</b> defines both the assured mode and non-assured mode (best effort) QoS parameters, and is further detailed in 3GPP2 C.S0017-0-2, entitled “Data Service Options for Spread Spectrum Systems,” which incorporated herein by reference in its entirety.

The R-P Bearer Service <b>223</b> is defined between the RAN <b>205</b> and the PDSN <b>207</b>. The R-P Bearer Service <b>223</b> has A<b>8</b>-A<b>11</b> interfaces that can signal assured mode QoS attributes to the PDSN/AGW <b>207</b>.

The External Bearer Service <b>225</b> is provided by an external network. The Core Network Bearer Service <b>227</b> of the Radio Network provides bearer service between the PDSN <b>207</b> and the BR <b>211</b>.

The Radio Transport Service <b>229</b> is provided by a physical layer that is categorized by QoS traffic classes and attributes based on requirements of the physical radio channels such as FCH (Fundamental Channel), DCCH (Dedicated Control Channel), SCH (Supplemental Channel), etc. These channels are further defined in 3GPP2 C.S0001-C, entitled “Introduction to cdma2000 Standards for Spread Spectrum Systems,” which is incorporated herein by reference in its entirety. The MAC/Multiplex sub-layer maps the radio bearer QoS attributes onto the physical channel QoS parameters. The radio transport layer service controls physical radio channel data units produced by the Radio Bearer Service <b>221</b>.

The R-P Transport Service <b>231</b> is provided by a R-P transport network (which is typically a non-Diffserv network) to guarantee delivery of the R-P Bearer Service <b>223</b> within their specified QoS limits.

<figref idref="DRAWINGS">FIG. 3</figref> is a diagram of a mobile station utilizing a QoS profile identifier to determine the QoS parameters, in accordance with an embodiment of the present invention. In this example, the MS <b>101</b> includes an end-to-end QoS logic <b>301</b> for determining QoS parameters and executing processes to detect deviations from the QoS parameters. A memory <b>303</b> stores a QoS table <b>305</b>, which can be pre-loaded in the memory <b>303</b> or can be downloaded during establishment of a communication session (e.g., call setup). The table <b>305</b> specifies sets of QoS parameter, as QoS profiles, with corresponding QoS profile indices. Under this arrangement, the base station <b>105</b> need only transmit a QoS profile identifier (“QoS ProfileID”), such as a table index value, over the radio link to specify an entire set of QoS parameters.

By way of example, the table <b>305</b> represent the QoS parameters of Table 1. Table 1 gives an example of the QoS table. It is recognized that due to the variations of the bandwidth requirements, the bandwidth (or data rate) requirement can be designated as a separate QoS attribute to minimize the table size.

<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="42pt" align="left" /><colspec colname="2" colwidth="42pt" align="left" /><colspec colname="3" colwidth="42pt" align="left" /><colspec colname="4" colwidth="42pt" align="left" /><colspec colname="5" colwidth="49pt" align="left" /><thead><row><entry namest="1" nameend="5" rowsep="1">TABLE 1</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row><row><entry>QoS</entry><entry>Relative</entry><entry /><entry>Delay</entry><entry>Information</entry></row><row><entry>ProfileID</entry><entry>Priority</entry><entry>Delay</entry><entry>Variation</entry><entry>Loss</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>1</entry><entry>Priority 1</entry><entry>&lt;150 ms</entry><entry>&lt;1 ms</entry><entry>&lt;2% FER</entry></row><row><entry>2</entry><entry>Priority 1</entry><entry>&lt;250 ms</entry><entry>&lt;1 ms</entry><entry>&lt;2% FER</entry></row><row><entry>3</entry><entry>Priority 1</entry><entry>&lt;500 ms</entry><entry>&lt;1 ms</entry><entry>&lt;2% FER</entry></row><row><entry>4</entry><entry>Priority 1</entry><entry>&lt;750 ms</entry><entry>&lt;1 sec</entry><entry>&lt;3% FER</entry></row><row><entry>5</entry><entry>Priority 2</entry><entry>&lt;1 sec</entry><entry>&lt;1 sec</entry><entry>&lt;3% FER</entry></row><row><entry>6</entry><entry>Priority 2</entry><entry>&lt;4 sec</entry><entry>&lt;2 sec</entry><entry>&lt;3% FER</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

As enumerated in Table 1, the exemplary set of QoS parameters can specify the following: a Relative Priority for indicating priority, Delay, Delay Variation, and Information Loss in terms of Error Rate (FER). The table <b>305</b> alternatively stores QoS parameters that can include anyone of the assured mode and non-assured mode (best effort) attributes. For example, QoS attributes defined for assured mode QoS include data rate, delay, jitter, error rate, priority, etc.

According to one embodiment of the present invention, some or all of the QoS attributes can be configured in advance of a request to enable a particular reservation. In this instance, the radio network <b>100</b>, as an Access Network (AN) needs knowledge of the potential QoS attributes (“QoS Profiles”) that the MS <b>101</b>, as an Access Terminal (AT), may request. With this knowledge, the radio network <b>100</b> could setup some or all of the attributes that define the various MAC and application layer flows well in advance of the time that these reservations are requested and/or enabled. The Tables 2-4 illustrate parameters (QoS Profiles) that are downloaded into the mobile station <b>101</b> during the call setup.

<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="42pt" align="center" /><colspec colname="2" colwidth="126pt" align="center" /><thead><row><entry /><entry namest="offset" nameend="2" rowsep="1">TABLE 2</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry /><entry>Length</entry></row><row><entry /><entry>Field</entry><entry>(bits)</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="49pt" align="left" /><colspec colname="1" colwidth="42pt" align="center" /><colspec colname="2" colwidth="126pt" align="char" char="." /><tbody valign="top"><row><entry /><entry>Length</entry><entry>8</entry></row><row><entry /><entry>AttributeID</entry><entry>16</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

The AttributeID field uniquely identifies the particular QoS attribute. Table 3 specifies the number of QoS Profiles that can be supported by the MS <b>101</b>, per the QoSProfileCount field.

<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="56pt" align="center" /><colspec colname="2" colwidth="119pt" align="center" /><thead><row><entry /><entry namest="offset" nameend="2" rowsep="1">TABLE 3</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry /><entry>Length</entry></row><row><entry /><entry>Field</entry><entry>(bits)</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>ValueID</entry><entry>8</entry></row><row><entry /><entry>QoSProfileCount</entry><entry>8</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

The fields of Table 4 correspond to each QoS Profile. The ProfileType fields indicate the type of profile, and the length is specified by the ProfileLength field. Regarding the ProfileValue field, the sender sets this field, which has a length dependent on the profile length. The ProfileValue field can be omitted, if the Profile Type field is set to a predetermined value (e.g., 0x00).

<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="35pt" align="left" /><colspec colname="1" colwidth="49pt" align="center" /><colspec colname="2" colwidth="133pt" align="center" /><thead><row><entry /><entry namest="offset" nameend="2" rowsep="1">TABLE 4</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry /><entry>Length</entry></row><row><entry /><entry>Field</entry><entry>(bits)</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>ProfileType</entry><entry>8</entry></row><row><entry /><entry>ProfileLength</entry><entry>8</entry></row><row><entry /><entry>ProfileValue</entry><entry>ProfileLength × 8</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

Because the QoS Profile is known in advance, the MS <b>101</b> and the radio network <b>100</b> need not initiate negotiation of the QoS attribute. Exemplary QoS setup procedures involving the above message fields are illustrated in 3GPP2 X.S0011-D, entitled “cdma200 Wireless IP Network Standard: Quality of Service and Header Reduction,” which is incorporated herein in its entirety.

In the event that the MS <b>101</b> develops a new QoS attribute that is not known by the radio network <b>100</b>. The MS <b>101</b> can propose an enumeration of all supported types including the new attribute; and the radio network <b>100</b> would select the supported subset of those types during, for example, session configuration. This approach has the advantage of providing an enumeration of all of the mutually supported QoS Profile types so that the MS <b>101</b> need only select the QoS Profile types it knows the radio network <b>100</b> will support.

<figref idref="DRAWINGS">FIG. 4</figref> is a flowchart of a process for obtaining a QoS table storing QoS parameters, according to an embodiment of the present invention. As described, the MS <b>101</b> receives, as in step <b>401</b>, a QoS profile identifier (e.g., table index) that corresponds to a set of QoS parameters. According to one embodiment of the present invention, the QoS table can be pre-defined according to a standard, such that the QoS parameters are pre-loaded or stored. If the table is pre-defined, as determined in step <b>403</b>, the appropriate QoS parameters are retrieved based on the index (per step <b>405</b>). In the alternative, the table can be downloaded, as in step <b>407</b>, during establishment of a communication session (e.g., call setup). In step <b>409</b>, the index is used to determine the corresponding set of QoS parameters.

<figref idref="DRAWINGS">FIG. 5</figref> is a diagram showing a Packet Data Serving Node (PDSN)-centric QoS setup procedure, in accordance with an embodiment of the present invention. For the purposes of illustration, the QoS setup procedure is described with respect to the QoS architecture of <figref idref="DRAWINGS">FIG. 2</figref>. A radio link is set up between the MS <b>101</b> and the PDSN <b>111</b> by an exchange of Service Connect and Service Connect Complete messages, as in step <b>501</b>. Next, the PSDN <b>301</b>, per step <b>503</b>, sends a QoS User Profile request toward the BS/PCF <b>305</b>.

In step <b>505</b>, the MS <b>101</b> sends a Reservation Protocol (RSVP) reservation (RESV) request (Resv) message to the PDSN <b>111</b>. At this point, the Service Network QoS is authorized (step <b>507</b>). In step <b>509</b>, an Update message is transmitted from the PDSN <b>111</b> to the BS <b>105</b>/PCF <b>113</b>, which grants the QoS after performing the necessary air link QoS authorization and admission control (step <b>511</b>).

In step <b>513</b>, the BS <b>105</b>/PCF <b>113</b> sends a Service Connect message to the MS <b>101</b>, which responds with a Service Connect Complete message (step <b>515</b>). In turn, the BS <b>105</b>/PCF <b>113</b> sends, as in step <b>517</b>, an A<b>11</b> Registration Request message to the PDSN <b>111</b>. In step <b>519</b>, the PDSN <b>111</b> responds with an A<b>11</b> Registration Reply message. In step <b>521</b>, a RSVP ResvConf message is communicated to the MS <b>101</b> by the PDSN <b>111</b>.

<figref idref="DRAWINGS">FIG. 6</figref> is a diagram of a message flow for negotiating QoS parameters, in accordance with an embodiment of the present invention. In this exemplary scenario, during the data session, the MS <b>101</b> sends a request to adjust the delay requirement with submission of a different QoS ProfileID. In step <b>601</b>, the MS <b>101</b> begins the QoS negotiations by sending a Service Connect message, which indicates a QoS ProfileID (e.g., QoS ProfileID of 3). The BS <b>105</b> responds with a Service Connect Completion message, and data traffic is exchanged between the MS <b>101</b> and the BS <b>105</b> (steps <b>603</b> and <b>605</b>).

At this point, the MS <b>101</b> becomes aware that the data flow requires a shorter delay. Consequently, the MS <b>101</b> issues, per step <b>607</b>, a QoS Request message specifying a different QoS ProfileID (that of 2). The BS <b>105</b> grants the request, as in step <b>609</b>, with transmission of a QoS Grant message to the MS <b>101</b>. Thereafter, data traffic is exchanged with the new QoS parameters (step <b>611</b>).

The QoS signaling in the above process can be carried by MAC signaling or L3 signaling (Signaling Application). If both Forward and Reverse PDCH are assigned, R-REQCH (Reverse Request Channel) and F-GCH (Forward Grant Channel) can be used to carry out this signaling. Formats of the Reverse Request Message and Forward Grant Channel Message are illustrated as below in Tables 5 and 6. If only F-PDCH is assigned, then R-CQICH (Reverse Channel Quality Indication Channel) and F-PDCCH (Forward Packet Data Control Channel) can be modified for this signaling. If none of the PDCH is assigned then L3 signaling is used.

<tables id="TABLE-US-00005" num="00005"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="49pt" align="center" /><colspec colname="2" colwidth="126pt" align="center" /><thead><row><entry /><entry namest="offset" nameend="2" rowsep="1">TABLE 5</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>Field</entry><entry>Length (bits)</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>RESERVED</entry><entry>1</entry></row><row><entry /><entry>QoS_ProfileID</entry><entry>6</entry></row><row><entry /><entry>RESERVED2</entry><entry>4</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

The RESERVED and RESERVED2 are reserved fields. The QoS_ProfileID field indicates the requested QoS profile identifier associated with the QoS table.

<tables id="TABLE-US-00006" num="00006"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="offset" colwidth="42pt" align="left" /><colspec colname="1" colwidth="49pt" align="center" /><colspec colname="2" colwidth="126pt" align="center" /><thead><row><entry /><entry namest="offset" nameend="2" rowsep="1">TABLE 6</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row><row><entry /><entry>Field</entry><entry>Length (bits)</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /><entry>MAC_ID</entry><entry>8</entry></row><row><entry /><entry>QoS_ProfileID</entry><entry>6</entry></row><row><entry /><entry namest="offset" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

The MAC_ID field is the MAC Identifier. By way of example, the base station <b>105</b> sets this field to the MAC identifier greater than or equal to “01000000” associated with the mobile station to which this QoS message is addressed. The QoS_ProfileID field indicates the QoS profile identifier.

The system <b>100</b> provides enforcement of the QoS policy through an alerting mechanism, as explained below.

<figref idref="DRAWINGS">FIG. 7</figref> is a flowchart of a process for providing alerts to support QoS enforcement, in accordance with an embodiment of the present invention. Once data traffic is exchanged at a negotiated QoS level using the QoS ProfileID, the MS <b>101</b> can monitor the communication session for compliance with the QoS parameters. In this example, the MS <b>101</b> detects violation of the QoS parameter, per step <b>701</b>. This detection, in an exemplary embodiment, can be based on thresholds. For example, the triggers for MS <b>101</b> to initiate QoS enforcement request may include determining that following: the forward link data rate is below a threshold, the delay is above a threshold, the jitter is above a threshold, or the error rate above threshold. The thresholds for triggering an alert can be loaded from the base station <b>105</b> or determined by the mobile station <b>101</b> based on application type.

The BS <b>105</b> can respond to the triggers with one of the following messages: an ACCEPT message to indicate acceptance of the request and that appropriate action will be taken to enforce the QoS; a REJECT message to indicate that the request cannot be processed due to, for instance, the current system load; and an ACK message to indicate that the trigger is received and is to be relayed to another network element (or node), which may be external to the radio network <b>100</b>.

Accordingly, the MS <b>101</b> sends an alert message, as in step <b>703</b>, to the base station <b>105</b>, requesting appropriate action to correct the problem. In step <b>705</b>, the base station <b>105</b> determines that the problem is external to the radio (or air link) of the system <b>100</b>. If the problem stems from a source internal to the system <b>100</b>, the base station <b>101</b> accepts the request and takes appropriate action to bring the QoS parameter back into compliance, per step <b>707</b>. However, if the problem is not external, the base station <b>105</b> acknowledges the request from the MS <b>101</b> with an ACK message, per step <b>709</b>. Because the problem is external to the system <b>100</b>, the base station <b>105</b> relays, as in step <b>711</b>, the alert message to the PDSN <b>111</b> to resolve the issue or to further forward the message to a proper entity or node for resolution.

<figref idref="DRAWINGS">FIG. 8</figref> is a diagram showing a message flow for QoS enforcement, in accordance with an embodiment of the present invention. Per steps <b>801</b> and <b>803</b>, a radio link is established between the MS <b>101</b> and the BS <b>105</b> through an exchange of Service Connect and Service Connection Completion messages. In step <b>805</b>, data is sent from the MS <b>101</b> to the BS <b>105</b>, but with degraded quality of service. One of the QoS attributes is below is respective threshold. The MS <b>101</b> in particular becomes aware that the data flow has a longer than expected delay (based on the QoS parameters). For example, whenever the QoS parameter (i.e., Delay) falls below a delay threshold value, this condition triggers the alert.

Consequently, in step <b>807</b>, the MS <b>101</b> sends a QoS Alert message that indicates the delay is too long. In response to this message, the BS <b>105</b> accepts the request, per step <b>809</b>. Thus, the MS <b>101</b>, as in step <b>811</b>, can now transmit data with the new QoS parameter.

It is contemplated that L3 signaling (Signaling Application) or MAC signaling can be used for this QoS Alert. If R-PDCH is assigned, R-REQCH and F-GCH can be used to carry the alert as MAC signaling. If only F-PDCH is assigned then R-CQICH and F-PDCCH can be used to carry the MAC signaling.

The processes described above provide an end-to-end QoS scheme in which a QoS ProfileID is used to specify QoS parameters, and a QoS alert mechanism to enforce the QoS policy. The processes detailed above can be executed through a variety of hardware and/or software configurations.

<figref idref="DRAWINGS">FIG. 9</figref> illustrates exemplary hardware upon which an embodiment according to the present invention can be implemented. A computing system <b>900</b> includes a bus <b>901</b> or other communication mechanism for communicating information and a processor <b>903</b> coupled to the bus <b>901</b> for processing information. The computing system <b>900</b> also includes main memory <b>905</b>, such as a random access memory (RAM) or other dynamic storage device, coupled to the bus <b>901</b> for storing information and instructions to be executed by the processor <b>903</b>. Main memory <b>905</b> can also be used for storing temporary variables or other intermediate information during execution of instructions by the processor <b>903</b>. The computing system <b>900</b> may further include a read only memory (ROM) <b>907</b> or other static storage device coupled to the bus <b>901</b> for storing static information and instructions for the processor <b>903</b>. A storage device <b>909</b>, such as a magnetic disk or optical disk, is coupled to the bus <b>901</b> for persistently storing information and instructions.

The computing system <b>900</b> may be coupled via the bus <b>901</b> to a display <b>911</b>, such as a liquid crystal display, or active matrix display, for displaying information to a user. An input device <b>913</b>, such as a keyboard including alphanumeric and other keys, may be coupled to the bus <b>901</b> for communicating information and command selections to the processor <b>903</b>. The input device <b>913</b> can include a cursor control, such as a mouse, a trackball, or cursor direction keys, for communicating direction information and command selections to the processor <b>903</b> and for controlling cursor movement on the display <b>911</b>.

According to one embodiment of the invention, the processes of <figref idref="DRAWINGS">FIGS. 4-8</figref> can be provided by the computing system <b>900</b> in response to the processor <b>903</b> executing an arrangement of instructions contained in main memory <b>905</b>. Such instructions can be read into main memory <b>905</b> from another computer-readable medium, such as the storage device <b>909</b>. Execution of the arrangement of instructions contained in main memory <b>905</b> causes the processor <b>903</b> to perform the process steps described herein. One or more processors in a multi-processing arrangement may also be employed to execute the instructions contained in main memory <b>905</b>. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the embodiment of the present invention. In another example, reconfigurable hardware such as Field Programmable Gate Arrays (FPGAs) can be used, in which the functionality and connection topology of its logic gates are customizable at run-time, typically by programming memory look up tables. Thus, embodiments of the present invention are not limited to any specific combination of hardware circuitry and software.

The computing system <b>900</b> also includes at least one communication interface <b>915</b> coupled to bus <b>901</b>. The communication interface <b>915</b> provides a two-way data communication coupling to a network link (not shown). The communication interface <b>915</b> sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information. Further, the communication interface <b>915</b> can include peripheral interface devices, such as a Universal Serial Bus (USB) interface, a PCMCIA (Personal Computer Memory Card International Association) interface, etc.

The processor <b>903</b> may execute the transmitted code while being received and/or store the code in the storage device <b>909</b>, or other non-volatile storage for later execution. In this manner, the computing system <b>900</b> may obtain application code in the form of a carrier wave.

The term “computer-readable medium” as used herein refers to any medium that participates in providing instructions to the processor <b>903</b> for execution. Such a medium may take many forms, including but not limited to non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks, such as the storage device <b>909</b>. Volatile media include dynamic memory, such as main memory <b>905</b>. Transmission media include coaxial cables, copper wire and fiber optics, including the wires that comprise the bus <b>901</b>. Transmission media can also take the form of acoustic, optical, or electromagnetic waves, such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, CDRW, DVD, any other optical medium, punch cards, paper tape, optical mark sheets, any other physical medium with patterns of holes or other optically recognizable indicia, a RAM, a PROM, and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave, or any other medium from which a computer can read.

Various forms of computer-readable media may be involved in providing instructions to a processor for execution. For example, the instructions for carrying out at least part of the present invention may initially be borne on a magnetic disk of a remote computer. In such a scenario, the remote computer loads the instructions into main memory and sends the instructions over a telephone line using a modem. A modem of a local system receives the data on the telephone line and uses an infrared transmitter to convert the data to an infrared signal and transmit the infrared signal to a portable computing device, such as a personal digital assistant (PDA) or a laptop. An infrared detector on the portable computing device receives the information and instructions borne by the infrared signal and places the data on a bus. The bus conveys the data to main memory, from which a processor retrieves and executes the instructions. The instructions received by main memory can optionally be stored on storage device either before or after execution by processor.

While the present invention has been described in connection with a number of embodiments and implementations, the present invention is not so limited but covers various obvious modifications and equivalent arrangements, which fall within the purview of the appended claims.