WO2008015379A1

WO2008015379A1 - User prioritisation of communications traffic

Info

Publication number: WO2008015379A1
Application number: PCT/GB2007/002686
Authority: WO
Inventors: Khong Neng Choong; Andy Lock Yen Low
Original assignee: British Telecommunications Public Limited Company
Priority date: 2006-07-31
Filing date: 2007-07-16
Publication date: 2008-02-07

Abstract

The present invention relates to communications associated with different user applications such as Voice over Internet Protocol (VoIP) voice calls and File Downloads, and the prioritisation (quality of service or QoS) of data relating to those applications through a network such as the Internet. The present invention provides a network node (122) for receiving and transmitting packet-based data (150) across a network (120), the node comprising an input (310) for receiving a data packet (150), means for determining a network priority parameter (X, 260) and a user defined priority index (Y, 265) from the data packet, and means for prioritising (320, 330, 340) the data packet for transmission (350) dependent on the network priority parameter (X) or the user defined priority index (Y), and arranged wherein the data packet is prioritised (400, 530) dependent on the user defined priority index in response to determining (405) a user defined priority index from the data packet.

Description

USER PRIORITISATION OF COMMUNICATIONS TRAFFIC Field of the Invention

The present invention relates to communications associated with different user applications such as Voice over Internet Protocol (VoIP) voice calls and File Downloads, and the prioritisation (as one of the quality of service or QoS measures) of data relating to those applications through a network such as the Internet.

Background of the Invention

The provision of different levels of quality of service (QoS) in a network is becoming increasingly important. Typically QoS is translated into the speed at which associated data packets travel over the network, and/or the manner in which different data packets are prioritised by routers and switches within the network depending on their QoS level. Real-time user applications such as voice call (VoIP) applications like Skype™, and video conferencing typically require a high level or quality of service, as packet delays can be very noticeable to a user. However other non-real-time applications such as file downloading, email and browsing applications generally do not require the same level of service, because minor delays are usually not noticeable to a user.

Network operators are able to charge more for higher QoS or priority data transfer, however the QoS level is generally allocated by industry agreement or by the network operator based on traffic types - for example real-time voice calls have the highest priority, and non-real-time file downloads the lowest. Table 1 below illustrates typical QoS or prioritisation assignments of data packets within a network and associated with different application types.

Table 1

Each packet in a packet-based network may be allocated a certain parameter based on its traffic type, which can then be mapped into a traffic or network based . priority value (e.g. 1-6 from Table 1) which is then used by the network to prioritise the respective packets; for example by assigning them to higher priority traffic queues in a router or switch.

A. Malla, M. El-Kadi, S.- Olariu, and P. Todorova, "A fair resource allocation protocol for multimedia wireless networks", IEE]E Trans. Parallel and Distributed Sys, 2003, Vol. 14, Nq. 1, describes a method of call admission on a wireless network based on the priority of the call as determined from whether it is real-time or non-real-time, for example a voice call or a file download.

F. Prihandoko, M.H. Habaebi, and B.M. AIi, "Adaptive Call Admission Control for QoS Provisioning in Multimedia Wireless Networks", Computer Communication, Elsevier, 2003, Vol. 26, pp. 1560-1569, describes a call admission control and bandwidth reservation scheme for a network based on prioritizing different traffic classes in a manner similar to that shown in Table 1.

US2005/0152373 describes a wireless network internal contention resolution function for an access point. The access point uses a MAC level enhanced distribution coordination function (EDCF) to classify traffic flows into different access categories reflecting the priority of these packets. This priority is based on parameters such as data rate, data delay and/or application type.

US2004/0111461 describes a switch for blocking or allowing packets based on the switch administrator's priority policy.

Summary of embodiments of the Invention

Embodiments of the invention provides a method and system for implementing a user defined priority level for communications traffic associated with a user application such as an e-mail client, a voice call, or a file download. This user defined priority level can be used by devices or nodes within a communications system to prioritise traffic such as data packets associated with traffic associated with a different application and having a different priority level. This different priority level may be defined by a user of the different application, or by the system or a node within the system. User application traffic is typically associated with a priority level or parameter which is dependent on the traffic or application type, for example real-time traffic typically has a higher traffic priority level than non-real-time traffic and similarly a voice call application typically has a higher traffic priority level than a file retrieval application. Embodiments allow a user to assign a user priority level to a user application and this can be used by the communications system in place of the default priority level assigned by the system operator or application itself.

This arrangement allows a user to manage the priority allocated by a network to a particular application, which may well be different from the priority that would normally be allocated by the network operator. For example a particular user may want a large file downloaded from their company server as soon as possible, and at the expense of other applications, in order to meet a work related deadline. This user may also be prepared to pay extra for this higher than normal QoS or priority level or measure for file downloading.

This arrangement also allows a network node to admit a new traffic connection session or control the bandwidth allocated to existing traffic connections using the user defined traffic priority level or index, instead of a network or otherwise predetermined network priority parameter dependent on the application and/or traffic types associated with each connection session.

There is also provided a network node such as a router or switch for receiving and transmitting packet-based data across a network. The network node determines a user defined priority index from within a received data packet, and prioritises the data packet for transmitting depending on the determined user priority index. Where a user defined priority index is not available, prioritisation of the data packet is based on a network priority parameter, for example corresponding to the application or traffic type associated with the data packet. The relative prioritisation between user defined priority index values and network defined priority values can be configured by the network node operator. For example a one-to-one mapping may be used, such that the highest ranking user defined priority index is prioritised at a similar level to the highest ranking network priority parameter. Thus a user may allocate a high user defined priority index to a file download application which may then receive equivalent transmission prioritisation to voice call applications without any overriding user defined priority index.

In an embodiment the received data packets each comprise a network priority parameter, and the network node is arranged to prioritise the received data packets for transmission depending on their respective network priority parameters where they do not comprise a user defined priority index.

In an embodiment the network node is implemented using a plurality of priority queues from which data packets are selected for output to a transmission queue, and received data packets are mapped into one of the priority queues depending on their respective user defined priority index or if none their respective network priority parameter.

In an embodiment, the network priority parameters and the user defined priority indexes each comprise one of a predetermined number of values, and the mapping of the received data packets to the priority queues based on their respective user defined priority index values is based on one of the following relationships compared with received packets mapped to the priority queues based on their respective network priority parameter values: one-to-one; one-to-two; two-to-one; one-to-three; three-to-one.

In an embodiment the user defined priority index is implemented using a header field in each data packet associated with the corresponding user application. In alternative embodiments, this association may be made at a higher layer, for example at a call or connection session level.

There is provided an internet protocol datagram comprising a header having an IP options field comprising two octets, a second octet including a user defined priority index. The second octet may also comprise a network priority parameter.

There is also provided a device for connecting to a network, the device comprising: a user application having a predetermined network priority parameter associated with packet-based data transfer for the user application over the network; means for determining a user defined priority index for associating with packet-based data transfer for the user application over the network; means for sending a request identifying data for downloading to user application, the request comprising the user defined priority index; and means for receiving the identified data.

There is also provided a device and method for sending packet-based traffic over a network, the device having a user application such as a VoIP voice call client which is associated with a predetermined network priority parameter (e.g. highest) associated with packet-based data transfer for the user application over the network. This may be provided in a dedicated header field or mapped from a field such as the IPv4 type of service (TOS) field. The device is arranged to determine a user defined priority index for the user application for associating with packet-based data transfer for the user application over the network. This may be extracted from a configuration file previously populated by a user of the device. The device sends data from the user application as a packet-based data transfer, the data packets each comprising the user defined priority index. , '

The device may be a server which is providing a file download service, and which receives the user defined priority index in a file request. Alternatively or additionally, the device may be a user device requesting a file, or sending data packets to another user device as part of a voice call application for example.

The user defined priority index may be adjusted dynamically, for example because the quality of a voice call has deteriorated, or because retrieval of a large file has become more urgent.

There is also provided a call control apparatus for admitting and controlling connection sessions of defined bandwidth. This might be implemented in a network gateway, a file retrieval server, or a wireless base station or access point supporting wireless connections to a number of wireless user devices. The apparatus is arranged to connect to a number of devices, each connection or connection session allocated a respective amount of bandwidth, typically dependent on the respective traffic or user application type. The apparatus determines a network priority parameter or a user defined priority index for each connection session, for example by inspecting packet headers, or as part of the higher layer call or connection set-up procedure. Where the bandwidth controlled by the apparatus exceeds a certain threshold, or a new connection session would exceed this threshold, the apparatus is arranged to reduce the bandwidth allocated to some of the connection sessions. This may be achieved in many known ways, however it is at least partially dependent on one or more determined user priority indexes, and the determined uspr priority index or network priority parameter of the other respective connection sessions.

In an embodiment there is provided a network node comprising: means for forming connection sessions with a number of devices, each session allocated a respective amount of bandwidth; determining the total bandwidth allocated for the connection sessions; means for determining user defined priority indexes within data packets of the connection sessions; means for reducing the bandwidth allocated to some of the connection sessions in response to the determined total bandwidth exceeding a predetermined threshold, the connection sessions on which bandwidth is reduced depending on the determined user priority index of data packets of the respective sessions.

Brief Description of the Drawings

Embodiments will now be described by reference to the drawings, by way of example only and without intending to be limiting, in which: Figure 1 is a schematic of a network coupled to two user devices and a server; Figure 2 illustrates an IP packet header field according to an embodiment; Figure 3A illustrates a data packet prioritising functions in a network router or switch according to an embodiment;

Figures 3B, 3 C, and 3D illustrate mapping to the different priority queues of figure 3 A using one-to-one, two-to-one, and three-to-one network priority to user defined priority level schemes;

Figure 4 illustrates a method for mapping data packets into the priority queues of figure 3A;

Figure 5 illustrates a method of selecting data packets for transmission from the different priority queues of figure 3 A according to an embodiment; Figure 6A illustrates a flow diagram for a file download application according to an embodiment;

Figure 6B illustrates a flow diagram for a VoIP call application according to an embodiment;

Figure 7 is a schematic for a user device;

Figure 8A is a flow chart of a method of operating the user device of figure 7 for a download application;

Figure 8B is a flow chart of a method of operating the user device of figure 7 for a voice call application;

Figure 9 is a flow chart of a method of operating a server for servicing a user device requesting a file download; and

Figure 10 is a flow chart of a method of reducing the bandwidth on lower priority calls.

Detailed Description

Figure 1 illustrates a system 100 comprising a first user device 110 coupled to a network 120 having one or more routers or switches 122, a server 130 coupled to the network 120, and a second user device 140 coupled to the network 120. Each user device 110, 140 comprises one or more user applications 114, 144 such as an e-mail client, a web browser, a VoIP voice call application, a video conferencing application, and a multi-media application. Each user application 114, 144 calls an application programmers interface (API) 112, 142 which builds data from the application 114, 144 into data packets for transmission over the network to another party 130, 140, and extracts data for the application from data packets received from other parties over the network 120.

The user devices 110, 140 may be coupled to the network 120 using an intermediate base station or access point 160, shown in dashed outline, in order to support wireless user devices. The base station or access point 160 will typically support wireless connections to a number of user devices 110, bandwidth for each connection typically being allocated depending on a user request for a particular user application 114 and the amount of bandwidth available to the base station. There is also shown, in dashed outline, a network gateway 170, which may be coupled to the access point 160 or user device 110. The gateway 170 may be used for call admission and control over the network 120, for example admitting call requests depending on bandwidth availability within the network and/or the priority or a QoS measure of the call.

The data packets 150 are typically Internet Protocol (IP) packets which include a data portion and a header portion 152 as is known. The header includes various fields as will be well known to those skilled in the art, and which include a Type of Service (TOS) field 154, and optionally an IP Options field 156 in an IPv4 packet 150. The TOS field 154 is used to indicate various service requirements for the packet, for example precedence level, minimise delay, maximise throughput, maximise reliability, minimise cost. This field is being replaced by the Differentiated Services Code Point (DSCP), however both comprise 8 bits. IPv6 comprises traffic class (TC) and flow label (FL) fields to implement service requests specific to certain types of traffic. Each user application is assigned TOS (or DSCP, TC or FL) values by the application 114. This is typically achieved by passing the API 112 a certain parameter as is known. Thus for example the router 122 is able to recognise a requirement to maximise bandwidth, and in response to route the packet through a high bandwidth path. .

The router 122 may also prioritise packets 150, for example allocating high priority packets to a high priority traffic queue for a particular network pathway or route. The high priority traffic is then transmitted ahead of any lower priority traffic. The priority assigned to each packet 150 may be derived from the TOS field by some predetermined algorithm for example, or a special additional parameter may be used such as a traffic class type in an IP options field 156. Various traffic classes together with a network allocated priority parameter or traffic-based priority value (1-6) were shown in Table 1 above. Thus the router 122 may also be able to recognise a high priority packet, for example from a VoIP application, and give this priority compared with another low priority packet from a file download application for example. This results in a low delay voice call with another user application 140 across the network 120. However a file download from the server 130 may take longer depending on the level of traffic on the network.

Figure 2 illustrates an IP options field 200 for an IP packet header which has been arranged according to an embodiment. As is known the first IP options byte 210 comprises a copy bit (C), two class bits (Class), and five option bits (Option). Currently, 24 of the 32 option values have been used, and so it is proposed to assign the value 25 to use with this embodiment. However any available IP option value could be used, or its equivalent in an IPv6 header or other type of packet. This first byte or octet may be followed optionally be a length byte indicating the total length of this IP options field. A further defined byte 250 follows which includes one user QoS on/off bit 255, three application type bits 260, and three user defined priority index bits 465. Alternative IP options fields or other arrangements could alternatively be implemented in order to achieve similar functionality to that described with respect to the embodiments. For example a wireless network embodiment may use MAC level parameters.

The user QoS on/off bit (UQ) 255 merely indicates whether a user has defined a user priority index for the current packet. The application type bits (App Type) 260 can be used to define the application or traffic type the packet is being used for, for example whether the packet relates to a VoIP call or a file download. Depending on the embodiment, the application type may be extracted from this field or by some other mechanism, for example a separate IP Options field including traffic class parameters. The value of this field 260 can be used directly as a network priority parameter (hereafter referenced X).

The user defined priority index bits (U.QoS) field 265 provides up to 8 values for this parameter, and contains the value assigned by the user to the user application associated with the current packet. The value of this field 265 can be used directly for a user defined priority index (hereafter referenced Y). As described below, this index (Y) can be used for prioritising the packet within the network.

Table 2 below illustrates the use of network priority parameters and user defined parameters for a number of different user applications. The user applications are voice service and audio phone applications such as Skype, video phone and conference applications, interactive media (e.g. games) and video on demand applications, email, paging and fax applications, remote login and data on demand applications, and file transfer and retrieval applications. The table shows standard connection bandwidth requirements, average bandwidth for the session, maximum bandwidth requirements, average session connection time, a traffic based or network priority parameter (X), together with a user defined priority index (Y) for each application type for a particular user.

Table 2

Table 3 Table 4 Table 5 As can be seen, this user rates file download type applications more highly than voice call type applications. This may suit a user who is working in R&D and thus has a large requirement for fast access to externally located documents, with the next highest priority application being remote login and data on demand services, then voice calls, and so on. Such a user defined QoS policy may well be applicable to users or workers who are not heavy phone users, whereas a marketing person may well require phone based applications to have highest priority.

Tables 3, 4, and 5 show user defined priority indexes for different user types. Table 3 treats the QoS ratings or values the same as the network, which may be suitable for frequent phone and video phone callers. Table 4 gives higher user priority to emailing, paging, and faxing, voice only calls, followed by remote login and file download. This user defined QoS scheme may be suitable for service personal who reply to emails, answer calls, and download files frequently. Table 5 gives higher priority to interactive multimedia and video on demand, followed by file download and voice. This scheme may be suitable for video viewers, gamers and other interactive media users.

The user defined priority indexes (Y) in these tables can be used by the router 122 to map traffic or packets associated with different user applications. Where a user priority index (Y) is not defined or for legacy arrangements, the router 122 may revert to their respective network priority parameter (X).

Figure 3 A illustrates a prioritising part of a router 122 or switch according to an embodiment. This prioritising arrangement 300 receives packets following routing. The incoming packets are associated with a network priority parameter (X= 1-6) and/or a user defined priority index (Y= 1-6). Where included, the user defined priority index (Y) may be provided in an IP Options header field built by the API 112 of a user device 110 or a server 130, or in any other suitable manner. The network priority parameter (X) may be provided in the same or a different IP Options header field built by the user device 110 or server 130, by mapping from the contents of the TOS field, or any other Suitable manner. Thus the two priority measures (X and Y) may be determined simply by extracting the contents of the App Type 260 and U.QoS 265 fields from an appropriate IP Options field 200 of the header 152 of the respective packet 150. However other suitable means for determining the network priority (X) and where present the user defined priority index (Y) may be used. The incoming packets are received into the input of a FIFO queue 310, and from there are mapped into one of three FIFO priority queues 230 (Ql, Q2, Q3) of decreasing priority from Ql to Q3 by a priority or mapping function 320.

Where received packets are only associated with or contain a network priority parameter (X) and no user defined priority index (Y), they are prioritised according to their network priority parameter (X) only. Table 2 above shows the types of user applications assigned the different network priority parameters (X), for example a voice call application such as Skype is allocated a network priority parameter (X) of 1, whereas e-mail and paging applications are assigned a network priority parameter (X) of 4. In the arrangement shown, incoming packets having a network priority level X=I or X=2 are input into the highest priority queue Ql 330_ql. Similarly incoming packets having a network priority level X=3 or X=4 are input into the second priority queue Q2 330_q2, and incoming packets having a network priority level X=5 or X=6 are input into the lowest priority queue Q3 330_q3. A selection function 340 then selects packets from the three priority queues 330 on , for example, a round robin basis, typically with more selection time given to the higher priority queues. The selected packets are input to a FIFO transmission or output queue 350 for transmitting to the next router or network gateway. In this way, the data packets are prioritised for transmission dependent on their network priority parameter (X) by mapping them to different priority queues from which packets are selected for transmission in the order of the priority queues.

Where the received packets are associated with or contain a user defined priority index (Y), any associated network priority parameter (X) is ignored in this embodiment; and then prioritisation for transmission is based solely on the user defined priority index (Y). Table 2 shows a user defined priority index (Y=l-6) for each application type, and this may be different for different users as discussed above (see Tables 3, 4, 5). In this example there is an X-to-Y mapping or ratio of one-to-one, such that incoming packets having a user defined priority index Y=I or Y=2 are input into the highest priority queue Ql 330_qi, along with packets having a network priority parameter X=I or X=2, and no user defined priority index (Y). Similarly incoming packets having a user defined priority index Y=3 or Y=4 are input into the second priority queue Q2 330_q2 (together with X=3 and X=4 packets), and incoming packets having a user defined priority index Y=5 or Y=6 are input into the lowest priority queue Q3 330_q3! (together with X=5 and X=6 packets).

Where packets of more than one. network priority parameter (eg X= 1,2) or user defined priority index (eg Y= 1,2) are mapped to the same queue (Ql), then one or more additional buffers 335 are used to accommodate lower priority packets. Here Y=I is taken as the highest priority value, then X=I, then Y=2, then X=2. Li the figure, only the buffers 335ql, 337ql, 339ql associated with the highest priority queue 330_ql and the buffers 335q2, 337q2i, 339q2 associated with the intermediate priority queue 330q2 are shown, and into which the lower priority packets (Y=2, X=I, X=2 for Ql and Y=4, X=3, X=4 for Q2) are input by the selection function; whilst the higher priority packets (Y=I for Ql and Y=3 for Q2) are input into the transmission queue 350 by the selection function 340. Periodically the lower priority packets (Y=2, X=I, X=2) are input into the transmission queue 350. Similar buffer arrangements also exist for the lower priority queue Q3.

Various alternative embodiments are contemplated, for example twelve (for X=I- 6 and Y=l-6) separate priority queues 330 and no buffers 335, 337, 339 may be implemented. However in this case the data packets are still prioritised for transmission dependent on their respective network priority parameter (X) or where present their user defined priority index (Y).

As noted, where an incoming packet has a Y value, its X value is ignored, thus for example a packet having X=6 (lowest available network priority parameter) but Y=I (highest available user defined priority index) will be mapped to the highest priority queue Ql. In this way a user is able to influence the prioritising of packets over a network comprising routers or switches according to this embodiment. Various embodiments are envisaged in which both the network priority parameter (X) and the user defined priority index (Y) can be used to prioritise packets for transmission.

A one-to-one mapping of X and Y values for incoming packets may be maintained for any number of priority queues 330. For example were there six such queues (Q1-Q6), incoming packets would be mapped as follows: Ql receives X=I, Y=I; Q2 receives X=2, Y=2; Q3 receives X=3, Y=3; Q4 receives X=4, Y=4; Q5 receives X=5, Y=5; and Q6 receives X=6, Y=6. However asymmetric mappings or relative prioritising of X and Y values can also be implemented.

Figure 3B illustrates schematically the mapping of the packets to three priority queues Q1-Q3 based on a one-to-one mapping of Y-to-X values. As described above, packets having the same values for X and Y are mapped into the same or similarly prioritised queue 330. Figure 3C illustrates an alternative two-to-one X-to-Ϋ mapping scheme or ratio which may be employed by the priority function 330. In this embodiment, X values are weighted by a ratio of two-to-one in terms of prioritising respective packets for transmission. Thus packets having X=I, X=2, or Y=I are mapped to the highest priority queue Ql, packets having X=3, X=4, Y=2 are mapped to the intermediate priority queue Q2, and all other packets (X=5, X=6, Y=3, Y=4, Y=5, Y=6) are mapped to the lowest priority queue Q3. This arrangement weights the operator's or network priority parameter (X) more importantly than the user defined priority index (Y), however it still allows the user some influence over packet propagation through a network having these modified routers. In an alternative arrangement, the user defined priority index may be weighted more heavily than the network priority parameter, for example to provide a one-to-two X-to-Y mapping. Figure 3 C shows a further mapping option in which X values are weighted by a ratio of three-to-one (compared with Y values) in terms of prioritising respective packets.

Y X

Table 6

Table 6 shows a two-to-one Y-to-X mapping scheme. Approximate overall priorities are indicated by the larger numbers to the side; for example Y=I and Y=2 have the highest priority through the router, X=I the next, Y=3 and Y=4 next, then X=2, then Y=4 and Y=5, then X=3, then X=4, X=5, and finally X=6. This could be implemented for example in a router prioritising arrangement (300) having four priority queues 330 (Ql, Q2, Q3, Q4), each with two buffers 335 and 337. The first priority queue Ql receives packets having Y=I, Y=2 and X=I, with Y=2 and X=I packets being buffered by the selection function to buffers 335 and 337 respectively. Similarly the second priority queue Q2 receives Y=3, Y=4, and X=2 packets; the third priority queue Q3 receives Y=5, Y=6, and X=3 packets, and the lowest priority queue Q4 receives X=4, X=5, and X=6 packets.

Figure 4 illustrates in more detail a method for mapping incoming packets to the priority queue 530 which could be implemented by the priority or mapping function 320 of figure 3 A. The method [400] of figure 4 first determines whether a user defined priority index (Y) is included in the packet header [410]. This can be done by checking the header for an IP options field (200) in which the Options value (Option - 210 bits 03- 07) is 25 or some other predetermined value, and if so, checking the user QoS on/off, bit (255). Alternatively in a different router implementation this task may have already been performed by an earlier process and the incoming packet already associated with an X and/or Y value. The method then simply checks whether a Y value is associated with the incoming packet.

If there is no user defined priority index [405N], then the method examines the network priority parameter (X) in order to determine how to map the packet to the priority queues (330). This network priority parameter X may have already been associated with the incoming packet by an earlier process, or it may be derived directly from the application type field (260) in the IP Options header field (200) of the packet. In a further alternative this X value may be mapped in a predetermined way from the values in the packet header's TOS field, or other header field(s). The method [400] then checks whether the network priority parameter X=I or X=2 [410], and if so [410Y] transfers or maps the corresponding packet to the highest priority queue Ql [415]. If not [410N], the method determines whether the network priority parameter X=3 or X=4 [420], and if so [420Y] maps the packet to the second priority queue Q2 [425]. If not [420N], the packet is mapped to the lowest priority queue Q3 [430]. If the packet header does include or is otherwise associated with a user defined priority index Y [405Y], then the method examines the user defined priority index (Y) in order to determine how to map the packet to the priority queues (330). The Y value may have already been associated with the incoming packet in some manner, for example a tag, by an earlier process, or the method may obtain this Y value directly from the user priority index field (265) from the IP Options field (250) in the packet header. In this case, any network priority parameter X is ignored. The method [400] then checks whether the user defined priority index Y=I or Y=2 [435], and if so [435Y] transfers or maps the corresponding packet to the highest priority queue Ql [440]. If not [435N], the method determines whether the user defined priority index Y=3 or Y=4 [445], and if so [445Y] maps the packet to the second priority queue Q2 [450]. If not [445N], the packet is mapped to the lowest priority queue Q3 [455].

The charging or billing function of the router may correspond to the priority queues 330 into which respective packets are mapped, and so the user can designate certain user applications to have high priorities (Y) so that they are transmitted rapidly through the network, though at an increased cost.

Figure 5 illustrates a method for implementing the selection function 340 of figure 3 A. In this embodiment, the selection function 340 and the priority or mapping function 320 work together to prioritise the packets for transmission, by selecting the highest priority packets (by X or Y value) to be mapped or transferred to the transmission or output queue 350 first. The method [500] of figure 5 first selects one of the priority queues 330 on which to operate [505]. Typically the method will select the priority queues 330 (Q1-Q3) in a round-robin fashion, though typically spending more time on the higher priority queues (e.g. Ql) as is known in order to ensure faster throughput and reduced delay for packets in this queue compared with packets in lower priority queues (e.g. Q2 and Q3). Various selection mechanisms will be known to those skilled in the art in order to implement the appropriate prioritising of packets from these queues. For simplicity of explanation the method is described with respect to operation on the packets in the second priority queue Q2 and indicated generally as 520. Similar methods will be implemented for the highest priority queue (Ql) - indicated as 510, and the lowest priority queue (Q3) - indicated as 570. Following selection of the intermediate queue (Q2) routine [520], the method [500] initially starts a queue timer [522]. Typically the queue timer values will be longer for the higher priority queues, and when the timer expires, the selection function 340 or method [500] moves on to another queue [510 or 570]. Timers associated with the buffers

335q2 (Y=4), 337q2 (X=3), and 339q2 (X=4) are also started [525]. Again the values of these timers depend on the relative priorities of the buffers or values of the respective network priority parameters (X) and user defined priority indexes (Y). For example the timer for the Y=4 packet buffer 235q2 may be half the duration of the timer for the X=3 packet buffer 237q2, which in turn may be half the duration of the timer for the X=4 packet buffer 239q2. When the buffer timers expire, their contents are transferred to the output or transmission queue 350, and so generally the higher the priority of the buffer the shorter the duration before the timer will expire. The next (or first) packet in the FIFO priority queue Q2 330q2 is then examined for its network priority parameter (X) or user defined priority index (Y) as appropriate [527]. The way in which the packet is marked (X or Y values) then determines where it is transferred to [530]. If the packet is marked with Y=3 (the highest priority in this arrangement) [530y=3] then the packet is transferred to the output or transmission queue 350 [532]. If the packet is marked with Y=4 (the second highest priority in this arrangement) [530y=4] then the packet is transferred to the Y=4 buffer 335q2 [535]. If the packet is marked with X=3 (the third highest priority in this arrangement) [530x=3] then the packet is transferred to the X=3 buffer 337q2 [537]. If the packet is marked with X=4 (the lowest priority in this arrangement) [530x=4] then the packet is transferred to the X=4 buffer 339q2 [539].

The method [500] then determines whether the timer associated with the Y=4 buffer 335q2 has expired [542], and if so [542Y] the contents of this buffer 335q2 are transferred to the output or transmission queue 350 [545]. This timer (for buffer Y=4 335q2) is then re-started [547]. The method then moves on to determine whether the timer associated with the X=3 buffer 337q2 has expired [550], and if so [550Y] the contents of this buffer 337q2 are transferred to the output or transmission queue 350 [552]. This timer (for buffer X=3 337q2) is then re-started [555]. The method then moves on to determine whether the timer associated with the X=4 buffer 339q2 has expired [557], and if so [557Y] the contents of this buffer 339q2 are transferred to the output or transmission queue 350 [560]. This timer (for buffer X=4 339q2) is then re-started [562]. The method then moves on to determine whether the queue timer has expired [565]. If so [565Y], then a new priority queue (Ql or Q3) is selected [505]. If the Q2 queue timer has not yet expired [565N], then the next packet in the Q2 queue is examined [527].

The use of the above described arrangements to provide user control over transmission of packets over the network 120 can be employed for a number of different situations and applications. Figure 6A illustrates control signal and traffic flow for a file download application. In this application [600], a user application 114 on a user device 110 first requests the download service from a server 130 using the user defined priority index (Y) for this user application [605]. The API 112 which builds the packets for the application 114 may be arranged to retrieve the appropriate user defined priority index for the calling application 114 from a pre-configured configuration file as described below, before constructing the request packet(s) and sending to the server 130. The server receives the request, and starts forwarding the requested download towards the user application 114 over the network (router/switch) [615]. The requested download or data is sent as a series of data packets which are associated with a network priority parameter (X) dependent on the requesting user application as previously discussed. This association may be achieved by including this parameter (X) within an appropriate header field (e.g. 260) of the packet header, or mapping it to a different header field (e.g. TOS 154). Or alternatively the association may be made at a higher layer, for example as part of a call set-up procedure. The server 130 builds packets containing the download data, and associates them with the user defined priority index (Y) from the request [610]. This may be achieved by inserting an IP Option field into an IPv4 packet with the received user defined priority index (Y) inserted into each of the packets before sending to the router 122 in the network 120. The router prioritising the packets according to their user defined priority index as described previously, and forwards them on to the user device 110 and its API 112 [620]. The API 112 extracts the data from the received packets, and passes this on to the user application 114 [625]. The user device and server related aspects of this application [600] are described in more detail below.

Figure 6B illustrates control signal and traffic flow for a two-way voice over internet protocol (VoIP) voice call application. In this application [630], a user application 114 on a user device 110 initially registers with a VoIP server 130 [635]. Similarly another or second user device 140 also registers with the VoIP server 130 [640]. The user application 114 on the first user device 110 initiates a voice call by sending a "call another user" request to the server 130 [645]. As is known, such a request will include an identifier for the called party, and may optionally include a user defined priority index (Y). Alternatively this index (Y) may be transferred to the server with the registration [635], or it may not be used by the server/second device 130/140. The server 130 forwards the call to the second user device 140 and its voice call user application 144 [650]. If the second user device answers the call, an answer message is sent back to the server [655], which then notifies the first user [860], and joins the two legs of the call together (665, 670, 675, 680, 685, 690). The user application 114 on the first user device 110 then forwards user data (voice) to the API 112 [665] which builds packets for sending across the network. The API 112 includes the user defined priority index for the user application 114 in each packet as illustrated with respect to figure 2, before forwarding these packets to a router 122 in the network 120 [670]. The router prioritises ^• the received packets as previously described before forwarding to the second user device 140 [675].

The second user application 144 of the second user device 140 receives these packets and may forward its own packets back towards the first user device 110 [680]. Packets sent by the API 142 of the second user device 140 may include a user defined priority index (Y2) provided by the second user. Alternatively the second user device may include the user defined priority index (Y) provided by the first user (via the server), or they may not include any user defined priority index and instead rely on an associated network priority parameter (X). Where included, any user defined priority index (Y) associated with packets sent from the second user device 140 to the router 122 [680] are used for prioritising in the router 122 as previously described, before being forwarded onto the API 112 of the first user device 110 [685]. The API 112 extracts the data from these received packets and forwards this on to the first user application 114 [690]. The user device and server related aspects of this application [600] are described in more detail below. Figure 7 illustrates a user device (110, 140) 700 according to an embodiment. The user device 700 includes a number of user applications 710 (114, 144 in figure 1) typically stored and executed as software, for example an e-mail client, a VoIP phone call client, a video call client, a browser, and a file download application. The device 700 also comprises a communications interface or application programmers interface (API) 720 (112, 142 in figure 1) which is called by the user applications 710 in order to build packets 725 from data 715 received from the user applications 710, for sending across a communications channel such as a network 750. The API 720 also receives packets and extracts data 715 from the packets for passing to the respective user application 710 as is well known. The user device 700 additionally comprises a quality of service (QoS) agent 730 and a configuration file 735. The QoS agent 730 generates a user entry graphical user interface (GUI) 740 in order to allow a user of the device 700 to enter user defined priority indexes (Y) for each of the user applications 710. These indexes are stored in the configuration file 735 and associated with a respective user application 710 for use by the API 720. When building and sending packets 725, the API 720 interrogates the configuration file 735 for the user defined priority index (Y) for the user application 710 it is building a packet 725 for, and adds an IP Options field 200 to the packet header which includes the user defined priority index 265, together with an "on" bit 255 to indicate that this packet uses this mechanism. Typically the network priority parameter (X) for a user application 710 will be passed to the API 720 by the user application 710, and may also be included in the IP Options field 200 in the App Type field 260. The QoS agent 730 can also be used to modify any file download requests from a file download application 710 to a server 130 to include the user defined priority index for that application 710.

The user device 700 may be arranged to allow a user to change the user defined priority index (Y) for a user application 710 during data transfer associated with the user application 710. Thus the API 720 may periodically retrieve the index (Y) from the configuration file during a voice call or data download for example. The user may increase the user defined priority index (Y) for downloading a large file when the retrieval of this has become more urgent. Similarly a user may increase the index for a voice call during the call if it is deteriorating, for example increasing delays or echoes. Figure 8A illustrates a method of operation of a user device 700 for providing a file download application 600. The method [800] initially calls the API 720 which is configured to determine whether a user defined priority index (Y) is stored for this application, and if so to include this in any request for the file download server [810]. The determined index (Y) may be included in the data part of the packet, or within the header as described above for interpretation by the server, and the API forwards the request to the server [815], Packets from the server are received as normal [820], and passed to the file download application [825].

Figure 8B illustrates a method of operation of a user device 700 for providing a two-way VoIP phone call application 630. The method [830] initially registers with the server [835], then either a user of the device may call another party [840], or another party may call the user [845]. Either the user application receives a "call answered" message [850], or the user application sends a "call answered" message to the calling party [855], and the application calls the API 720 in order to transfer audio data [860]. Audio data 715 provided to the API 720 from the user application 710 are received by the API [865] which begins to build this content into packets 725 [870]. The API 720 is configured to determine whether a user defined priority index (Y) is stored for this application, and to extract this [875]. The determined index (Y) is included in each packet built for the application [880] as described above with respect to figure 2 or in any other suitable manner as would be appreciated by those skilled in the art. The API may also include the network priority parameter (X) in the packet as described with respect to figure 2, or it may be integrated using a different header field, for example a suitable mapping to the TOS field 154. Alternatively, the network priority parameter (X) may be omitted when a user defined priority parameter is included in the packet. The API then forwards these packets to the other user device [885]. Packets 725 from the other device are received as normal [890] by the API 720, and their data or contents 715 passed to the VoIP application [895]. A similar method [830] may be implemented on the second or other user device.

Figure 9 illustrates a method of operating a server 130 in order to implement a file download application according to an embodiment. The method [900] initially receives a file download request from a user application 710, which request includes a user defined priority index (Y) [905]. After locating the requested file, the server 130 calls its API for building packets for communications across the network 120 [910]. The file contents are retrieved [915] and the API starts building them into packets [920]. The API additionally includes an IP options field incorporating the received user priority index (Y) as previously described with respect to figure 2 or in some other suitable manner [925]. The server API may additionally include a predetermined network priority parameter (X) in this same header field 200. Alternatively this may be already associated with a existing parameter (eg TOS) in the packet header, and so may not require specific inclusion in the packet headers. These packets are then sent towards the requesting user over the network [930]. Any routers 122 in the network 120 which are capable of handling the user defined priority index (Y) may then prioritise these packets as described for example with respect to figures 3, 4 and 5.

Whilst embodiments so far have been described with respect to associating a user priority index (Y) with traffic or data packets to/from a user application by including this index in each packet header, this association may be made at a higher layer for example a connection session or call. Thus packets related to a particular call may be associated by certain network nodes (e.g. gateway, base station, or server) with the same user defined priority index (Y). Any network priority parameter (X) may also be associated in the same way.

Figure 10 illustrates a method for allocating bandwidth to connection sessions depending on the user defined priority index (Y), and which may be implemented on the server 130, a base station or access point 160 coupled to a user device 110, or a network gateway 170 which controls call admissions to the network 120. The method [1000] receives a request for connection from a user application [1005]. This request may be to a base station 160 in order to provide a wireless connection session of defined bandwidth (a call) for a user application 114; or the request may be to a server 130 to provide a file download service, video-on-derhand, email or other session; or the request may be to the gateway 170 to admit a new connection session of defined bandwidth (a call) to the network.. The method then determines the QoS scheme of the request, for example whether a user defined priority index (Y) has been specified and/or what type of application the request relates to [1010]. If a user defined priority index (Y) has not be specified [1015N], then a conventional QoS scheme is applied [1020]. For example the server allocates bandwidth to the session based on the application type (e.g. 3Mbps average and 6Mbps maximum for gaming). If there is insufficient bandwidth available to the base station or server to provide this new session, then the method may reduce the bandwidth allocated to applications having a lower network priority parameter as is known. An example bandwidth reduction scheme is described in F. Prihandoko, M.H. Habaebi, and B.M. Ali, "Adaptive Call Admission Control for QoS Provisioning in Multimedia Wireless Networks", Computer Communication, Elsevier, 2003, Vol. 26, pp. 1560-1569.

If however a user defined priority index (Y) is specified [1015Y], the method allocates bandwidth to the session based on the application type (e.g. 3Mbps average and 6Mbps maximum for gaming or 30Kbps for VoIP phone calling) [1025]. The application type and/or a requested bandwidth amount may be extracted from a specific parameter included in the connection request data as is known. The method [1000] then determines whether there is sufficient bandwidth available given the other sessions currently being supported [1030]. Thus the method may determine the total bandwidth allocated to all current connection sessions supported by the server 130, base station 160, or network 120 as determined by the gateway 170. Various methods of determining this total bandwidth will be known to those skilled in the art. If there is available bandwidth [1030Y], then the connection session is admitted or formed, such that data can be transferred between the server and the user device [1035]. If however there is insufficient bandwidth available [1030N], then the method reduces the bandwidth allocated to lower priority connection sessions or calls [1040]. Unlike a conventional QoS scheme however, the priority of the connections supported by the server 130, base station 160 or gateway 170 is based on their respective user defined priority indexes (Y) instead of their respective network priority parameters (X). The prioritising of connections can adopt the various X and Y prioritising scheme adopted earlier, for example a ranked list of applications may appear as follows: 1) Y=I; 2) X=I; 3) Y=2; 4) X=2 ... 11) Y=6; X=6. For example if the requesting user application has Y=2, then all applications with X>1 and Y>2 in this embodiment would have their bandwidth reduced in order to provide additional bandwidth for the requesting connection. However connections having X=I, X=2, or Y=I would remain unchanged. Again the Prihandoko scheme noted above or another call admission bandwidth reduction scheme could be used in which the priority values used are taken as the user priority index (Y) where available. Once the bandwidth of lower priority applications has been reduced, the method determines whether there is now sufficient bandwidth for the requesting application [1045]. If so [1045Y], the connection is admitted or formed as is known [1035]. If however there is still insufficient bandwidth for the requested session [1045N], then the user application is informed of this and the connection request fails [1050].

After admission of a new connection session [1035], the call or session is monitored for termination [1055]. Once termination of the session has been detected [1055Y], the bandwidth allocated to the session is returned to the pool of available bandwidth of the server [1060]. Lower priority applications which had their bandwidth reduced, may now have there original bandwidth allocation restored.

The skilled person will recognise that the above-described apparatus and methods may be embodied as processor control code, for example on a carrier medium such as a disk, CD- or DVD-ROM, programmed memory such as read only memory (Firmware), or on a data carrier such as an optical or electrical signal carrier. For many applications embodiments of the invention will be implemented on a DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit) or FPGA (Field Programmable Gate Array). Thus the code may comprise conventional programme code or microcode or, for example code for setting up or controlling an ASIC or FPGA. The code may also comprise code for dynamically configuring re-configurable apparatus such as reprogrammable logic gate arrays. Similarly the code may comprise code for a hardware description language such as Verilog ™ or VHDL (Very high speed integrated circuit Hardware Description Language). As the skilled person will appreciate, the code may be distributed between a plurality of coupled components in communication with one another. Where appropriate, the embodiments may also be implemented using code running on a field-(re)programmable analogue array or similar device in order to configure analogue hardware.

The skilled person will also appreciate that the various embodiments and specific features described with respect to them could be freely combined with the other embodiments or their specifically described features iri general accordance with the above teaching. The skilled person will also recognise that various alterations and modifications can be made to specific examples described without departing from the scope of the appended claims.

Claims

1. A network node for receiving and transmitting packet-based data across a network, the node comprising: an input for receiving a data packet; means for determining a network priority parameter and a user defined priority index from the data packet; means for prioritising the data packet for transmission dependent on the network priority parameter or the user defined priority index, and arranged so that the data packet is prioritised dependent on the user defined priority index in response to determining a user defined priority index from the data packet.

2. A network node according to claim 1, wherein the network priority parameter and the user defined priority index are' contained within a respective data packet and each comprise one of a plurality of predetermined values.

3. A network node according to claim 2, wherein the means for prioritising is arranged such that received packets are prioritised for transmission dependent on respective user defined priority index or network priority parameter values in one of the following ratios of user defined priority index values to network priority parameter values: one-to-one; two-to-one; one-to-two; three-to-one; one-to-three.

4. A network node according to any one preceding claim, wherein the means for prioritising the data packet comprises a plurality of priority queues from which data packets are selected for output to a transmission queue, and a mapping function which is arranged to map received data packets into one of the priority queues depending on their respective user defined priority index or if none their respective network priority parameter.

5. A network node according to any one preceding claim, wherein the ^"data packets are Internet Protocol packets comprising a header having an IP options field containing the user defined priority index.

6. A method of receiving and transmitting packet-based data across a network, the method comprising: . determining a network priority parameter from a received data packet; in response to determining a user defined priority index from the data packet, prioritising the packet for transmission dependent on the determined user defined priority index, or prioritising the packet for transmission dependent on the determined network defined priority parameter.

7. A device for connecting to a network, the device comprising: means configured to send data associated with a user application as a series of data packets over the network, the data packets being associated with a predetermined network priority parameter dependent on the user application; means for determining a user defined priority index for the user application; means for associating the user defined priority index with each data .packet prior to sending.

8. A device according to claim 7, wherein the means for sending and associating comprises means for building the data associated with the user application into the series of data packets each comprising a header having the user defined priority index and the network priority parameter.

9. A device according to claim 7 or 8, further comprising means for adjusting the user defined priority index associated with the data packets during sending of the data packets in response to receiving an adjusted user defined priority index from a user.

10. A device according to any one of claims 7 to 9, wherein the device is a server and the means for determining a user defined priority index for the user application comprises means for receiving a request from a user device identifying the data associated with the user application, the request comprising the user defined priority index.

11. A device according to any one of claims 7 to 9, further comprising the user application and means for receiving the user defined priority index in response to user input.

12. A method of transmitting packet-based data across a communications network, the method comprising: sending data associated with a user application as a series of data packets over the network, the data packets being associated with a predetermined network priority parameter dependent on the user application; determining a user defined priority index for the user application; associating the user defined priority index with each data packet prior to sending.

13. A call control apparatus for admitting and controlling connection sessions of defined bandwidth in a communications network, the apparatus comprising: means for forming connection sessions with a number of devices, each connection session being allocated a respective amount of bandwidth; means for determining a network priority parameter or a user defined priority index for each connection session; means for reducing the bandwidth allocated to some of the connection sessions in response to the bandwidth of all the connection sessions exceeding the total bandwidth of the network, the identity of the connection sessions on which bandwidth is reduced depending on the determined user priority index of at least one connection session and the determined user priority index or network priority parameter of the other respective connection sessions.

14. A call control apparatus according to claim 13, further comprising means for receiving a request for admitting a new connection session having a defined bandwidth, together with a user defined priority parameter, and means for reducing the bandwidth allocated to some of the connection sessions in response to the bandwidth of the new connection session exceeding the available bandwidth of the network.

15. A method of admitting and controlling connection sessions of defined bandwidth in a communications network, the method comprising: forming connection sessions with a number of devices, each connection session being allocated a respective amount of bandwidth; determining a network priority parameter or a user defined priority index for each connection session; reducing the bandwidth allocated to some of the connection sessions in response to the bandwidth of all the connection sessions exceeding the total bandwidth of the network, the identity of the connection sessions on which bandwidth is reduced depending on the determined user priority index of at least one connection session and the determined user priority index or network priority parameter of the other respective connection sessions.