GB2457254A - Optimisation of wireless multimedia data transmission - Google Patents

Abstract

A link configuration controller (310) for a wireless communications network, for providing an interface between at least one QoS (Quality of Services) manager (311, 312) and a plurality of wireless remote terminals (301, 302, 303) including end terminal devices, the link configuration controller (310) comprising: a network interface for obtaining current link performance information relating to link configurations for at least some of the remote terminals (301, 302, 303); storage means for storing said link performance information to collectively represent the system configuration; QoS communication means for informing said at least one QoS manager (311, 312) of link performance quality and for receiving an instruction from the QoS manager (311, 312) to select one of a plurality of configuration options; and control means for sending link configuration instructions to at least one of the remote terminals (301, 302, 303) to implement the selected configuration option.

Description

Optimisation of Wireless Multimedia Data Transmission

Field of the Invention

The present invention relates to wireless communications, and in particular, to the optimisation of wireless networks and the support for Quality of Service (QoS) sensitive traffic in wireless networks.

Background of the Invention

The use of multimedia data services over wireless networks is becoming increasingly common. For example, many mobile devices, such as PDAs (personal digital assistants) and mobile telephones, are now provided with sophisticated web browsing capabilities. These may include facilities for the reception of a wide range of data types, such as audio and video streams, large image files, orjava applets. Services such as mobile television, VoIP and broadband internet access may also be provided via a local area network to portable computing devices.

Due to the dynamic nature of a typical wireless connections and the growing trend towards supporting multiple radio technologies and I or radio modes of operation, performance and QoS (Quality of Service) issues may arise, in particular with respect to time critical data that is transmitted via a wireless network. Many approaches have been developed in an attempt to improve performance and Q0S in wireless networks.

Conventional approaches can be categorised as control mechanisms for traffic prioritisation (for example scheduling algorithms), reservation mechanisms for reserving resources and resource allocation, and performance monitoring mechanisms.

Many different methods have been developed for implementing each of these mechanisms.

Each of the presently known technologies for enhancing performance and QoS in wireless networks tends to be specific to particular hardware, operating systems and/or protocols and does not consider the multiple modes of operation (or configurations) present within radio devices. For instance, performance and QoS improvement may be implemented within protocol stacks or operating systems of particular communication devices. This creates a problem for a vendor or system administrator who wants to provide QoS support, because no single solution is likely to be sufficient for all of the QoS needs, particularly for wireless LANs in which the device capabilities can range from low end devices (such as VoWLAN phones) to multi-media laptop computers.

The Microsoft RallyTM set of technologies has attempted to address such problems.

Microsoft Ra11yTM includes the Microsoft Link Layer Topology Discovery Protocol (LLTD), and the network Q0S framework entitled Quality Windows Audio-Video Experience ("qWave"), which is available in the Windows Vista release. This technology addresses home AIV streaming scenarios that involve real-time, high-priority traffic sharing a single network with best-effort, low-priority traffic. These scenarios present challenges for network QoS. The challenges are more critical for scenarios involving home networks that use Wi-Fi technology because of bandwidth, stability and range limitations in Wi-Fi technology, together with the lack of any centralised management entity.

The Microsoft approach delivered in the qWave framework is based on a combination of QoS admission control, caching, monitoring, probing, traffic prioritisation and shaping. The LLTD Protocol, together with qWave, can provide the means to retrieve link performance information and to perform traflic prioritisation and shaping. It also provides APIs (referred to as the QoS2 and native WiFi APIs) that enable applications to determine available bandwidth, select the appropriate QoS levels, and to be notified when this is not met.

To illustrate the functionality of the qWave technology, Figure 1 shows a block diagram illustrating multiple levels in the Microsoft Operating System network support stack, and illustrating how qWave controls traffic flow in the system. The top layer, shown by the upper box 100, contains multimedia and real time collaboration applications, such as VoIP, video clips, and the like. Below this is situated a platform layer 101, with media and real time communications platforms. The networking layer 102 is shown beneath the platform layer, and beneath this is the physical media layer 103. The networking layer 102 comprises A/V transport 105 which is implemented by UDP/TCP, admission control 107, caching 106, monitoring and probing (M&P) 108, and traffic tagging and shaping (Ti'S) 109. As shown, qWave provides the framework to coordinate admission control 107 and A/V transport 105, between TTS 109 and M&P 108, and between M&P 108 and caching 106.

However, the qWave approach does not include the radio configuration or radio based measurements such as signal levels, interference and noise measurement (which are accessed through the native WiFi API), that can enable more options to be added to the QoS framework, such as different modes of operation. Thus, multi-mode device technologies and highly dynamically varying technologies are not integrated into the qWave framework. This may also preclude those types of resource multiplexing schemes that involve load sharing and frequency selection, which could otherwise improve network performance by selecting different channels for different traffic, and by switching between broadcast and unicast modes. Therefore, although it contains a large set of the functionality required to perform global WLAN optimisation, the qWave framework does not consider the many possible configuration options of radio links that are required to implement a complete and scalable solution.

Furthermore, the Microsoft solution supports information sharing between qWave capable devices. However, it does not support other types of devices. Thus, the use of LLTD and qWave does not guarantee performance in a wireless network which may, and probably will, include devices not employing Microsoft based technology.

Other known prior art also does not provide both a means for collating performance information and a means to control the configuration of radio links to achieve QoS targets as logically separate functions that can be performed on different devices and sourced from different vendors.

Some prior art addresses the QoS parameter and signalling methods as intrinsic parts of the protocol stack. US 6,804,222 (Lin et al) relates to an inband QoS signalling reference model for a QoS driven wireless LAN. It discusses a signalling scheme for Q0S provisioning in a WLAN, in which Q0S Management entities are used to control the resource allocation based on QoS ID's. However, the only signals used are bandwidth requirements and Q0S requirement parameters. Thus, although this solution addresses the method of signalling Q0S requirements between devices, it does not include any real-time performance measurements and estimates for the various modes of operation that are required to more filly understand the overall system QoS options and performance.

US2006/0215556 (Wu et al) uses overlay protocols and QoS differentiation methods that are integral parts of the QoS management solution, and are embedded into the operating system. This document discusses VoIP support over existing implementations, mainly WLAN MAC and multi-hop scenarios. It is a pure overlay concept, addressing the rate control implementation, but not the method of selecting different link transmission configurations (or modes of operation) for multimedia traffic in conjunction with the rate control and QoS management solution.

WO 2006/097832 (Nokia) discusses a method of triggered statistics reporting on QoS streams, based on 802.11k mechanisms. This involves determining whether triggered reporting should be used by an access point (AP) for a particular service/ stream.

Trigger thresholds are defined for a service or stream with which triggered reporting is to be used. A measurement report is formed if trigger conditions are met and this is then transmitted to the AP. The approach does not consider multi-configuration measurements or performance estimation techniques. For instance, if measurements are triggered to be performed on a certain frequency channel, (such as signal strength or radio power level measurements), the corresponding estimated link throughput or error rates for different possible link configurations are not addressed.

US2006/0 104230 (Gidwani) relates to the use of a central controller to process traffic related information obtained from access points. The disclosed technology is based on using information from access points to configure access points (frequency channels, etc.) in order to improve performance. The approach does not specify the manner in which such information is gathered apart from specifying that a separate control channel can be used for this purpose. It also only considers traffic information and not the measured or estimated performance of different configuration options of the radio links.

EP1484862 (Microsoft) relates to a method for providing contention free quality of service to time constrained data. Although this includes disclosure of a method of providing Q0S differentiation through time slot assignment to high priority devices, it does not discuss methods of performance measurement collection which would be required to enable decisions to be made regarding the best way to support the application QoS requirements. Also, this disclosure primarily addresses scheduling performed at the access point.

Therefore, in this prior art, there is no readily appreciable way of implementing different QoS management applications or entities on the same network, or of exchanging QoS management entities with ease. Most existing solutions require that all devices have the same or standardised QoS management entities, which limits the deployment of the technology. This is one of the main reasons why QoS mechanisms are not used in existing wireless LAN systems, as there is generally a mix of legacy and newer radio devices with different capabilities (configuration options) and Q0S support mechanisms. Although the Microsoft qWave approach provides some of the mechanisms required to achieve this commonality, not all devices will support qWave and the framework does not include the performance measurement or estimation associated with multiple modes of operation.

The 802.lle standard specifies control mechanisms that provide support for different traffic classes (or access categories) and a signalling method to enable the specification of Q0S requirements (within the TSPEC data element) to access points. However, it is only possible to use these mechanisms if the radio devices support the 802.1 le standard.

It also does not provide a means for applications (such as Q0S managers) to easily interface with the QoS support functionality, particularly if a central QoS management method is preferred to provide global WLAN optimisation. Also, it only considers the request and allocation of QoS requirements for 802.11 radios and not multi-mode device configurations. Therefore, it does not provide configuration option information or performance bounds or estimates related to the available modes.

Figure 2 illustrates the process specified within 802.1 le, for standard compliant devices (designated MT1, MT2, MT3, MT4) to request admission of a flow or transmission opportunities (TXOPs) from correspondingly standard compliant access points (AP 1, AP2). To do this, a frame is sent to the AP with a corresponding TSPEC request, as defined in the Standard. A TSPEC element contains the traffic QoS requirement for the device (MTI, MT2, MT3 and MT4). The QoS manager in each device p'2]would need to request a certain Q0S which is then mapped to the appropriate TSPEC within the operating system or driver. For example, the Intel Centrino drivers provide an Intel ProSet Wireless API to allow the request of a specific Q0S, but this is only supported on Intel Centrino devices. The Centrino device then translates the QoS parameters into the relevant TSPEC elements and sends this to the access point. Windows qWave APIs also provide a means for requesting QoS targets (using the QoS2 API) and this would then need to be mapped to the appropriate 802.1 le traffic classes and TSPEC elements.

Once the AP (for instance API) cannot allocate any more resources, admission of new flows are rejected and so MT2 may not be able to obtain the required QoS from API once MT1 has been allocated resources for its flow. The QoS manager (within MT2) must now determine the other available options, which may be to try to connect to AP2 and make the same request or to try a lower QoS level. However, determination of the different available configuration options must use other methods, such as accessing Windows native WiFi and other wireless APIs and any configuration changes for the APs cannot normally be observed or initiated by devices (MT1-4), and so the only option available for MT2 may be to select AP2 even though better options could be available.

Therefore, a major drawback of Q0S management solutions in wireless technologies (and particularly WLAN) is that it is difficult to deploy a QoS management solution when devices are sourced from many different vendors each with different capabilities (and configuration options or modes of operation) which exploits the full capabilities of all these different devices. The QoS management approaches should also consider the different configuration options and modes of operation that are now available as standard with most wireless devices when determining whether to admit or reserve resources for new traffic streams. Although Microsoft Windows is a dominant Operating System (OS) for desktop PCs, and offers some methods and APIs to access different QoS capabilities, it is a less dominant product in the field of mobile devices and so several different operating systems and versions are likely to exist with different inbuilt QoS mechanisms and APIs. Also, access points (APs) typically have separate management solutions running proprietary operating systems and bespoke network management platforms that are not accessible to end devices, which often restricts the ability to exploit different modes of operation (and other configuration options such as frequencies) even if the radio devices could support them.

Summary of the Invention

A first aspect of the present invention provides a link configuration controller for use in a wireless communications network, and a corresponding method, for providing an interface between at least one QoS (Quality of Services) manager and a plurality of wireless remote terminals including end terminal devices. The link configuration controller includes network interface means, which preferably comprises a wireless network interface, for obtaining current link performance information related to link configurations for at least some of the remote terminals; storage means for storing said link performance information to collectively represent the system configuration; QoS communication means for informing said at least one Q0S manager of link performance quality and for receiving an instruction from the QoS manager to select one of a plurality of configuration options; and control means for sending link configuration instructions to at least one of the remote terminals to implement the selected configuration option.

The link configuration controller may include means for determining measured or estimated performances for said plurality of different configuration options, using said link performance information.

The storage means may obtain device configuration parameters and/or link configuration parameters obtained from one or more of said remote terminals, and may store said parameters in the storage means, to provide at least a part of said representation of the system configuration.

The link configuration controller may include one or more QoS managers, each for receiving link performance quality information from the QoS communication means and for selecting one of said plurality of configuration options for use by the control means. Alternatively, or additionally, one or more independent QoS managers may be used.

The QoS managers may include a first QoS manager operating with a first protocol and a second QoS manager operating with a second protocol. For example, the first and second protocols may be any of SIP, RSVP, LLTDP, qWAVE or other proprietory protocols. More than two QoS managers may be included, e.g. to operate with a larger number of protocols. One or more Q0S managers may be configured to receiving link performance information and monitor for a trigger condition to decide whether to activate a different configuration option from a plurality of available configurations.

The controller may include trigger means for registering trigger conditions for network performance and for issuing triggers when performance degrades below threshold levels set by applications. This may or may not be included as part of a Q0S manager.

The controller may include simulation means for using a simulation model to predict or estimate the performance of different link configurations based on information stored in the storage means. The simulation model may be contained within the Q0S manager.

However, this is not essential, and the predicted performance information may be stored in the storage means of the controller to assist in selection of configuration options. The controller may be configured to store past performance data in the storage means or elsewhere, and to use this past performance data to predict the performances of alternative configuration options The wireless network interface may include a plurality of radios that can be used for forming a wireless link connection to one or more of said remote terminals, each of these wireless link connections may be selectable for use and configured by the controller.

The controller may be configured to support the collection of performance information using a ULLA (Unified Link Layer API) implementation.

The configuration options may include a broadcast configuration and a unicast communication mode configuration, a plurality of transmission frequencies, rates and/or scheduling parameters for a multiplexed transmission scheme (such as priority level or traffic class).

The link performance information may include at least one of signal level, noise level, frame latency or inter-arrival, and frame error statistics from the end terminal devices, for each received packet. Alternatively or additionally, the link performance information may include at least one of signal level, noise level and frame errors statistics from an access point device serving at least one of said remote terminals, for each received packet. The control means may be configured to instruct handover of a remote terminal from a first to a second access point, according to the loading on each access point.

The controller may comprise a second network interface for connection to a second network, wherein the controller is configured to act as a gateway between the wireless network and said second network.

A further aspect of the invention provides a video server including the link configuration controller as previously described.

Thus, embodiments of the present invention provide both means for estimating and collating link performance information for various different link configurations and for controlling the configuration of the radio links and admitting application traffic as logically separate functions that can be performed on different devices sourced from different vendors and use different protocols, as appropriate. In this manner the key way to cooperate is to share the common link configuration options and performance information between all these functions using performance abstractions, such as generic link performance metrics and uniquely identifiable objects denoting different link configurations, for example.

In some embodiments, the control of link configuration options is performed by a central Wireless Monitoring and Control Gateway (WMCG) that is also a central server to allow combination of all the gathered information for global optimisation. It may determine and implement link configurations to support multimedia streams to meet their QoS requirements and the global resource utilisation efficiency requirements. This results in a method of supporting QoS that can consider many different possible link configuration options as well as permitting resource reservation and admission control..

Potential product applications include home gateways, video server and DVD products, laptops and mobile devices.

Embodiments of the present invention may collate the measured system performance in terms of link metrics, such as signal (and noise) levels, error rates and frame latency within the gateway in order for the Q0S management to be performed centrally, with a global network-wide perspective and also provide more detail than any single device can provide on its own.

Embodiments of the invention may use performance statistics that are either measured directly or estimated for different configuration options, in order to trigger configuration changes. A remote database update approach may be used. However, support for qWAVE and the approach described in WO 2006/097832 can also be implemented if required.

In contrast to just using access points to gather information, embodiments of the invention allow remote retrieval from terminals and other nodes. Thus, controlling transmissions from individual terminals is possible, if the terminals have appropriate hardware/software. Embodiments of the present invention may also provide the advantage of reducing the complexity and overhead on less capable terminal and access point devices.

Embodiments of the invention enable scheduling, traffic shaping and admission control to be performed to permit Q0S differentiation. This may be performed at the controller, allowing it to consider not only the local access point environment, but the whole network environment and all possible link configuration options. This is advantageous in scenarios in which either dual radio access points (or more generally multi-radio access points) and/or access points from other vendors are used and dynamic switching between these different configurations is permitted. For instance, the controller might switch from one radio mode to another in order to support a new application traffic flow.

Embodiments of the invention have the advantage that heterogeneous device types can be exploited within the network to provide Q0S related performance information and therefore there is no reliance on all devices supporting the same QoS related capabilities. Also, the QoS manager (as the decision maker) can be separated from the application and radio devices to provide the ability to have independent software vendor sourcing of QoS management functionality supporting different QoS signalling mechanisms or decision making algorithms. Furthermore, application aware decisions may be made by means of allowing applications to observe link performance and register thresholds for acceptable performance that can be used in the network configuration decision making.

Embodiments of the present invention provide generic Q0S support without mandating any particular Q0S protocol or management mechanisms, but rather uses common link configuration option and performance information abstraction. The link configuration controller contains generic performance information and configuration options (such as different modes of operation) obtained from the various devices in a form that enables a different QoS manager or other applications to be informed of performance degradation or availability of better configurations and select the appropriate action. This can even be performed if the devices do not support the same QoS related capabilities and performance as information can be estimated by historical trends and from simulation, analytical or empirical models.

Embodiments of the invention can be implemented by means of specifically provided hardware, or by software on general purpose computing means. Such software could be provided in a computer as supplied, such as stored in a non volatile memory component, or could be introduced such as on a carrier medium or on a signal. A carrier medium could comprise, for example, a magnetic or optical readable medium, or a non-volatile memory component.

Brief Description of the Drawings

Embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which: Figure 1 is a block diagram showing the role of Microsoft's qWave application in a Figure 2 is a schematic diagram showing a process for 802.lle compliant devices to request resources (TXOP's) from 802.11 e compliant access points; Figure 3 is a block diagram of a conventional WLAN arrangement; Figure 4 is a block diagram of a WLAN according to an embodiment of the invention, showing how QoS managers can access WLAN performance information and configure the links to achieve Q0S targets; Figure 5 shows a further embodiment of the present invention, with more details of the protocol stack in the network controller, access points and devices; Figure 6 shows a timing diagram for communications between the different network entities, in an embodiment of the invention where interference occurs; Figure 7 shows a flow chart illustrating an example of a process for communications between the different network entities, in an embodiment of the invention where interference occurs; Figure 8 shows a timing diagram for communications between the different network entities, in an embodiment of the invention where fading occurs; Figure 9 shows a flow chart illustrating an example of a process for communications between the different network entities, in an embodiment of the invention where fading occurs; Figure 10 shows a graph of signal strength as a function of time in an embodiment of the invention; Figure 11 shows a graph of minimum, mean, maximum and standard deviation, and Received Signal Strength as a function of time in an embodiment of the invention; and Figure 12 shows a graph of the signal level and packet error rate as a function of time in an embodiment of the invention.

Detailed Description of the Drawings

The conventional approach to QoS is shown in figure 3. Three network devices 201, 202,203 are shown within a WLAN 200. The first device 201 is a SIP enabled device, and its QoS manager 211 supports SIP. The third device 203 is a RSVP enabled device, and its Q0S manager 212 supports RSVP. The second device 202 has no QoS manager support, and it operates without the use of QoS with best effort traffic. The first device 201 and the third device 203 can interact to establish the best use of the WLAN resources by means of 802.lle (TSPEC) mechanisms if both of the devices support 802.11 e. However, there is no direct interaction or information sharing between QoS managers and therefore sub-optimal use of resources may occur. For instance, if the Q0S manager 211 establishes a session requiring certain resources and then QoS manager 212 tries to set up a session with more resources that available with the current configuration, it will be rejected by the admission control at the 802.lle level (interaction between devices I and 3). The Q0S manager 212 now must determine what to do and does not have enough knowledge to determine what the best option is and will select a lower QoS level for the session than it really wants. The second device may now not have sufficient resource for its session and it will terminate.

The following example of the invention allows QoS management entities and link configuration control functionality to cooperate by virtue of a link configuration controller which may be contained within a Wireless Monitoring and Control Gateway (WMCG), and supports the use of generic performance thresholds and triggers.

In this example, the preferred approach is centralised Q0S management in which one or more QoS management entities are active within a network using the central WMCG to access common performance and configuration information. Each QoS manager can still use different signalling methods for interaction with application and resource reservation mechanisms (for instance based on RSVP, SIP or proprietary protocols) but may configure the different radio devices accordingly when Q0S targets are not met, or pre-emptively when better configurations become available.

This has the advantage that the QoS managers are directly aware of the configuration options that are available and the corresponding performance expectations. This allows modes of operation to be selected so that resources are more suitably utilised by the different devices.

Figure 4 is a block diagram showing a WLAN in an embodiment of the invention.

Three devices, 301, 302 and 303, are shown within the WLAN 300. A central WMCG 310 receives performance information for different configurations (modes of operation) from each of the three devices 301, 302 and 303, and sends configuration information to each of the three devices 301, 302, 303 when changes in mode of operation are requested. Two Q0S applications 311 and 312 are provided external to the WLAN, although in alternative embodiments, these may be provided inside the WLAN (such as running on the WLAN terminal or access point devices directly). The first Q0S application 311 is a QoS manager that supports SIP for session initiation. The second QoS application 312 is a QoS manager that supports RSVP for resource reservation.

Thus, figure 4 illustrates how Q0S managers can access WLAN performance information and configure the links to achieve QoS targets, via the WMCG, compared with the conventional approach in figure 3. In this example if the QoS manager 311 starts a session and requests resources it may first consider the configuration options available for the device 301 and could select a configuration change before proceeding with the initiating of the session. Likewise for the QoS manager 312 the configuration options and performance can be observed and requests to change mode made before resource reservation commences. In this manner it is highly unlikely that a reservation request would fail and the configuration (mode of operation) of the devices would be most suitable for the sessions. It is even possible that devices (such as 302) that may not support wireless QoS (such as 802.1 le enhancements) can make use of QoS mechanisms provided by the WMCG.

Figure 5 illustrates the control and data plane interactions for the previous example (in figure 4) in more detail. A WIvIOC 410 can be used as a platform to execute Q0S managers (preferably locally but also remotely if necessary) 411, and controls the traffic flows communicated to the two access points 404,405 via an ethernet link. The first access point 404 has a wireless link to a first device ("Device 1") 401, and the second access point 405 has wireless links to a second device ("Device 2") 402 and a third device ("Device 3") 403. In this example setup of the QoS control function is simplified to setting different scheduling configurations within packet scheduling functions contained within device 3 (403) and the WMCG routing flmction (423).

A simplified version of the protocol stack is illustrated in each of the WMCG 410, the access points 404, 405 and the devices 401, 402, 403. In device 1 (401), the protocol stack comprises the 802.11 protocol at its data link layer 450, with IP at the network layer 451 and TCP at the transport layer 452. Device 1 (401) supports a generic performance reporting function (which updates information held in the ULLA core (418) at the WMCG), illustrated by the vertically striped box shown above the transport layer. The performance information is used by the WMCG QoS Managers to determine whether the different configurations provide adequate performance.

The protocol stack of device 402 is the same as for device 401, with the 802.11 protocol at its data link layer 453, IP at the network layer 454 and TCP at the transport layer 455.

The device supports a performance reporting function, which also updates the information held in the ULLA core 418 of the WMCG 410.

The protocol stack of device 403 is different from the other two devices. Again at the data link layer 456 is the 802.11 protocol. However, above this is shown a TCP transport layer 458 over a networking layer 457 using IP at the right hand side of the box representing device 403, and a network layer with ICMP 460 and IP 459 at the left hand side of the box representing device 403. ICMP is Internet Control Message Protocol, which is used to dynamically control the packet scheduling function by the WMCG, using short broadcast packets. Device 3 (403) supports a packet loss monitoring function (which updates information held in the ULLA core (418) at the WMCG), illustrated by the solid black box shown above the transport layer.This permits the WMCG to be informed of the reliability of the ICMP packet delivery observed by the device 403.

The two access points are each shown with similar and conventional protocol stack arrangements. The first access point 404 has a data link layer 444 for Ethernet for communication with the WMCG 410, and a data link layer 445 for 802.11 for communication with network devices such as the device 401. Above this is WLAN access point (AP) software 446, which typically bridges or routes packets between the two underlying interfaces. The second access point also has a data link layer 447 for Ethernet for communication with the WMCG 410, and a data link layer 448 for 802.11 for communication with network devices such as the devices 402 and 403. Above this is WLAN access point (AP) software 449.

In this embodiment, the WMCG 410 contains a Unified Link Layer API (ULLA) 417 core implementation 418 in the control plane. This provides a single interface for retrieving link layer information from each technology and platform. It offers a flexible query interface and a powerful notification mechanism that enables applications to become link aware. It thus supports the collection of performance information, via an 802.11 device 415 and its Link Provider (LP) 416 can be advantageous to provide a platform and technology independent method of implementing the WMCG. The 802.11 interface 415 is not used for data communication and is permanently in monitoring mode in order to gather radio interference and channel activity related information.

The WMCG 410 also has a protocol stack with Ethernet at its data link layer, and IP at the network layer 422. The Ethernet may connect to two separate networks 420,421, e.g. a local wireless access network and a core network. A routing function 423 is provided, and this also contains packet scheduling and packet loss monitoring functionality and also controls packet scheduling functions on remote devices 403. The WMCG also supports a performance prediction function 424, which is used to estimate the performance of different configurations of the scheduling function depending on the observed performance obtained from device 1 (401) and device 2 (402) and information stored within the ULLA Core (418).

The wireless devices 401, 402, 403 register with the central WMCG 410. Wireless devices 401 and 402 report performance data back to the WMCG 410, for example, they may report back information relating to the received signal strength levels and packets or bytes transmitted and/or received per second.

Wireless device 403 cannot detect signal level information but can detect packet losses (using sequence numbers embedded in the control ICMP broadcast messages) and report this information back to the WMCG 410. The wireless device 403 and the WMCG 410 may optionally use a scheduling function that allows the WMCG 410 to periodically control when packets from mobile device 403 are transmitted. This permits one or more additional configuration options to be made available for remote activation by the WMCG 403.

If the wireless device 401 attempts to initiate a QoS sensitive video stream, the client application registers performance thresholds through a proxy QoS manager on the WMCG 410, using ULLA notification requests. The proxy Q0S manager can be dynamically loaded onto the WMCG by standard means, such as File Transfer Protocol (FTP) or Hyper-Text Transfer Protocol (HTTP) that operates over TCP and can execute in a common execution environment such as Java virtual machine or Javascript engine and has access to the ULLA API on the WMCG. The Q0S Manager 411 (which can be regarded as an ULLA Agent on the WMCG) then detects when the thresholds are crossed using the combination of performance information available in the ULLA core (418) at the WMCG 410, (for instance derived by the WMCG from packet loss information from Device 403 and signal level information from device 402 and latency information from the WMCG 410) to decide whether to select a different configuration option (which might for instance suppress the mobile device 403 transmission by activating the scheduling configuration option available to the WMCG).

This example can be extended to allow the QoS manager 411 to determine whether to instruct mobile device 403 to handover from access point 405 to access point 404 by observing the loading (number of packets or bytes per second) of the devices on both access points as reported by the WMCG 410 and activating a new configuration.

In a further embodiment, the QoS manager is configured to determine whether both mobile devices 401 and 402 are receiving the same video stream and to select between unicast and broadcast transmission modes. To achieve this, an additional function is added to the mobile devices 401 and 402. This function is an application traffic stream reporting function (in addition to the performance reporting function). When mobile device 401 sets up its video stream it reports the details to the WMCG (via the proxy QoS manager ULLA Agent) and likewise, if mobile device 402 also sets up a video stream it does the same. If the Q0S Manager 411 determines that the two streams are identical and live video transmissions (i.e. not video on demand), the QoS manager 411 can decide whether to use a broadcast configuration in which a single stream is sent to both devices or to transmit separate unicast packet streams and perform packet duplication. This feature is highly beneficial in resource constrained scenarios as it allows the resources to be more efficiently utilised when the performance is determined to be acceptable by broadcasting multi-media streams.

Some examples are now described, of how embodiments of the invention may be used for performance enhancement in a wireless network. The performance enhancement can be triggered and achieved in a number of ways.

A first scenario is for interference avoidance. One example of this is shown in the timing diagram of figure 6. The figure has five columns, representing a user, a third party software/content provider, a multimedia device, a WMCG device, another network device, and an interfering device respectively. The vertical axis represents time.

Horizontal arrows are shown indicating the interactions between these six different entities in a number of different interference situations.

A process for this example is also shown in the flowchart of figure 7. Firstly, the process starts at step S50 1, and the user activates a multimedia device. At step S502, a multi-media application is started that discovers and registers a QoS manager (ULLA Agent) with the WMCG (for instance as shown in Figure 6 using FTP or HTTP). The multimedia session is then started via a wireless network, for instance an access point in infrastructure mode or other device in ad-hoc mode. The multimedia session can be local to the vicinity of the network or via the access point to a content provider in the Internet. At step S503, an interfering system causes degradation to the service by transmitting on the same radio medium and the multi-media device updates performance information held at the WMCG. At step S504, the QoS manager registered with the WMCG determines a more suitable configuration option that now has better estimated performance than the current configuration and it is selected. The multi-media device is requested to adapt to the interference by configuring the link to avoid the interference, for instance by changing to a new channel. Examples of this adaptation would be changing radio frequency or other resource sharing schemes (configuration option) utilised for access to the shared medium.

If the interfering system uses a different radio technology, or is a separate network, then the device can easily change frequency channel to avoid interference. If the interfering system is on the same network, as shown at step S 505, then other resource sharing techniques must be used (such as rate control or channel multiplexing in time) or by switching from less reliable (e.g. broadcast) mode of operation to a more reliable one.

This is shown at step S506.

A further step S507 permits the multimedia stream to receive a notification of performance change (or of discontinuity while configuration takes place) at step S508 and adapts the session accordingly.

A second scenario is a dynamic radio environment, and an example is shown in the timing diagram of figure 8. The figure has five columns, representing a user, a third party software/content provider, a multimedia device, a WMCG device, and radio environment respectively. The vertical axis represents time. Horizontal arrows are shown indicating the interactions between these six different entities in a number of different interference situations.

This scenario is similar to the previous scenario except for the inclusion of a dynamic radio environment instead of the interfering system, and an example process is shown in figure 9. The same steps and options apply in this scenario, but the adaptation is performed in response to the radio environment changing rather than the interference traffic. Steps S601 and S602 correspond to steps S501 and S502 in figure 7.

If the impairment is caused by signal fading such as shadow fading as shown at step S603 (or other types of fading, long or short term), a successful strategy may be to switch the device mode or rate, as shown at step S 604, for instance changing from a less reliable (e.g. broadcast) to more reliable (e.g. unicast) mode or changing modulation schemes.

If the impairment is caused by the mobility of the devices, as shown at step S605 (i.e. moving away from the access point or other devices), improved results may be obtained by the switching from one access point to another (handover) or changing rate of mode, as shown at step S606.

A further variation is shown at step S607, where the multimedia stream is subsequently adapted by the third party application. At step S608, the third party software receives a notification of performance degradation (or of discontinuity while configuration takes place) and adapts the session accordingly.

Further devices may also be present in the systems shown in figures 6 and 8, e.g. remote content providers for providing content or software to the multimedia device.

An example is now given of how thresholds may be implemented in embodiments of the invention.

Figure 10 is a graph of the signal strength measured over a period of time, indicating that the channel varies over time and differently for different configuration options. For instance in this case configuration 1 may correspond to a connection with API and configuration 2 to AP2.

Figure 11 is also a graph of signal strength measurements over a shorter time period, but in this case the minimum, average and maximum observed in each sample period are shown together (lower 3 traces) with the standard deviation (upper trace). This graph includes a horizontal line at a standard deviation value of 8, indicating that a threshold level of 8 has been set in this example, for packet transfer between the mobile device and another device, such as an access point, wireless gateway or another end device.

The multimedia wireless device and the other device periodically report the signal strength to the WMCG device. When the threshold is crossed a new configuration (for instance configuration 2) can be selected by a QoS manager at the WMCG if it would provide better performance. To determine whether another configuration would achieve better performance may require some evaluation by analysis, historical performance data or simulation modeling. All of these techniques can be utilised by the WMCG to estimate the performance of the different configuration options. For instance in Figure 12 the relationship between signal strength and packet error rate over time is depicted for one configuration option. The relationship may be different for each configuration option or could be the same and the WMCG determines this relationship. An example packet error rate threshold is set at 20% and this could, for instance correspond to the signal level variance threshold of 8.

A ULLA Query Language (UQL) notification request may be used for the QoS manager to set the threshold for a particular device. An UQL information request may be used by the WMCG to observe the trends in error rate over time (as shown in figure 12) and perform estimation of the performance of the other configurations and performance parameters.

The link signal levels (and corresponding error rates) obtained and shown in figures 10, 11 and 12 are sufficient for determining the appropriate configurations for devices to use, but are not sufficient for determining the frequencies to use in a dynamic channel assignment mechanism. The reason for this is that the link signal levels correspond to a single access point (when the device is associated with the AP) and do not consider other co-channel or adjacent channel transmissions or interference from other radio sources. To augment this with more general WMCG channel monitoring (the WMCG can perform channel monitoring and update the corresponding channel information within the ULLA core), the QoS Manager can then dynamically assign frequencies, for instance using the ullachannel objects to retrieve channel signal and activity information and select different frequency channel configurations.

The above results then enable the WMCG to determine the best frequency and also time based channels to use for dynamic channel assignment strategies that utilise signal levels and activity measurements. It is also worth noting that the longer term average signal measurement analysis is highly beneficial because of the short term variations that occur (see figure 10, 11 and 12) and can be, to a certain extent, factored out by looking at the longer term trends. However, when sudden changes occur (such as shadow fading) it is necessary to react quickly and so the combination of long term trend (average) and short term (variance related) thresholds may be highly beneficial, and may be based on percentage deviations, (such as 10% or greater reduction) or signal level variance (as shown in Figure 11).

The above examples are only indicative of the different options that are being considered, but are currently believed to be the most useful in a WLAN environment.

However, further options may be used instead or additionally.

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

Alternatively, the present invention can be implemented by software or programmable computing apparatus. This includes any computer, including PDAs (personal digital assistants), mobile phones, etc. 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.

Thus the present invention encompasses a carrier medium carrying machine readable instructions or computer code for controlling a programmable controller, computer or number 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.

Claims (22)

1. CLAIMS: 1. A link configuration controller for a wireless communications network, for providing an interface between at least one Q0S (Quality of Services) manager and a plurality of wireless remote terminals including end terminal devices, the link configuration controller comprising: a network interface for obtaining current link performance information related to radio link configurations for at least some of the remote terminals; storage means for storing said link performance information to collectively represent the system configuration; QoS communication means for informing said at least one QoS manager of link performance quality and for receiving an instruction from the QoS manager to select one configuration option from a plurality of different configuration options; and control means for sending link configuration instructions to at least one of the remote terminals to implement the selected configuration option.
2. 2. The link configuration controller of claim 1, comprising means for determining measured or estimated performances for said plurality of different configuration options, using said link performance information.
3. 3. The controller of claim 1 or claim 2, wherein the storage means is further configured to obtain device configuration parameters and/or link configuration parameters from one or more of said remote terminals and to store said parameters in said storage means, to provide a part of said representation of the system configuration.
4. 4. The controller of any previous claim, further comprising one or more QoS managers, each for receiving link performance quality information from the QoS communication means and for selecting one of said plurality of configuration options for use by the control means.
5. 5. The controller of claim 4, wherein said one or more QoS managers comprises a first QoS manager operating with a first protocol and a second QoS manager operating with a second protocol.
6. 6. The controller of claim 4 or claim 5, wherein at least one of said one or more Q0S managers is configured to receive said link performance information and monitor for a trigger condition to decide whether to activate a different configuration option.
7. 7. The controller device of any previous claim, further comprising trigger means for registering trigger conditions for network performance and for issuing triggers when performance degrades below threshold levels set by applications.
8. 8. The controller of any previous claim, further comprising simulation means for using a simulation model to predict the performance of different link transmission configurations based on information stored in the storage means.
9. 9. The controller of claim 8, configured to update said storage means in the controller with the predicted performance information to assist in selection of configuration options.
10. 10. The controller of any previous claim, configured to use past performance data stored in said storage means to predict the performances of alternative configuration options
11. 11. The controller of any previous claim, wherein the network interface comprises one or more radios that can be used for forming a wireless link connection to one or more of said remote terminals, and wherein each said wireless link connection can be selected for use and configured by the controller.
12. 12. The controller of any previous claim, configured to support the collection of performance information using a ULLA (Unified Link Layer API) implementation.
13. 13. The controller of any previous claim, wherein said configuration options comprise a broadcast configuration and a unicast configuration.
14. 14. The controller of any previous claim, wherein said configuration options comprise a plurality of transmission frequencies.
15. 15. The controller of any previous claim, wherein said configuration options comprises scheduling parameters for a multiplexing transmission.
16. 16. The controller of any previous claim, wherein the link performance information comprises at least one of signal level, noise level, frame latency or inter-arrival, and frame error statistics from the end terminal devices, for each received packet.
17. 17. The controller of any previous claim, wherein the link performance information comprises at least one of signal level, noise level and frame errors statistics from an access point device serving at least one of said remote tenninals, for each received packet.
18. 18. The controller of any previous claim, wherein the control means is configured to instruct handover of a remote terminal from a first to a second access point, according to the loading on each access point.
19. 19. The controller of any previous claim, further comprising a second network interface for connection to a second network, wherein the controller is configured to act as a gateway between the wireless network and said second network.
20. 20. A video server comprising the controller of any previous claim.
21. 21. A carrier medium carrying computer readable code for configuring a computer as the apparatus of any one of claims Ito 19.
22. 22. A method of controlling the link configuration in a wireless communication network by providing an interface between at least one QoS (Quality of Services) manager and a plurality of wireless remote terminals including end terminal devices, the method comprising: obtaining current link performance information related to radio link configurations for at least some of the remote terminals; storing said link performance information to collectively represent the system configuration; informing said at least one QoS manager of link performance quality; iceiving an instruction from the QoS manager to select one configuration option from a plurality of different configuration options; and sending link configuration instructions to at least one of the remote terminals to implement the selected configuration option.