Handover optimisation in a WLAN radio access network

TECHNICAL FIELD

The invention relates generally to radio access networks and more specifically to methods and means for assisting handover of a communication session in such networks.

BACKGROUND

<figref idrefs="DRAWINGS">FIG. 1</figref> illustrates the basic network architecture of a conventional radio access network <b>100</b>, in form of a wireless local area network, WLAN, comprising a first access point AP<b>1</b><b>110</b>, a second access point AP<b>2</b><b>120</b>, and an Access Router, AR <b>150</b>. The WLAN <b>100</b> may be connected to other network/s <b>160</b> such as e.g. the Internet and/or a UTRAN (Universal Terrestrial Radio Access Network). In <figref idrefs="DRAWINGS">FIG. 1</figref>, AP<b>1</b><b>110</b> and AP<b>2</b><b>120</b> are connected with AR <b>150</b> via Multicast-enabled Layer <b>2</b> Switches, M-L<b>2</b>S<b>1</b><b>130</b> and M-L<b>2</b>S<b>2</b><b>135</b>, respectively, but many other possibilities exist. The APs may e.g. be connected directly to AR <b>150</b> without any intermediate M-L<b>2</b>Ss, or they may be connected to the same M-L<b>2</b>S which in turn is connected to AR <b>150</b>. Since the Ethernet (IEEE 802.3) protocol is used for most of the WLAN access points today as layer 2 protocol to communicate with fixed network infrastructure, an M-L<b>2</b>S is identical with an Ethernet switch. A User Terminal, UT, <b>140</b> having a communication session, e.g. a data session or a Voice over IP session with a peer connected to the network <b>160</b> (e.g. Internet or UTRAN), routed via AP<b>1</b>, <b>110</b>, normally performs a handover of the session from AP<b>1</b>, <b>110</b>, to AP<b>2</b>, <b>120</b>, whenever a certain handover criterion is fulfilled. The criterion is normally a function of the offered radio link quality and/or QoS (quality of service) of AP<b>11</b><b>10</b> and AP<b>2</b><b>120</b>, respectively, so that the UT's <b>140</b> communication session will be routed through the access point offering the highest/best radio link quality/QoS, in a conventional manner. However, the handover criterion may be based on other aspects e.g. regarding accounting, security etc.

General problems regarding effective handover schemes for radio access networks relate e.g. to data loss minimization, interference suppression, packet delay minimization and to minimize network signaling.

More specifically, for the WLAN in <figref idrefs="DRAWINGS">FIG. 1</figref> exploiting the IEEE 802 standard, the establishment of a security association between the UT <b>140</b> and a target AP, i.e. AP<b>2</b><b>120</b> in case of a handover from AP<b>1</b><b>110</b> to AP<b>2</b><b>120</b> in <figref idrefs="DRAWINGS">FIG. 1</figref>, when applying a standard EAP (Extensible Authentication Protocol) authentication in accordance with the IEEE 802.11i security specification may pose a crucial issue regarding the caused interruption time, i.e. it may cause unacceptable packet delay/loss for real time applications such as voice and/or video. Such an authentication is carried out after that the UT <b>140</b> has been successfully associated with the new AP (AP<b>2</b><b>120</b> according to above example), and the radio link connectivity between UT <b>140</b> and the old AP (AP<b>1</b>, <b>110</b>) is thus already aborted. During the period between the initiation of association with a new target AP (AP<b>2</b>, <b>120</b>) and completion of the EAP authentication and installation of the security parameters at the new target AP, no data (e.g. IP-) packets can be exchanged between UT <b>140</b> and AR <b>150</b> over the WLAN transmission path, which of-course constitutes a problem.

Another problem associated with the handover of TCP-sessions in radio access networks is that received packets being out of order will be retransmitted, which increases the radio interference, and the transmission rate may also be tuned down as a consequence, since the TCP interprets packets being out of order as a network congestion state.

SUMMARY OF THE INVENTION

The present invention seeks to mitigate/solve above problems.

It is an object of the present invention to improve the handover characteristics of radio access networks, such as e.g. a WLAN or a UTRAN (Universal Terrestrial Radio Access Network).

It is an object of the present invention to minimize data loss and/or to decrease the interference and/or the packet delay/loss and/or the network signaling, during a handover of a communication session from one radio access point to another, in a radio access network.

It is a further object to mitigate the packet delay problems during handover, especially for real time applications such as voice and/or video, when applying an authentication procedure, such as an EAP standard procedure, in a wireless data network according to the IEEE 802 standard.

According to a first aspect, the invention provides a method for assisting handover of a user terminal's, UT's, communication session from a first radio access point, AP<b>1</b>, to a second radio access point, AP<b>2</b>, in a radio access network, said method to be used by said AP<b>1</b>, said method comprising the following steps: <ul><li id="ul0001-0001" num="0000"><ul><li id="ul0002-0001" num="0011">receiving a handover intention notify message comprising a session identifier and indicating that said UT intends to perform a session handover,</li><li id="ul0002-0002" num="0012">assigning said session a buffer memory space (<b>213</b>) in a memory (<b>211</b>) of said AP<b>1</b> (<b>210</b>),</li><li id="ul0002-0003" num="0013">buffering downlink data packets addressed to said UT (<b>240</b>) in said buffer memory (<b>213</b>) as a response on receiving said handover intention notify message.</li></ul></li></ul>

In one embodiment, said radio access network is a wireless data network according to an IEEE 802 standard arranged to authenticate UTs requesting network access and wherein said session identifier is a MAC address of said UT (<b>240</b>) as defined by said IEEE 802 standard.

In one embodiment, the method further comprises the step of: <ul><li id="ul0003-0001" num="0000"><ul><li id="ul0004-0001" num="0016">blocking the transmission of downlink session packets to said UT as a response on receiving said handover intention notify message.</li></ul></li></ul>

In one embodiment, said handover intention notify message further comprises an AP-identifier identifying said AP<b>2</b>, indicating a handover of said session to said AP<b>2</b>, wherein the method further comprises the step of: <ul><li id="ul0005-0001" num="0000"><ul><li id="ul0006-0001" num="0018">sending said buffered downlink packets to said AP<b>2</b> as a response on receiving said handover intention notify message.</li></ul></li></ul>

In one embodiment, the method further comprises the steps of: <ul><li id="ul0007-0001" num="0000"><ul><li id="ul0008-0001" num="0020">receiving an association update message identifying said AP<b>2</b> and indicating that said UT is associated with said AP<b>2</b>,</li><li id="ul0008-0002" num="0021">sending said buffered downlink packets to said AP<b>2</b> (<b>220</b>) as a response on receiving said association update message.</li></ul></li></ul>

In one embodiment, the method further comprises the step of: <ul><li id="ul0009-0001" num="0000"><ul><li id="ul0010-0001" num="0023">sending a handover intention notify message to an access router, AR, in said radio access network, said message indicating a handover of said session and comprising a session identifier of said communications session and instructing said AR to buffer downlink data packets addressed to said UT.</li></ul></li></ul>

In one embodiment, said handover notify message which is sent to said AR further comprises an AP-identifier identifying said AP<b>2</b>.

According to a second aspect, the invention provides a method for assisting a handover of a user terminal's, UT's communication session from a first access point, AP<b>1</b>, to a second access point, AP<b>2</b>, in a radio access network, said method to be used by said AP<b>2</b> wherein said method comprises the following steps: <ul><li id="ul0011-0001" num="0000"><ul><li id="ul0012-0001" num="0026">establishing that said communication session is to be handed over from said AP<b>1</b> to said AP<b>2</b>,</li><li id="ul0012-0002" num="0027">sending a handover intention notify message to said AP<b>1</b> indicating a handover of said session and comprising a session identifier identifying said session.</li></ul></li></ul>

In one embodiment, the method further comprises the step of: <ul><li id="ul0013-0001" num="0000"><ul><li id="ul0014-0001" num="0029">sending said handover notify message to an access router, AR, instructing said AR to buffer downlink data packets of said session addressed to said UT (<b>240</b>).</li></ul></li></ul>

In one embodiment, said handover notify message further comprises an AP-identifier identifying said AP<b>2</b>.

In one embodiment, said radio access network is a wireless data network according to an IEEE 802 standard, said method further comprising the step of: <ul><li id="ul0015-0001" num="0000"><ul><li id="ul0016-0001" num="0032">authenticating said UT by sending and receiving authentication credentials to/from UT, e.g. by means of the EAP standard.</li></ul></li></ul>

According to a third aspect, the invention provides a method for assisting a handover of a user terminal's, UT's communication session from a first access point, AP<b>1</b>, to a second access point, AP<b>2</b>, in a radio access network comprising an access router, AR, for routing data packets to/from said UT via said AP<b>1</b> and/or AP<b>2</b>, said method to be used by said AR and wherein said method comprises the following steps: <ul><li id="ul0017-0001" num="0000"><ul><li id="ul0018-0001" num="0034">receiving a handover intention notify message indicating a handover of said communication session,</li><li id="ul0018-0002" num="0035">buffering downlink data packets of said session in a buffer memory, as a response to said handover intention notify message.</li></ul></li></ul>

In one embodiment, the method comprises the steps of: <ul><li id="ul0019-0001" num="0000"><ul><li id="ul0020-0001" num="0037">receiving an AP-update-message comprising a session identifier identifying said session and an AP-identifier identifying said AP<b>2</b>, said message indicating a handover to said AP<b>2</b>,</li><li id="ul0020-0002" num="0038">forwarding said buffered downlink data packets of said session to said AP<b>2</b>. In one embodiment, said radio access network is a wireless data network according to an IEEE 802 standard being arranged to authenticate UTs requesting access to said network.</li></ul></li></ul>

According to a fourth aspect, the invention provides a method for assisting a handover of a user terminal's, UT's communication session from a first radio access point, AP<b>1</b>, to a second radio access point, AP<b>2</b>, in a radio access network, said method to be used by said UT and comprising the following steps: <ul><li id="ul0021-0001" num="0040">a) establishing that said communication session is to be handed over from said AP<b>1</b> to said AP<b>2</b>,</li><li id="ul0021-0002" num="0041">b) identifying a first data frame in a first buffer memory of said UT,</li><li id="ul0021-0003" num="0042">c) extracting a frame sequence number, FSN, from said first packet and storing said FSN in a first memory space of a second buffer memory of said UT,</li><li id="ul0021-0004" num="0043">d) forwarding said first packet to an application running on said UT or to a higher level protocol of said UT,</li><li id="ul0021-0005" num="0044">e) fetching a next packet from said first buffer memory being the next packet received by said UT after said first packet,</li><li id="ul0021-0006" num="0045">f) extracting a frame sequence number from said next packet, FSNNEXT,</li><li id="ul0021-0007" num="0046">g) establishing whether said next packet is a consecutive packet of said first packet by comparing said FSNNEXT with said FSN, and,</li><li id="ul0021-0008" num="0047">h) storing said FSNNEXT in said first memory space of said second buffer memory and forwarding said “next packet” to a higher layer protocol or to a final application if it was established in step g) that said “next packet” is a consecutive packet of said first packet, and otherwise buffering said “next packet” in a second memory space of said second buffer memory.</li></ul>

The step a) of establishing that said communication session is to be handed over from said AP<b>1</b> to said AP<b>2</b>, may comprise any of the following steps: <ul><li id="ul0022-0001" num="0000"><ul><li id="ul0023-0001" num="0049">a de-association of AP<b>1</b>, or,</li><li id="ul0023-0002" num="0050">an association of AP<b>2</b>, or,</li><li id="ul0023-0003" num="0051">a handover decision taken by UT according to a certain handover criterion, or,</li><li id="ul0023-0004" num="0052">a handover decision according to a certain handover criterion taken by a network node and signaled to said UT.</li></ul></li></ul>

In one embodiment, the method further comprises the step of: <ul><li id="ul0024-0001" num="0000"><ul><li id="ul0025-0001" num="0054">limiting the size of said second memory space of said second buffer memory by defining a maximum threshold number of stored packets/bytes for said second memory space or defining a maximum allowable storage time for a packet being stored in said second memory space.</li></ul></li></ul>

In one embodiment, data packets received from AP<b>1</b> and/or AP<b>2</b> are stored in received chronological in said first buffer memory, being of a FIFO type, wherein said steps a) and e) of identifying a first and second data frame comprise the step of: <ul><li id="ul0026-0001" num="0000"><ul><li id="ul0027-0001" num="0056">reading a data packet from said FIFO memory.</li></ul></li></ul>

In one embodiment, the method further comprises the steps of: <ul><li id="ul0028-0001" num="0000"><ul><li id="ul0029-0001" num="0058">reading a third data packet from said first buffer memory (FIFO) and establishing that said third data packet is a consecutive data packet of the data packet being the last packet forwarded to said application,</li><li id="ul0029-0002" num="0059">forwarding said third data packet to said application or higher protocol layer and updating the first memory space of said buffer memory with the frame sequence number of said third data packet,</li><li id="ul0029-0003" num="0060">establishing that there is at least one stored data packet in said second memory space of said second buffer memory,</li><li id="ul0029-0004" num="0061">searching said first memory space of said second buffer memory for a consecutive data packet of said third data packet.</li></ul></li></ul>

In one embodiment, said radio access network is a wireless data network according to the IEEE 802 standard and wherein said method further comprising the step of: <ul><li id="ul0030-0001" num="0000"><ul><li id="ul0031-0001" num="0063">sending and receiving authentication credentials to/from AP<b>2</b>, for instance according to the EAP standard.</li></ul></li></ul>

According to a fifth aspect, the invention provides a radio access point AP<b>1</b> allowing a user terminal, UT, access to a radio access network by means of a radio link connection wherein said AP<b>1</b> comprises means realizing the method according to the first aspect when said AP<b>1</b> (<b>210</b>) is installed in a radio access network comprising a second access point AP<b>2</b> and an access router AR.

In one embodiment, said means of the access point AP<b>1</b> comprises a data memory having a first memory space with a first entrance forming a buffer memory for storing downlink packets addressed to said UT, said data memory further having a second memory space with stored program code means which, when loaded in a processing means of said AP<b>1</b>, make said processing means execute at least one procedure realizing said method.

In one embodiment, the AP<b>1</b> is realised as an access point according to the IEEE 802 standard, arranged to realise said method when said AP<b>1</b> is installed in a wireless data network according to the IEEE 802 standard, and wherein said AP<b>1</b> is further arranged to authenticate user terminals requesting access to said wireless data network.

According to a sixth aspect, the invention provides a computer program product comprising program code means which, when loaded into a processing means of a first access point AP<b>1</b>, being installed in a radio access network, make said processing means execute at least one procedure realizing the method according to the first aspect of the invention.

In one embodiment, the computer program product includes a computer readable medium having said program code means stored thereon.

According to a seventh aspect, the invention provides a radio access point AP<b>2</b> allowing a user terminal, UT, access to a radio access network by means of a radio link connection wherein said AP<b>2</b> comprises means realizing the method according to the second aspect when said AP<b>2</b> is installed in a radio access network comprising a first access point AP<b>1</b> and an access router AR.

In one embodiment, said means of the access point AP<b>2</b> comprises a data memory having a first memory space with a first entrance forming a buffer memory for storing downlink packets addressed to said UT, said data memory further having a second memory space with stored program code means which, when loaded in a processing means of said AP<b>2</b>, make said processing means execute at least one procedure realizing said method.

In one embodiment, the AP<b>2</b> is realised as an access point according to the IEEE 802 standard, arranged to realise said method when said AP<b>2</b> is installed in a wireless data network according to the IEEE 802 standard, and wherein said AP<b>2</b> is further arranged to authenticate user terminals requesting access to said wireless data network.

According to an eighth aspect, the invention provides a computer program product comprising program code means which, when loaded into a processing means of a said access point AP<b>2</b>, being installed in a radio access network, make said processing means execute at least one procedure realizing the method according the second aspect of the invention.

In one embodiment, said computer program product includes a computer readable medium having said program code means stored thereon.

According to a ninth aspect, the invention provides an access router, AR, arranged to route a user terminal's, UT's communication session via a first access point, AP<b>1</b> (<b>210</b>), and/or via a second access point, AP<b>2</b>, (<b>220</b>), wherein said AR comprises means realizing the method according to the third aspect of the invention when said AR is installed in a radio access network comprising said AP<b>1</b> and AP<b>2</b>.

In one embodiment, said means of the AR comprises a data memory having a first memory space with a first entrance forming a buffer memory for storing downlink packets addressed to said UT, said data memory further having a second memory space with stored program code means which, when loaded in a processing means of said AR, make said processing means execute at least one procedure realizing said method.

In one embodiment, the AR is realised according to the IEEE 802 standard, being arranged to realise said method when said AR is installed in a wireless data network according to the IEEE 802 standard, and wherein said AR is further arranged to authenticate user terminals requesting access to said wireless data network.

According to a tenth aspect, the invention provides a computer program product comprising program code means which, when loaded into a processing means of an AR according to the ninth aspect and being installed in a radio access network, make said processing means execute at least one procedure realizing the method according to the second aspect of the invention.

In one embodiment, the computer program product includes a computer readable medium having said program code means stored thereon.

According to an eleventh aspect, the invention provides a UT for assisting a handover of a communication session from a first radio access point, AP<b>1</b>, to a second radio access point, AP<b>2</b>, in a radio access network, said UT comprising means realizing the method according to the fourth aspect of the invention.

In one embodiment, said means of the UT comprises a data memory having a first memory space with a first entrance forming a buffer memory for storing downlink packets addressed to said UT and a second entrance for storing a packet sequence number associated with at least one downlink packet, said data memory further having a second memory space with stored program code means which, when loaded in a processing means of said UT, make said processing means execute at least one procedure realizing said method.

In one embodiment, the UT is realised according to the IEEE 802 standard, being arranged to realise said method when said session is routed through a wireless data network according to the IEEE 802 standard, and further arranged to be authenticated by said wireless data network.

According to a twelfth aspect, the invention provides a computer program product comprising program code means which, when loaded into a processing means of the UT communicating with a radio access network, make said processing means execute at least one procedure realizing the method according to the fourth aspect of the invention.

In one embodiment, the computer program product includes a computer readable medium having said program code means stored thereon.

Even though the invention has been summarized above, the invention is defined by the accompanying claims.

BRIEF DESCRIPTION OF THE DRAWINGS

The features and advantages of the present invention will become more apparent from the following detailed description of the preferred embodiments with reference to the accompanying drawings, wherein

<figref idrefs="DRAWINGS">FIG. 1</figref> illustrates a network architecture of a conventional radio access network in form of a WLAN,

<figref idrefs="DRAWINGS">FIG. 2A</figref> illustrates a network architecture of a radio access network according to the present invention in form of a WLAN,

<figref idrefs="DRAWINGS">FIG. 2B</figref> illustrates an alternative network architecture of a radio access network according to the present invention in form of a WLAN,

<figref idrefs="DRAWINGS">FIG. 3</figref> is an illustrative example of the user plane and control plane protocol stack for the network in <figref idrefs="DRAWINGS">FIG. 2A</figref>,

<figref idrefs="DRAWINGS">FIGS. 4A and 4B</figref> illustrate an example of the method according to some aspects the invention, in form of a flow chart diagram,

<figref idrefs="DRAWINGS">FIGS. 5A and 5B</figref> illustrate an example of an algorithm according to one aspect of the invention, in form of a flow chart diagram.

<figref idrefs="DRAWINGS">FIGS. 6A and 6B</figref> illustrate a signaling scenario for carrying out the method of the invention described in <figref idrefs="DRAWINGS">FIGS. 4A</figref> and B, in the network depicted in <figref idrefs="DRAWINGS">FIG. 2A</figref>.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

Now, with reference to <figref idrefs="DRAWINGS">FIGS. 2-6</figref>, the present invention shall be described in more detail.

In the <figref idrefs="DRAWINGS">FIGS. 1-6</figref>, corresponding elements have been given the same reference number along with a figure prefix number, e.g. AP<b>1</b>, <b>110</b>, in <figref idrefs="DRAWINGS">FIG. 1</figref> is referred to as AP<b>1</b>, <b>210</b>, in <figref idrefs="DRAWINGS">FIG. 2</figref> etc.

<figref idrefs="DRAWINGS">FIG. 2A</figref> depicts an illustrative example of a radio access network according to the present invention in form of a WLAN <b>200</b>. The WLAN <b>200</b> comprises at least two radio access points, AP<b>1</b>, <b>210</b>, and AP <b>2</b>, <b>220</b>, connected to an access router AR <b>250</b>, optionally via conventional layer <b>2</b> switches M-L<b>2</b>S<b>1</b>, <b>230</b>, and M-L<b>2</b>S<b>2</b>, <b>235</b>, as illustrated in <figref idrefs="DRAWINGS">FIG. 2A</figref>. Many possibilities exist; the APs may e.g. be connected directly to AR <b>250</b>. AR <b>250</b> may be connected to other ARs of the WLAN <b>200</b> (not illustrated in <figref idrefs="DRAWINGS">FIG. 2</figref>) and/or to other communication networks <b>260</b>, such as e.g. the Internet and/or a 3GPP UTRAN. AP<b>1</b>, <b>210</b>, and AP<b>2</b>, <b>220</b>, have a respective conventional radio transceiver unit (not illustrated in <figref idrefs="DRAWINGS">FIG. 2</figref>) connected to a respective antenna, allowing a user terminal, UT, <b>240</b>, to establish a radio link connection with AP<b>1</b>, <b>210</b>, or AP<b>2</b>, <b>220</b>, e.g. in form of a communication session with the WLAN <b>200</b>. AP<b>1</b>, <b>210</b>, AP<b>2</b>, <b>220</b>, UT <b>240</b> and AR <b>250</b> have a respective conventional processing means, PM, <b>212</b>, <b>222</b>, <b>242</b> and <b>252</b>, normally a CPU, arranged to read and write from/to a respective conventional data memory, M, <b>211</b>, <b>221</b>, <b>241</b> and <b>251</b>, (e.g. RAMs) in a conventional manner exploiting a data/address/control bus. According to the invention, the respective data memory, M, <b>211</b>, <b>221</b>, <b>241</b> and <b>251</b> have a first memory space, <b>213</b>, <b>223</b>, <b>243</b> and <b>253</b>, allocated with stored program code means which, when loaded into the respective processing means, <b>212</b>, <b>222</b>, <b>242</b> and <b>252</b>, make said processing means realize the method according to various aspects of the invention, as described further below. According to the invention, the respective data memory, M, <b>211</b>, <b>221</b>, <b>241</b> and <b>251</b> have a second buffer memory space, <b>214</b>, <b>224</b>, <b>244</b> and <b>254</b>, allocated, for temporary storage of data packets associated with the UT <b>240</b>, as explained further below. The UT <b>240</b> has a conventional first buffer memory <b>245</b>, normally a FIFO, in which data packets/frames demodulated by the radio receiver unit of UT <b>240</b> are temporarily stored before they are forwarded to a higher protocol layer or to the right higher level final application (e.g. an end user multi-media application such as VoIP, Voice over IP) by the LLC-protocol, in a conventional manner. It is to be understood that the WLAN in <figref idrefs="DRAWINGS">FIG. 2</figref> is only an illustrative example and that the invention may be realized in any radio access network, such as a e.g. a 3GPP UTRAN, wherein a 3GPP radio base station Node B corresponds with AP<b>1</b>, <b>210</b>, a 3GPP radio network controller, RNC, corresponds with AR <b>250</b> etc, as understood by a person skilled in the art. However, the invention is advantageously realized in wireless data networks according to the IEEE 802 standard protocol, such as e.g. Wireless Personal Area Networks (WPAN, IEEE 802.15), Wireless Metropolitan Area Networks (WMAN, IEEE 802.16), Mobile Broadband Wireless Access (MBWA, IEEE 802.20), Wireless Regional Area Networks (WRAN, IEEE 802.22) etc, exploiting the EAP authentication scheme which causes significant delays during handover, since the invention decreases packet delay during handover.

<figref idrefs="DRAWINGS">FIG. 3</figref> illustrates an example of the user plane and control plane protocol stacks at UT, <b>240</b>, AP<b>1</b>, <b>210</b>, M-L<b>2</b>S<b>1</b>, <b>230</b> and AR, <b>250</b>, in <figref idrefs="DRAWINGS">FIG. 2A</figref>. The protocol stack for M-L<b>2</b>S<b>2</b>, <b>235</b>, is identical with the stack of M-L<b>2</b>S<b>1</b>, <b>230</b>, and M-L<b>2</b>S<b>2</b>, <b>235</b> has therefore been left out in <figref idrefs="DRAWINGS">FIG. 3</figref>. The physical layer <b>1</b> in <figref idrefs="DRAWINGS">FIG. 3</figref>, L<b>1</b>, at AR <b>350</b>, M-L<b>2</b>S<b>1</b>, <b>230</b> and AP<b>1</b>, <b>210</b>, is a conventional Ethernet physical layer, above which a conventional WLAN-MAC layer is installed, i.e. the IEEE 802.3 MAC protocol, defining data ports for the various nodes in a conventional manner. The UT <b>340</b> and the AP<b>1</b><b>310</b> have conventional IEEE 802.11 physical and MAC protocol layers installed, defining a physical radio link layer and data ports for UT <b>340</b> and AP<b>1</b>, <b>310</b>, in a conventional manner. A conventional link control layer in the form of a IEEE 802.2 LLC-layer is installed above the MAC layer at UT <b>340</b>, AP<b>1</b>, <b>310</b> and AR <b>350</b>. The UT <b>340</b>, AP<b>1</b>, <b>310</b>, and AR <b>350</b> has further an IP protocol and a UDP/TCP protocol (not illustrated at UT <b>340</b>) installed above the LLC layer. The UT <b>340</b> and AR <b>350</b> has further higher protocol layers/applications installed, such as e.g. a multi media application at UT <b>340</b> and packet handling applications (e.g. regarding tunneling, routing etc) at AR <b>350</b>, in a conventional manner. The protocol layers allow the UT <b>340</b> and AR <b>250</b> to establish logical data connections by conventional protocol layer processing, as a person skilled in the art realizes. For instance, the MAC layer filters out packets intended for the physical device, the LLC layer forwards the packets to the “right” layer/application which in turn may forward the packet further up to a specific layer/application until it is received by the “right” final application or protocol layer. The Access Point Management Entity (APME) at AP<b>1</b>, <b>310</b>, in <figref idrefs="DRAWINGS">FIG. 3</figref> is not a layered protocol since it represents the main operational program of the AP<b>1</b>, <b>310</b>, which implements AP manufacturer's proprietary features and algorithms, and incorporates the Station Management Entity (SME) of IEEE 802.11, e.g., the APME receives Association request messages from WLAN terminals (UTs) and takes further action accordingly. What is important is that the STAME application at UT <b>340</b> and PME application at AP<b>1</b>, <b>310</b>, allow the UT <b>340</b> and AP<b>1</b>, <b>310</b> to exchange and interpret various control messages, e.g. regarding radio link measurement etc. The Inter Access Point Protocol (IAPP) as specified in IEEE 802.1. If standard is installed in all the AP's of the network, such as at the AP<b>1</b>, <b>310</b>, and at AR <b>350</b>, as illustrated in <figref idrefs="DRAWINGS">FIG. 3</figref>. The IAPP allows the AP<b>1</b>, <b>310</b> and AR <b>350</b> to communicate with each other, e.g. for signaling various control messages. The IAPP protocol also allows the AP<b>1</b>, <b>210</b> and AP<b>2</b>, <b>220</b>, to communicate with each other, in a conventional manner. The IAPP entity requires UDP and TCP to distribute its messages as IP packets towards other IAPP entities, e.g. in order to notify a new association of a WLAN terminal at the AP<b>1</b>, <b>310</b>. M-L<b>2</b>S<b>1</b>, <b>330</b>, only functions as a relay of Ethernet frames to the destined stations or other L<b>2</b> devices. The Ethernet frames may be unicast, multicast or broadcast frames. In one embodiment, the UT <b>340</b> has further a WLAN authentication entity installed, e.g. according to the 802.1X EAP/TLS/TTLS/PEAP standard, allowing UT <b>340</b> to communicate with a corresponding authentication entity of the WLAN, e.g. in form of a RADIUS or DIAMETER server connected to AP<b>1</b>, <b>310</b>, for authentication purposes. The RADIUS or DIAMETER server may e.g. be integrated in AR <b>350</b>, but many possibilities exist. Many other protocol options exist, as a person skilled in the art realizes, e.g. a LWAPP, (Light Weight Access Point Protocol), could be used instead of the IAPP, or RLC/RNC protocols could be used instead of the LLC/IAPP in case of a UTRAN etc. The RADIUS server normally exploits a conventional RADIUS protocol, e.g. as specified by the documents RFC 3579 (RADIUS support for EAP), RFC 2865, RFC 2869 (RADIUS Extensions), RFC 3576 (Dynamic Authorization Extensions to RADIUS) and RFC 3580 (IEEE 802.1X RADIUS Usage Guidelenes) and the DIAMETER server normally exploits a conventional DIAMETER protocol, e.g. as specified by RFC 3588 (DIAMETER Base Protocol), along with a conventional EAP (Extensible Authentication Protocol), e.g. as defined by standard AAA—(Authenticating, Authorization, Accounting) protocols RFC 2284—PPP EAP, RFC 4017 (EAP requirements for WLAN) or RFC 3748 (EAP) or RFC 2716 (PPP EAP TLS) or the EAP-TTLS (EAP Tunneled TLS Authentication Protocol), issued by the IETF standard organisation (Internet Engineering Task Force), and may further exploit the EAP-PEAP (Protected EAP Protocol), as a person skilled in the art realises.

Now, with reference to <figref idrefs="DRAWINGS">FIG. 4</figref> and <figref idrefs="DRAWINGS">FIGS. 6A</figref> and B, the method according to the invention shall be described in more detail when realized in the network illustrated in <figref idrefs="DRAWINGS">FIG. 2A</figref>. It is assumed that each AP maintains its own up-to-date database containing information about the neighbor APs, whose coverage areas may overlap with its own (normally each AP has a stored list of the IDs, e.g. the WLAN MAC address, of all its neighboring APs. This way, each AP is capable to provide associated UTs with a site report according to IEEE 802.11k specification, which contains information about other APs in proximity to which the UT may roam (or handoff). This may only be achieved if all the involved APs are controlled by the same operator or if special inter-operator agreements exist.

In step <b>4100</b>, there is an ongoing communication session between UT <b>240</b> and a Host/peer (e.g. on the Internet <b>260</b>), wherein e.g. IP-packets are routed over the WLAN by means of the IEEE 802.2 LLC layer (and lower layers), as illustrated by step <b>1</b> in <figref idrefs="DRAWINGS">FIG. 6A</figref>. The communication session may e.g. be a conventional VoIP-session (Voice over IP). At any given time, once a WLAN connectivity between UT <b>240</b> and AP<b>1</b>, <b>210</b>, is established, AP<b>1</b>, <b>210</b>, sends a conventional conditional beacon frame request to UT <b>240</b>, as illustrated by step <b>2</b> in <figref idrefs="DRAWINGS">FIG. 6A</figref>. The request indicates the reporting condition that a (periodical) beacon report for AP<b>1</b>, <b>210</b>, should be sent by UT <b>240</b> to AP<b>1</b>, <b>210</b>, when the average RCPI (Received Channel Power Indicator) level falls below a specified threshold value. The UT <b>240</b> then performs passive scanning and evaluates the current RCPI level continuously within certain measurement duration.

In step <b>4110</b> the reporting condition is met, (i.e. RCPI level below threshold is determined), and the UT <b>240</b> sends a conventional beacon report to AP<b>1</b>, <b>210</b>, illustrated by step <b>3</b> in <figref idrefs="DRAWINGS">FIG. 6B</figref>, which thus estimates that the UT <b>240</b> will leave the coverage area of AP<b>1</b>, <b>210</b>, soon and that a handover is to be effectuated. According to its own AP location database, AP<b>1</b>, <b>210</b>, knows that its coverage area (partly) overlaps with the coverage area of one or some neighbor APs, including AP<b>2</b>, <b>220</b>. However AP<b>1</b>, <b>210</b>, may not be capable to determine whether or not UT <b>240</b> is currently within this overlap area.

In step <b>4120</b>, AP<b>1</b>, <b>210</b> sends a conventional site report to UT <b>240</b>, illustrated by step <b>4</b> in <figref idrefs="DRAWINGS">FIG. 6A</figref>, in order to support the UT <b>240</b> to carry out its handover procedure, which site report includes further information about AP<b>2</b>, <b>220</b>, (i.e., its BSSID, PHY type, channel, etc.) and other neighbor APs. This site report informs the UT <b>240</b> about the registered neighbor APs, to which the UT <b>240</b> can associate according to the user's (subscription) profile. The UT <b>240</b> may also receive conventional broadcast beacon frames from APs that do not belong to the UT's <b>240</b> operator's network.

In step <b>4130</b>, the UT <b>240</b> initiates a conventional passive scanning to find a suitable AP having an adequate RCPI level. By performing passive scanning, the UT <b>240</b> may or may not receive beacon frames from the listed neighbour APs, depending on the UT's, <b>240</b>, geographical location. Assuming that UT <b>240</b> receives the beacon frames broadcasted by AP<b>2</b>, <b>220</b>, as illustrated by step <b>5</b> in <figref idrefs="DRAWINGS">FIG. 6A</figref>, the UT <b>240</b> compares the RCPI level of AP<b>2</b>, <b>220</b>, with the RCPI level of AP<b>1</b> and decides to change the association from AP<b>1</b>, <b>210</b>, to AP<b>2</b>, <b>220</b>, if the RCPI level of AP<b>2</b>, <b>220</b>, exceeds the RCPI level of AP<b>1</b>, <b>210</b>, in a conventional manner, i.e. the UT <b>240</b> decides to carry out a handover from AP<b>1</b>, <b>210</b> to AP<b>2</b>, <b>220</b>.

In step <b>4140</b>, the UT announces the handover decision by sending a conventional standard Probe Request frame to AP<b>2</b>, <b>220</b>, illustrated by step <b>6</b> in <figref idrefs="DRAWINGS">FIG. 6A</figref>. AP<b>2</b>, <b>220</b>, responds with a conventional Probe Response frame, as illustrated by step <b>7</b> in <figref idrefs="DRAWINGS">FIG. 6A</figref>, which contains conventional detailed information about AP<b>2</b>, <b>220</b>. According to the invention, the AP<b>2</b>, <b>220</b>, then sends a handover intention notify message to AP<b>1</b>, <b>210</b>, and/or AR <b>250</b>, indicating a handover to AP<b>2</b>, <b>220</b>, and comprising a session identifier uniquely identifying the communication session of UT <b>240</b>. The handover intention notify message may also comprise identifiers uniquely identifying AP<b>2</b>, <b>220</b>, and/or UT <b>240</b>, e.g. the WLAN MAC address of AP<b>2</b>, <b>220</b> and/or UT <b>240</b>, for reasons explained further below. The session identifier may e.g. be a conventional LLC-connection identifier or a conventional TCP/IP-flow identifier or the WLAN MAC address, or the IP-address, of UT <b>240</b>. The handover intention notify message may e.g. be realized as a modified LAPP-PROBE. Notify packet, as illustrated by step <b>8</b> in <figref idrefs="DRAWINGS">FIG. 6B</figref>, which conventionally also includes the UT's WLAN MAC address, by adding said session identifier in a suitable data field or by simply defining the WLAN MAC address of UT <b>240</b> to be said session identifier, as understood by a person skilled in the art. The handover intention notify packet may in this case also have a defined handover identifier field, which may be set to “1” to indicate a handover intention and to “0” otherwise, in order to allow the receiving nodes to make a correct interpretation of the received message. However, the handover identifier may be left out and the receiving nodes (i.e. the AP<b>1</b>, <b>210</b> and AR <b>250</b>) may be modified/arranged to interpret this handover intention notify message correctly even without such an identifier, as a person skilled in the art realises. This modified IAPP packet, which is sent as UDP/IP packet, is not defined in the IEEE 802.11f specification, but a person skilled in the art realizes how to realise such an LAPP packet given the described functionality above. The handover intention notify message, in form of the modified IAPP-PROBE. NOTIFY packet, is normally multicasted to a group address towards M-L<b>2</b>S<b>2</b>, but may alternatively be unicasted to AP<b>1</b>, <b>210</b>, and/or AR <b>250</b>, e.g. in case AP<b>2</b>, <b>220</b> knows that the session in question is currently associated with AP<b>1</b>, <b>210</b>, (e.g. signaled by UT <b>240</b>). The multicast address is according to the invention chosen in such a way that the neighbour APs (including AP<b>1</b>) and/or AR <b>250</b> receive/s the handover intention notify—IAPP packet. The handover intention notify message may alternatively be formed and sent by UT <b>240</b> to AP<b>1</b>, <b>210</b>, which forwards it to the AR <b>250</b>, but still other possibilities exist.

In step <b>4150</b>, the AP<b>1</b>, <b>210</b>, interprets the received handover intention notify message (e.g. in form of the modified IAPP-PROBE.Notify packet) as the intention of UT <b>240</b> to perform a session handover from AP<b>1</b>, <b>210</b>, to AP<b>2</b>, <b>220</b>. According to the invention, AP<b>1</b>, <b>210</b>, then starts caching (buffering) the downlink IP packets addressed to UT, <b>240</b>, in memory (<b>213</b>). This reduces the risk of packet loss and the necessary amount of re-transmitted packets, (and thereby the interference level and network signaling) at least in a statistical sense. In one embodiment, in case said handover intention notify message comprises an identifier uniquely identifying AP<b>2</b>, <b>220</b>, e.g. the WLAN MAC address of AP<b>2</b>, <b>220</b>, then AP<b>1</b>, <b>210</b> starts to forward packets to AP<b>2</b>, <b>220</b>, immediately, as a response on receiving said handover intention notify message. This allows for a reduced packet delay and a “smoother” handover. According to an alternative embodiment, AP<b>1</b>, <b>210</b>, continues to transmit downlink packets over its radio link to UT <b>240</b>, and simultaneously forwards duplicate packets to AP<b>2</b>, <b>220</b>, allowing a soft handover realisation. Furthermore, in step <b>4150</b>, according to one embodiment of the invention, the AR <b>250</b> may start to buffer downlink data packets of said session (i.e. addressed to UT <b>240</b>) in a buffer memory (<b>253</b>) instead of forwarding them to AP<b>1</b> (<b>210</b>), as a response on receiving said handover intention notify message. This decreases the risk of packet delay/loss/retransmission and, in case the AR <b>250</b> forwards the downlink packets only to AP<b>2</b>, <b>220</b>, also reduces the necessary buffer memory size at AP<b>1</b>, <b>210</b>, as a person skilled in the art realises. In one embodiment, in case said handover intention notify message comprises an identifier uniquely identifying the AP<b>2</b>, <b>220</b>, e.g. the WLAN MAC address of AP<b>2</b>, <b>220</b>, the AR <b>250</b> immediately starts to route downlink packets of said session to AP<b>2</b>, <b>220</b>, instead of AP<b>1</b>, <b>210</b>. In an alternative embodiment, AR <b>250</b> starts to send downlink packets addressed to UT <b>240</b> to both AP<b>1</b>, <b>210</b>, and AP<b>2</b>, <b>220</b>, as a response on said handover intention notify message, allowing a soft handover (bi-casting) by duplicate transmission over the respective radio link of AP<b>1</b>, <b>210</b>, and AP<b>2</b>, <b>220</b>. This further reduces packet delays during the handover by means of a soft handover realisation.

In step <b>4160</b>, the UT <b>240</b> starts the (open system) EAP authentication procedure with AP<b>2</b>, <b>220</b>, and sends a conventional Association Request frame to AP<b>2</b>, <b>220</b>, as illustrated by step <b>9</b> in <figref idrefs="DRAWINGS">FIG. 6B</figref>. This triggers an abortion of the radio connectivity between UT <b>240</b> and AP<b>1</b>, <b>210</b>, in a conventional manner. According to one embodiment of the invention, this also triggers a packet re-sequencing algorithm at UT <b>240</b>, as illustrated in <figref idrefs="DRAWINGS">FIG. 5</figref>, and described further below. At the same time, since AP<b>1</b>, <b>210</b>, does not receive any beacon reports from UT <b>240</b>, the AP<b>1</b>, <b>210</b> sends after a certain pre-established time, T<b>1</b>, a handover intention notify message to AR <b>250</b>, according to one embodiment of the present invention, e.g. in case AP<b>1</b>, <b>210</b>, has not yet sent this message to AP<b>2</b>, <b>220</b>. As already stated, the handover intention notify message comprises a session identifier, e.g. an LLC-connection identifier or IP-connection identifier or the WLAN address, or IP-address, of UT <b>240</b>, uniquely identifying the data session and may be realized as above described modified IAPP PROBE Notify packet or e.g. as a modified IAPP-LEAVE.Notify packet, as illustrated by step <b>10</b> in <figref idrefs="DRAWINGS">FIG. 6B</figref>. A person skilled in the art realizes how form a handover intention notify message with the described functionality by modifying these IEEE 802 standard packets. This provides a possibility of early “warning” to the AR <b>250</b> that a handover is to be carried out so that the AR <b>250</b> may start buffer session downlink packets as early as possible, which reduces the overall packet delay/loss and network signaling, at least in a statistical sense. Thus, the AR <b>250</b> may receive a handover intention notify message from AP<b>1</b>, <b>210</b>, and/or AP<b>2</b>, <b>220</b>, and which message arrives first depends on network settings such as Ti etc. Alternately, a handover intention notify message, e.g. in form of a modified IAPP-LEAVE.Notify packet, may be sent from UT <b>240</b> to AR <b>250</b> via AP<b>2</b>, <b>220</b>, in step <b>4140</b>. Many possibilities exist.

In step <b>4170</b>, when UT <b>240</b> has been associated with AP<b>2</b>, <b>220</b>, AP<b>2</b> multicasts an association update message, e.g. as a IAPP-ADD.Notify packet, as illustrated by step <b>11</b> in <figref idrefs="DRAWINGS">FIG. 6B</figref>, towards M-L<b>2</b>S<b>2</b>. The IAPP-ADD.Notify packet is sent as a multicast UDP/IP packet to notify other APs (e.g. AP<b>1</b>, <b>210</b>) and AR <b>250</b> about the new association of the particular UT (UT <b>240</b> in this case) at the new target AP (i.e. AP<b>2</b>, <b>220</b>). AP<b>2</b>, <b>220</b>, concludes the association procedure by sending a conventional Association Response message to UT <b>240</b>, as illustrated by step <b>12</b> in <figref idrefs="DRAWINGS">FIG. 6B</figref>. According to the invention, the IAPP-ADD.Notify packet includes a session identifier uniquely identifying the session in question and may also comprise a sequence number indicating the packet's validity, along with the WLAN MAC address of UT <b>240</b> and/or AP<b>2</b>, <b>220</b>. The multicast IP (or MAC) address should be selected in such a way that only the AR <b>250</b> and other relevant APs (i.e. at least AP<b>1</b>, <b>210</b>), which are geographically closely located to the sending AP<b>2</b>, <b>220</b>, can receive the IAPP-ADD.Notify packet, in order not to introduce excessive signaling within the WLAN domain. The multicast IP (or MAC) address specified for the L<b>2</b> update frame must be chosen in such a way that intermediate M-L<b>2</b>Ss and AR <b>250</b> can receive it to allow them to update their bridging table, if necessary. In accordance with its multicast IP (or MAC) address the IAPP-ADD.Notify packet will be received by AP<b>1</b>, <b>210</b>, and AR, <b>250</b>. Since AP<b>2</b>, <b>220</b>, is connected to the same M-L<b>2</b>S as AP<b>1</b>, <b>210</b>, M-L<b>2</b>S<b>1</b>, <b>230</b>, and AR, <b>250</b>, need not update their bridging tables. This means that AR, <b>250</b>, will continue to forward all downlink IP packets for UT <b>240</b> through M-L<b>2</b>S<b>1</b>, <b>230</b>, and M-L<b>2</b>S<b>2</b>, <b>235</b>, as it did before receiving the L<b>2</b> update frame and/or LAPP-ADD.notify packet. According to the invention, the AP<b>1</b>, <b>210</b>, and AR <b>250</b> starts to forward downlink packets for said session to AP<b>2</b>, <b>220</b>, after having received this IAPP-ADD.Notify packet. This reduces the risk of packet delay/loss and the signaling within the WLAN during the handover, thereby providing a more “smooth” handover. It shall be understood that the present invention may be realised by means of (optionally) modified IAPP-MOVE.Notify packet/s along with IAPP-MOVE RESPONSE.Notify packet/s and/or by means of (optionally) modified IAPP-CASH.Notify packet/s along with IAPP-CASH.Response packet/s, instead of the above described (optionally) modified IAPP-ADD.notify packet/s, as a person skilled in the art realises. The IAPP-MOVE.Notify packet is then preferably unicasted by AP<b>2</b>, <b>220</b>, to AP<b>1</b>, <b>210</b>, (as a dedicated message), further decreasing network signaling.

In step <b>4180</b>, after that the AP<b>2</b>, <b>220</b>, has sent the conventional Association Response in step <b>4170</b>, the conventional <b>802</b>.<b>1</b>X (EAP) based authentication is then carried out between UT, <b>240</b>, AP<b>2</b>, <b>220</b> and the network authentication entity (e.g. a RADIUS entity integrated in AR <b>250</b>), as illustrated by step <b>13</b> in <figref idrefs="DRAWINGS">FIG. 6B</figref>. Downlink and uplink IP packets can be sent over the radio link between UT <b>240</b> and the AP<b>2</b>, <b>220</b>, as soon as the EAP authentication procedure is completed. Meanwhile, in step <b>4180</b>, AP<b>2</b>, <b>220</b>, receives session downlink packets from AR <b>250</b> and/or AP<b>1</b>, <b>210</b>, and buffers them in memory <b>223</b>. All session downlink IP packets (encapsulated as LLC/Ethernet frames), that are still cached in AP<b>1</b>, <b>210</b>, and/or not yet transmitted to or acknowledged by UT <b>240</b>, can be sent directly to AP<b>2</b>, <b>220</b>, as illustrated by step <b>14</b> in <figref idrefs="DRAWINGS">FIG. 6B</figref>, or alternatively, removed since their re-transmissions, if necessary, can be conducted between UT <b>240</b> and AR <b>250</b> through AP<b>2</b>, <b>220</b>. This forwarding procedure is thus carried out while the EAP authentication between UT <b>240</b> and AP<b>2</b>, <b>220</b>, and the network authentication entity, is still ongoing since both procedures are independent to each other. Since M-L<b>2</b>S<b>2</b> has already updated its bridging table, according to their destination MAC address (i.e., UT's WLAN MAC address) the LLC/Ethernet frames can be forwarded through the specified port of M-L<b>2</b>S<b>2</b>, <b>235</b>, to which AP<b>2</b>, <b>220</b>, is connected. The forwarded packets should not be routed through M-L<b>2</b>S<b>1</b>, <b>230</b>. The LLC/Ethernet frames forwarded by AP<b>1</b>, <b>210</b>, and AR <b>250</b> via M-L<b>2</b>S<b>1</b>, <b>230</b> (including new downlink packets), are according to the invention cached in memory <b>223</b> at AP<b>2</b>, <b>220</b>, and transmitted to UT <b>240</b> immediately after the EAP authentication procedure is completed. Memory <b>223</b> may be a FIFO memory, first in first out, so that a reordering of the downlink LLC/Ethernet frames must be performed by an algorithm residing at the LLC layer of UT <b>240</b>, according to the invention. This solves problems regarding the TCP interpreting packets out of order as network congestion, and provides a “smoother” handover, especially important for real time applications such as VoIP. The session handover is concluded after both uplink and downlink IP packets can be exchanged as LLC/Ethernet frames between UT <b>240</b> and AR <b>250</b> through AP<b>2</b>, <b>220</b>, and the corresponding M-L<b>2</b>Ss, as illustrated by step <b>15</b> in <figref idrefs="DRAWINGS">FIG. 6B</figref>. According to one embodiment of the present invention, the completion of the EAP authentication procedure triggers a packet re-sequencing algorithm of UT <b>240</b>, as illustrated and described further with reference to <figref idrefs="DRAWINGS">FIG. 5</figref>.

<figref idrefs="DRAWINGS">FIG. 2B</figref> illustrates another example of a network architecture for which the invention is applicable. In <figref idrefs="DRAWINGS">FIG. 2B</figref>, we may consider a session wherein the UT <b>240</b> is currently associated with AP<b>1</b>, <b>210</b>′, (i.e., old AP) and the IP packets, that are encapsulated as LLC/Ethernet frames, are being exchanged between UT <b>240</b>′ and AR <b>250</b>′ through the WLAN transmission path. The link between AP<b>1</b>, <b>210</b>′, and AR, <b>250</b>′, is thus bridged by two M-L<b>2</b>Ss, i.e., M-L<b>2</b>S<b>1</b>, <b>230</b>′, and M-L<b>2</b>S<b>2</b>, <b>235</b>′. In contrast to the previous HO-<b>1</b> scenario described with reference to <figref idrefs="DRAWINGS">FIG. 2A</figref>, AP<b>2</b>, <b>220</b>′, is connected to a different M-L<b>2</b>S, i.e., M-L<b>2</b>S<b>3</b>, <b>236</b>. However, both layer <b>2</b> switches, i.e., M-L<b>2</b>S<b>2</b>, <b>235</b>′, and M-L<b>2</b>S<b>3</b>, <b>236</b>′, are connected to the same AR, <b>250</b>′, via M-L<b>2</b>S<b>1</b>, <b>230</b>′. The coverage areas of AP<b>1</b>, <b>210</b>′, and AP<b>2</b>, <b>220</b>′, are assumed to be (partly) overlapped and we consider a situation where UT <b>240</b>′ is going to hand off its current data session from AP<b>1</b>, <b>210</b>′, to AP<b>2</b>, <b>220</b>′, (i.e., new AP).

In general, the session handover procedure for the network in <figref idrefs="DRAWINGS">FIG. 2B</figref> is quite similar with the one illustrated in <figref idrefs="DRAWINGS">FIG. 2A</figref>. The main differences between the procedures relate to steps <b>4140</b> and <b>4170</b>, in the following way:

In step <b>4140</b>: UT <b>240</b>′ sends a Probe Request frame to AP<b>2</b>, <b>220</b>′, to “announce” its intention to perform handover to AP<b>2</b>, <b>220</b>′. After responding with a Probe Response frame, AP<b>2</b>, <b>220</b>′, sends the (non-standard) IAPP-PROBE.Notify packet, which includes the UT's <b>240</b>′ WLAN MAC address, to a multicast group address towards M-L<b>2</b>S<b>3</b>, <b>236</b>. The multicast address should be chosen in such a way that AP<b>1</b>, <b>210</b>′, (in general the neighbour APs) and AR, <b>250</b>′, receives the IAPP packet after it is routed through M-L<b>2</b>S<b>3</b>, <b>236</b>, M-L<b>2</b>S<b>1</b>, <b>230</b>′, and M-L<b>2</b>S<b>2</b>, <b>235</b>′. AP<b>1</b>, <b>210</b>′, interprets the received IAPP-PROBE.Notify packet as the intention of UT <b>240</b>′ to perform a session handover from AP<b>1</b>, <b>210</b>′, to AP<b>2</b>, <b>220</b>′. AP<b>1</b>, <b>210</b>′, then starts caching the downlink IP packets for UT, <b>240</b>′, which will be forwarded to AP<b>2</b>, <b>220</b>′, as soon as the handover takes place. The AR, <b>250</b>′, may use the information provided in the IAPP-PROBE.Notify packet to make its own decision whenever it receives an IAPP-LEAVE.Notify packet, which includes the UT's WLAN MAC address.

In step <b>4170</b>: After UT, <b>240</b>′, is successfully associated with AP<b>2</b>, <b>220</b>′, AP<b>2</b>, <b>220</b>′, multicasts the layer <b>2</b> update frame and the corresponding IAPP-ADD.Notify packet towards M-L<b>2</b>S<b>3</b>, <b>236</b>. The multicast MAC address of this L<b>2</b> frame is chosen in such a way that M-L<b>2</b>S<b>1</b>, <b>230</b>′, AR, <b>250</b>′, and M-L<b>2</b>S<b>2</b>, <b>235</b>′, (and other L<b>2</b> devices between them) can receive the L<b>2</b> frame and update their bridging table. In accordance with its multicast IP address the IAPP-ADD.Notify packet will be received by AP<b>1</b>, <b>210</b>′, and AR, <b>250</b>′. Since AP<b>2</b>, <b>220</b>′, is connected to the same AR, <b>250</b>′ as AP<b>1</b>, <b>210</b>′, i.e., via M-L<b>2</b>S<b>1</b>, <b>230</b>′, no update of AR's, <b>250</b>′, bridging table is necessary (an update is required at M-L<b>2</b>S<b>3</b>, M-L<b>2</b>S <b>1</b> and M-L<b>2</b>S<b>2</b>). This means that AR, <b>250</b>′, will continue to forward all the downlink IP packets for UT, <b>240</b>′, through M-L<b>2</b>S<b>1</b>, <b>230</b>′, which now routes the packets through M-L<b>2</b>S<b>3</b>, <b>236</b>, (instead of M-L<b>2</b>S<b>2</b>, <b>235</b>′).

Furthermore, AP<b>1</b>, <b>210</b>′, may optionally forward all UT downlink IP packets (encapsulated as LLC/Ethernet frames), that are still cached in AP<b>1</b>, <b>210</b>′, and/or not yet acknowledged, to AP<b>2</b>, <b>220</b>′, through the switches M-L<b>2</b>S<b>2</b>, <b>235</b>′, M-L<b>2</b>S<b>1</b>, <b>230</b>′, and M-L<b>2</b>S<b>3</b>, <b>236</b>. This is possible because all these three L<b>2</b> switches have already updated their bridging tables, and can therefore route the LLC/Ethernet frames based on its specified destination MAC address (i.e., UT's WLAN MAC address).

The present invention provides a packet re-sequencing algorithm for UT <b>240</b>, the working method of which shall now be described in more detail, with reference to <figref idrefs="DRAWINGS">FIG. 5</figref>. The re-sequencing algorithm normally resides at the LLC layer of UT <b>240</b> and is advantageously triggered by any conventional authentication procedure taking place between the UT <b>240</b> and the radio access network <b>200</b>. For instance, the re-sequencing algorithm may be triggered by the UT <b>240</b> sending a conventional Association Request frame to AP<b>2</b>, <b>220</b>, as described in association with step <b>4160</b> above, or e.g. by the completion of the EAP authentication procedure in step <b>4180</b>, described above. Since the re-sequencing algorithm according to the invention reduces packet delay (reduced packet loss), it is advantageously used in combination with an authentication procedure, which itself is time consuming. Alternatively, the re-sequencing algorithm may be triggered by a handover decision taken by a suitable network node such as AP<b>1</b> (<b>210</b>) or AP<b>2</b> (<b>220</b>) or AR, <b>250</b>, in the network of <figref idrefs="DRAWINGS">FIG. 2A</figref>, and signaled to UT <b>240</b>, or taken by UT (<b>240</b>). Many possibilities exist and it is obvious for a person skilled in the art how to realize such a triggering.

In step <b>5010</b>, a first data packet addressed to said UT (<b>240</b>) and received from AP<b>1</b> (<b>210</b>) is fetched in a conventional manner from the first buffer memory <b>245</b> of UT <b>240</b> in which demodulated packets received over the radio link are temporarily stored before being forwarded to the “right” final higher level application, e.g. a real time multi-media application or a VoIP application. Since the re-sequencing algorithm is triggered before the AP<b>2</b>, <b>220</b>, has started to transmit downlink packets to the UT <b>240</b>, the algorithm interprets any (i.e it fetches the first “packet in the queue”) data packet in said first buffer memory <b>245</b> as being a packet from AP<b>1</b>, <b>210</b>.

In step <b>5020</b>, a frame sequence number, FSN, is extracted from said first data packet, and said FSN is stored in a first memory space of a second buffer memory <b>243</b> of said UT <b>240</b>. The first and second buffer memories may be physically separated memories, e.g. FIFOs, or may be defined by having different memory spaces allocated in e.g. a RAM <b>241</b> of said UT <b>240</b>, but many possibilities exist. FSN may e.g. be a conventional LLC frame sequence number defined by the LLC protocol or a conventional IP-packet sequence number defined by the IP- or IPSec- or mobile IP-protocol or a conventional TCP- or SCTP (Stream Control Transmission Protocol) frame sequence number. The term “frame sequence number” shall here be interpreted to be any conventional sequence number identifying a packet or the payload thereof.

In step <b>5030</b>, said first packet is forwarded to a higher protocol layer, e.g. to “the right” final application running on said UT (<b>240</b>), e.g. a real time VoIP-application, in a conventional manner, as explained above.

In step <b>5040</b>, the next data packet addressed to said UT (<b>240</b>) is fetched from said first buffer memory <b>245</b>.

In step <b>5050</b>, the frame sequence number of said next data packet, FSNNEXT, is extracted.

In step <b>5060</b>, it is established whether said next packet is a consecutive packet of the last packet forwarded to the higher protocol layer/final application, referred to as “last forwarded packet” by comparing said FSNNEXT with said FSN. In case of extracted LLC packet sequence numbers, the “next packet” is a consecutive packet of the “last forwarded packet” if FSNNEXT=FSN+1, in case of extracted TCP frame sequence numbers, the “next packet” is a consecutive packet of the “last forwarded packet” if FSNNEXT=FSN+ e.g. 1460, since a commonly used segment size of TCP-packets comprise 1460 payload frames. The invention is however applicable for any segment size/s and a person skilled in the art knows how to realize said comparison in order to establish whether said “next packet” is a consecutive packet of said “last forwarded packet” or not. If it is established that said “next packet” is a consecutive packet of said “last forwarded packet”, then the algorithm proceeds to step <b>5070</b>, otherwise it proceeds to step <b>5080</b>.

In step <b>5070</b>, said “next packet” is forwarded to a higher protocol layer/final application of UT <b>240</b> and the value of said FSNNEXT is stored in said first memory space of the second buffer memory (<b>243</b>). In one embodiment, said FSN is simply overwritten in said memory <b>243</b>, thereby minimizing the required size of memory <b>243</b>. The stored FSNNEXT value thus forms an updated FSN value for future frame sequence number comparisons in order to identify a consecutive packet of said “next packet” and so on. The algorithm then proceeds to step <b>5100</b>.

In step <b>5080</b>, said “next packet” is buffered in a second memory space of said second buffer memory <b>243</b>. Advantageously, said “next packet” is stored in a list in said second buffer memory <b>243</b> on a row corresponding to the difference of FSN and FSNNEXT. For instance, in case of extracted LLC sequence numbers, if said difference is 3, then the “next packet” will be stored on the 3:rd row in this list, thereby minimizing the retrieval time when fetching packets from said second buffer memory <b>243</b> at a later stage, since the packets are stored in their correct consecutive order in said list. The re-sequencing algorithm according to the invention normally limits the required size of said second memory space of said buffer memory <b>243</b>. This can be achieved e.g. by defining a threshold level size of said second memory space of memory <b>243</b> and forwarding the stored in front packet (i.e. the packet with the lowest frame sequence number) from said second memory space of buffer memory <b>243</b> before buffering the “next packet” in step <b>5080</b>, if said threshold size have been reached. Another possibility is to buffer the “next packet” for a defined maximum time period after which the “next packet” is simply being forwarded to a higher protocol layer/final application. The “next packet” would then be associated with a specific packet timer when it is stored in the second memory space of buffer memory <b>243</b> and forwarded from said second memory space when said packet timer elapses (i.e. when the storage time of the “next packet” in said second memory space exceeds said maximum time period). A person skilled in the art realizes how to realize such memory limitations. This memory limitation is advantageous since it also hinders the blocking of the algorithm, as a person skilled in the art realizes. The algorithm then proceeds to step <b>5090</b>.

In step <b>5090</b>, the further next data packet is fetched from the first buffer memory <b>245</b>, which packet is treated as above “next packet”. The algorithm then returns to step <b>5050</b>.

In step <b>5100</b>, the second memory space of said second buffer memory <b>243</b> is searched in order to find a consecutive data packet, or a cluster of consecutive packets, of the “last forwarded packet” (e.g. forwarded to a real time VoIP application). The search is carried out by checking the (suitable) respective frame <b>10</b> sequence number of the stored packets, and comparing these with the frame sequence number of the “last forwarded packet”. If such a consecutive packet is found, or a cluster of such consecutive packets, this packet, or cluster of packets, is/are forwarded to a higher protocol/final application (e.g. a real time application such as VoIP) in step <b>5110</b> and the corresponding “latest” frame sequence number of the last forwarded packet is stored in the second memory space of said second buffer memory <b>243</b>, i.e. FSN is updated accordingly, and the algorithm continues to step <b>5090</b>. If no such a consecutive packet is found, or a cluster of such consecutive packets are found, after having searched through the second buffer memory, the algorithm then proceeds to step <b>5090</b>. Since the receiver, i.e. the higher layer protocol/final application of UT <b>240</b>, thus receives less packets out of order in this way, the invention reduces the number of necessary re-transmissions and interference level in the network and also reduces the risk of a reduced data rate, e.g. in the case of a TCP communication session, at least in a statistical sense. Since the invention reduces packet delay during handover, it is particularly advantageous for real time applications, such as e.g. VoIP, especially if an authentication procedure is to be carried out during the handover, such as an EAP procedure between UT <b>240</b> and AP<b>2</b>, <b>220</b>.

The method and algorithm according to the present invention is normally realized by means of software programs comprising code means which, when loaded in the processing means <b>252</b>,<b>212</b>, <b>222</b> and <b>242</b> of the AR <b>250</b>, AP<b>1</b>, <b>210</b>, AP<b>2</b>, <b>220</b> and UT <b>240</b> realize said method and/or algorithm. The software programs may be stored on e.g. CD-ROMs, flash memories, etc. allowing an efficient distribution/installation. The principles of the present invention have been described in the foregoing by examples of embodiments or modes/examples of operations, i.e. in the case of a WLAN. However, as already stated, the invention is applicable for any radio access network and many modifications and/or combinations are possible. Therefore, the invention should not be construed as being limited to the particular embodiments/working examples discussed above, and it should be appreciated that variations may be made in those embodiments/working examples by persons skilled in the art, without departing from the scope of the present invention as defined by the appended claims.