WO2003075521A1

WO2003075521A1 - Packet data communications networks

Info

Publication number: WO2003075521A1
Application number: PCT/GB2003/000950
Authority: WO
Inventors: Simon Charles Durrant; John David Ainsworth
Original assignee: Pa Consulting Services Ltd.
Priority date: 2002-03-05
Filing date: 2003-03-05
Publication date: 2003-09-12
Also published as: GB0205107D0; AU2003214384A1; GB2386284A

Abstract

The usage of the transmission resources allocated to applications executing on a device in a packet data communications network are monitored and controlled. An application utilises multiple packet data streams on different physical bearers simultaneously. The amount of data transmitted per unit time by said application on each packet data stream is controlled individually such that data is not transmitted at a rate in excess of the assigned bit rate for each packet data stream. Each packet data stream of said application is assigned an individual bit rate at which data packets can be transmitted, the actual bit rate at which the application offers data packets for transmission on each packet data stream is monitored, and data packets offered for transmission on each packet data stream that would cause the assigned bit rate for said packet data stream to be exceeded, are delayed or discarded.

Description

Packet Data Communications Networks

FIELD OF THE INVENTION

The present invention relates to packet data communications networks, and more particularly, to controlling the rate at which applications executing on a packet data communications device send data over shared transmission resources.

The invention has been developed primarily for mobile wireless communications networks such as UMTS. However, it will be appreciated by those skilled in the art that the invention is not limited to use with those particular technologies.

BACKGROUND TO THE INVENTION

In UMTS an application can specify the quality of service it requires for each of the data streams that it uses to send and/or receive packetised data to/from other applications. Each data stream is sent over a packet switch connection. Within UMTS the connection is defined by a Packet Data Protocol (PDP) context and is known as a UMTS bearer. The PDP context is used to specify the attributes of the connection and hence the quality of service provided by that connection. At the radio layer, for each PDP context a separate Radio Access Bearer (RAB) is established, with the quality of service attributes as specified in the PDP context. As a consequence, if multiple PDP contexts exist simultaneously, then multiple corresponding RABs will also exist to support each UMTS bearer.

The attributes that can be set for each PDP context are as follows:

Traffic class Maximum bit rate Guaranteed bit rate Delivery order Maximum SDU size SDU format information SDU error ratio Delivery of erroneous SDUs Transfer delay Traffic handling priority Allocation retention priority Source statistics descriptor

For each one of the four traffic classes, a subset of the other attributes is defined as being applicable to that class. For example in both the conversational and streaming classes, all attributes are applicable with the exception of traffic handling priority.

An application executing on a mobile device will request a connection to be set-up for each one of the data streams it will use. The applications view of the connection is termed a socket. When the application requests a socket to be set-up it will specify the quality of service attributes it requires for the connection such that it is appropriate for the type of data to be transmitted. It is obvious that these could be specified it terms of the PDP context attributes or other suitable set of parameters which can be mapped to PDP context attributes. The entity that deals with the application's connection requests is termed a QoS Manager. It will determine if an existing PDP context could be used for the connection or whether a new UMTS bearer should be set up. Either way, once a UMTS bearer with the appropriate quality of service characteristics has been obtained, the QoS manager will associate the application's socket with that bearer. In this way packets sent on a particular socket are delivered to a particular bearer with the correct QoS attributes.

The network may change the attributes of a UMTS bearer at any time, typically in response to changes in traffic loading. The network notifies the QoS manager when a modification to a PDP context is required, and it will then in turn notify the applications that have sockets that are bound to the changed PDP context. The application can then adjust its data transfer accordingly, or may even decide to terminate if the required quality of service is no longer available. An application may also request a modification to the QoS attributes of any of its connections, which may result in the mobile device initiating a PDP modification to the network. In the so called 3^rd generation wireless systems it will be common for two or more applications to be utilising the same radio access bearer for their data streams. It will also be usual for an application to use different bearers, with different quality of service attributes, for individual data streams. The Quality of Service Manager (QoSM) is the entity responsible for managing how the bandwidth on each bearer is apportioned between the data streams of applications sharing each said bearer. The QoSM can determine each data streams share of the available bandwidth by a variety of techniques such as:

Allocating an equal share for each data stream; or

Allocation based upon application request; or

Allocation based upon QoS policy profile settings stored for the application, terminal or user.

The QoSM is also responsible for determining how each data streams share of the available bandwidth should change, when either a modification is made by the network or when an application closes a data stream, which can also be done using the techniques described above.

The prior art International patent application WO00/36796 provides for controlling the bandwidth utilised by an application regardless of the number of data streams it is using, and how they are mapped on to bearers. It does not provide a mechanism to police the usage by an application of its allocated bandwidth at the level of individual streams, and, as a consequence, does not address the issue of one application using more than one bearer. This is the object of the present invention.

SUMMARY OF INVENTION

According to a first aspect, the present invention provides a method of monitoring and controlling the usage of the transmission resources allocated to applications executing on a device in a packet data communications network, a method of monitoring and controlling the usage of the transmission resources allocated to applications executing on a device in a packet data communications network, wherein an application utilises multiple packet data streams on different physical bearers simultaneously, the method comprising individually controlling the amount of data transmitted per unit time by said application on each packet data stream such that data is not transmitted at a rate in excess of the assigned bit rate for each packet data stream.

According to a second aspect, the invention provides a data communications device a data communications device comprising means for monitoring and controlling the usage of the transmission resources allocated to applications executing on said device in a packet data communications network, said device further comprising means for an application to utilise multiple packet data streams simultaneously on different physical bearers, and filter means to individually control the amount of data transmitted per unit time by said application on each packet data stream such that data is not transmitted at a rate in excess of the assigned bit rate for each packet data stream.

Preferably the bit rate at which data packets can be transmitted is assigned to a packet data stream, the method including the steps of the application requesting a packet data stream to be established; and transmission resources being allocated to the packet data stream; and the assigned bit rate for the packet data stream being communicated back to the application.

Preferably, the bit rate at which data packets are offered by an application for transmission on a packet data stream is monitored, the method including the steps of identifying the packet data stream the packet is sent on; recording the size of each individual packet; and the number of packets sent per unit time.

In a preferred form, the application utilises multiple packet data streams simultaneously on the same physical bearer, the method further comprising the step of collectively controlling the amount of data transmitted per unit time by said application on said packet data streams such that data is not transmitted at a rate in excess of the sum of the assigned bit rate for said packet data streams. In a preferred form, a packet data stream or a group of packet data streams is monitored and controlled using a token bucket algorithm, said algorithm permitting a mean bit rate and a maximum bit rate for said packet data stream or group of packet data streams.

In a preferred form, packet data traffic is monitored and controlled after processing by the IP protocol stack and before being delivered to a link layer protocol.

In a preferred form, an application is informed that it is transmitting data packets on a packet data stream at a rate in excess of the assigned rate for said data stream.

In a preferred form, the packet data protocol is Internet Protocol version 4, or Internet Protocol version 6, or is transmitted over a UMTS network.

BRIEF DESCRIPTION OF DRAWINGS

Preferred embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 is a simplified schematic diagram of a packet data communication system showing terminals, an access network, a core network, and other packet data networks;

Figure 2 is a simplified schematic diagram of a UMTS communication system showing two mobile terminals, a radio access network, a UMTS backbone and a gateway to other IP networks;

Figure 3 is a simplified schematic of the architecture of the protocol stack of a wireless packet data communications device that supports QoS;

Figure 4 shows the different types of PDP QoS attributes for a RAB.

Figure 5 is an entity relationship diagram in UML notation showing the relationships and cardinalities of the relationships between objects involved in quality of service enabled packet data communications; Figure 6 is a message sequence chart showing the sequence of events and actions when an application running on a UMTS mobile terminal opens a QoS enabled socket;

Figure 7 is a message sequence chart showing the sequence of events and actions when a UMTS network initiates a change in the quality of service attributes of a UMTS bearer in use by a UMTS mobile terminal;

Figure 8 shows the QoSM, packet data protocol stack, packet classifier, data stream traffic policing function and UMTS protocol stack in the handset;

Figure 9 shows bandwidth allocation and subsequent policing of bitrate with an application transmitting data over a two bearers, using existing technology, when said application generates more data on one bearer than it was allocated;

Figure 10 shows bandwidth allocation and subsequent policing of bitrate with an application transmitting data over a two bearers, using the invention, when said application generates more data on one bearer than it was allocated;

Figure 11 shows bandwidth allocation and subsequent policing of bitrate with an application transmitting data over a two bearers, using existing technology, when the overall bandwidth of one of the bearers is reduced;

Figure 12 shows bandwidth allocation and subsequent policing of bitrate with an application transmitting data over a two bearers, using the invention, when the overall bandwidth of one of the bearers is reduced.

Figure 13 shows a hierarchical arrangement of token-buckets for three socket groups being policed in accordance with the invention and feeding into a single token-bucket at the bearer level. DETAILED DESCRIPTION OF PREFERRED AND OTHER EMBODIMENTS

The preferred embodiment of the present invention is applied to packet data communication terminals that are able to provide guarantees of quality of service (QoS) of packet data communications to applications executing on the terminal and the associated networks that support guaranteed QoS packet data communication.

Referring to the drawings, and in particular Figure 1, there is shown a packet data communications network 100. The network is composed of different network elements, which cooperate to provide the end-to-end connectivity. Of these elements, the packet data terminal 101 is the endpoint of communication on the network. It provides the initial point of access to the network for user applications. Each packet data terminal has at least one network address that uniquely identifies it to the network and hence allows packetised data to be sent to a specific terminal based upon this address. The packet data terminal is physically connected to the access network 105 of the packet data commvuiications network by the access link 103. The access network 105 and the access links 103 may be either wireline or wireless. The access network 105 manages terminal connectivity with its access control function 106. This function determines whether terminals are authorised to connect, the resources they are allowed for connection based upon policy, and provides accounting of the usage of terminal or access resources. It is also responsible for the resource management of the access network and providing guarantees on QoS of access links used by terminals. The access network 105 is connected by a high bit rate connection 107 to the core packet data network. Thus, one aspect of the access network is to convert between the link layer technologies of the access link to the link layer technology of the core packet data network. The core packet data network provides connectivity to a plurality of access networks and hence packet data terminals. The core packet data network also provides connectivity 109 to other packet data networks 110, and hence to packet data terminals in other networks. The core packet data network maybe QoS enabled in that it provides guarantees on, for example, the bandwidth available or the delay, for a packet data stream, between two packet data terminals. It will be appreciated that a single core packet data network may have a plurality of access networks that in turn provide access to a plurality of packet data terminals. The core packet data network may also provide connectivity to a plurality of other packet data networks. Two terminals on a packet data network communicate using a packet data protocol such as Internet Protocol version 4 (IPv4), and Internet Protocol version 6 (IPv6). This protocol prescribes how the packets are constructed and the addressing of network elements. Packets are routed between terminals of the network based upon the network address by the packet routers of the access network and the core packet data network. The packet data protocol provides independence of the underlying link layer technology such that applications requiring packet data communications need only understand the packet data protocol.

It will be appreciated that Figure 1 and the above description is an abstract view of a packet data communications network, and that many different instantiations are possible, utilising a wide range of technologies and protocols. A specific example is shown in Figure 2, which is a Universal Mobile Telecommunications System (UMTS) packet data network. The UMTS packet data network will be used throughout to provide concrete examples of prior art and also the present invention, however this in no way restricts the invention to a UMTS packet data network. The mobile terminals (MT) 121 are the endpoints of communication on the network. They are connected to the Radio Access Network (RAN) 127 via the Uu interface, which uses Wideband Code Division Multiple Access (WCDMA) technology. The RAN is composed of the so-called Node-B base stations, and the Radio Network Controller (RNC) 129 which manages the resources of the radio network. The core packet data network is effectively composed of the Serving GPRS Support Node (SGSN) 131, which provides connectivity to access networks, the UMTS backbone 133, and the Gateway GPRS Support Node (GGSN) 135, which provides interconnectivity to other IP networks 137. The UMTS backbone provides connectivity between SGSN and GGSN. The connection between MT and SGSN is known as the Radio Access Bearer (RAB) Service. The QoS of each Radio Bearer that is set up is managed by the RNC. It also performs dynamic allocation of the finite radio resources available for data transmission across the RABs across the terminals.

QoS for packet data communication means guaranteeing that the characteristics of an end-to-end application data connection will be maintained for said application data connection. These characteristics include, but are not limited to, bit rate, delay, and error rates. In order to achieve these guarantees, the network must ensure that:

data packets cany an indication of how they should be treated by the network; and resources are reserved across the network so that phenomena such as congestion are avoided; and the links of the network path that a packet is sent on have the desired characteristics such as bit error rate.

For IP networks the Internet Engineering Task Force (IETF) defined protocols DIFFSERV, INTSERV and RSVP perform these functions.

Referring now to Figure 3, there is shown a packet data communications terminal 300. Some operational units and protocol layers of the terminal are shown where required for the description of the invention. All possible operational units and protocol layers are not shown. It will also be appreciated that there could be many specific instances of protocol layers and operational units used in the terminal, wherein Figure 3, an abstraction of the protocol layer or operational unit is used. The terminal provides an execution environment for applications 311. Examples of applications which require packet data communications with other terminals or servers include, but are not limited to, email (using SMTP), web browsers (using HTTP), packetised voice (using SIP and RTP/RTCP) and streaming video (using RTSP and RTP/RTCP). Applications 311 which execute on the terminal 300 are provided access to packet data communications by the terminal's operating system using a socket application programming interface (Socket API) 310. This interface provides programmatic routines that allow an application to open a data stream for reading and/or writing between itself and another application resident on another terminal or server in the network. A second API 309 is provided to the application by the terminal's operating system through which the application can request that particular QoS attributes are guaranteed for a data stream. This is termed the quality of service application programming interface (QoS API). It is known that the Socket API and the QoS API may be combined into a single application programming interface or they maybe be separate APIs from the applications perspective. Using the QoS API the application can request that characteristics of the data stream such as the mean bandwidth, peak bandwidth, delay, error rate, etc. are set in accordance with the applications needs. For example, a video telephony application requires that the data streams it uses have a very low delay and hence would request low delay for each data stream through the QoS API.

The packet data protocol layer 308 is an implementation of packet data communications protocol on the terminal and is accessed by the application through the Socket API. There are many different packet data protocols such as Internet Protocol version 4 (IPv4), Internet Protocol version 6 (IPv6) and X.25. This protocol layer takes in data from the application via a socket and processes and formats it in accordance with the protocol. The protocol layer can provide various different types of packet data communication to the application. For example, IPv4 and IPv6 provide an unreliable datagram service using UDP and a reliable streaming service using TCP. The packet data protocol layer may also provide mechanisms for guaranteeing end-to-end quality of service. For example in IPv4 RSVP can be used to reserve resources across a network.

The line 301 divides the packet data protocol layer 308 and the link layer protocols. The link layer protocol (303 and 304) is responsible for establishing channels in the underlying physical transmission medium and for formatting and processing the packets received from the packet data protocol layer for transmission. The link layer protocol is separated into two parts, a control function 303 that is used for establishing and managing channels, setting up QoS characteristics for the channel and responding to network initiated changes in the QoS. The data function 304 performs the task of processing the packets received from the packet data protocol layer and transmitting them on to the actual physical network interface, and processing packets received from the physical network interface and transmitting them to the packet data protocol layer.

Between the packet data protocol layer and the link layer protocol sits the packet classifier 307. Its function is to map packets from the packet data protocol layer 308 on to the channels provided by the data transmission function 304. In order to do this, it needs to know from which data stream a packet originated and which data transmission channel is associated with that socket. This information is provided by the quality of service manager (QoSM) 305 over the interface 302.

The QoSM 305 provides the implementation behind the QoS API. In the prior art it is known to provide the following functions:

determine whether a data transmission channel needs to be established or whether an existing data transmission channel is to be reused in response to an application request for a specific QoS for a data stream; request the establishment of data transmission channels with the application specified QoS characteristics from the link layer control function 303; negotiate with the network the acceptable QoS characteristics for a data transmission channel; inform the application of the QoS assigned to a data stream; receive from the network any changes to the QoS characteristics of a data transmission channel; receive from the application requests for changes to the QoS characteristics of a data stream; irrform the application of network initiated changes in QoS for a data stream; interact with the packet data protocol in. establishing end-to-end QoS guarantees; inform the packet classifier of the mapping of data streams to data transmission channels; dynamically manage the association of data streams and data transmission channels such that the closest match between the application requested QoS and the available QoS in the network on a given data transmission channel is achieved at all times; assigning default QoS attributes for data streams when not specified by the application.

It uses the interface 302 to control the packet data protocol and the packet classifier. The QoS API provides a way for the application to request that a particular data stream has certain attributes, which are collectively termed the QoS Profile. In a UMTS packet data network, each bearer has values for each of these attributes:

Traffic class

Uplink maximum bit rate, Downlink maximum bit rate

Uplink guaranteed bit rate, Downlink guaranteed bit rate

Delivery order

Maximum SDU size

SDU format information

SDU error ratio

Residual bit error ratio

Delivery of erroneous SDUs

Uplink transfer delay, Downlink transfer delay

Traffic handling priority

Allocation retention priority

Source statistics descriptor

The specific set of values of the QoS attributes associated with a bearer is contained within the PDP Context. The actual values of the QoS attributes of each PDP context are controlled by the network and may be modified by the network at any time. The network manages the available resources such that each user is allocated a fair share in accordance with the network operator's policy. The application may also request at any time a modification to the QoS Profile associated with a particular data stream. The QoS attributes of the PDP context can be categorised as either:

asymmetric cumulative; or asymmetric non-cumulative; or symmetric non-cumulative.

Asymmetric attributes have independent values in the send and receive directions respectively, and they may be the same or they may be different. Symmetric attributes must take on the same value in both the send and receive directions. Non-cumulative attributes have the property that every data stream that is using the PDP context takes on the same value for that attribute. For example, the residual bit error ratio is non-cumulative as it is the same for all data streams on the same bearer. Cumulative attributes are those attributes that can be must be sub-divided between the data streams using the bearer. For example, if three data streams are sharing a single PDP context, then the guaranteed uplink bit rate of the PDP context must be shared between the data streams. The value of cumulative PDP context attributes can be changed, but this does not necessarily result in a change of said attribute for all application data streams using that PDP context. Figure 4 shows the breakdown of the PDP QoS attributes.

Referring now to Figure 5 there is shown a relationship diagram in the Unified Modelling Language (UML) notation, which illustrates the relationship between the key entities in a packet data terminal involved in IP packet data communication with QoS. An application 208 executing on a packet data terminal opens sockets to write 202 and sockets to read 322 for its transmit data streams 201 and receive data streams 321. An application can open one or more read or transmit data streams and hence read or write sockets, but only one application can use any specific socket. The operating system of the packet data terminal associates each write socket with a physical bearer downlink 203 which will be used for the transmission of packet data, and each read socket with a physical bearer uplink 323 which will be used for the reception of packet data. A single physical bearer 207 may be used to transmit or receive the data packets of one or more sockets.

An IP address identifies an endpoint of communication to the network. Each data packet contains a recipient address, which is composed of an IP address and a port number so that any packet can be first delivered to the correct terminal and secondly delivered to the correct socket and hence application on said terminal. The combination of IP address and port number is known as the transport address. Associated with each write socket 202 are a destination IP address of a remote host 205 and a port number on that remote host. Associated with each read socket 322 are an IP address on the local host 325 and a port number on the local host. Each physical bearer 207 has a set of bearer QoS attributes 206 which defines the QoS that packets transported on said bearer will receive on the uplink and downlink. For UMTS packet data this is known as the PDP context. When the application opens a socket for reading or writing it will specify the QoS it requires for that socket. The QoS manager in the packet data terminal must associate with that socket a physical bearer with the same QoS attributes specified by the application for the socket. Once the resources have been allocated to the socket, the QoS manager informs the application of the values of the QoS attributes allocated to the socket.

Referring now to Figure 6 there is shown a message sequence chart of the prior art for an application 210 executing on a UMTS mobile terminal 219 opening a QoS enabled IP data stream for communication with a server 215 in the packet network. Firstly, the application 210 requests the QoS Manager 211 to create a connection with the required QoS attributes in the UMTS network 221. This triggers the QoS manager to request the UMTS protocol stack 213 in the MT to establish a PDP context whose QoS attributes correspond to those requested by the application 222. The UMTS protocol stack creates an Activate PDP Context Request 223 and sends it to the UMTS network 214. The UMTS network responds with a positive acknowledgement 224 and the PDP context is established in the network. This acknowledgement is received by the UMTS stack, which forwards it 225 to the QoS manager. With the PDP context now set up and hence also the UMTS bearer, the QoS manager can now open the end to end IP connection with the server through the IP stack 226. The details of the TCP/IP protocol exchange 227 are not shown. When completed, the IP stack acknowledges positively to the QoS manager 228, which then provides the application with a reference to the socket 229. End-to-end QoS can be established by the QoS manager once the PDP context and associated RAB has been established, but before returning the socket reference to the application. Further detailed information is available in the Third Generation Partnership Project (3 GPP) technical specifications TS23.107 and TS23.207.

Referring now to Figure 7 there is shown a message sequence chart of the known art for a network-initiated change in the QoS of a UMTS bearer. The SGSN 121 detects a need to modify the QoS attributes of a PDP context 231, possibly due to cell loading for example. It instructs 232 the Radio Access Network.127 to modify the Radio Access Bearer in accordance with the new QoS attributes supplied 233. Once the RAN has completed and informed the SGSN 234, the SGSN requests that the GGSN that the PDP context of the UMTS bearer is updated 235. The GGSN updates its internal memory 236, and then signals the change 237, 238 to the Mobile Terminal 219 via the SGSN. The QoS Manager 211 in the MT handles the PDP context modification message and updates its internal memory of the PDP context for that bearer to reflect the change in QoS 239. It acknowledges the PDP context modification back to the network 241. The QoS manager then determines which applications have data streams that are affected by the PDP context change and informs them of the new settings in turn 242, 243, 244. Finally, if any application's data streams were assigned to a new PDP context, then the Traffic Flow Template in the GGSN must be updated 245.

The present invention provides a method and apparatus to multiplex packetised data from an application on to multiple bearers such that the data on each bearer from a given application is guaranteed its share of the available bandwidth.

In 3G wireless systems it will be common for applications to utilise multiple radio access bearers (RABs) for their data streams, and also for several applications to utilising a single RAB. The QoS Manager (QoSM) is the entity responsible for managing how the bandwidth on each of these bearers is apportioned between the applications sharing said bearer. The QoSM can determine each applications share of the bandwidth on each bearer by a variety of techniques such as:

Allocating an equal share for each application using a given bearer; or

Allocation based upon application request; or

Allocation based upon a QoS policy.

The QoSM is also responsible for determining how each application's share should change when a modification in bearer bandwidth is received from the network or when an application closes a data stream, which can also be done using the techniques described above.

It is the object of the present invention to perform policing of bandwidth usage by applications on each packet data stream such that the bandwidth guarantees made by the QoSM to the applications can be enforced. Throughout, the token bucket algorithm is used as an example of a policing mechanism. It will be appreciated by those skilled in the art that there are many other techniques and algorithms that can be used for policing packet data transmission besides the token bucket approach, and the invention is in no way restricted to the token bucket approach.

When the token bucket packet policing algorithm is employed with the present invention, each application data stream will be constrained to work within the mean and peak data rates assigned by the QoSM. Figure 8 shows how the data stream traffic policing function (Packet Policer 313) is incorporated into a UMTS packet data protocol stack. It is located below the packet classifier, whose function is to map data packets to bearers, and above the UMTS stack. It controls how packets originating from different write sockets are delivered to each bearer.

When a data stream is created, the QoSM will assign to each transmit data stream a token bucket, and return to the application the buckets parameters, namely:

token rate, (corresponds to the monitored Maximum bitrate/Guaranteed bitrate). bucket size, (the upper bound of the number of tokens allowed in the bucket, corresponds to bounded burst size).

The data stream layer token bucket mechanism is of course in addition to the UMTS bearer level token bucket mechanism implemented as Traffic Policing 314 in Figure 8. Conceptually the transmit data stream buckets police on the level of an individual data stream and then feed into the UMTS bearer token bucket. According to the prior art, International patent application WOOO/36793, the policing of the bandwidth usage is done at the granularity level of the application by the packet policer 313. When all transmit data streams for a given application are sent over a single bearer this approach is sufficient. However when an application uses more than one bearer this method breaks down. In Figure 9, two applications A and B share a single bearer RABo 400. Each has opened a single transmit data stream. Furthermore, application B is using an additional bearer R-ABi over which it has an additional transmit data stream 401. Both transmit data streams of application B have the same allocated bandwidth so the same token bucket mechanism can be used for both in the packet policer 313. At some time later, tAFTER, application B tries to use too much bandwidth over RAB₀ 402. Consequently the output packets actually transmitted from application B will be reduced by the packet policer 313. This results in a certain amount of the data written by application B being discarded. However since the packet policer only works at the granularity level of the application, all packets written by application B will be subject to reduction in proportion to the overall excess of data written by application B (ie. reduced by br_B(tBEF0RE)/br_B(tAFTER))- Consequently, there is not sufficient reduction 403 in the data from application B written to RABo while data sent over RABi will be unnecessarily reduced by the same fraction 404.

In Figure 10 the same scenario occurs but in this case the packet policer 313 is based on the invention. In this case, the granularity level is not the application, but individual transmit data stream. Consequently, the transmission of the transmit data stream over RABo is reduced 403, but the transmit data stream over RABi is unaffected 405.

Another scenario which illustrates the problem with the prior art is shown in Figure 11, where two applications A and B share a single bearer RABo 400. Each has opened a single transmit data stream. Furthermore, application B is using an additional bearer RABi over which it has an additional transmit data stream 401. Both transmit data streams of application B have the same allocated bandwidth so the same token bucket mechanism can be used for both in the packet policer 313. The bandwidth is policed according to the prior art, such that policing is performed for the application, and not for each application data stream. At some time later, tAFTER, the total bandwidth available on RAB₀ 405 is reduced by the network by a certain amount. In turn the packet policing applied to each application is reduced by the same fraction, such that bandwidth allowed for application A and application B on RABo 405, cannot exceed the capacity of RAB₀ 405. However, this also results in the available bandwidth on RABi 406 being under-utilised, because the packet policer 313 has reduced the total bandwidth allowed for application B, in accordance with the bandwidth change that occurred on RAB₀ 405. Because the packet policer 313 is policing at the application level, it is unable to police bandwidth usage effectively when an application has multiple data streams across multiple RABs.

In Figure 12 the same scenario occurs but in this case the packet policer 313 is based on the invention. In this case the granularity level is not the application, but individual transmit data stream. Consequently the transmission by application B at time tAFTE of the transmit data stream over RABo is reduced 405, but the transmit data stream over RABi is unaffected 407. Thus the invention provides effective policing of bandwidth usage with efficient use of transmission resources.

Referring now to Figure 13, a simplified schematic of an arrangement of the invention is presented for a UMTS terminal. The example shows one data streams SI 441 being used by one application Al 451, and two data streams S2 442 and S3 443 that are being used by one application A2 452. Application Al 451 uses SI 441 to send data packets to another device in the network using a Radio Access Bearer RABI 448. Application A2 452 uses S2 442 and S3 443 to send data packets to another device on the network using two Radio Access Bearers RABI 448 and RAB2 449. When a data packet is written to one of these streams it passes from the application into the operating system of the terminal via the socket interface 421. With the present invention, the packets are then processed by an individual packet policing function associated with the each of the data streams used by the application. For SI 441 this is Data Stream Policer 444, for S2 442 this is Data Stream Policer 450 and for S3 443 this is Data Stream Policer 446. The packets are then passed to the lower level RAB Packet Policer 447 for RABI 448 and RAB Packet Policer 445 for RAB2 449. The RAB Packet Policers are contained within the UMTS. The policing function at this level ensures that the limits on bandwidth specified by the network are not exceeded. If the packet passes the policing function, it is transmitted on the RAB 448 or RAB 449. The QoSM ensures that the total allocated bandwidth to all data streams on a RAB does not exceed the bandwidth of that RAB. So referring to Figure 13:

o BGsi + BGs_ = BG ABI o BMsi + BM_S2 = BMRABI

o BM_S3 = BMRAK

The embodiment shown in Figure 13 uses a token bucket algorithm for policing the bandwidth at both the data stream level and the RAB level. The token bucket algorithm works by adding to the bucket a constant number of tokens per unit time. Each token represents the ability to transmit the amount of data represented by the token per unit time. The bucket has a maximum size and attempts to add additional tokens to a full bucket do not succeed. When data packets are transmitted, a corresponding number of tokens are removed from the bucket. Thus the maximum burst bit rate allowed by the token bucket algorithm is equal to the bucket size. The guaranteed steady bit rate allowed by the token bucket algorithm is equal to the rate at which tokens are added to the bucket. Thus in order for a packet to be accepted for transmission by a token bucket policing function there must be sufficient tokens in the bucket. If there are not enough tokens available, then the data packet may either be queued until enough tokens have accrued in the bucket or it may be discarded. RABI 448 and RAB2 449 themselves are assigned both a guaranteed bandwidth BGRAM/BGRA_K and a maximum bandwidth BMRAEI/BMRAB₂ by the network at which data can be transmitted. The RAB packet policers 447 and 445 employ a token bucket algorithm, with a token rate RRABI/RRAB₂ and a bucket size B_RABI, BRAB₂ to ensure that these limits are not exceeded. When each data stream is created, it is assigned, by the QoSM, a fraction of the bandwidth available on the RAB and so each data stream has a guaranteed bandwidth (BG_Sι, BG_S2, BG_S3) and a maximum bandwidth (BMsi, BM_S2, BM_S3). This is policed by the associated data stream policer (444, 450, 446) using a token bucket where the token rate (Rsi, Rs₂, Rs₃), and the bucket size (B_Sι, Bs₂, B_S3), correspond to the guaranteed and maximum bandwidth respectively for the data stream. Any packet offered for transmission on the packet data stream must pass through the data stream packet policer and hence packets offered for transmission to the RAB are conformant with the bandwidth allocated by the QoSM. In this way the invention provides two levels of policing. In addition to the known policing at the RAB level, each application packet data stream is also policed to ensure fair usage of shared transmission resources amongst said packet data streams.

It will be appreciated that the invention can be applied to any type of packet data network and is not limited to wireless packet data networks such as UMTS

Claims

1. A method of monitoring and controlling the usage of the transmission resources allocated to applications executing on a device in a packet data communications network, wherein an application utilises multiple packet data streams on different physical bearers simultaneously, the method comprising individually controlling the amount of data transmitted per unit time by said application on each packet data stream such that data is not transmitted at a rate in excess of the assigned bit rate for each packet data stream.

2. A method as claimed in claim 1 in which each packet data stream of said application is assigned an individual bit rate at which data packets can be transmitted; in which an actual bit rate at which the application offers data packets for transmission on each packet data stream is monitored; and in which data packets offered for transmission on each packet data stream by the application that would cause the assigned bit rate for said packet data stream to be exceeded, are delayed or discarded.

3. A method according to claim 2, in which said application requesting a packet data stream to be established; transmission resources are allocated to said packet data stream; and the assigned bit rate for said packet data stream is communicated back to the application.

4. A method according to claims 2 or 3, including the steps of identifying the packet data stream each packet is sent on; and recording the size of each individual packet and the number of packets sent per unit time.

5. A method according to any preceding claim, wherein an application utilises multiple packet data streams simultaneously on the same physical bearer, the method further comprising the step of collectively controlling the amount of data transmitted per unit time by said application on said packet data streams such that data is not transmitted at a rate in excess of the sum of the assigned bit rate for said packet data streams.

6. A method according to any preceding claim, wherein a packet data stream or a group of packet data streams is monitored and controlled using a token bucket algorithm, said algorithm permitting a mean bit rate and a maximum bit rate for said packet data stream or group of packet data streams.

7. A method according to any preceding claim, characterised in that packet data traffic is monitored and controlled after processing by the IP protocol stack and before being delivered to a link layer protocol.

8. A method according to any preceding claim, comprising the step of informing an application that it is transmitting data packets on a packet data stream at a rate in excess of the assigned rate for said data stream.

9. A method according to any preceding claim characterised in that the packet data protocol is Internet Protocol version 4.

10. A method according to any preceding claim characterised in that the packet data protocol is Internet Protocol version 6.

11. A method according to any preceding claim characterised in that the packet data is transmitted over a UMTS network.

12. A data communications device comprising means for monitoring and controlling the usage of the transmission resources allocated to applications executing on said device in a packet data communications network, said device further comprising means for an application to utilise multiple packet data streams simultaneously on different physical bearers, and filter means to individually control the amount of data transmitted per unit time by said application on each packet data stream such that data is not transmitted at a rate in excess of the assigned bit rate for each packet data stream.

13. A data communications device as claimed in claim 12 comprising means to assign a bit rate at which data packets can be transmitted to a packet data stream of an application; and means to monitor the actual bit rate at which said application transmits data packets in said packet data stream; and filter means to delay or discard data packets offered for transmission on a packet data stream by said application that would cause the assigned bit rate for said packet data stream to be exceeded.

14. A data communications device according to claim 13 in which the means for assigning said bit rate at which data packets are transmitted to a packet data stream, further comprises means for the application to request a packet data stream to be established and means for the assigned bit rate for the packet data stream to be communicated back to the application once transmission resources are allocated to said packet data stream.

15. A data communications device according to claim 13 or 14 in which said means for monitoring the bit rate at which data packets are offered by said application for transmission on packet data stream, further comprises means for identifying the packet data stream the packet is sent on; and means for recording the size of each individual packet; and the number of packets sent per unit time.

16. A data communications device according to any of claims 12 to 15 comprising means for an application to utilise multiple packet data streams simultaneously on the same physical bearer, the data communications device further comprising means to collectively control the amount of data transmitted per unit time by said application on said packet data streams such that data is not transmitted at a rate in excess of the sum of the assigned bit rate for said packet data streams.

17. A data communications device according to any of claims 12 to 16 in which the filter means for a packet data stream or a group of packet data streams comprises a token bucket algorithm, said algorithm permitting a mean bit rate and a maximum bit rate for said packet data stream or group of packet data streams.

18. A data communications device according to any of claims 12 to 17 in which the filter is located after an IP protocol stack and before a link layer protocol.

19. A data communications device according to any of claims 12 to 18 comprising means for informing an application that it is transmitting data packets on a packet data stream at a rate in excess of the assigned rate for said data stream.

20. A data communications device according to any of claims 12 to 19 which comprises means for providing packet data communications using Internet Protocol version 4.

21. A data communications device according to any of claims 12 to 19 which comprises means for providing packet data communications using Internet Protocol version 6.

22. A data communications device according to any of claims 12 to 21 which comprises means for transmitting data packets over a UMTS network.

23. A computer program product for carrying out method of monitoring and controlling the usage of the transmission resources allocated to applications executing on a device in a packet data communications network, wherein an application utilises multiple packet data streams on different physical bearers simultaneously, the method comprising individually controlling the amount of data transmitted per unit time by said application on each packet data stream such that data is not transmitted at a rate in excess of the assigned bit rate for each packet data stream.