Method and system for admission control in communication networks

Field of the invention

The present invention relates to techniques for admission control in communication networks. The invention was devised by paying specific attention to the possible application to local area networks (LANs) such as e.g. a wireless LAN.

Obviously, reference to this possible field of application of the invention must not be construed in a limiting sense of the scope of the invention. In fact, the invention is also adapted for use e.g. in non-wireless networks (such as the Ethernet), other types of wireless networks (UltraWideBand), or mobile telephone networks including terminals equipped with a WLAN interface.

Description of the related art

Wireless LANs (WLANs) are becoming increasingly popular not just for data transmission but also for real time streaming applications.

WLANs are being increasingly introduced in domestic environments mainly for sharing access to a broadband Internet connection. IEEE802.11b (see IEEE802.1lb standard, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications", 1999 edition) running at 11 Mbps is widely used nowadays, while higher speed IEEE802.11g at 54 Mbps is being gradually introduced. Consumer electronics manufacturers are interested in using a domestic WLAN to distribute audiovisual content among entertainment devices and PC's.

However, none of the above-mentioned standards has been developed to support streaming services, which require strict quality of service (QoS) guarantees in terms of delay and delay variation.

The lack of quality of service (QoS) support at the MAC (Medium Access Control) layer of existing WLANs makes audio video streaming particularly sensitive to interfering data traffic.

Streaming media over a Wireless LAN is relatively simple in the ideal case of a channel with a limited error rate and without interference. In practice, however, the attenuation of the signal caused by walls and multipath effects of a closed environment such as a home. environment sometimes result in a high (and variable) bit error rate. Furthermore, as wireless equipment in the 2.4 and 5 GHz ISM bands is becoming commonplace, multiple users may be sharing the same radio spectrum in an uncoordinated way, thereby producing mutual interference.

The consequence of transmission errors and interference thus generated is twofold.

Firstly, the need of re-transmitting frames causes bandwidth waste.

Secondly, such retransmissions increase the jitter of frames that arrive at the receiver of a real-time flow: a bigger buffer is therefore needed to compensate for the ensuing delay variations.

For immediate reference, an exemplary home WLAN networking scenario is depicted in Figure 1. There, a set-top box STB is shown receiving a stream from a personal computer PC through a Wireless LAN (WLAN). At the same time, a laptop LT is accessing the Internet (NET) through the WLAN access point AP, which has a broadband connection.

In this scenario, the TCP/IP (Transport Control Protocol/Internet Protocol) connection could use a significant portion of the radio bandwidth, especially if the Internet connection is broadband. This situation results in a decrease of the bandwidth available for the real time stream. In a common case where the video source cannot adapt the source coding rate to the variable channel capacity, a loss of packets is experienced at the receiver, with an unacceptable video quality. This phenomenon may be burst-like and largely unpredictable.

For the sake of completeness, it should be mentioned that home WLAN topologies different from the one shown in figure 1 exist. This fact does not derogate from the key issues considered here, which apply e.g. to whatever device plays the role of the WLAN access point (whose function may be incorporated to the set-top box STB).

A number of solutions have been proposed to solve the problem of robust real time streaming over packet networks (including Wireless LANs).

For instance, enhancing the WLAN MAC layer has been proposed in the draft standard IEEE802.11e so that the medium access probability of a station depends on the priority of the frame it transmits.

Specifically, the IEEE802.11e draft standard adds QoS capabilities to the 802.11 MAC layer by introducing the following features: <ul id="ul0001" list-style="dash" compact="compact"><li>identification of different Traffic Categories (TC): each TC has an associated priority</li><li>Enhanced Distributed Coordination Function (EDCF), which dictates that stations use TC information when accessing the medium, resulting in a modified random access scheme (the probability to get access to the channel is proportional to TC)</li><li>an enhanced polling mechanism that allows mobile stations to request Transmission Opportunities (TXOP), i.e. reserved time intervals that are assigned by a 802.11e access point to a requesting station for transmission</li><li>Traffic Specification (TS) that specify QoS parameters for signalling purposes between the nodes and the access point</li><li>improved ARQ (Automatic Repeat Request) mechanism through delayed and selective acknowledgments</li><li>Forward Error Correction (FEC) for improved error robustness.</li></ul>

To support all the above features, new MAC frame formats are defined as well as specific signalling in the access point beacon.

Use of the new 802.11e features inevitably requires applications to be provided with means for requesting a specific QoS. The appropriate priority is thus assigned to the frames transmitted within a LAN. This can be done by means of Ethernet frame tagging (IEEE802.1q), which extends the normal Ethernet header with traffic priority tags. The 802.11e MAC layer can then use the 802.1q header to classify the frame to transmit.

Such an arrangement shifts to a higher layer the problem of assigning priorities to Ethernet frames in a LAN. Using 802.11e in a LAN thus requires that all the equipment in the network understands Ethernet 802.1q frames and processes them accordingly. Furthermore, applications have no standard way of requesting a specific priority for their traffic, since no API is universally accepted. It is therefore unclear how applications will use the mechanisms introduced by IEEE802.11e.

To sum up, the IEEE802.11e addendum will introduce new features in the MAC layer to address this problem; however, significant effort will be required to make use of the new QoS features in a standardized way. In fact, a universally accepted Application Programmers' Interface (API) for using the QoS mechanisms available in the link layer does not exist and it will take some time to emerge.

The Reservation Protocol (RSVP) is a signaling protocol at the IP layer, which enables a node to request a certain QoS for a traffic flow. If resources to support such QoS are available in all the intermediate nodes, a path is reserved for that flow. This protocol is part of the so-called "IntServ" QoS Internet architecture but suffers from scalability problems. Routers must store a considerable amount of information for each QoS-enabled flow, which makes RSVP hardly applicable in the "big" Internet. This scalability problem does not hold for a home networking scenario, so RSVP may play a role here. However, recent announcements from certain OS vendors indicate that RSVP adoption is at risk also in restricted environments.

So the key problem remains however, related to the signalling required to set up the LAN resources in such a way that the packets are properly allotted priorities. Such a signalling mechanism is usually implemented at the IP layer or above and results in resources being reserved for specific traffic flows at various nodes in the network. A universally accepted signalling method does not exist nowadays, even if several proposals have been standardized.

In Y. Rasheed, J. Ritchie: "High-Quality Media Distribution in the Digital Home", Intel Technology Journal, Vol. 6, issue 04, Nov. 2002, ISSN 1535-766X an architecture for QoS capability discovery, signalling and mapping on physical resources is discussed which is adapted for use in a home environment. The authors suggest a solution that is implemented at the application level and which makes use of the Universal Plug-n-Play standard (UPnP). UPnP allows service discovery and remote procedure calls by using HTTP (HyperText Transfer Protocol) as a transfer protocol and XML (Extensive Markup Language) for data representation. By means of this solution, devices - including consumer electronics (CE) equipment - are able to discover the content that is stored in other home network devices and reserve QoS resources in the relevant network elements for streaming purposes.

Although UPnP support is growing in popularity, it is clear that a significant complexity is involved in the software that devices have to incorporate. While this is not a problem for PC's, it may limit the adoption of this architecture in CE equipment. Small footprint implementations are being developed that however come at the price of a slightly reduced functionality, which translates in potential interoperability problems. Another drawback of this approach is that all devices should cooperate according to the proposed architecture. This leaves some questions open related to legacy devices as well as legacy link layer technologies that lack QoS support at the MAC layer (e.g. IEEE802.11b/g but also plain Ethernet).

Object and summary of the invention

Given the great and growing interest for streaming services such as e.g. WLAN-based A/V (audio/video) streaming, the high number of legacy devices without QoS support already in the market and the uncertain path towards QoS-enabled applications in the home, a basic need exists for simple solutions for a "better-than-best-effort" service to A/V streams in existing networks such as WLANs.

More to the point, the need is felt for arrangements that: <ul id="ul0002" list-style="dash" compact="compact"><li>should not require changes in the applications that manage A/V streaming,</li><li>use existing and emerging standards such as e.g. WLAN standards without explicit QoS support at the MAC layer, and</li><li>have a limited complexity.</li></ul>

According to the present invention, that object is achieved by means of a method having the features set forth in the claims that follow. The invention also relates to a corresponding system, a related network as well as a related computer program product, loadable in the memory of at least one computer and including software code portions for performing the steps of the method of the invention when the product is run on a computer. As used herein, reference to such a computer program product is intended to be equivalent to reference to a computer-readable medium containing instructions for controlling a computer system to coordinate the performance of the method of the invention. As used herein, the term "computer" also encompasses i.a. embedded devices such as access points, home gateways or set-top boxes. Reference to "at least one computer" is evidently intended to highlight the possibility for the present invention to be implemented in a distributed/ modular fashion.

A preferred embodiment of the invention thus provides an arrangement for WLAN A/V streaming that does not require any explicit signalling among devices. Conversely, in a preferred embodiment of the arrangement described herein, the WLAN access point constantly monitors all the traffic among stations and autonomously understands the priority of each flow (real time vs. data streams).

In that way, a user-defined admission control policy can be applied each time a new traffic flow is detected by the AP, which may result in the new traffic flow not being serviced by the AP. This policy leaves more bandwidth available for the privileged traffic flows like real time flows. When a new mobile station joins the WLAN or a new TCP/IP session is being initiated, the AP checks if there is sufficient bandwidth for all the traffic flows. In case of congestion, i.e. when the new traffic flow could hamper an ongoing real time transmission, the AP drops all the packets belonging to the identified interfering flow, thereby blocking such interfering traffic.

The arrangement described herein thus presents a new approach for limiting such effects. Specifically a procedure is introduced that runs in the residential gateway (or access point) and keeps track of ongoing transmissions. When new TCP/IP sessions that could deteriorate the quality of the audiovisual stream(s) are detected, the algorithm selectively discards interfering packets. In that way a call admission control function is performed, which does not need specific signalling mechanisms to be introduced in the other terminals of the Wireless LAN, thereby reducing complexity.

Brief description of the annexed drawings

The invention will now be described, by way of example only, with reference to the enclosed figures of drawing, wherein: <ul id="ul0003" list-style="dash" compact="compact"><li>figure 1, exemplary of a WLAN home networking scenario, has been already discussed in the foregoing,</li><li>figure 2 is a flowchart exemplary of traffic handling at a WLAN access point in the arrangement described herein,</li><li>figure 3 is a state flow diagram of access point processing,</li><li>figure 4 represents initiating data transmissions being blocked in the arrangement described herein,</li><li>figure 5 is a block diagram representative of a WLAN scenario where only some devices support IEEE802.11e,</li><li>figure 6 is a simplified block diagram of an access point, and</li></ul>    figure 7 is a block diagram of an access point with hardware packet classifier.

Detailed description of preferred embodiments of the invention

The main steps of the procedure described herein are summarized in the flow chart of Figure 2. Essentially the goal pursued thereby is to determine how the access point AP (see the general representation of figure 1) can monitor the network traffic and autonomously detect the different traffic flows.

Specifically, the blocks 110 to 112 are representative of the following steps/actions: <ul id="ul0004" list-style="dash" compact="compact"><li>packet reception (100),</li><li>flow detection classification (102),</li><li>flow table management (104),</li><li>Call Admission Control (CAC) policy,</li><li>check as to whether the packet is to be forwarded (108), and</li><li>forwarding (110) or dropping (112) the packet.</li></ul>

In detecting a real time A/V (audio/video) streaming flow the access point AP can detect a real time audiovisual stream by: <ul id="ul0005" list-style="dash" compact="compact"><li>inspecting the source and destination MAC headers of the Ethernet frames it forwards</li><li>checking the IP header protocol type - usually UDP (Unreliable Datagram Protocol), but other kinds of encapsulation are also possible, e.g. TCP/HTTP</li><li>checking the UDP payload and recognizing RTP headers</li><li>examining the interarrival time statistics of consecutive packets that belong to the same flow as well as the flow average bitrate.</li></ul>

In detecting active stations, the arrangement described herein takes advantage of the fact that according to IEEE802.1d a LAN access point is an Ethernet learning bridge. WLAN stations that are actively sending and receiving traffic can be identified in the AP by looking at the MAC addresses in the bridge forwarding table, which is specified in the bridge MIB. Because of the soft-state nature of this table, the MAC addresses of stations that have not been exchanging frames for a while are deleted after a specified timeout.

Detecting data traffic flows that could potentially interfere with the real time audiovisual stream can be recognized by the access point AP by looking at the content of the Ethernet frames it forwards. Since the dominant protocol is TCP/IP, the access point AP in most cases only needs to recognize this protocol.

For example, whenever a new TCP/IP session is initiated a three-way handshake is performed between the client and the server. The access point AP can easily recognize this sequence, insert the "tuple" {IP source address, IP destination address, TCP source port, TCP destination port} in a list and apply a specific policy to this flow, as identified by the tuple. Another approach for identifying a data flow is based on MAC header information instead of IP header information or a combination of the above.

Conversely, there is no easy way for the access point AP to determine the presence of an interferer, which is possibly located close to a WLAN station.

One possible solution is monitoring of the number of packet retransmissions for a given link. An abrupt increase of such an indicator may correspond to other devices that are transmitting in the same band.

For the purposes of the procedure described herein, the access point AP should record this event and decrease the amount of available bandwidth. When the bad conditions of the wireless link between the access point AP and the WLAN station persist, the amount of frame retransmissions considerably reduces the overall available bandwidth in the WLAN.

Therefore the AP may decide to drop the connection with the specific station and remove the cause of bandwidth waste in case of congestion.

As regards the CAC function, once the access point AP has recognized real time traffic in the network, it calculates its bit rate and, depending on the wireless channel conditions for each of the stations connected, it calculates the remaining available bandwidth.

For example, referring to Figure 1, the bandwidth occupied by the real time traffic flow depends on: <ul id="ul0006" list-style="none" compact="compact"><li>- i) the real time flow bitrate</li><li>- ii) the relative positions of the access point the AP and the personal computer PC</li><li>- iii) the relative positions of the access point AP and the set top box STB</li><li>- iv) the presence of other interfering equipment in the same ISM band.</li></ul>

With reference to points ii) and iii), the procedure must take into account the average bit error rate of each of the wireless links, which affects the number of frame retransmissions (and hence the radio bandwidth).

In case of high bit error rates or interference on the downstream wireless link (from the access point AP to the set top box, STB in the example considered), the access point AP may decide to apply a suitable fragmentation threshold so that shorter packets are transmitted that have a smaller retransmission probability.

In any case, by looking at the retransmission rate of the frames (both received and transmitted) the access point AP can estimate the bandwidth that can be made available to other traffic flows.

Given the channel conditions and the estimated average bitrate of a traffic flow, a correction factor is introduced that takes retransmission probabilities into account. This allows a conservative estimate of the remaining bandwidth.

The available bitrate can be approximated by the access point the AP as follows:<maths id="math0001" num=""><math display="block"><mrow><msub><mrow><mtext>B</mtext></mrow><mrow><mtext>A</mtext></mrow></msub><msub><mrow><mtext> = C - Σ</mtext></mrow><mrow><mtext>i</mtext></mrow></msub><msub><mrow><mtext> B</mtext></mrow><mrow><mtext>R,i</mtext></mrow></msub><msub><mrow><mtext>. (1/η</mtext></mrow><mrow><mtext>L,i</mtext></mrow></msub><msub><mrow><mtext>) - Σ</mtext></mrow><mrow><mtext>i</mtext></mrow></msub><msub><mrow><mtext> B</mtext></mrow><mrow><mtext>D,i</mtext></mrow></msub><msub><mrow><mtext>. (1/η</mtext></mrow><mrow><mtext>L,i</mtext></mrow></msub><mtext>)</mtext></mrow></math><img file="EP1557982A1_D0001.tif" /></maths>    where C is the channel capacity, B_R,i is the bitrate of the i-th real time flow, η_L,i is the efficiency of the i-th link (that takes retransmissions into account) and B_D,i is the average bitrate of the i-th data flow.

A state diagram that describes the CAC algorithm on the access point is depicted in figure 3.

The access point AP is normally in the network monitoring state 200, where it tracks flows bitrates as well as wireless link conditions. In this state, no limitations to admitted traffic flows are applied.

Once a real time (RT) stream is detected (step 201), the AP enters a classification state 202, where the characteristics of such a flow are estimated (mainly the bandwidth it requires). Then a user-defined call admission control policy is applied (state 204), which can specify if the flow is to be admitted or not.

In the latter case, all the packets belonging to the stream will be discarded (dropped) by the access point AP, thereby freeing some bandwidth. This part of the processing is performed in the network protection state designated 206. In this state the AP keeps monitoring the network and the wireless link conditions, but selectively discards packet that belong to non-admitted flows.

If a new real time stream is activated by a station (in a step 207), the flow classification state 202 is entered again. In the period of time where the new flow is being classified, there is a probability that the bandwidth is not sufficient for both flows and interference effects are experienced.

To avoid this effect, the user-defined CAC for the first flow may dictate that new flows should not even be evaluated for admission.

When all real time flows are terminated, the state machine goes from the network protection state 206 back to the normal network monitoring state 200.

In the network protection state 206, when a non-real time flow is detected (in a step 208), the flow may be admitted to the network or not given the estimated available bandwidth and the call admission control policy. Even in the latter case, the access point AP needs some time to estimate the statistical characteristics of the data flow. This CAC policy is represented in the diagram of figure 3 by the state 209, from which the machine switches back to the network protection state 206.

In the case of burst-like downlink data traffic (a common case for Internet browsing sessions), the access point AP may perform traffic shaping by smoothing packet inter transmission times: this requires resources in terms of memory in the AP but has the effect of reducing interference with an audiovisual real time flow.

The effects of packet dropping in the access point AP may be evaluated by considering that, when a traffic flow is not admitted in the network, the access point AP simply does not forward its packets (either towards the wired network or inside the WLAN). However, this does not prevent the station from transmitting data, so the consequences vary depending on the traffic flows that are being denied.

In the case of a data traffic flow, one needs to take into account the transport protocol characteristics, namely the TCP/IP behaviour.

Normally, once a TCP/IP connection has been established, the sender transmits data without waiting for acknowledgements until a transmission window is reached. The transmission rate depends on the ACK (Acknowledgemnt Message) interarrival times.

If ACK packets are dropped, the TCP sender retransmits packets after the retransmission timeout expires.

If no ACKs are received the retransmission timeout is doubled.

After an amount of time in the order of seconds, the TCP/IP connection is finally dropped.

If TCP data packets are dropped, the ACK signalling mechanism also causes retransmissions at the TCP sender, which follow an exponential backoff scheme. Furthermore, the normal transmission rate is reduced.

So, in the case of an ongoing TCP/IP connection, dropping packets causes retransmissions with a frequency that decreases over time. Clearly this will have effects on the user that is requesting the data service (see below for UI aspects). In case of a TCP/IP connection that is being started, the AP can in any case interrupt the three-way handshake process by dropping either TCP-SYN, TCP-SYN-ACK or TCP-ACK messages. Details of this specific procedure are known in the art (see, e.g., D. Comer: "Internetworking with TCP/IP Volume 1: Principles, Protocols and Architecture", 4th edition, 2000, ISBN 0-13-018380-6 ).

After some retransmissions, the client will stop the connection establishment process (unless the user manually re-starts it). This scenario is depicted in figure 4 that represents the process of blocking initiating data transmissions.

In the diagram WLAN STA is indicative of any station in the WLAN considered, while WLAN AP is indicative of the corresponding Access Point AP.

Specifically, I represents as a whole those transactions that would lead to establishing the usual TCP/IP connection. The double pointed arrow is representative of (bilateral) data flow, while II generally represents the effect of the intervention of the access point AP in interrupting the establishment of the TCP/IP connection.

The enforcement of the CAC policy enforcement at the access point AP is effective for data flows. The same may not apply to real-time flows that the AP wants to inhibit, since there is typically no transport control mechanism that use acknowledgements from the receiver back to the transmitter. The access point AP may send ICMP error messages back to the station that is generating traffic but the consequences depend on the applications that manage the real time data transmission.

Finally, when calculating the available bandwidth, the access point AP takes into account the background traffic that can always be found in a network, such as ARP requests. Such traffic, in fact, is generated by WLAN stations and cannot be blocked by the access point AP.

Blocking interfering flows by MAC-layer disassociation is another mechanism that the access point AP may use to prevent non-admitted stations to generate traffic. In that way, stations are disconnected by the access point AP and, at least momentarily, stop sending frames.

This method, however, assumes that a driver can properly control the WLAN MAC layer firmware.

Effectiveness of the proposed method in networks with 802.11e terminals can be examined by referring to a scenario where the access point AP runs the proposed admission control procedure: consequently it also has IEEE802.11e traffic differentiation support feature in its WLAN card.

Reasonably, one cannot assume that all the terminals/stations that will be connected to the AP have 802.11e support. Legacy 802.11b/g terminals connected to the access point AP can still generate traffic in an unpredictable way.

Without an admission control mechanism like the one proposed in the present invention, high-priority traffic between two 802.1le-enabled devices can be adversely affected by a legacy 802.11b/g terminal. In fact, although IEEE802.11b/g interfering frames have a lower probability of getting access to the channel compared to higher priority traffic generated by 802.11e nodes, they can still occupy the channel for long periods of time, especially when the link conditions are not good (high bit error rate) and therefore many retransmissions are necessary to correctly deliver frames to their destinations.

This scenario is depicted in figure 5. There possible interaction of an 802.11e access point AP with two stations STA1 and STA2 is shown in connection with high priority, low BER flows represented by a real time flow A and a data flow B, respectively. The station STA1 is an 802.11e station while the station STA2 is a non-802.11e station (e.g. an 802.11b/g terminal).

The admission control procedure described herein is able to autonomously detect the condition where STA2 is interfering with higher priority traffic and consequently disconnect STA2.

Therefore, the admission control procedure described herein can be beneficial also when prospected QoS enhancements in the IEEE802.11 MAC layer will be made available.

Concerning user interfaces, two aspects are particularly significant, namely i) how to configure the access point AP with a user-defined call admission control policy, and ii) how to notify users that their traffic is not admitted.

As regards configuration, commercial access points usually have a small embedded web server that allows a client to configure the main parameters (Service Set Identifier, channel,...). Therefore, adding Web pages to configure the call admission control policy is not an issue. Significant CAC parameters may be: <ul id="ul0007" list-style="dash" compact="compact"><li>bandwidth reserved for RT flows</li><li>max number of simultaneous clients admitted</li><li>priorities of application flows.</li></ul>

Other ways of configuring such parameters (for example by means of the UPnP protocol or other proprietary mechanisms) are obviously possible.

Notification of denial of service

The effects of packet not being forwarded by the access point as a result of a call admission control policy are immediately experienced by the user as a lack of application responsiveness.

To help create a better user experience, the access point AP may send some information back to the station. In case of an HTTP based application, the access point AP can send a redirect message back to the station so that a suitable Web page is shown in the client browser.

Figures 6 and 7 provide some details of possible embodiment of an access point AP according to the arrangement described herein.

Specifically, figure 6 is a simplified block diagram of the structure of an the access point AP including an Ethernet card 10, one or more Wireless LAN card(s) 12, a CPU 14, a Flash memory 16 and dynamic memory 18. The elements mentioned are usually connected via a bus 20. The WLAN and Ethernet cards 10 and 12 may be connected through a PCI bridge (not shown in the picture for simplicity).

In any case, their typical behaviour is transmitting and receiving Ethernet frames from/to the memory 16 using DMA access and CPU interrupts.

The structure of the CPU 14 (which usually boots an operating system from flash memory upon startup) is highlighted in the right hand portion of figure 6. Specifically, device drivers 141 and 142 take care of handling Ethernet frames both in transmission and reception by preparing/checking their headers and copying their payload into data structures specific to an Operating System (OS) 143.

Usually, bridging modules 144 in the access point AP takes care of forwarding frames from one network interface to another.

Furthermore, the AP usually includes an SNMP (Simple Network Management Protocol) agent 145 that enables remote control of the device, an authentication module 146 to give access only to allowed clients, an IP stack 147 (to enable remote monitoring through SNMP) and a Web browser 148 for configuration purposes.

The Call Admission Control procedure described invention runs as a stand-alone process/module 149 (designated "QoS agent") and controls the behaviour of the Ethernet bridge by using information coming from the device drivers. This can be accomplished by using the well-known socket interface (see once again, e.g., D. Comer: "Internetworking with TCP/IP Volume 1: Principles, Protocols and Architecture", 4th edition, 2000, ISBN 0-13-018380-6 ) and private "ioctl" commands.

A QoS agent can also be conceived that does not influence the bridging software but only interacts with the device drivers. In that case, a small modification in the WLAN device driver could enable dropping specific packets under control of the QoS agent.

As indicated, the present invention is applicable not only to traditional WLAN access points, but also to such devices as Set-top boxes, TV sets, personal computers or other equipment configured to act as a WLAN access point.

The CAC procedure considered is based on the inspection of the content of each MAC frame by the access point AP. This may turn out to be a heavy task especially for high data rates. Some sort of optimisation may thus be introduced. For example, a dedicated hardware block could take care of packet classification by comparing header fields against a look-up-table (LUT).

This hardware block could be programmed by the CPU at boot time and the look up table could be accessible by the CPU through memory mapped I/O.

Events like new flows detected or terminated flows are signalled to the main CPU by means of interrupts. By accessing the LUT, the CPU can retrieve statistical information about WLAN traffic flows.

A corresponding block diagram is shown in Figure 7, where references 14, 16, and 20 designate the same elements shown in figure 6, namely the CPU, the dynamic memory and the bus. Reference 22 indicates the packet classifier considered in the foregoing, including a LUT 22a. References 24 and 26 designate the WLAN MAC and PHY layers, and the Ethernet, respectively

One possible configuration of the LUT 22a is shown in Table 1. <tables id="tabl0001" num="0001"><table frame="all"><title>Table 1:</title><tgroup cols="9" colsep="1" rowsep="1"><colspec colnum="1" colname="col1" colwidth="17.50mm" /><colspec colnum="2" colname="col2" colwidth="17.50mm" /><colspec colnum="3" colname="col3" colwidth="17.50mm" /><colspec colnum="4" colname="col4" colwidth="17.50mm" /><colspec colnum="5" colname="col5" colwidth="17.50mm" /><colspec colnum="6" colname="col6" colwidth="17.50mm" /><colspec colnum="7" colname="col7" colwidth="17.50mm" /><colspec colnum="8" colname="col8" colwidth="17.50mm" /><colspec colnum="9" colname="col9" colwidth="17.50mm" /><thead valign="top"><row><entry namest="col1" nameend="col9" align="left">Packet classifier look up table structure.</entry></row><row><entry namest="col1" nameend="col1" align="left">Flow No.</entry><entry namest="col2" nameend="col2" align="left">SRC MAC</entry><entry namest="col3" nameend="col3" align="left">DST MAC</entry><entry namest="col4" nameend="col4" align="left">SRC IP</entry><entry namest="col5" nameend="col5" align="left">DST IP</entry><entry namest="col6" nameend="col6" align="left">A/V</entry><entry namest="col7" nameend="col7" align="left">SRC port</entry><entry namest="col8" nameend="col8" align="left">DST port</entry><entry namest="col9" nameend="col9" align="left">admitted</entry></row></thead><tbody valign="top"><row><entry namest="col1" nameend="col1" align="left">1</entry><entry namest="col2" nameend="col2" align="left">00:08:74:B2:A2:BE</entry><entry namest="col3" nameend="col3" align="left">00:02:2D:68:2D:3C</entry><entry namest="col4" nameend="col4" align="left">A</entry><entry namest="col5" nameend="col5" align="left">B</entry><entry namest="col6" nameend="col6" align="left">yes</entry><entry namest="col7" nameend="col7" align="left">1234</entry><entry namest="col8" nameend="col8" align="left">1234</entry><entry namest="col9" nameend="col9" align="left">Yes</entry></row><row><entry namest="col1" nameend="col1" align="left">2</entry><entry namest="col2" nameend="col2" align="left">00:08:02:6A:75:08</entry><entry namest="col3" nameend="col3" align="left">00:08:74:B2:A2:BE</entry><entry namest="col4" nameend="col4" align="left">C</entry><entry namest="col5" nameend="col5" align="left">D</entry><entry namest="col6" nameend="col6" align="left">no</entry><entry namest="col7" nameend="col7" align="left">X</entry><entry namest="col8" nameend="col8" align="left">80</entry><entry namest="col9" nameend="col9" align="left">No</entry></row><row rowsep="1"><entry namest="col1" nameend="col1" align="left">3</entry><entry namest="col2" nameend="col2" align="left">00:02:2D:68:2D:3C</entry><entry namest="col3" nameend="col3" align="left">00:08:02:6A:75:08</entry><entry namest="col4" nameend="col4" align="left">B</entry><entry namest="col5" nameend="col5" align="left">C</entry><entry namest="col6" nameend="col6" align="left">no</entry><entry namest="col7" nameend="col7" align="left">X</entry><entry namest="col8" nameend="col8" align="left">80</entry><entry namest="col9" nameend="col9" align="left">Yes</entry></row></tbody></tgroup></table></tables>

In the example considered above, the A/V flow No. 1 has been admitted, therefore each packet whose source and destination MAC address, source and destination IP address and ports match the content of the first row of the LUT will be forwarded.

The second flow has not been admitted; therefore each packet whose headers match the second row of the LUT will not be forwarded.

The comparison between the relevant frame header fields and the rows in the LUT are performed by dedicated hardware in the packet classifier.

An arrangement has been described to protect audiovisual streams from interfering data traffic in a WLAN. Such an arrangement performs call admission control without requiring any signalling among WLAN stations and only runs in the access point. This is a major advantage with respect to the prior art.

The access point continuously estimates the wireless network conditions and can block data traffic that could interfere with real time streams, according to user selectable policies.

It is once more recalled that the detailed description of a possible application to local area networks (LANs) such as e.g. a wireless LAN must not be construed in a limiting sense of the scope of the invention.

In fact, the invention is also adapted for use e.g. in non-wireless networks (such as the Ethernet), other types of wireless networks (UltraWideBand), or mobile telephone networks including terminals equipped with a WLAN interface. In view of the foregoing, the term "access point" is used herein to designate any point providing access to a network.

Consequently, without prejudice to the underlying principles of the invention, the details and the embodiments may vary, also appreciably, with reference to what has been described by way of example only, without departing from the scope of the invention as defined in the annexed claims.