GB2386282A - Allocating shared resources in a packet data communications network - Google Patents

Allocating shared resources in a packet data communications network Download PDF

Info

Publication number
GB2386282A
GB2386282A GB0205105A GB0205105A GB2386282A GB 2386282 A GB2386282 A GB 2386282A GB 0205105 A GB0205105 A GB 0205105A GB 0205105 A GB0205105 A GB 0205105A GB 2386282 A GB2386282 A GB 2386282A
Authority
GB
United Kingdom
Prior art keywords
application
packet data
transmission
resources
data stream
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
GB0205105A
Other versions
GB0205105D0 (en
Inventor
Simon Charles Durrant
John David Ainsworth
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
PA CONSULTING SERVICES
PA CONSULTING SERVICES Ltd
Original Assignee
PA CONSULTING SERVICES
PA CONSULTING SERVICES Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by PA CONSULTING SERVICES, PA CONSULTING SERVICES Ltd filed Critical PA CONSULTING SERVICES
Priority to GB0205105A priority Critical patent/GB2386282A/en
Publication of GB0205105D0 publication Critical patent/GB0205105D0/en
Publication of GB2386282A publication Critical patent/GB2386282A/en
Application status is Withdrawn legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic or resource management
    • H04W28/16Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/24Negotiating SLA [Service Level Agreement]; Negotiating QoS [Quality of Service]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic regulation in packet switching networks
    • H04L47/10Flow control or congestion control
    • H04L47/14Flow control or congestion control in wireless networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic regulation in packet switching networks
    • H04L47/70Admission control or resource allocation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic regulation in packet switching networks
    • H04L47/70Admission control or resource allocation
    • H04L47/76Reallocation of resources, renegotiation of resources, e.g. in-call
    • H04L47/762Reallocation of resources, renegotiation of resources, e.g. in-call triggered by the network
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic regulation in packet switching networks
    • H04L47/70Admission control or resource allocation
    • H04L47/80Actions related to the nature of the flow or the user
    • H04L47/801Real time traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic regulation in packet switching networks
    • H04L47/70Admission control or resource allocation
    • H04L47/80Actions related to the nature of the flow or the user
    • H04L47/803Application aware
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic regulation in packet switching networks
    • H04L47/70Admission control or resource allocation
    • H04L47/80Actions related to the nature of the flow or the user
    • H04L47/805QOS or priority aware
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic regulation in packet switching networks
    • H04L47/70Admission control or resource allocation
    • H04L47/80Actions related to the nature of the flow or the user
    • H04L47/808User-type aware
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic regulation in packet switching networks
    • H04L47/70Admission control or resource allocation
    • H04L47/82Miscellaneous aspects
    • H04L47/824Applicable to portable or mobile terminals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W72/00Local resource management, e.g. wireless traffic scheduling or selection or allocation of wireless resources
    • H04W72/04Wireless resource allocation

Abstract

The allocation of shared transmission resources are optimised between two or more packet data streams of applications executing in a device in a packet data communications network. The device includes a transmission resource manager function. Each application specifies a range of acceptable values for one or more of the parameters that determine the transmission quality of its data stream, and the transmission resource manager function allocates the available transmission resources to all the data streams in dependence on the range of acceptable values supplied by each application. Preferably, the application supplies for each parameter a range in the form of a target value, which is the preferred value for the application, and a limit value, which is the minimum acceptable value to the application. Transmission resources may be allocated in such a way as to maximise the number of active data streams. May be applied to GPRS and UMTS radio communication systems.

Description

<Desc/Clms Page number 1>

PACKET DATA COMMUNICATIONS NETWORKS FIELD OF THE INVENTION The present invention relates to packet data communications networks, and more particularly, to optimising the allocation of transmission resources between applications executing on a packet data communications device.

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 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. Consequently, if multiple PDP contexts exist simultaneously, then multiple corresponding RABs will also exist to support each UMTS bearer. <img class="EMIRef" id="024165486-00010001" />

I 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

<Desc/Clms Page number 2>

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 application's 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 in 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 associatc the application's socket with that hearer. 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.

<Desc/Clms Page number 3>

The above works well if each application has a unique PDP context and hence bearer for each data stream, as the application can respond directly to changes. However, when two or more sockets are bound to a single PDP context and the bit rate of the bearer changes, the QoS manager must determine the impact to each of the affected data streams. The fairest way is to simply adjust the bit rate allocated to each socket by the same fraction, and in the absence of any further information this is all that can be achieved. Some applications will be able to reduce their output accordingly, whilst some applications will terminate their execution, as the quality of service required no longer exists. A more intelligent QoS manager with more information at its disposal could make better decisions about how a change in a PDP context should affect the individual data streams of each application. In the above example, if the QoS manager knew how each application would be affected by a change in the bit rate, then it could adjust the bit rate for each socket such that at least the minimum required quality of service was maintained for both applications.

SUMMARY OF INVENTION According to a first aspect, the present invention provides a method of optimising the allocation of shared transmission resources between two or more packet data streams of applications executing in a device in a packet data communications network, in which said device includes a transmission resource manager function, the method characterised in that each application specifies a range of acceptable values for one or more of the parameters that determine the transmission quality of its data stream; and the transmission resource manager function allocates the available transmission resources to all the data streams in dependence on the range of acceptable values supplied by each application.

According to a second aspect, the invention provides a device comprising the means for optimising the allocation of shared transmission resources between two or more packet data streams of applications executing on said device in a packet data communications network, said device including a transmission resource manager function, and means for the application to specify a range of acceptable values for one or more of the parameters that determine the transmission quality of its data stream; the transmission resource manager function being adapted to allocate the available transmission resources to all the data streams in dependence on the range of acceptable values supplied by each application.

<Desc/Clms Page number 4>

Preferably, the application supplies for each parameter a range in the form of a target value, which is the preferred value for the application, and a limit value, which is the minimum acceptable value for the application.

In a preferred embodiment, one of the parameters specifies the guaranteed bit rate for a packet data stream.

In a preferred embodiment, one of the parameters specifies the maximum bit rate for a packet data stream.

In a preferred embodiment, one of the parameters specifies the bit error rate for a packet data stream.

In a preferred embodiment, one of the parameters specifies the transfer delay for a packet data stream.

An application can request a new packet data stream from the transmission resource manager function of the device, and the transmission resource manager function preferably attempts to acquire the transmission resources required to provide the target value of each of the transmission parameters specified by the application from the network and when the required resources are not available from the network, reallocates the resources already amongst the data streams of the applications such that the number of data streams utilising the available transmission resources is maximised and each data stream is allocated at least the limit value for each transmission parameter specified; each application being informed by the transmission resource manager function of the new allocation.

The network can change the resources allocated to the transmission resource manager function of a device at any time, in which case the transmission resource manager function preferably reallocates the available resources amongst the data streams of the applications such that the number of data streams utilising the available transmission resources is maximised; and each data stream is allocated at least the limit value for each transmission

<Desc/Clms Page number 5>

parameter specified; and each application is informed by the transmission resource manager of the new allocation.

An application can change the ranges requested for any transmission parameter of any packet data stream at any time, and the transmission resource manager function then preferably attempts to acquire the transmission resources required to provide the target value of each of the transmission parameters specified by the application from the network; and when the required resources are not available from the network, reallocates the resources already acquired amongst the data streams of the applications such that the number of data streams utilising the available transmission resources is maximised, and each data stream is allocated at least the limit value for each transmission parameter specified; each application being informed by the transmission resource manager of the new allocation.

In a preferred embodiment, the transmission resource manager function determines the actual value of the parameters of the transmission resources to request from the network for a packet data stream ensure that the value to be requested for a parameter is within the range specified by the application for said packet data stream; and the transmission resource manager function uses tariff information for determining the cost per unit time of the transmission resources at the current time of day, and ensures that the cost per unit time of the transmission resources to be requested from the network for all the packet data streams of an application or all the packet data streams active on the device are within a user specified range.

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:

<Desc/Clms Page number 6>

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 is a message sequence chart showing the sequence of events and actions when a UMTS network reduces the bandwidth of a RAB over which an application is transmitting on the uplink; Figure 9 is a message sequence chart showing the sequence of events and actions when a UMTS network reduces the bandwidth of a RAB over which an application is receiving on the downlink;

<Desc/Clms Page number 7>

Figure 10 is a diagram illustrating how the bandwidth or a wireless bearer is shared between a first and a second application, when the first application has a flexible QoS policy profile; Figure 11 is a diagram illustrating how the bandwidth or a wireless bearer is not shared between a first and a second application, when the first application has a inflexible quality of service policy profile, resulting in the establishment of a second bearer for the second application; and Figure 12 is a diagram illustrating how a network initiated change in the bit error rate of one wireless bearer can result in a reconfiguration of the mapping of applications to wireless bearers and a corresponding change in the bandwidth allocated to the applications, in order to accommodate all applications within the quality of service attribute ranges specified in their quality of service policy profiles.

DETAILED DESCRIPTION OF PREFERRED 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

<Desc/Clms Page number 8>

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 may be 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

<Desc/Clms Page number 9>

applications requiring packet data communications need only understand the packet data protocol.

It will be appreciated that Figure 1 and the above description is a schematic view of a packet data communications network, and that many different installations 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 but the invention is not restricted 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 from 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

<Desc/Clms Page number 10>

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, where in Figure 3, a schematic 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.

<Desc/Clms Page number 11>

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 and a data function 304. The control function 303 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 onto 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:

<Desc/Clms Page number 12>

- 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

<Desc/Clms Page number 13>

Maximum SDU size <img class="EMIRef" id="024165486-00130001" />

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

<Desc/Clms Page number 14>

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.

<Desc/Clms Page number 15>

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 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

<Desc/Clms Page number 16>

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 prior art applications can specify the attributes that they require of the data transmission path to achieve a certain QoS, and the QoSM will allocate the resources if available or request more resources from the network. In the prior art, it is only known for applications to specify a single value of each QoS attribute that they require for each data stream. For example, in a UMTS packet data network they can specify a residual bit error ratio or a maximum transmit bit rate or the required guaranteed bit rate. This enables the QoSM to match the data stream to the physical bearer with the desired characteristics. It may happen that: an existing PDP context has matching QoS attributes and is reused. The extra bandwidth required to accommodate the new data stream on said PDP context is requested from the network; - there is no existing PDP context with matching QoS attributes and the QoSM requests a new PDP context and hence physical bearer is setup by the network; <img class="EMIRef" id="024165486-00160001" />

In either case, the request for resources from the network may fail, and the application must . be informed that its QoS requirements cannot be met. It is then up to the application to determine what it should do next. It may choose to terminate or request a lower QoS for its data stream.

An application can request at any time that its QoS for a data stream should be changed. In a first example, the application using an uplink makes a request of the QoSM for more bandwidth. In this case, the QoSM can request that the network allocated more bandwidth to the PDP context. This may be successful, but it may also fail. If it fails, then the QoSM may have the option of reallocating bandwidth that other applications are using on the same PDP context. However, the QoSM does not know how a reallocation of bandwidth on the uplink will affect the transmit data streams of other applications. In a second example, the application using an uplink may request a reduction in the bandwidth it requires for a

<Desc/Clms Page number 17>

transmit data stream. In this case, the QoSM can simply return the resources to the network, or alternatively reallocate it to the data streams of other applications using the uplink that are active. However, again the QoSM cannot make an intelligent decision about how to allocate the excess bandwidth to applications using the uplink.

The network can change the PDP context at any time in accordance with its resource control algorithms, which affects the QoS granted to the data streams whose sockets are using the uplink or downlink of the corresponding physical bearer. In a first example, the RNC reduces the uplink bandwidth of a PDP context. The QoSM must decide how each transmit data stream using the uplink is affected by this change, and inform the affected applications. In the case where there is only a single transmit data stream on the PDP context, this is straightforward. The QoSM must pass the entire reduction on to the single transmit data stream and it's associated application. However, when there are two or more transmit data streams the QoSM must distribute the reduction on to each data stream and associated application in equal measures, because it does not know how each transmit data stream and associated application will be affected. This is not necessarily the optimal action, as one application may be more tolerant to a reduction in bit rate than the other, but the QoSM does not have this information. Alternatively, one application may accept the same bit rate on a data stream but at a higher bit error rate, which may be available.

In a second example, the radio network controller increases the bandwidth of, a PDP context. As in the first example, the QoSM lacks the information to make an intelligent decision about how this new bandwidth should be optimally distributed between the data streams and their respective applications sharing this PDP context.

It is a feature of the present invention that the application makes available to the QoSM additional information about the QoS it requires for each of its data streams, such that the QoSM is able to manage the resources made available by the network between multiple applications more effectively than in the prior art.

In a preferred embodiment, the application provides to the QoSM what is termed a QoS policy profile (QPP) for each socket that it opens. This extends the apparatus and method

<Desc/Clms Page number 18>

of the QoS API, in that it allows an application to specify for one or more of its data streams information for each QoS attribute that specifies: - The value that the application requires for ideal operation. This is termed the target value.

- The value beyond which the application cannot function. This is termed the limit value.

In a preferred embodiment the following QoS attributes would be specified in terms of target, and limit values: - Maximum bit rate - Guaranteed bit rate - SDU error ratio - Transfer delay It will be appreciated by those skilled in the art that the target and limit values can be applied to any QoS attribute that can take on a range of values and it is not limited to those specified above.

In a preferred embodiment, the user can change the QPP for an applications packet data streams through an application configuration tool. In another embodiment, applications will have these values permanently fixed by the application developer.

The QoSM utilises the QPP supplied by the application for the data streams to perform intelligent management of the transmission resources allocated to it by the network such that: - Applications do not monopolise scarce resources unnecessarily.

Each application can be allocated a fair share of the resources available.

- The maximum possible number of simultaneous streams is maintained.

<Desc/Clms Page number 19>

It is an object of the present invention that the QoSM will always attempt to obtain from the network the target value of a QoS attribute for a data stream, specified by the application in the QPP. If the target values for QoS cannot be obtained, for example, because the network is heavily loaded, then the QoSM will reallocate some of the available resources such that each data stream of each application has at least the limit values specified in its QPP for its allocated QoS. If the available resources are limited such that there are not enough resources to satisfy the limit values of all the QPPs then the QoSM will use an algorithm to determine which QPPs will be satisfied with their limit resources and which will not be satisfied. This algorithm can be, though is not limited to, one of the following: - Last in first out allocation of resources - Maintaining the maximum possible number of open data streams.

If the available resources are increased, the QoSM will allocate them according to an algorithm such as, though not limited to: The maximum possible number of data streams to meet their QPP targets for the maximum possible number of values; - An allocation based upon the difference between current value and target values; - An allocation based upon the ratio of current value and target values.

The QoSM will use the QPP as described above whenever a change in resource allocation is required, specifically: - When an application requests the opening of a new data stream with a new QPP; - When an application closes an existing data stream; - When an application modifies an existing QPP; - When the network increases the allocated resources; When the network decreases the allocated resources.

<Desc/Clms Page number 20>

According to another aspect of the invention, the QoSM will use tariff information available to it, for example, in a terminal's memory, which provides information about the costs of different QoS at different times of the day, along with a specified user preference for how much a packet data communication session for the specific application should cost, to determine whether - the target value from the QPP should be requested; - the limit value from the QPP should be requested; - a value in-between the target and limit should be requested.

Thus the QPP enables the QoSM to vary the QoS provided to an application in order to maintain a user specified cost for the service.

The invention is equally applicable whether an application is transmitting data, receiving data or both over the UMTS network. Transmit data streams will be transmitted over a RAB uplink, and receive data streams will be received over a RAB downlink. For each type of data stream, a QPP will be specified by the application to the QoSM. In the case of transmit data streams, the application will set the target and limit of QoS parameters based on its requirements. In the case of receive data streams, it will set the target and limit of QoS parameters based on the requirements of the entity transmitting. These requirements will have been communicated to the application from the entity transmitting.

If after the QPPs have been setup, and the application is receiving or transmitting data, the PDP context of a RAB is changed by the network, the QoSM takes action using the QPPs and notifies the application. In the case of transmit data streams the application will use the modified QoS parameters received from the QoSM to modify its output as in Figure 8. An application 500 is transmitting data 510 to a receiver 502 over a RAB. At some time later, a network generated reduction in the bandwidth of this bearer occurs 511. Through a dialog with the QoSM the application is notified of this reduction and reduces it's output bitrate 512.

<Desc/Clms Page number 21>

In the case of receive data streams, the application will pass on notice of these changes in the QoS parameters to the transmitting entity as in Figure 9. An application 500 is receiving data 520 from a transmitter 503. At some time later, a network generated reduction in the bandwidth of this bearer occurs 511. Through a dialog with the QoSM the application is notified of this reduction and notifies the transmitter 522. Transmitter 503 then reduces it's output bitrate 523. Also as a result of the reduction of bandwidth 511, it may be necessary to reallocate the receive data streams onto different RABs. This would involve updating the Traffic Flow Templates (TFT) of the existing PDP contexts.

As illustrated in Figure 10, an application 401 has one transmit data stream using a PDP context PDPO (ttBEpoRE) 403. Its target bit rate, BR (A) TARGET, is equal to the uplink guaranteed bit rate of PDPO (t=tBEFORE) 403, BRpDPO. Its limit bit rate, BR (A) LIMIT, is half of its target bit rate, BR (A) TARGET. Another application 402 is launched which can use the same PDP context (because QoS attributes such as error rate or delay are suitable for the second application) PDPO (t=tAFTER) 404 (may even be the only one available as with GPRS) for its transmit data stream. No more resources are available from the network. The QoSM can then determine that both applications can share the PDPO (t=tAFTER) 404 if the sum of their limit bit rates, BR (A) LIMIT + BR (B) LIMIT, is less than the PDP bit rate, BRpDpo. Each transmit data stream is assigned a portion of the bit rate such that the available bandwidth <img class="EMIRef" id="024165486-00210001" />

on the PDPO (t=tAFTER) 404 is fully utilised. Without the QPP, the application must either request the minimum values acceptable, e. g. BRuMIT, or request its ideal value, e. g.

BRTARGET. In the first case, the application will always deliver to the user a sub-optimal experience, but will not monopolise the available resources. In the second case, it can deliver to the user high quality but will monopolise the resources and starve other applications to the extent that it can prevent them from executing.

As illustrated in Figure 11, an application 411 has one transmit data stream using a PDP context PDPO (t=tBEFORE) 413. Its target bit rate, BR (A) TARGET, is equal to the uplink guaranteed bit rate of the PDPO (t=tBEFoRE) 413, BRpDPO. Its limit bit rate BR (A) LIMIT is, for example, 80% of its target bit rate, BR (A) TARGET. At some time later, tAFTER, another application 412 is launched which can use the same PDP context PDPO (t==tAFTER) 414 for its transmit data stream as the QoS attributes match. However, the sum of the two limit bit

<Desc/Clms Page number 22>

rates, BR (A) LIMIT + BR (B) LINT, is greater than the total available bandwidth on the uplink of the bearer BRpDPO. The QoSM then is able to determine that it must establish a new PDP context PDPl (t=tAFTER) 415 for the second application 412. The original PDP context PDPO remains unchanged i. e. PDPO (t=tBEFORE) = PDPO (t=tAFTER).

Consider now the situation illustration in Figure 12 in which two transmit data streams belonging to different applications 421 and 422 share a PDP context PDPO (t=tBEpoRE) 424.

Both transmit data streams have only their limit value of the bit rate allocated. The bit error rate (BER) of the PDPO (ttBEFORE) 424, BERpDPO, is the limit value for one transmit data stream (BER (B) LIMIT = BERpDpo), but is the target value for the other (BER (A) TARGET = BERpDpo). Note that for BER, a lower value represents superior quality. Another transmit data stream belonging to a third application 423 is mapped to a separate PDP context PDPl (t=tBEFoRE) 426 with the same BER as that for PDPO (t=tBEFORE) 424, i. e. BERpDpo = BERpDp). Now at some later time, tAFrER, the network increases BERpDPo. Because the QoSM knows that one of the transmit data streams on PDPO (t=tAFTER) cannot accept a higher BER, i. e. the transmit data stream belonging to application 422, it moves that transmit data stream to PDPl (t=tAFrER) where bandwidth is made available by reducing that available to application 423, since on PDP1 (t==tAFTER) 427 the BER is lower than on PDPO (t=tAFTER) 425.

The application 421 is then able to utilise all the bandwidth on PDPO (t=tAFTER). This is only possible when a range of acceptable values for a QoS attribute is provided. Without this information, the QoSM would have increased the BERRABO which would have terminated application 422 which could not tolerate this.

The cost of network resources varies over time. Peak time usage is more expensive than off-peak. The QoSM can use this tariff information combined with the QPP to trade off cost and quality in accordance with the users configuration.

The usage of a QPP is independent of where it is stored during application execution. In the preferred embodiment, it is passed to the QoSM, which can then autonomously make decisions about how to manage the QoS. In another embodiment, it is retained in the application, and the QoSM will offer new QoS attributes for a data stream to the application, which the application can then either accept or reject based upon its QPP. This

<Desc/Clms Page number 23>

embodiment is less efficient because of this negotiation procedure between the applications and the QoSM. It is also only possible for QoS- aware applications.

The characteristic feature of this invention is that specifying a limit value and a desired value for each QoS attribute enables the QoSM to perform intelligent management of the transmission resources.

Claims (28)

  1. CLAIMS 1. A method of optimising the allocation of shared transmission resources between two or more packet data streams of applications executing in a device in a packet data communications network, in which said device includes a transmission resource manager function, the method being characterised in that: each application specifies a range of acceptable values for one or more of the parameters that determine the transmission quality of its data stream; and the transmission resource manager function allocates the available transmission resources to all the data streams in dependence on the range of acceptable values supplied by each application.
  2. 2. A method according to claim 1, wherein the application supplies for each parameter a range in the form of a target value, which is the preferred value for the application, and a limit value, which is the minimum acceptable value to the application.
  3. 3. A method according to any preceding claim, wherein one of the parameters specifies the guaranteed bit rate for a packet data stream.
  4. 4. A method according to any preceding claim, wherein one of the parameters specifies the maximum bit rate for a packet data stream.
  5. 5. A method according to any preceding claim, wherein one of the parameters specifies the bit error rate for a packet data stream.
  6. 6. A method according to any preceding claim, wherein one of the parameters specifies the transfer delay for a packet data stream.
  7. 7. A method according to any preceding claim, wherein an application requests an increase in transmission resources from the transmission resource manager function ; the transmission resource manager function reallocates the resources already acquired amongst the data streams of the applications such that the number of data streams utilising the available transmission resources is maximised and each data
    <Desc/Clms Page number 25>
    stream is allocated at least the limit value for each transmission parameter specified; and each application is informed of the new allocation for each affected packet data stream.
  8. 8. A method according to claim 7 in which the transmission resource manager function responds to a request for increased transmission resources by attempting to acquire the transmission resources required to provide the target value of each of the transmission parameters specified by the application from the network; and if the required resources are not made available by the network, reallocating the resources already acquired amongst the data streams of the applications.
  9. 9. A method according to claim 7 or 8 wherein an application requests a new packet data stream.
  10. 10. A method according to claim 7 or 8, wherein an application changes the range requested for any transmission parameter of any packet data stream so as to require increased transmission resources.
  11. 11. A method according to any preceding claim, wherein an application reduces its requirement for transmission resources compared with those previously acquired. by the transmission resource manager function; the transmission resource manager function reallocating the required resources amongst the data streams of the applications and freeing up any remaining network resources such that the number of data streams utilising the available transmission resources is maximised and each data stream is allocated at least the limit value for each transmission parameter specified ; and each application is informed of the new allocation for each affected packet data stream.
  12. 12. A method according to any preceding claim, wherein the network changes the resources allocated to [and controlled by the transmission resource manager function ofl a device at any time;
    <Desc/Clms Page number 26>
    the transmission resource manager function reallocates the available resources amongst the data streams of the applications such that the number of data streams utilising the available transmission resources is maximised and each data stream is allocated at least the limit value for each transmission parameter specified; and each application is informed of the new allocation for each affected packet data stream.
  13. 13. A method according to any preceding claim, wherein said transmission resource manager function determines the actual value of the parameters of the transmission resources to request from the network for a packet data stream, the method including the steps of : ensuring that the value to request for a parameter is within the range specified by the application for said packet data stream; and using tariff information available to the transmission resource manager function for determining the cost per unit time of the transmission resources at the current time of day; and ensuring that the cost per unit time of the transmission resources to be requested from the network for all the packet data streams of an application or all the packet data streams active on the device are within a user specified range.
  14. 14. A data communications device comprising the means for optimising the allocation of shared transmission resources between two or more packet data streams of applications executing on said device in a packet data communications network, said device including a transmission resource manager, characterised in that the device further comprises means for the application to specify a range of acceptable values for one or more of the parameters that determine the transmission quality of its data stream; and the transmission resource manager is adapted to allocate the available transmission resources to all the data streams in dependence on the range of acceptable values supplied by each application.
    <Desc/Clms Page number 27>
  15. 15. A data communications device according to claim 14, in which said means supplies for each transmission parameter a range in the form of a target value, which is the preferred value for the application, and a limit value, which is the minimum acceptable value to the application.
  16. 16. A data communications device according to claims 14 or 15, in which said means specifies the guaranteed bit rate for a packet data stream.
  17. 17. A data communications device according to any one of claims 14 to 16, in which said means specifies the maximum bit rate for a packet data stream.
  18. 18. A data communications device according to any one of claims 14 to 17, in which said means specifies the bit error rate for a packet data stream.
  19. 19. A data communications device according to any one of claims 14 to 18, in which said means specifies the transfer delay for a packet data stream.
  20. 20. A data communications device according to any one of claims 14 to 19, in which said means can request an increase in transmission resources; and in which the transmission resource manager function reallocates the resources already acquired amongst the data streams of the applications such that the number of data streams utilising the available transmission resources is maximised and each data stream is allocated at least the limit value for each transmission parameter specified; and each application is informed of the new allocation for each affected packet data stream.
  21. 21. A data communications device as claimed in claim 20 in which the transmission resource manager function responds to a request for increased transmission resources by attempting to acquire the transmission resources required to provide the target value of each of the transmission parameters specified by the application from the network; and if the required resources are not made available by the network, reallocating the resources already acquired amongst the data streams of the applications.
    <Desc/Clms Page number 28>
  22. 22. A data communications device as claimed in claim 20 or 21 wherein an application can request a new packet data stream.
  23. 23. A data communications device as claimed in claim 20 or 21 wherein an application can change the range requested for any transmission parameter of any packet data stream, so as to require increased transmission resources.
  24. 24. A data communications device as claimed in any one of claims 14 to 23 wherein an application can reduce its requirement for transmission resources compared with those previously acquired by the transmission resource manager function; the transmission resource manager reallocating the required resources amongst the data streams of the applications and freeing up any remaining network resources such that the number of data streams utilising the available transmission resources is maximised and each data stream is allocated at least the limit value for each transmission parameter specified ; and each application being informed by the transmission resource manager of the new allocation for each affected packet data stream.
  25. 25. A data communications device wherein when the network changes the resources allocated to and controlled by the transmission resource manager of ; the transmission resource manager reallocates the available resources amongst the data streams of the applications such that the number of data streams utilising the available transmission resources is maximised and each data stream is allocated at least the limit value for each transmission parameter specified; and each application is informed of the new allocation for each affected packet data stream.
  26. 26. A data communications device according to any one of claims 14 to 25, in which the transmission resource manager determines the actual value of the parameters of the transmission resources to request from the network for a packet data stream; ensures that the value to request for a parameter is within the range specified by the application for said packet data stream; and using tariff information available determines the cost per unit time of the transmission resources at the current time of day; and ensures that the cost per unit time of the transmission resources to be requested
    <Desc/Clms Page number 29>
    from the network for all the packet data streams of an application or all the packet data streams active on the device are within a user specified range.
  27. 27. A data communications device according to any one of the claims 14 to 26, that is a mobile terminal in a UMTS packet data network.
  28. 28. A data communications device according to any one of the claims 14 to 27, that is a mobile terminal in a GPRS packet data network.
GB0205105A 2002-03-05 2002-03-05 Allocating shared resources in a packet data communications network Withdrawn GB2386282A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
GB0205105A GB2386282A (en) 2002-03-05 2002-03-05 Allocating shared resources in a packet data communications network

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
GB0205105A GB2386282A (en) 2002-03-05 2002-03-05 Allocating shared resources in a packet data communications network
AU2003209476A AU2003209476A1 (en) 2002-03-05 2003-03-05 Quality of service management in packet data networks
PCT/GB2003/000970 WO2003075523A1 (en) 2002-03-05 2003-03-05 Quality of service management in packet data networks

Publications (2)

Publication Number Publication Date
GB0205105D0 GB0205105D0 (en) 2002-04-17
GB2386282A true GB2386282A (en) 2003-09-10

Family

ID=9932286

Family Applications (1)

Application Number Title Priority Date Filing Date
GB0205105A Withdrawn GB2386282A (en) 2002-03-05 2002-03-05 Allocating shared resources in a packet data communications network

Country Status (3)

Country Link
AU (1) AU2003209476A1 (en)
GB (1) GB2386282A (en)
WO (1) WO2003075523A1 (en)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005099294A1 (en) * 2004-04-08 2005-10-20 Nokia Corporation Controlling transmission resources in mobile radio systems with dual transfer mode
WO2006012794A1 (en) 2004-08-02 2006-02-09 Huawei Technologies Co., Ltd. A METHOD FOR SIGNALING INTERACTION OF ENSURING THE INTERNET PROTOCOL (IP) QUALITY OF SERVICE (QoS)
WO2007069941A1 (en) * 2005-12-12 2007-06-21 Telefonaktiebolaget Lm Ericsson (Publ) A method and arrangement for establising a communication session for multimedia
WO2008008990A3 (en) * 2006-07-14 2008-07-17 Srinivasan Balasubramanian Call establishment and maintanance in a wireless network
FR2934745A1 (en) * 2008-07-30 2010-02-05 Radiotelephone Sfr Multimode mobile terminal for communicating e.g. voice data, over cellular network, has deregistering unit deregistering application, where message relative to channels is transmitted between managing device and applications
WO2010151850A1 (en) * 2009-06-26 2010-12-29 Qualcomm Incorporated OPTIMIZED RESOURCE USAGE WITH NETWORK INITIATED QoS
WO2011157833A1 (en) 2010-06-18 2011-12-22 Skype Limited Controlling data transmission over a network
EP2417796A1 (en) * 2009-10-31 2012-02-15 Huawei Technologies Co., Ltd. Method in a wireless communication system for determining quality of service fulfilment
WO2012103503A1 (en) * 2011-01-27 2012-08-02 Qualcomm Incorporated Coexistence of user equipment initiated and network initiated quality of service flows
US9179381B2 (en) 2011-09-29 2015-11-03 Qualcomm Incorporated Reducing network-initiated QoS interruption time when radio and core networks are out of synchronization due to different underlying technologies
WO2019210966A1 (en) * 2018-05-03 2019-11-07 Huawei Technologies Co., Ltd. Client device, network control node and upf for transmission and reception of streams of data packets in multi-connectivity

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI20031414A (en) * 2003-09-30 2005-03-31 Nokia Corp Transmission of data in a mobile telephony in a wireless packet switching computer system
FR2860679A1 (en) * 2003-10-03 2005-04-08 Nec Technologies Uk Ltd Service bearer selecting method for universal mobile telecommunication system network, involves selecting service bearer corresponding to parameter e.g. cost parameter of quality of service interfering into selection of service bearer
CN104618968A (en) * 2004-04-08 2015-05-13 核心无线许可有限公司 Method for controlling transmission resource in mobile wireless system with double conveying modes
WO2006092645A1 (en) * 2005-03-03 2006-09-08 Telefonaktiebolaget Lm Ericsson (Publ) Ip multiservice network and method for making resource reservations for priority traffic
EP1946577B1 (en) 2005-11-09 2013-01-02 Telefonaktiebolaget LM Ericsson (publ) Selection of radio resources in a radio communications network

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0734195A2 (en) * 1995-03-22 1996-09-25 AT&amp;T Corp. A delay-minimizing system with guaranteed bandwith for real-time traffic
US5892754A (en) * 1996-06-07 1999-04-06 International Business Machines Corporation User controlled adaptive flow control for packet networks
WO2001089234A2 (en) * 2000-05-16 2001-11-22 Telefonaktiebolaget Lm Ericsson (Publ) Policy server and architecture providing radio network resource allocation rules

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
NO304570B1 (en) * 1997-05-20 1999-01-11 Ericsson Telefon Ab L M FremgangsmÕte related to GPRS (General Packet Radio Service) system with packet-switched connections
US6937566B1 (en) * 1997-07-25 2005-08-30 Telefonaktiebolaget Lm Ericsson (Publ) Dynamic quality of service reservation in a mobile communications network
FI108192B (en) * 1998-03-19 2001-11-30 Nokia Networks Oy A method and apparatus for controlling quality of service in a mobile communication system
GB2341059A (en) * 1998-08-28 2000-03-01 Nokia Oy Ab Internet protocol flow detection
EP1154664A1 (en) * 2000-05-09 2001-11-14 Lucent Technologies Inc. Resource reservation in 3G or future generation telecommunication network II

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0734195A2 (en) * 1995-03-22 1996-09-25 AT&amp;T Corp. A delay-minimizing system with guaranteed bandwith for real-time traffic
US5892754A (en) * 1996-06-07 1999-04-06 International Business Machines Corporation User controlled adaptive flow control for packet networks
WO2001089234A2 (en) * 2000-05-16 2001-11-22 Telefonaktiebolaget Lm Ericsson (Publ) Policy server and architecture providing radio network resource allocation rules

Cited By (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005099294A1 (en) * 2004-04-08 2005-10-20 Nokia Corporation Controlling transmission resources in mobile radio systems with dual transfer mode
US8712423B1 (en) 2004-04-08 2014-04-29 Core Wireless Licensing S.A.R.L Controlling transmission resources in mobile radio systems with dualtransfer mode
US7751349B2 (en) 2004-08-02 2010-07-06 Huawei Technologies Co., Ltd. Signalling exchange method for guaranteeing internet protocol quality of service
WO2006012794A1 (en) 2004-08-02 2006-02-09 Huawei Technologies Co., Ltd. A METHOD FOR SIGNALING INTERACTION OF ENSURING THE INTERNET PROTOCOL (IP) QUALITY OF SERVICE (QoS)
EP1760935A1 (en) * 2004-08-02 2007-03-07 Huawei Technologies Co., Ltd. A METHOD FOR SIGNALING INTERACTION OF ENSURING THE INTERNET PROTOCOL (IP) QUALITY OF SERVICE (QoS)
EP1760935A4 (en) * 2004-08-02 2010-05-05 Huawei Tech Co Ltd A METHOD FOR SIGNALING INTERACTION OF ENSURING THE INTERNET PROTOCOL (IP) QUALITY OF SERVICE (QoS)
WO2007069941A1 (en) * 2005-12-12 2007-06-21 Telefonaktiebolaget Lm Ericsson (Publ) A method and arrangement for establising a communication session for multimedia
US7944880B2 (en) 2005-12-12 2011-05-17 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement for establishing a communication session for multimedia
US10447557B2 (en) 2006-07-14 2019-10-15 Qualcomm Incorporated Call establishment and maintenance in a wireless network
US9781014B2 (en) 2006-07-14 2017-10-03 Qualcomm Incorporated Call establishment and maintenance in a wireless network
US8849297B2 (en) 2006-07-14 2014-09-30 Qualcomm Incorporated Call establishment and maintenance in a wireless network
WO2008008990A3 (en) * 2006-07-14 2008-07-17 Srinivasan Balasubramanian Call establishment and maintanance in a wireless network
FR2934745A1 (en) * 2008-07-30 2010-02-05 Radiotelephone Sfr Multimode mobile terminal for communicating e.g. voice data, over cellular network, has deregistering unit deregistering application, where message relative to channels is transmitted between managing device and applications
WO2010151850A1 (en) * 2009-06-26 2010-12-29 Qualcomm Incorporated OPTIMIZED RESOURCE USAGE WITH NETWORK INITIATED QoS
CN102804708A (en) * 2009-06-26 2012-11-28 高通股份有限公司 Optimized resource usage with network initiated qos
US8599720B2 (en) 2009-06-26 2013-12-03 Qualcomm Incorporated Optimized resource usage with network initiated QoS
KR101369348B1 (en) 2009-06-26 2014-03-04 퀄컴 인코포레이티드 OPTIMIZED RESOURCE USAGE WITH NETWORK INITIATED QoS
CN102804708B (en) * 2009-06-26 2016-01-20 高通股份有限公司 The optimization resource of the QoS utilizing network to initiate uses
EP2417796A1 (en) * 2009-10-31 2012-02-15 Huawei Technologies Co., Ltd. Method in a wireless communication system for determining quality of service fulfilment
EP2417796A4 (en) * 2009-10-31 2012-07-04 Huawei Tech Co Ltd Method in a wireless communication system for determining quality of service fulfilment
WO2011157833A1 (en) 2010-06-18 2011-12-22 Skype Limited Controlling data transmission over a network
US9264377B2 (en) 2010-06-18 2016-02-16 Skype Controlling data transmission over a network
WO2012103503A1 (en) * 2011-01-27 2012-08-02 Qualcomm Incorporated Coexistence of user equipment initiated and network initiated quality of service flows
JP2014508459A (en) * 2011-01-27 2014-04-03 クゥアルコム・インコーポレイテッドQualcomm Incorporated Coexistence of QUALITYOFSERVICE flow initiated by user equipment and QUALITYOFSERVICE flow initiated by network
US9179381B2 (en) 2011-09-29 2015-11-03 Qualcomm Incorporated Reducing network-initiated QoS interruption time when radio and core networks are out of synchronization due to different underlying technologies
WO2019210966A1 (en) * 2018-05-03 2019-11-07 Huawei Technologies Co., Ltd. Client device, network control node and upf for transmission and reception of streams of data packets in multi-connectivity

Also Published As

Publication number Publication date
AU2003209476A1 (en) 2003-09-16
WO2003075523A1 (en) 2003-09-12
GB0205105D0 (en) 2002-04-17

Similar Documents

Publication Publication Date Title
US9560669B2 (en) Method and devices for specifying the quality of service in a transmission of data packets
JP5512719B2 (en) Packet flow processing in communication systems
US8738820B2 (en) Method and apparatus for wireless network communication wherein a universal serial bus request block (URB) is generated that will vary parameters that controls wireless transmission commands between devices
US8811423B2 (en) Edge-based per-flow QOS admission control in a data network
WO2017211289A1 (en) Systems and method for quality of service monitoring, policy enforcement, and charging in communications network
JP5258989B2 (en) Mobile node handover between access networks of different technologies in a mobile IP communication system
AU776918B2 (en) Dynamic upgrade of quality of service in a packet switched network
US20130165084A1 (en) Systems and methods for cooperative applications in communication systems
US20120213114A1 (en) Adaptive quality of service policy for dynamic networks
US6738361B1 (en) Method, apparatus and computer program for IP traffic prioritization in IP networks
EP1382214B1 (en) Binding information for ip media flows
RU2450485C2 (en) Control of bit speed of adaptive multispeed codec in wireless communications system
JP3574788B2 (en) Control of service quality in mobile communication systems
US8064395B2 (en) Data transmission
FI108601B (en) Dissemination of QoS mapping information in a packet radio network
JP4343229B2 (en) Automatic IP traffic optimization in mobile communication systems
US6668175B1 (en) Method and apparatus for providing radio access bearer services
JP4309338B2 (en) QoS parameter converter
FI108192B (en) A method and apparatus for controlling quality of service in a mobile communication system
US6621793B2 (en) Application influenced policy
EP1610492B1 (en) Adaptive and scalable qos architecture for multiple-bearer multicast/broadcast services
US7920541B2 (en) Resource allocation in a radio access network
ES2392339T3 (en) Transfer of packet data to a wireless terminal
US7289453B2 (en) Adaptive quality-of-service reservation and pre-allocation for mobile systems
EP1282995B1 (en) Policy server and architecture providing radio network resource allocation rules

Legal Events

Date Code Title Description
WAP Application withdrawn, taken to be withdrawn or refused ** after publication under section 16(1)