The present invention relates to a method and apparatus for controlling data flow on a data network, and in particular for improving traffic flow for traffic with a need for low levels of latency such as telephone traffic.

Originally, telephone systems were built on circuit switched networks. The internet has developed based on packet switched networks. However, a Voice over Internet Protocol (VoIP) has been developed to allow telephone calls to be made over a packet switched network operating the Internet Protocol (IP).

Broadband Internet access has provided the opportunity to deliver all data and voice services over a common telecommunications infrastructure. The bandwidths available on ADSL (Asymmetric Digital Subscriber Line) are more than enough to deliver several concurrent telephone calls using VoIP (Voice over IP) together with a data service, all over a single access line. This converged method of telecommunications services delivery can provide significant cost savings for businesses, and an opportunity for service providers to increase their revenues and profits through additional value added services.

As packets travel through a data network, any bottleneck in the network may cause a queue to form. For these reasons, packets are subject to varying delays due to variance in the queuing delays at the various nodes in the network. The degree of variance in the latency of the network is termed "jitter". Normal web-based data is not very susceptible to network latency but needs high bandwidth. However, transmitting high quality voice services over IP networks requires moderate bandwidth with low degrees of jitter.

In today's data networks, the queue forming bottlenecks are often in the access network to the internet, although queues may also form elsewhere on the internet. The access networks for ADSL are commonly run by a telephone company (Telco), using telephone lines for data transmission. Other types of access network include cable links

or wireless links. The bottlenecks are primarily caused by the access line or link itself, due to its low bandwidth compared with other parts of the internet.

The VoD? media, gateways have techniques for dealing with jitter in the received data streams. Typically they can cope with up to 60ms or 70ms of jitter but any jitter in the received stream beyond that will typically cause breaks in the reconstructed voice, and result in discarded data. Thus, a typical "jitter budget" for such a network is around 60ms, which can be applied to the data stream.

The problems of jitter apply not only to telephone conversations over the internet, but also to any kind of real-time audio, video or other time-critical data transmitted over a data network. Although jitter also affects non time-critical data, it is a major quality issue where the timing of receipt of the data is important.

The present invention provides a method of traffic control for a data network and a data network traffic controller apparatus which is adapted to reduce jitter for high priority data such as real-time audio in the upstream, downstream or both, by dynamically adjusting data flow of less time-critical data according to the amount of high priority data traffic passing through the network. Data traffic of a first type, such as VoIP data packets, may be considered to be high priority traffic, and data traffic of a second type, such as TCP packets, may be considered to be lower priority traffic.

One aspect of the present invention provides a method and apparatus for reducing jitter that arises due to a queue of data on a data network. The apparatus comprises a data network traffic controller for controlling flow of traffic between a first part and a second part of the data network. The data network may comprise any two computing devices connected together by a data link, such as a cable link, wire link, wireless link, bluetooth link, infrared link, etc. Each of the first and second parts of the data network may comprise a separate "network" in its own right, e.g. a LAN, or the internet, or may be a single computing device, e.g. a multimedia PC. Preferably, but not essentially, the data network is based on an IP network carrying TCP and VoD? packets. •

The data network traffic controller may then classify the packets, by identifying packets of a particular type. The packet classification may use any of several possible methods to classify the packets. One of the simplest methods is the use of the protocol field of the IP header to identify the protocol used in each packet. However, any of the fields in the packet, including the packet payload itself, could be used to classify the packets. For example, the packet classification could be a lot more specific, and use TCP or UDP port numbers, or IP addresses.

Certain packet classes are high priority, and other packet classes are not. Packets may, for example, be identified as being of either a first type or a second type, according to the priority of their packet class. E.g., one type may comprise packets of a particular protocol, and the other type may comprise packets of a different protocol, or may simply be defined as all packets that are not of the particular protocol.

In one example, the packet classifier may identify only packets of one protocol, such as TCP, and classify any non-TCP packets as having a high priority. Non-TCP packets may include VoIP and other protocols such as UDP packets, which are sometimes used for streamed internet data. In another example, the packet classifier may identify only VoIP packets, and classify any non-VoIP packets as having a lower priority. In a third example, the packet classifier may identify packets as using any of several different protocols. For example, it may identify VoIP packets and classify them as high priority, and identify TCP packets and classify them as lower priority. For any packets of another protocol which have not been identified, e.g. packets which are not TCP or VoIP, the packet classifier may either be configured to classify these as high priority or the packet classifier may be configured to classify these as a lower priority. The packet classifier may categorise packets into priority groupings by storing data or labelling them to indicate their priority. However, the packet classifier may simply use knowledge of the ^■ classification to tell the controller how to deal with an incoming packet.

hi embodiments of the invention, the data network traffic controller detects whether there is any current traffic of high priority, and uses this information to .decide whether or not to alter- the data flow of lower priority traffic, and/or to what extent to alter the , data flow. To obtain an indication of how much data traffic of a particular type is

moving through the network, the controller may use its identification of data packets. Alternatively, the controller may obtain an indication from an external source, such as a proxy server or other device on the network, of the amount of high priority traffic passing between the first and second parts of the network. For example, the controller may obtain an estimate or measurement of the total bandwidth used by traffic of a particular type, or of the number and/or type of connections in progress between different nodes of the network. Another possibility is that the controller may use an indication of uplink traffic to estimate downlink traffic, or vice versa.

The indication may be an estimate or maybe a measurement of the amount of high priority traffic. The indication may simply indicate whether there is currently no high priority traffic, or whether there is currently at least one high priority traffic connection established. Alternatively, the indication may indicate a numerical amount of high priority data likely to be transferred over a next time period, or a numerical indication of the number of high priority traffic connections that are currently established. In embodiments of the invention, the indication of traffic flow is obtained dynamically, to allow the controller to adapt its behaviour to the changing conditions on the network.

The controller may store lower priority packets in a queue until bandwidth is available to send them to the second part of the data network. The controller may control the bandwidth available for packets to pass from the first part of the data network to the second part of the data network, and may divide the available bandwidth into a first part for high priority packets and a second part for lower priority packets, if the current traffic flow includes high priority packets. However, it is not essential to the invention that the data network traffic controller should control the bandwidth, because in embodiments where the bottleneck already occurs at the data network traffic controller, there is no need to move the queue.

The controller can modify flow control parameters in packets of a protocol having a built in flow control mechanism, such as TCP, where these packets are passing from one-part to the another part of the data network, to cause a reduction in flow of data in • the opposite direction through the data network. For-example, the controller may alter the header of all TCP packets.

One embodiment of the invention involves modification of the TCP window size, to prevent too much unacknowledged TCP data being sent. This is particularly useful to reduce the length of transmission queues in the downlink from the internet to a LAN, but can still have a beneficial effect if used to reduce data flow in the uplink.

A further aspect of the present invention provides a method and apparatus for managing data transmission over a low bandwidth link, in order to minimise the queuing delay for high priority packets. This involves keeping the size of each packet below a predetermined maximum, to prevent any individual packet taking too much time for transmission. One embodiment of the invention involves modification of the maximum segment size parameter in the TCP header, which is an indication of the maximum packet size, to reduce the maximum wait for a packet to be dispatched. This is most useful for reducing the size of packets in the uplink to the internet, though could also be used for reducing the size of packets on the downlink.

The data network may have more than one link between the first part of the network and the second part of the network, for example, it may have both a broadband connection and a dial up modem connection. La that case, the controller may be configured to control data passing though only one of these links, e.g. through the broadband link.

The data network traffic controller may be configured to control routing of data packets sent from one location in the first part of the network to a second location in the first part of the network, and/or data packets sent from one location in the second part of the network to a second location in the second part of the network. Alternatively, it may be configured only to control traffic passing from one part of the network to the other part of the network. Other means may be provided for internal routing within the first and/or the second part of the network. For example, VoP telephones or PCs on a LAN may connect to each other via a local network hub without routing through the data network traffic controller, in order to reduce the demand for resources on the controller.

Embodiments of the present invention may be used for telephone calls, video links, internet radio, internet video, phone or video conferencing, or any other application requiring real time data transmission.

EmbυdimenLs of lhe present, invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 is a schematic diagram showing a typical small office LAN connected to the internet via a router, according to the prior art;

Figure 2 is a schematic diagram showing a typical small office LAN receiving voice and data packets from the internet via a router, in an embodiment of the invention;

Figure 3 is a schematic diagram showing the structure of a TCP packet header;

Figure 4 is a block diagram of a router according to an embodiment of the invention;

Figure 5 is a flowchart showing an algorithm to control the window size, according to an embodiment of the invention; and

Figure 6 is a flowchart showing an algorithm to control the maximum packet size, according to a further embodiment of the invention.

Figure 1 shows an example of a typical small office LAN that supports both voice and data services. The LAN shown in figure 1 is an ethernet 103, with two telephones 107, 107, and two PCs 105, 106 connected to it. The LAN is connected to the internet 100 via an ADSL router 102. Thus, the PCs and telephones share the ADSL bandwidth. ASDL broadband connections are generally configured to provide substantially larger bandwidth for the downlink than for the uplink. The ASDL line 101 connecting the router 102 to the internet 100 is typical in that it supports IMbps downstream and 256 kbps upstream bandwidths, where "upstream" refers to the LAN to internet connection and "downstream" refers to the internet to LAN connection.

The data sent from the PCs in this example is in the form of TCP/IP (transmission control protocol / internet protocol) packets. The IP deals with network routing, and the TCP deals with flow control, and the re-sending of any missing packets. The VoIP telephones use IP (internet protocol) for network routing, along with RTP (real time protocol) in place of TCP. Unlike TCP, RTP does not resend missing packets. Each RTP packet contains a timestamp, and the recipient should be able to reconstruct enough of these packets in the right order in real time to obtain an acceptable quality of audio signal.

When a user on the LAN 103 requests a large amount of data from the internet 100, a queue of packets tends to form, because any instance of a bottleneck in the data path will delay some of the packets. The queue will typically form at the interface between the ADSL 101 and the internet 100. A queue is not a major problem for TCP/IP traffic, which is not timing critical, but it can have a major impact on the quality of a telephone link. The jitter introduced by the queuing delays can seriously degrade the quality of the telephone link. If telephone connections are established at the same time as other data is being transmitted, then jitter becomes an important issue for the voice packets.

With a IMbps downstream link, such as that shown in figure 1, a queue forms at the Telco (telephone company) end of this link when the PCs are using the link heavily. Packets, including VoIP packets, get queued waiting for transmission down the link towards the customer router. The problem is caused by the fact that the queue in the Telco equipment often has no QoS (quality of service) capability, and thus treats all traffic equally. There is no possibility of prioritising the VoIP traffic over the data traffic.

Figure 2 illustrates a first embodiment of the invention. A local ethernet 203 like that in figure 1 is shown, with two VoIP phones 204, 207, two PCs 205, 206 and a link to the internet 200 via an ADSL router 202. This router 202 is configured as a network data traffic controller, according to an embodiment of the invention. As in the previous -figure, -the uplink and downlink bandwidth over the ADSL-201.,-between the .router 202 and the internet 200, are 256kbps and IMbps respectively.

In order to address the problem of a queue on the Telco equipment with no QoS, a new bottleneck, narrower than the existing bottleneck, is created between the router 202 and the LAN 203. Creating a new narrower bottleneck has the effect of moving where the queue forms, so that the queue is moved away from the ADSL link to the router 202 on the customer premises. Once the router has control of the queue it can introduce QoS techniques to prioritise the VoIP traffic and minimise the jitter in the VoIP streams.

The new bottleneck is created by limiting the rate at which data is transmitted from the router 202 onto the LAN 203, as shown on figure 2. As the ADSL downstream bandwidth is IMbps, the router 202 in this example introduces a narrower limit of, for example, 500kbps. Once data is flowing steadily through the network, the queue in the Telco equipment disappears, and a new queue forms in the customer premise router 202. The original queue vanishes because TCP has a flow control mechanism that allows the queue to form naturally at the bottleneck, and not simply flood the network. Thus, this technique makes use of the fact that almost all non-VoIP traffic uses TCP, because it utilises the in-built flow control within TCP.

On the router, a QoS rule is introduced to prioritise the VoIP traffic being transmitted onto the LAN. This allows the VoIP traffic to bypass the newly formed data queue in the router. Once the data flow has stabilised and the Telco queue has gone, VoIP packets to be delivered to the LAN will be delivered almost immediately.

To prioritise the VoIP traffic, the router identifies the types of packets being transmitted (e.g. VoIP or TCP/IP). The type of packet can be identified by looking at the IP header within the packet. The IP header is the part of the packet which deals with network routing information, and it also contains a field to identify the other protocol used in the packet, e.g. TCP or UDP (User Datagram Protocol). By reading this field in the IP header, the router can tell whether a packet is a voice packet or a TCP/IP data packet.

It would not be suitable to use TCP/IP for VoIP packets, because TCP includes error correction- and flow control. In real time voice communications there is no time to wait- for a packet to be re-transmitted if it gets lost or corrupted. Thus, .the router can be. - confident that any TCP/IP packet is not a voice packet.

Once each packet has been identified, the router can send only TCP/IP packets to the queue, allowing VoIP packets to bypass the queue and go straight to the LAN. Thus, a reliable voice connection between phones and a reliable TCP/IP link between computers may co-exist.

The above method of moving the queue and prioritising VoIP packets works well once the data flow has stabilised and the queue on the Telco equipment has disappeared. However, one complication arises when a new TCP stream is started. A new TCP stream opens a new TCP flow control window and there is typically a large burst of data from the TCP responder whilst this new TCP window fills up. For example, a typical PC running Windows XP opens a window of 64K octets that a TCP responder (such as a web server) can transmit to, before any flow control takes place. This burst of data will temporarily cause a queue of data to form at the Telco end of the ADSL link, and jitter will be introduced in any VoIP calls running at the time the new TCP connection is opened.

Although TCP may use a "slow start mechanism", designed to open a window in stages at the start of a new connection, this slow start mechanism still does not open a small enough window to prevent initial build-up of a queue on the Telcom equipment. In "slow start", the window opens exponentially until packets are lost, and then it reduces and re-opens linearly. However, "slow start" does not solve the problems of jitter on VoIP , because the window is too large, and it is opened too quickly.

Also, if a new VoIP connection is made while a lot of TCP/IP data is being carried by the network, there will be a time delay between the VoFP connection opening and the TCP parameters automatically adjusting to take into account the increased overall data flow.

The present inventors have realised that the problem of jitter during opening of a new connection can- be solved with a further improvement to the traffic management over and above simple VoIP traffic .prioritisation. Jn embodiments of the present invention,- ■

the router modifies the TCP header in the TCP/IP data streams to improve the VoIP data flows.

Figure 3 shows the structure of a TCP header in a TCP/IP data packet. The first 16 bits of the header indicate the source port, and the second 16 bits indicate the destination port for the data. Examples of common TCP ports are 7 echo; 19 chargen; 20 ftp-data; 21 ftp-control; 22 ssh; 23 telnet; 25 smtp; 53 domain; 79 finger; 80 http; 110 pop3; 111 ^' sunrpc; 119 nntp; 143 imap; 139 netbios-ssn; 179 bgp; 389 ldap; 443 https (ssl); 445 microsoft-ds; 1080 socks.

The next 32 bits in the header is a serial number known as the packet sequence number, indicating the sequence of data in the packet, m the first packet of a new connection, the sequence number is set to an initial sequence number (ISN). The sequence number is increased for successive packets, according to the amount of data that has been sent. The next field in the header is a 32-bit acknowledgement number, indicating the sequence number of the last remote byte that has been received. If an ACK flag is set in the TCP header (see below), the acknowledgement number field contains the value of the next sequence number that the sender of the segment is expecting to receive. The , ACK flag is always set, once a connection is established.

The _. next field is the offset field, which is 4 bits long, and indicates the number of 32-bit words in TCP header. TCP header padding is used to ensure that the TCP header ends and data begins on a 32 bit boundary. The offset is followed by six reserved bits, which are commonly set to zero.

The next part of the header is six one-bit flags. The URG flag indicates that the packet is urgent. The ACK flag indicates that the packet is functioning as an acknowledgement of data previously received, and that the Acknowledgement field of the header is valid. The ACK flag is always set once the connection is established. The PSH flag is set to force data to be sent, without waiting for the send buffers to fill. The RST flag indicates ^{• •} that the connection is being-reset. The SYN flag indicates-synchronisation of sequence ■ numbers. -The SYN flag is-always set in the. first packet of a new .connection. The FIN flag indicates that there is no more data, and that the connection should be terminated.

After the flags, a 16-bit "window" field indicates the window size that the sender wishes to allocated for non-acknowledged data. The window size is used in TCP's flow control mechanism. If data is being lost, e.g. due to a buffer filling up at a bottleneck in the network, the receiving user will be able to detect from the packet sequence numbers that data is missing. Thus, the receiving user can alter the "window" field in its return packets, to reduce the window size. This has the effect of instructing the sender to send a smaller amount of not-yet acknowledged data to the receiving user.

The "window" field in the TCP header is followed by a 16 bit checksum, which covers both the pseudoheader and entire TCP segment. Next is an "urgent pointer", which is only interpreted in packets with the URG flag set, and indicates the sequence number of the byte following urgent data.

Finally, the TCP header includes a 32 bit block allocated for options. The Maximum Segment Size (MSS) option indicates the maximum size of a packet, which the sender of the packet wishes to receive. Normally TCP automatically chooses the packet size, but setting the MSS puts an upper limit on this size. The MSS field is normally only sent in the initial connection request (i.e., in segments with the SYN control bit set). If the MSS option is not set, any segment size is allowed.

When a new TCP/IP connection is opened between a client and a server, the first packet from the client has the SYN flag set, to indicate that this is a new connection. The server responds with a packet having both the SYN and ACK flags set. The client sends another packet with the ACK flag set in reply to the server's SYN, and the connection is now established. If an error occurs during transmission, a packet is sent with the RST flag set, to reset the sequence number. To end the connection, both client and server send a packet with the FIN flag set.

TCP flow control using the TCP "window" field operates continuously during a TCP connection. Eachparty engaged- in a -TCP session uses the "window'ϊ-field to tell the other party how much unacknowledged ^, data .to -send. The window size is.normaUy.set to . a default value at the start of the session, and this may be altered as the session

progresses, according to the delays experienced in the network. If the delays in the network increase, TCP will detect this because the number of lost packets will increase. TCP will then decrease the window size, to reduce the rate at which data is transmitted. Normally, however, there is a time delay before the window size and data rate stabilise.

In embodiments of the present invention, the router alters the TCP packet header right from the first packet, to reduce the window- size and thus reduce the amount of data sent through the link per unit time. In one embodiment of the present invention, the router adjusts the TCP Window size that is published by the PCs to the servers from 64K to 2K. It is alternatively possible for the router to adjust the TCP window to a different size, e.g. IK or less, 4K, 8K, 16K, 32K, or some other number. However, the greatest benefit of the invention occurs when the window size is optimised to allow some data flow, but is not so high as to cause a large queue to form outside the router. The router modifies the TCP window size in the TCP packets transmitted from the PCs on the LAN to the servers on the internet, to instruct the servers on the internet to send only a very small amount of unacknowledged data at the start of a TCP connection. Normally, the first couple of packets in a new connection will be SYN packets which do not carry any data. Thus, these initial packets will not result in network congestion, due to their small size. For packets following these SYN packets, the window size will now have been reduced appropriately.

After modifying the TCP header, the checksum is recalculated to make the packet valid. The checksum may be calculated as the 16 bit one's complement of the one's complement sum of all 16 bit words in the header and text. If a segment contains an odd number of header and text octets to be checksummed, the last octet is padded on the right with zeros to form a 16 bit word for checksum purposes. The pad is not transmitted as part of the segment. While computing the checksum, the checksum field itself is normally replaced with zeros. The checksum also covers a 96 bit pseudo header conceptually prefixed to the TCP header. This pseudo header contains the Source Address, the Destination Address, the Protocol, and TCP length, which are carried in ^■ the IP header of the packet. This gives the TCP protection- against misrouted segments. ••

The width of the new bottleneck at the router should not be fixed at 500kbps, but should be dynamically adjusted. Whilst applying QoS rules improve the quality of the VoIP calls, it defeats the purpose of running both data and voice if prioritisation of the VoIP cannot be marshalled dynamically. For example, if there are no VoIP calls in progress then it is not desirable to create a false bottleneck in the network, but better to let the data flow as fast as possible. Therefore, when there are no VoIP calls, all of the bandwidth should be made available to the PCs, and the TCP window sizes are not modified. The TCP window sizes are only modified when VoIP calls are in progress.

In some embodiments of the invention, the router monitors the number of active VoIP calls and makes adjustments to the QoS settings, depending on the number of VoIP calls in progress. If there is only 1 VoIP call in progress the width of the false bottleneck can be wider than if there are many calls in progress. In effect, the difference between the ADSL downstream bandwidth and the false bottleneck bandwidth is bandwidth reserved for VoIP and this should be controlled to reserve the appropriate bandwidth for each concurrent call.

The router may include means such as a proxy server to detect the number of concurrent high priority connections at any time, for example, a VoIP Proxy server configured to detect the number of VoIP calls at any time. This proxy server thus allows the router to dynamically adjust the jitter management parameters. The proxy server may also limit the maximum number of connections or calls allowed at any one time. The proxy may support both MGCP (Media Gateway Control Protocol) and SIP (Session Initiation Protocol) signalling protocols. The IP telephones may use the address of the router as ■their Call Agent address.

The above system of creating a bottleneck on the router, allowing VoIP packets to bypass the resulting queue, and adjusting the TCP window size of return packets, tends to produce the most benefit when used for the downstream part of the link. It can also have some benefit for the upstream link, but normally to a smaller extent, because the ■ problem of managing jitter in the downstream path is much greater -than the -upstream .. • path. . . ^. . .. . . ,

Figure 4 shows a schematic structure of a router 300, according to an embodiment of the invention. The router 300 has a stream of input data 301 from the internet, and a stream of output data 308 to a LAN. The router includes a buffer 302 for storing incoming data. When new packets arrive at the buffer 302 via the input stream 301, a packet classifier 303 detects whether each new packet is a high priority packet, such as VoIP , or a lower priority packet. This detection will typically involve reading a parameter from the IP header of the packet which indicates the protocol type, although alternative methods of packet classification are also possible.

If the packet is a high priority packet, then the packet classifier will send a control signal to a packet management controller 305. The packet management controller 305 then sends a control signal to a packet flow controller 304, instructing it to allow the high priority packet to immediately proceed to the output stream 308. Thus, instead of having to sit in the buffer awaiting its turn, the high priority packet will be sent to the output stream as soon as possible. In practice, it may have a short delay if another packet is currently being output at the output stream, but this will be insignificant in terms of Qo S.

If a packet which newly arrives in the buffer 302 is a lower priority packet, then the packet classifier 303 will not alert the packet management controller of the packet being high priority. Thus, the packet will remain in a queue on the buffer 302. If a timeslot becomes available to transmit a lower priority packet, the packet flow controller 304 will allow a lower priority packet to proceed from the buffer to the output stream 308 via a packet header processor 316. In some embodiments, the packet header processor will not alter any of the packets on the downlink. However, in other embodiments, some packet header information may be altered, and further details are provided later in the text.

Meanwhile, if there are also high priority packets passing through the system (e.g. if a voice call is in progress), the router 300 will modify the headers of TCP packets on the uplink. This is because the window-size in a TCP packet indicates the window size-of -- the sender. Therefore, to stop the sender from sending too much information over the downlink, it is necessary to modify the window size in the uplink packets.

The uplink packets arrive from the LAN to an uplink input stream 310. Again, they are held on a buffer 311, until the router is ready to send them on. An uplink packet classifier 312 detects whether or not a packet is a TCP packet, and sends this information to the packet management controller 305. If the packet is not a TCP packet, the uplink packet flow controller 313 routes it straight to the uplink output stream 315. However, if the packet is a TCP packet, the packet is passed to the packet header processor 314, and the packet management controller sends a control signal to the packet header processor 314 to read the window size in the TCP header. If the window size is below a predetermined threshold, the packet header processor 314 will not modify the window size, but allow the packet to proceed straight to the uplink output stream 315. However, if the window size is larger than the predetermined threshold, the packet header processor 314 will modify the window size in the packet header, making it equal to the threshold value. The packet header modifier will then re-calculate and modify the packet checksum, and send the modified packet on to the uplink output stream 315.

Parameters such as the threshold value for the window size may be stored in the parameter and algorithm store 307. The packet management controller 305 may consist of separate controllers for the uplink and the downlink.

Figure 5 is a flowchart illustrating the process of modifying the window size setting in the TCP packet from the LAN to the internet. The process starts at step S400. At step S401, the router receives the TCP packet, and identifies the protocol as TCP. The downlink part of the router already has determined that the window size should be limited. Then, at step S402, the router readers the part of the TCP header relating to the window size. In step S403, the router compares this window size to a predetermined size X. As previously discussed, X may be dependent on the number of VoIP connections in progress. If the window size is not less than X already, at step S404, the router modifies the window section of the TCP header to change the window size to X. The router then recalculates the packet checksum at step S405, and modifies the packet to replace the old checksum with the new checksum. The process then proceeds to step S406, where the router sends the packet onwards to its intended recipient. If in step

S403, the window size was found to already be less than or equal to X ₅ then steps S404 and S405 are omitted, and the process immediately proceeds to step S406, where the packet is sent on to the intended recipient. The process ends at step S407.

A further embodiment of the invention is now described, which will normally have greatest benefit for the uplink. The uplink has a much lower bandwidth than the downlink in ADSL. Thus, the transmission delay caused by a typical PC data packet is much greater on the uplink than on the downlink. The most common maximum packet size is 1500 octets (plus some variable header sizes, depending on the access protocol, that we will ignore for simplicity). The time taken to transmit 1500 octets over 256Kbps is: (1500*8)/256000=46ms. So, if a VoIP packet arrives for transmission from the LAN to the router, and a large data packet transmission has just previously started, then the VoIP packet will wait for 46ms before its transmission will be started, introducing 46ms of jitter into the stream. As the "jitter budget" is only 60ms of jitter in any stream, the 46ms delay uses up most of this budget at the first network hop.

When a VoIP call is in progress, a stream of RTP packets is sent through the uplink, from the VoIP phone to the ADSL line and beyond to a remote media gateway. The bottleneck in this path is typically the ADSL line, with its relatively low speed of typically 256Kbps. When one or more PCs are active on the LAN they are also sending packets that will share this upstream bandwidth. In the case where one or more PCs are sending, for example, large email attachments, then a sizeable queue will form waiting for transmission on the ADSL line. Without any traffic management the VoIP packets will take their turn on this queue and this will introduce jitter on the received stream at the remote media gateway.

The TCP "Maximum Segment Size" (MSS) is a field in the TCP header that can be set to indicate the maximum size of each TCP packet that the sender will accept. In a second aspect of the present invention, the router modifies the TCP streams to reduce the MSS from its typical 1460 octets to a much lower value, such as 730. Hence, the PCs on the LAN will no longer send 1500-octet packets, but 770-octet packets. Together with the VoIP packet prioritisation, this reduces the maximum jitter introduced into the upward VoIP stream to 24ms, which is well below the budget for the

network, and hence will provide the quality of service required. Although the PCs will use smaller packet sizes than before, this does not typically have any significant adverse effect on the service.

Again, after modification of the TCP header, the TCP checksum should be recalculated and modified, to prevent the packet being rejected as corrupt.

In this embodiment, the TCP MSS modification technique has less benefit for reducing the size of packets in the downlink, because the serialisation time for a large 1500-octet packet is reduced to 1 lms due to the higher speed of the downlink. However, in some embodiments, this technique may still be useful for the downlink.

In figure 4, the downlink packet header processor 316 is used to modify the MSS of downlink TCP packets, in order to reduce the size of return TCP packets sent on the uplink. This reduces the delay for VoIP packets on the uplink, thus decreasing uplink jitter to an acceptable level.

Figure 6 is a flowchart illustrating the process of modifying the maximum segment size (MSS) setting in a TCP packet. Since the MSS in a packet indicates the sender's maximum segment size, the TCP header should be altered for packets in the downlink, in order to reduce the packet size in the uplink. The process starts at step S500. At step S501, the router receives the TCP packet, and the packet classifier identifies the protocol as TCP. Then, at step S502, the router readers the part of the TCP header relating to the MSS. In step S 503, the router identifies whether a MSS has actually been set in the packet header. If a MSS has been set, the process moves to step S504, where the router compares this MSS to a predetermined size Y. Y may be dependent on the number of VoIP connections in progress. If the MSS is not less than Y already, at step S405 the router modifies the MSS in the TCP header to change the MSS to Y. The router then recalculates the packet checksum at step S506, and modifies the packet to replace the old checksum with the new checksum. The process then proceeds to step S507, where the router sends the packet onwards to its intended recipient. If in step S504, the MSS was found to already be less than or equal to Y, then steps S505 and S506 are omitted, and the process immediately proceeds to step S507, where the packet

is sent on to the intended recipient. If in step S 503, the MSS was found to not be set at all, then the process goes on to step S505, where the MSS is set to Y, and then step S506, where the checksum is recalculated and modified. The process then proceeds to step S507, where the packet is sent on to the intended recipient. The process ends at step S508.

It is also possible to modify the MSS on the uplink, in order to change the maximum packet size on the downlink. This can be done as well as or instead of modifying the MSS on the downlink. However, due to the lower bandwidth on the uplink in these embodiments, reducing the size on the uplink will have a larger benefit.

It is not essential that the controller according to embodiments of the invention should be split into separate units, as shown in figure 4. The controller may have separate modules to deal with upstream and downstream data, or it may use a common module for both. The controller may have separate modules for different functions, e.g. for detecting packet headers, and for processing and modifying packet headers, or it may use a common module for both purposes. Alternatively, the controller may be implemented on general purpose hardware controlled by software, rather than having a modular structure.

In a further embodiment of the invention, control means such as Call Admission Control Support may be set up, to enable the router to limit the number of concurrent calls on a line. For example, typically the maximum number of calls on an ADSL line with 256kbps upstream bandwidth is limited to 5 when using a G.729 Codec.

Another embodiment uses NAT (network address translation) without a Border Gateway Controller. This means that local calls between phones on the same LAN do not traverse the WAN link, thus avoiding "tromboning" calls.

The present invention may be provided as part of a multi-service platform that delivers ■ ^• other services such as Firewall, VPN, content filtering and- VoIP services. This multiservice platføxm may support multiple WAN access protocols such as ADSL ₃ G.SHDSL, Tl, El G.703, and Ethernet. ISDN and V.90 backup may also be available.

The present invention is not limited to ADSL broadband connections, but includes other type of data network connections, including cable modems, wireless networks, etc.

The present invention can be implemented in dedicated hardware, using a programmable digital controller suitably programmed, or using a combination of hardware and software.

The router or traffic controller according to embodiments of the invention may be provided as a separate unit which can be installed on an existing data network, or may be provided as a hardware card for insertion into a PC on the data network, or for insertion into a pre-existing network router, proxy server, etc.

Alternatively, the present invention can be implemented by software or programmable computing apparatus. The code for each process in the methods according to the invention may be modular, or may be arranged in an alternative way to perform the same function. The methods and apparatus according to the invention are applicable to any computer with a network connection.

The controller may have an input and an output for upstream data. It may also have an input and an output for downstream data. However, in some embodiments, the controller is implemented as software on a general purpose computer, and thus may comprise a software module which operates, for example, on data input to the computer hardware, or on data which has been input to the computer hardware and subsequently modified by other software code. The software module may operate on data by indirect means such as by use of pointers to access only particular parts of the input data, and thus, there may be no part of the software module which comprises an input and output for the data stream.

Thus the present invention encompasses a carrier medium carrying machine readable instructions or computer code for controlling a programmable controller, computer or • • < umber of computers as the apparatus of the invention. The. carrier medium can ... . - , comprise any storage medium such as a floppy disk, CD ROM, DVD ROM, hard disk,

magnetic tape, or programmable memory device, or a transient medium such as an electrical, optical, microwave, RF, electromagnetic, magnetic or acoustical signal. An example of such a signal is an encoded signal carrying a computer code over a communications network, e.g. a TCP/IP signal carrying computer code over an IP network such as the Internet, an intranet, or a local area network.

While the invention has been described in terms of what are at present its preferred embodiments, it will be apparent to those skilled in the art that various changes can be made to the preferred embodiments without departing from the scope of the invention, which is defined by the claims.