GB2386283A

GB2386283A - Packet data communications network

Info

Publication number: GB2386283A
Application number: GB0205106A
Authority: GB
Inventors: Simon Charles Durrant; John David Ainsworth
Original assignee: PA Consulting Services Ltd
Current assignee: PA Consulting Services Ltd
Priority date: 2002-03-05
Filing date: 2002-03-05
Publication date: 2003-09-10
Also published as: GB0205106D0; AU2003209472A1; WO2003075522A1

Abstract

The usage of allocated transmission resources by applications 501, 502 executing in a device in a packet data communications network are optimised by an application specifying to a quality of service manager function that two or more packet data streams 521-529 have the same quality of service requirements as regards non-cumulative quality of service requirements, and the quality of service manager function manages said packet data streams 521-529 as a packet data stream group in accordance with said non-cumulative quality of service requirements, and in accordance with the totality of a cumulative quality of service requirement, such as bandwidth of all said packet data streams 521-529 in said packet data stream group. May be applied to Packet Data Protocol (PDP) attributes in a UMTS system.

Description

PACKET DATA COMMUNICATIONS NETWORKS FIELD OF THE INVENTION The present invention relates to packet data communications networks, and more particularly, to providing applications that send and receive packet data the means to manage their transmission resources effectively.

The invention has been developed primarily for mobile wireless communications networks such as GPRS and 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 (QoS) 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 QoS provided by that connection. At the radio layer, for each PDP context a separate Radio Access Bearer (RAB) is established, with the QoS 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 QoS 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 QoS 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 QoS 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.

A socket can be opened for an application with a defined set of QoS attributes, and the QoSM may assign two or more sockets owned by the same application to the same PDP context, but the QoSM is unable to identify that these sockets are owned by the same application. As a consequence, each socket retains an individual QoS policy profile, which defines its QoS attributes, and is managed independently by the QoSM. This can mean that the QoSM allocates bandwidth to data streams inappropriately from the applications point of view, because the QoSM does not know the relative priorities of the data streams to the application that owns them.

SUMMARY OF INVENTION According to a first aspect, the present invention provides a method of optimising usage of allocated transmission resources by applications executing in a device in a packet data communications network, said device including a method of optimising the usage of allocated transmission resources by applications executing in a device in a packet data communications network, said device including a quality of service manager function; characterised in that an application can specify to the quality of service manager function that two or more packet data streams have the same quality of service requirements as regards non-cumulative quality of service requirements; and the quality of service manager function manages said packet data streams as a packet data stream group in accordance with said non-cumulative quality of service requirements, and in accordance with the totality of a cumulative quality of service requirement of all said packet data streams in said packet data stream group.

According to a second aspect, the present invention provides a data communications device adapted to optimise the usage of allocated transmission resources by applications executing on said device in a packet data communications network, said device including a quality of service manager, characterised in that the device further comprises means for an application to specify that two or more packet data streams have the same quality of service requirements as regards non-cumulative quality of service requirements; and means for said quality of service manager to manage said packet data streams as a packet data stream group in accordance with said non-cumulative quality of service requirements, and in accordance with the totality of a cumulative quality of service requirement of all said

packet data streams in said packet data stream group.

In a preferred embodiment, the application includes a packet group identifier in each request to the Quality of Service Manager function for the packet data streams that are to exist in the same packet data stream group.

In a preferred embodiment a packet group identifier is associated with a set of Quality of Service parameters.

In a preferred embodiment, the Quality of Service Manager function allocates resources in dependence of the Quality of Service parameters associated with the packet group identifier.

Preferably, the application specifies a range of values for each Quality of Service parameter.

In a preferred embodiment the Quality of Service Manager informs the application owner of a packet data stream group of the totality of the resources available to said packet data stream group.

Preferably, the application specifies the Quality of Service attributes for a packet data stream group and receives a corresponding packet group identifier.

In a preferred form, the application can open two or more packet data streams with a single request to the Quality of Service Manager function, the method includes the steps of specifying the number of packet data streams to be opened ; and specifying the totality of the bandwidth required for all packet data streams.

Preferably the packet data streams can be either read or write streams.

In a preferred embodiment, the device is a mobile terminal attached to a UMTS packet data network.

In a preferred embodiment, the device is a mobile terminal attached to a GPRS packet data 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 an application with two sockets open on a single bearer, where each socket has it's own independent QoS attributes ;

Figure 9 shows an application with two write sockets open on a the uplink of a single bearer, where the two sockets have common QoS attributes; Figure 10 shows an application with two write sockets open on the uplink of a single bearer, where the two sockets have common QoS attributes, as a message sequence diagram. This is the same scenario as in; Figure 11 shows an application with two read sockets open on the downlink of a single bearer, where the two sockets have common QoS attributes, as a message sequence diagram; Figure 12 is an entity relationship diagram in UML notation showing the relationships and cardinalities of the relationships between objects involved in QoS enabled packet data communications when using the present invention; Figure 13 illustrates the relationships between applications, data streams, QPPs and PDP contexts using existing technology. A QoS profile is associated with each data stream; illustrates the relationships between applications, data streams, QPPs and PDP contexts when employing the present invention.

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 communications 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 I 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 carry 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 ; - inform 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 fornat 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 (3GPP) 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.

In the prior art, a data stream can be opened for an application with a defined set of QoS attributes, and the QoSM may assign two or more data streams owned by the same

application to the same PDP context, but the QoSM is unable to identify that these data streams are owned by the same application. As a consequence, each data stream retains an individual QoS Policy Profile (QPP) and is managed independently by the QoSM. This can mean that the QoSM allocates bandwidth to data streams inappropriately from the applications point of view, because the QoSM does not know the relative priorities of the data streams to the application.

For example, consider the case, as in Figure 8, where a conversational video application AV 603 has two transmit data streams, and hence two write sockets SAV1 604 and SAV2 605 open on a single PDP context 601. The video application 603 is using SAV1 604 to send the video data and SAV2 605 to send the audio data. The QoSM treats SAV1 and SAV2 as independent entities, each with its own QPP, 608 and 609 respectively, as it does not know that they belong to the same application. Now consider a network-initiated change in the uplink bandwidth of the UMTS bearer. This reduces the bandwidth at time tAFTER of PDPO 602. The QoSM must now reduce the bandwidth allocated to the transmit data streams on the uplink of the bearer. The fairest scheme from the QoSM's point of view is to simply decrease the bandwidth of each of SAV1, SAV2 by the same fraction.

The end result of this modification at time tAFTER, is shown as SAV1 606 and SAV2 607 are reduced by the same fraction.

However, this may not be the best approach from the point of view of AV. For optimal results AV may wish to reduce the allocated bandwidths on SAV1 and SAV2 by different fractional amounts. For example it maybe be deemed beneficial to maintain good audio quality when at all possible, irrespective of how much the video quality may deteriorate.

If the QoSM treated SAV I and SAV2 as belonging to the same application and did not try to impose an individual bandwidth on each one, then the application AV can preferentially control the codec such that the combined output bit rate of the audio and video does not exceed the total bandwidth allocated to AV on the uplink of the bearer, and maximally utilises the available bandwidth. This is shown in Figure 9.

Figure 9 shows the same video application AV 603 with two write sockets SAV1 614 and SAV2 615 open on a single PDP context PDPO 621. The entire bandwidth of PDPO is available to AV 603. The QoSM manages SAV1 614 and SAV2 615 as a single entity and they have a combined QoS policy profile QPPAV 618. This combined QPP contains the sum of the bandwidth required for SAV1 614 and SAV2 615. A network initiated change in the bandwidth allocated to PDPO occurs at time tAFrER and the new bandwidth allocation to PDPO at this time is shown as 622. Since the QoSM is now managing SAV1 616 and SAV2 617 as a single entity, it does not need to determine how the reduction in bandwidth affects each data stream individually. The QoSM simply informs the application AV 603 of the reduction in available bandwidth for the data stream group comprising SAV1 616 and SAV2 617 whose QoS attributes are specified by QPPAV 619. The application is free to choose how much of the available bandwidth BRpDPo is allocate to SAV1 616 and SAV2 617, and does not have a bandwidth allocation imposed on it by the QoSM. In this example AV 603 has chosen that the total bandwidth reduction be borne by SAV 1 616. Figure 10 shows the same scenario as in Figure 9 described as a message sequence chart.

It should be noted that data stream groups can group together either transmit data streams which are carried on the uplink of a particular bearer (as in the previous example), or of receive data streams which are carried on the downlink of a particular bearer. Figure 11 is a similar message sequence chart to that in Figure 10 only in this case the video application AV 703 is receiving data from a transmitter 704 over two read sockets SAV1 714 and SAV2 715, received over the downlink of a bearer. When there is a network initiated change 720 at tAFTER the QoSM informs AV 703 of the reduction of available bandwidth for the data stream group comprising SAV1 714 and SAV2 715. AV 703 then notifies the transmitter 704, which chooses how the reduction in bandwidth should be borne between SAV1 716 and SAV2 717. As in the previous case all the bandwidth reduction is borne by SAV1 716.

It is a feature of the present invention that an application can specify that two or more packet data streams have the same QoS requirements and should utilise a common bearer, and where two or more packet data streams belonging to the same application are using the

same bearer, the QoSM will treat them as a single entity for the purpose of managing the transmission resources allocated to them.

This is advantageous since it is the application that is best able to decide how the bit rate that it has been allocated on any particular uplink or downlink of a bearer should be sub-divided between the data streams using that bearer. It is noted that bandwidth, unlike the other QoS parameters in UMTS, is not the same for all data streams which share a particular uplink or downlink of a bearer. For instance, all data streams on the same uplink or downlink of a bearer are subjected to the same bit error rate. However, the bandwidth of the uplink or downlink of the bearer can be arbitrarily allocated to the individual data streams.

In a preferred embodiment, the application will use a programmatic interface to request from a QoSM a unique identifier that it will use to identify a data stream group to the QoSM throughout the data stream groups existence. In the remaining text this is referred to as a packet group identifier. Associated with this identifier is a QPP, which defines a common set of transmission parameters for all packet data streams in the group. This extends the apparatus and method of the QoS API in that it allows an application to specify a data stream group in which a new packet data stream should be placed, and allows the QoSM to allocate the required resources correctly. Figure 12 illustrates the relationship between data stream groups and QPPs. Each data stream group 712 and 722 has associated with it a unique QPP 714 and 724. Data stream group 712 contains one or more transmit data streams 711 to be placed on the uplink of a bearer 701. Data stream group 722 contains one or more receive data streams 721 to be placed on the downlink of a bearer 701.

It is a feature of the present invention that when a request for a new packet data stream and the associated resources is made by an application to the QoSM through the QoS API, and the application specifies an existing data stream group for the new packet data stream, the QoSM will determine the additional bandwidth required for the new packet data stream. It will then request the allocation of more bandwidth for the affected PDP from the network or if more bandwidth cannot be obtained, existing bandwidth may be reallocated. In the

case where their are sufficient resources available for the new packet data stream, the QoSM will add the new packet data stream into the specified packet data stream group, and subsequently only manage their transmission resources as a single packet data stream with a single set of QoS attributes. The packet data streams themselves are still uniquely identified by their transport addresses (IP address and port number), and it is only their transmission resources that are managed as a single entity. The single entity created by the QoSM is termed a data stream group.

In a preferred embodiment, the QoSM will determine the values for the bandwidth of a data stream group from the summation of the values for the bandwidth of the constituent parts of said data stream group.

It is a feature of the present invention that the QoSM informs the application of the transmission resources allocated to said data stream group. The QoSM will inform the application which owns the data stream group whenever a change in the QoS resources allocated to the data stream group occurs, such that the application can use this information to adjust its behaviour accordingly.

In an preferred embodiment, the QoS API is extended such that an application can request the QoSM to create a data stream group by specifying the transport addresses for each socket but specifying a single set of QoS attributes.

In a preferred embodiment, the QoSM can create a data stream group by: - combining the newly requested packet data stream with an existing packet data stream; or - combining the newly requested packet data stream with an existing data stream group; or - combining the newly requested data stream group with an packet data stream; or - combining the newly requested data stream group with an existing data stream group.

In one embodiment, the application determines how the bandwidth allocated to a data stream group by the Q08M is allocated to each individual data stream within the data stream group. The application can change the allocation to each individual data stream at any time, but will always ensure that the sum of the bandwidth allocated to each data stream does not exceed the bandwidth available to the data stream group. Also, when a change in the bandwidth allocated to said data stream group occurs, such as when the network reduces the bandwidth available to a bearer, then the application can determine how each individual packet data stream is affected.

Referring now to Figure 13, which shows the relationship between applications, data streams, QPPs and PDP contexts when each data stream is treated independently, as in the prior art. In the example all data streams are of the transmit type. There are two applications Al (501) and A2 (502) executing concurrently on a UMTS mobile terminal and both are engaging in packet data communications. Al (501) has two data streams Sl (521) and S2 (522) open on PDP Context 1 (503) and three data streams S3-S5 (523,524, 525) bound on to PDP Context 2 (504). A2 (502) has two data streams S6 (526) and S7 (527) open on PDP Context 1 (503) and another two data streams S8 (528) and S9 (529) bound on to PDP Context 2 (504). Each data stream S1-S9 (521,522, 523,524, 525,526, 527,528, 529) is given a single QoS profile QPP1-QPP9 (511,512, 513, 514,515, 516, 517,518, 519) by the Q08M and is consequently managed independently in terms of their resource allocation.

Figure 14 shows the same relationships when the present invention is employed. Al (501) has two data streams Sl (521) and S2 (522) open on PDP Context 1 (503) and three data streams S3-S5 (523,524, 525) bound on to PDP Context 2 (504). A2 (502) has two data streams S6 (526) and S6 (527) open on PDP Context 1 (503) and another two data streams S8 (528) and S9 (529) bound on to PDP Context 2 (504). A group of data streams, S1-S2 or S3-S5 or S6-S7 or S8-S9, which all belong to the same application Al or A2, and are using the same PDP context, are given a single QoS policy profile QPP1 (531) and QPP2 (532) and QPP3 (533) and QPP4 (534) respectively, by the QoSM. The application still uses each data stream individually for writing data, and the application itself manages the

bandwidth for each data stream in a group, but the QoSM manages the QPP, representing a group of data streams.

In a preferred embodiment of the present invention, the socket creation function of the programmatic interface that applications use to request packet data streams is extended so that a data stream group identifier is passed to the QoSM as part of the API. Each socket is created separately, in that it has a unique transport address, however, all sockets created with the same data stream group identifier have a common PDP context, and the QoSM manages the totality of their transmission resources as if they were a single entity. Since the sockets were assigned to a common PDP context, then they have by definition the same set of QoS attributes with the exception of the bit rates, which must be summed by the QoSM so that the total is equal to that assigned to the application. All the sockets within a socket group are either of type read or type write only.

In a preferred embodiment of the present invention the socket creation function of the programmatic interface that applications use to request packet data streams is extended so that the Socket API incorporate a new socket creation function that permits an application to open multiple sockets, to read or write, and pass a single data stream group identifier.

The application would specify the source and/or destination address for each socket to the QoSM, which would then bind the sockets to a common PDP context.

If an application has multiple sockets, in one direction, with a common QPP, which the QoSM has assigned to a common PDP context, then if this PDP context is changed, for example reduction in bandwidth, then the QoSM will inform the application that a new reduced bit rate is available for that QPP.

The invention gives an application more freedom to manage bandwidth on an uplink or downlink bearer in the most effective way, rather than the QoSM trying to guess what is best for the application.

Claims

CLAIMS 1. A method of optimising the usage of allocated transmission resources by applications executing in a device in a packet data communications network, said device including a quality of service manager function ; characterised in that an application can specify to the quality of service manager function that two or more packet data streams have the same quality of service requirements as regards non-cumulative quality of service requirements; and the quality of service manager function manages said packet data streams as a packet data stream group in accordance with said non-cumulative quality of service requirements, and in accordance with the totality of a cumulative quality of service requirement of all said packet data streams in said packet data stream group.
2. The method as claimed in claim 1 in which the data transmitted in each packet data stream in a packet data stream group is managed by the respective application so that the cumulative quality of service requirement is not exceeded.
3. The method as claimed in claim 1 in which the data transmitted by a server to said application on each packet data stream in a packet data stream group is managed by said server so that the cumulative quality of service requirement is not exceeded.
4. A method of optimising the usage of allocated transmission resources by applications executing in a device in a packet data communications network, said device including a quality of service manager function; characterised in that: an application can specify to the quality of service manager function that two or more packet data streams have the same quality of service requirements; and the quality of service manager function manages said packet data streams as a packet data stream group in accordance with the combined resources of all the packet data streams in the group; each packet data stream group being allocated a unique packet data stream group identifier.
5. A method according to any preceding claim, in which the application includes a packet group identifier in each request to the quality of service manager function for packet

<Desc/Clms Page number 22>

data streams that are to exist in the same packet data stream group.
6. A method according to any preceding claim, including the step of associating with a packet group identifier a set of quality of service parameters.
7. A method according to any preceding claim, including the step of allocating transmission resources in dependence on the quality of service parameters associated with the packet group identifier.
8. A method according to any preceding claim, in which the application specifies a range of values for each quality of service parameter.
9. A method according to any preceding claim, including the step of informing the application owner of a packet data stream group of the totality of the resources available to said packet data stream group.
10. A method according to any preceding claim, in which the application specifies the quality of service attributes for a packet data stream group and receives a packet group identifier.
11. A method according to any preceding claim, in which the application opens two or more packet data streams with a single request to the quality of service manager function; the number of packet data streams to be opened is specified; and the totality of the bandwidth required for all packet data streams is specified.
12. A method according to any preceding claim, wherein the packet data streams are either read or write streams.
13. A data communications device adapted to optimise the usage of allocated transmission resources by applications executing on said device in a packet data communications network, said device including a quality of service manager, characterised in that the device further comprises means for an application to specify that two or more packet

<Desc/Clms Page number 23>

data streams have the same quality of service requirements as regards non-cumulative quality of service requirements; and means for said quality of service manager to manage said packet data streams as a packet data stream group in accordance with said non-cumulative quality of service requirements, and in accordance with the totality of a cumulative quality of service requirement of all said packet data streams in said packet data stream group.
14. A data communications device as claimed in claim 13 comprising means for said application to manage the data transmitted in each packet data stream in each packet data stream group so that the cumulative quality of service requirement is not exceeded.
15. A data communications device as claimed in claim 13 comprising means for a server to manage the data transmitted to said application on each packet data stream in a packet data stream group so that the cumulative quality of service requirement is not exceeded.
16. A data communications device adapted to optimise the usage of allocated transmission resources by applications executing on said device in a packet data communications network, said device including a quality of service manager, the device further comprising means for an application to specify that two or more packet data streams have the same quality of service requirements; means for said quality of service manager to manage said packet data streams as a. packet data stream group in accordance with the combined resources of all the packet data streams in the group; and means for the quality of service manager to give each packet data stream group a unique packet data stream group identifier.
17. A data communications device according to any of claims 13 to 16 in which said means for an application to specify quality of service requirements includes a packet group identifier in each request to the quality of service manager function for packet data streams that are to exist in the same packet data stream group.

<Desc/Clms Page number 24>
18. A data communications device according to any one of claims 13 or 17 comprising means for associating with a packet group identifier a set of quality of service parameters.
19. A data communications device according to any one of claims 13 to 18 in which the quality of service manager allocates resources in dependence on the quality of service parameters associated with the packet group identifier.
20. A data communications device according to any one of claims 13 to 19 in which the application specifies a range of values for each quality of service parameter.
21. A data communications device according to any one of claims 13 to 20 in which the quality of service manager informs the application owner of a packet data stream group of the totality of the resources available to said packet data stream group.
22. A data communications device according to any one of claims 13 to 21 in which an application specifies the quality of service attributes for a packet data stream group and receives a corresponding packet group identifier.
23. A data communications device according to any one of claims 13 to 22 in which an application opens two or more packet data streams with a single request [to the quality of service manager function], the device further comprising means for specifying the number of packet data streams to be opened and specifying the totality of the bandwidth required for all packet data streams.
24. A data communications device according to any one of claims 13 to 23 in which the packet data streams are either read or write streams.
25. A data communications device according to any one of claims 13 to 24 which is a mobile terminal attached to a UMTS packet data network.

<Desc/Clms Page number 25>
26. A data communications device according to any one of claims 13 to 25 which is a mobile terminal attached to a GPRS packet data network.