A METHOD AND SYSTEM FOR HANDLING ROAMING IN TRAIN-TO-TRACKSIDE WIRELESS NETWORKS

Abstract

A method and system for handling roaming in train-to-trackside wireless networks including: receiving, by an access point (AP.sub.i) currently associated with a train access terminal installed on-board a train, radio measurements of signals received by the train access terminal from access points of the train-to-trackside wireless network; determining a next access point (AP.sub.next) providing the highest signal quality (maxSQ); evaluating compliance with roaming criteria including: the next access point (AP.sub.next) is included in a list of candidate access points (N.sub.i); the time elapsed since the last roaming exceeds a minimum permanency time (t.sub.p); the highest signal quality (maxSQ) exceeds the signal quality (SQ(i)) of the access point (AP.sub.i) by a roaming margin; if the roaming criteria are met, sending a roaming command instructing the train access terminal to roam to the next access point (AP.sub.next).

Claims

1. A method of handling roaming in a train-to-trackside wireless network, the network comprising a plurality of access points deployed along a railway track and one or more train access terminals installed on-board at least one train, the method comprising: receiving, by an access point (AP.sub.i) currently associated with a train access terminal installed on-board a train, radio measurements of signals received by the train access terminal from access points of the train-to-trackside wireless network; determining a list of candidate access points for the train access terminal, based on the direction of travel and the route followed by the train; determining, based on the received radio measurements, a next access point (AP.sub.next), said next access point (AP.sub.next) being the access point providing the highest signal quality (maxSQ) according to a quality metric; evaluating compliance with a set of roaming criteria, the roaming criteria including: the next access point (AP.sub.next) is included in the list of candidate access points (N.sub.i); the amount of time elapsed since the last roaming performed by the train access terminal exceeds a minimum permanency time (t.sub.p); the highest signal quality (maxSQ) exceeds the signal quality (SQ(i)) of the access point (AP.sub.i) currently associated with the train access terminal by at least a roaming margin; if the roaming criteria are met, sending, by the access point, a roaming command instructing the train access terminal to roam from the access point (AP.sub.i) currently associated with the train access terminal to the next access point (AP.sub.next).

2. (canceled)

3. The method of claim 1, further comprising acquiring the direction of travel (d) and the route followed by the train by accessing a train database of a data center.

4. The method of claim 1, wherein all the access points deployed along the railway track share a common SSID, and wherein the method comprises sending, by the access point (AP.sub.i) currently associated with the train access terminal, a radio measurement request addressed to the train access terminal and including a command to perform active scanning of the common SSID.

5. The method of claim 1, the method comprising repeatedly sending, by the train access terminal, radio measurements of signals received from access points in range of the train access terminal, to the access point currently associated with the train access terminal.

6. The method of claim 1, wherein the quality metric includes computing, for each access point, the least squares regression of the instant values of the signals strength comprised in the radio measurements received from the train access terminal.

7. The method of claim 1, wherein the roaming margin is a dynamic margin M(t) that decreases over time for t>t.sub.r, where t.sub.r is the instant of time when the last roaming procedure of the train access terminal occurred.

8. The method of claim 1, further comprising: obtaining, by the next access point (AP.sub.next) when the roaming criteria are met, information (RCDL.sub.i) related to the quality of the radio link between the train access terminal and the access point (AP.sub.i) currently associated with the train access terminal; determining, based on said information (RCDL.sub.i), a modulation and coding scheme to transmit data frames from the next access point (AP.sub.next) to the train access terminal; setting, in the radio driver of the next access point (AP.sub.next), the selected modulation and coding scheme for the downlink communication with the train access terminal.

9. The method of claim 8, wherein the information (RCDL.sub.i) used to determine the modulation and coding scheme is obtained by querying the access point (AP.sub.i) currently associated with the train access terminal.

10. The method of claim 8, further comprising storing, on a global database by each access point of the train-to-trackside wireless network, information related to the quality of the radio link between the access point and the associated train access terminals; and wherein the information (RCDL.sub.i) used to determine the modulation and coding scheme is retrieved by the next access point (AP.sub.next) by accessing the global database when the roaming criteria are met.

11. The method of any preceding claim, further comprising: receiving, by an access point (AP.sub.j) of the network, a roaming request from a train access terminal; checking if said access point (AP.sub.j) corresponds to the determined next access point (AP.sub.next), and in that case accepting the roaming request by the next access point (AP.sub.next); otherwise, ignoring the roaming request.

12. A system for handling roaming in a train-to-trackside wireless network, the system comprising a plurality of access points deployed along a railway track, the access points including an access point currently associated with a train access terminal installed on-board a train, the system being configured to: receive, by the access point (AP.sub.i) currently associated with the train access terminal, radio measurements of signals received by the train access terminal from access points of a train-to-trackside wireless network; determine a list of candidate access points for the train access terminal, based on the direction of travel and the route followed by the train; determine, based on the received radio measurements, a next access point (AP.sub.next), said next access point (AP.sub.next) being the access point providing the highest signal quality (maxSQ) according to a quality metric; evaluate compliance with a set of roaming criteria, the roaming criteria including: the next access point (AP.sub.next) is included in the list of candidate access points (N.sub.i); the amount of time elapsed since the last roaming performed by the train access terminal exceeds a minimum permanency time (t.sub.p); the highest signal quality (maxSQ) exceeds the signal quality (SQ(i)) of the access point (AP.sub.i) currently associated with the train access terminal by at least a roaming margin; if the roaming criteria are met, send, by the access point, a roaming command instructing the train access terminal to roam from the access point (AP.sub.i) currently associated with the train access terminal to the next access point (AP.sub.next).

13. The system of claim 12, comprising a central control station configured to receive the radio measurements from the access point, determine the list of candidate access points, determine the next access point and evaluate compliance with the roaming criteria.

14. The system of claim 13, wherein the central control station is configured to, upon reception of a roaming request from a train access terminal sent by an access point (AP.sub.j) of the network of a roaming request from a train access terminal, check if said access point (AP.sub.j) corresponds to the determined next access point (AP.sub.next), and in that case accept the roaming request by the next access point (AP.sub.next); otherwise, ignoring the roaming request.

15. The system of claim 12, wherein the access point (AP.sub.i) currently associated with the train access terminal is configured to determine the list of candidate access points, determine the next access point and evaluate compliance with the roaming criteria.

16. The system of claim 15, wherein each access point (AP.sub.j) is configured to, upon reception of a roaming request from a train access terminal, check if said access point (AP.sub.j) corresponds to the next access point (AP.sub.next) determined by the access point (AP.sub.i) currently associated with a train access terminal, and in that case accept the roaming request; otherwise, ignore the roaming request.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0029] A series of drawings which aid in better understanding the invention and which are expressly related with an embodiment of said invention, presented as a non-limiting example thereof, are very briefly described below.

[0030] FIG. 1 depicts an example of a train-to-trackside infrastructure and the coverage along the railway track, and also showing different elements that may be part of a system with either a centralized or a distributed configuration.

[0031] FIGS. 2A and 2B represent two possible layouts of a train-to-trackside infrastructure: circular use case (FIG. 2A), and round trip use case (FIG. 2B).

[0032] FIGS. 3A and 3B respectively show an exemplary graph G of the circular use case of FIG. 2A and the round trip use case of FIG. 2B.

[0033] FIG. 4 shows an example of ping-pong effect due to multi-path fading.

[0034] FIG. 5 depicts a state diagram of the method of the present invention to control roaming procedures in a train-to-trackside application.

[0035] FIGS. 6, 7 and 8 respectively represent the states S0, S1 and S2 of the state diagram shown in FIG. 5.

[0036] FIG. 9 shows an example of a roaming process and the messages exchanged between the system elements in a centralized configuration.

[0037] FIG. 10 shows an example of a roaming process and the messages exchanged between the system elements in a distributed configuration.

[0038] FIG. 11 represents an example of monitoring the quality of RF signals between a train access terminal and nearby access points, and the roaming performed based on the least squares regression of the instant values of the received signals.

[0039] FIG. 12 depicts an example of a minimum permanency time (t.sub.p) in a cell just after performing a roaming process.

[0040] FIG. 13 represents the throughput degradation after a roaming process due to the common operation of rate control algorithms.

[0041] FIG. 14 illustrates an example of the common operation, according to the prior art, of a rate control algorithm in the downlink (access point side).

[0042] FIG. 15 illustrates an example of the common operation, according to the prior art, of a rate control algorithm in the uplink (train access terminal side).

[0043] FIG. 16 shows an example of the operation of a rate control algorithm in the downlink (access point side) according to an embodiment of the present invention.

[0044] FIG. 17 shows an example of the operation of a rate control algorithm in the uplink (train access terminal side) according to an embodiment of the present invention.

[0045] FIG. 18 represents an example of communication of messages to transfer the local database RCDL of a train access terminal from one access point to another.

[0046] FIG. 19 shows an example of communication of messages to periodically transfer the local database RCDL of a train access terminal from one access point to another.

[0047] FIG. 20 depicts an example of communication of messages to update and query the local database RCDL of a train access terminal using a global database.

[0048] FIG. 21 illustrates an exemplary table containing information related to the quality of the radio link between the train access terminal and the access point. This information may be used by the rate control algorithm of the present invention.

DESCRIPTION OF A PREFERRED EMBODIMENT OF THE INVENTION

[0049] The present invention refers to a system and method of handling roaming in IEEE 802.11 train-to-trackside wireless networks. As depicted in FIG. 1, this type of networks includes a plurality of access points 102 (AP.sub.n, AP.sub.n+1, AP.sub.n+2) deployed along a railway track 100 and one or more train access terminals 112 installed on-board (normally outside the front and back railcar) at least one train 110 moving along the railway track 100. Both the train access terminals 112 and the access points 102 deployed along the railway track 100 may have directional antennas with a radiation pattern 104 that covers all the area of interest with a high enough signal quality in both the downlink and the uplink. In the following, for the sake of simplicity and without loss of generality, we assume that there is only one train access terminal 112 installed outside one of the train's railcars.

[0050] A process to roam from an access point (AP.sub.n) to a subsequent access point (AP.sub.n+1) is normally initiated when the train access terminal 112 reaches the intersection 106 of adjacent radiation patterns 104.

[0051] All the access points 102 are connected through an aggregation network 116. Access points may be connected to the aggregation network 116 through wired or wireless links. The aggregation network 116 may also include a mesh communication network among access points. A central data center 120, in charge of storing and processing information related to the invention described herein, may be directly connected to the aggregation network 116. Alternatively, a remote data center 130 may be remotely connected to the aggregation network 116 through the Internet 118. Both the central data center and the remote data center may be part of any of the systems of the railway operator. The system of the present invention may work using a distributed configuration or a centralized configuration.

[0052] In a centralized configuration, a central control station 122 is in charge of managing and coordinating the roaming of the train access terminal 112 from an access point 102 to another access point 102. The central control station 122 may be located in the central data center 120, in the remote data center 130, or in a different site (although there are two different central control stations 122 depicted in FIG. 1, normally only one central control station 122 would be required).

[0053] The central data center may comprise a train database 124 for storing information on trains 110 and train access terminals 112, such as unique identifiers of the trains and/or train access terminals, route followed by each train, graph G of access points of the network associated to the route followed by each train, direction of travel d of each train and its train access terminals, etc. This information may be used by the method of handling roaming. Again, although there are two different train databases 124 depicted, normally only one would be needed.

[0054] In a distributed configuration, the system may make use of a global database 126 for storing and sharing data among the access points 112 of the network. The global database 126 may be installed in the central/remote data center (120, 130) or in a different installation, as depicted in the example.

[0055] The present invention improves the communication between the train access terminals 112 and the access points 102 deployed along the railway track 100, i.e. the train-to-trackside network. Examples of two possible use cases are shown in FIG. 2A for a circular path across several train stations 108 (stations A, B, C and D) and FIG. 2B for a round trip path between two train stations (station A and D). In both examples, the train access terminal 112 must frequently re-associate with other access points as it moves along the railway track 100 in order to maintain the Internet data session of the train passengers (see FIG. 1).

[0056] The frequency at which a train access terminal 112 roams from the current access point to a next access point depends on the train velocity, cells size, and distance among access points. Once the network infrastructure (i.e. the access points 102 along the railway track 100) knows the path followed by every train 110 in that railway track, a graph G associated with the route followed by each train is obtained (the nodes 302 of the graph G correspond to the access points 102 along the train route). The graph G associated with each of the two use cases of FIG. 2 is depicted in FIG. 3. FIG. 3A shows the graph G for the circular case of FIG. 2A, and FIG. 3B shows the graph G for the round trip of FIG. 2B. Once known the graph G, the access point currently associated to the train access terminal 112, and the direction of travel d of the train (i.e., [current AP, G, d]), the next access point in graph G, to which the train access terminal 112 should be re-associated, can be determined. The graph G can be obtained by using any known method in graph theory.

[0057] Signals transmitted to/by a train access terminal 112 are affected by several radio-electrical physical effects which may make signals received by a wireless device fluctuate to a greater or lesser extent. A direct consequence of such fluctuation of received signals is that prior-art proposals may make bad roaming decisions, especially in the border of two radio cells. An example is depicted in FIG. 4, where due to fluctuations in the received signals, the train access terminal 112 performs several roaming processes between the current access point (AP.sub.n) and the next access point (AP.sub.n+1). This effect is commonly known as ping-pong effect and may lead to critical throughput degradations and even to service disruptions.

[0058] The present invention proposes different mechanisms to deal with the ping-pong effect. Firstly, all roaming requests directed to a non-candidate access point are ignored, avoiding this way all backward roaming processes (e.g. roaming processes from AP.sub.n+1 to AP.sub.n in the example of FIG. 4), as well as all roaming processes directed to adjacent access points. Secondly, the present invention uses a minimum permanency time (t.sub.p) and a margin (M(t)). The minimum permanency time (t.sub.p) is used to ignore all the roaming requests sent by the train access terminal 112 during a determined period of time t.sub.p after the last roaming procedure (see FIG. 12). The margin (M(t)) is preferably a dynamic margin, and is used when comparing the quality of the signals received from the current access point with the quality of the signals received from all the candidate access points. M(t) may vary in time according to a positive function that decreases over time, e.g. M(t) may be an exponential function such as M(t)=e.sup.(1/(t−tr))−1, where t>t.sub.r and t.sub.r is the time instant when the last roaming procedure occurred.

[0059] The state diagram of the invention proposed herein is shown in FIG. 5. The state diagram comprises the states S0 (502), S1 (504) and S2 (506). All the parameters used in the state diagram of the invention may be adjusted depending on the train velocity.

[0060] The state diagram is executed for each train access terminal 112 traveling along the railway track. The state diagram may be executed in a distributed or a centralized way.

[0061] In a distributed configuration, the steps needed to implement the state diagram are distributed among the access points 102. Each step of the state diagram may be performed by one or more access points 102. The set of access points 102 in charge of carrying out a given step of the state diagram may vary as the train access terminal 112 moves along the railway track 100. In this configuration, information is exchanged between the access points, which may be connected through a wireless or a wired communication link.

[0062] In a centralized structure, a central network infrastructure (e.g. a central control station 122) performs the steps S0-S2 of the state diagram. The central control station 122 is in communication (wired or wirelessly) with all the access points 102 of the network, gathering information and sending instructions. The inputs for the state diagram are the access point currently associated to the train access terminal (AP.sub.i), the graph G of the route followed by the train 110, and the direction of travel d of the train (i.e. [AP.sub.i, G, d]).

[0063] In the following examples, it is assumed that all the access points 102 deployed along the railway track 100 are configured with the same SSID (e.g. SSID.sub.T2T). In state S0, represented in FIG. 6, the first step is to obtain 602 the set of candidate access points N.sub.i for the train access terminal 112. The set of candidate access points N.sub.i is calculated by using the graph G (which can be derived from the route followed by the train) and taking into account the direction of travel d of the train. The list of candidate access points N.sub.i may comprise one or more access points. Afterwards, the access point (AP.sub.i) currently associated with the train access terminal periodically monitors 604 the quality of the signals (signal quality, SQ) received by the train access terminal 112. The access point (AP.sub.i) currently associated with the train access terminal 112 may periodically send radio measurement requests to the train access terminal 112 to inquire the train access terminal 112 to perform active scanning of SSID.sub.T2T. Upon receiving a radio measurement request, the train access terminal 112 actively scans the corresponding frequency band and, afterwards, reports the result of such active scanning to AP.sub.i, which would store that results in a database. The scan results stored in a database may be processed in order to determine the quality of the signals received by the train access terminal 112 from each of the access points in its range.

[0064] The data processing may provide a metric (SQ) per access point in range, associating a real value to the signal quality perceived by the train access terminal 112. Some prior-art proposals use as a metric the received signal strength obtained in the last scan result. However, comparing signals quality based on instant values of the received signals strength may be a poor practice in train-to-trackside applications because the strength of the received signals may fluctuate due to multipath fading, causing the ping-pong effect of FIG. 4 (i.e., several consecutive roaming processes from AP.sub.n and AP.sub.n+1 and vice versa). A more advanced quality metric may be used, for instance by computing the least squares regression 1102 of the instant values of the received signals strength (see FIG. 11). By doing so, the signal randomness is reduced, and even it may be predicted when the roaming process should take place by determining the cross point between the two least squares lines associated with the current access point (AP.sub.n in FIG. 11) and the next access point (AP.sub.n+1 in FIG. 11). The IEEE 802.11 standard provides mechanisms to inquire a train access terminal 112 to perform some predefined commands, which are described in the IEEE 802.11k amendment. The invention described herein may make use of the IEEE 802.11k amendment, or of any other mechanism used to command the train access terminal to perform an active scanning and report the result of such active scanning.

[0065] Once a quality metric (SQ) is obtained for each access point in range, the access point that provides the best quality metric (maxSQ) is determined 606 and selected as the next access point (AP.sub.next). The computation in step 606 is performed on the set of signal qualities [SQ-SQ(i)], excluding the quality metric SQ(i) of the access point (AP.sub.i) currently associated with the train access terminal, so that the selected next access point (AP.sub.next) cannot be AP.sub.i. Alternatively, the best quality metric (maxSQ) can be obtained considering all the access points, even AP.sub.i, but if the best quality metric (SQmax) corresponds to SQ(i) the roaming is not performed. Thereafter, the following conditions or roaming criteria are checked (steps 612, 614 and 616 of FIG. 6): [0066] (i) The next access point (AP.sub.next) is not the access point AP.sub.i currently associated with the train access terminal (this roaming criterium may be checked after the signal quality measurements, if the signal quality is measured for all the access points; or may be implicitly performed when measuring signal qualities by disregarding the signal quality of AP.sub.i, as depicted in FIG. 6; or AP.sub.i may be not included in the list of candidate APs, see next criterium); [0067] (ii) the next access point (AP.sub.next) is in the list of candidate APs (N.sub.i); [0068] (iii) more than t.sub.p seconds have passed since the last roaming; and [0069] (iv) the difference between the signals quality received by the train access terminal from AP.sub.i (SQ(i)) and from the next access point AP.sub.next (maxSQ) is greater than the value of the margin (M(t)) at that time.

[0070] If the next access point (AP.sub.next) is not a node of the graph G, checked in step 608, a graph repairing operation 618 may be carried out to include the new node in the graph G. The graph repairing operation 618 may be performed by the network administrator. Every change in the graph G must be updated in the corresponding network nodes and databases, e.g. in the central/remote data center for the centralized configuration or in the global database and the access points within the path (G) of that train access terminal for the distributed configuration. Any of the prior-art methods to repair the graph G may be used. When all the roaming criteria are met, a counter S1.sub.count is initialized to 0 in step 620 and the system transitions to state S1; otherwise, the system remains periodically monitoring 604 the quality of the signals received by the train access terminal 112 until the roaming criteria are met.

[0071] State S1 is depicted in FIG. 7. In this state, the access point (AP.sub.i) currently associated with the train access terminal 112 commands 702 the train access terminal 112 to perform a roaming (e.g., a fast roaming) from AP.sub.i to AP.sub.next. The IEEE 802.11 standard provides mechanisms to inquire a train access terminal to roam from one access point to another. This operation is defined in the IEEE 802.11v amendment. The present invention may make use of the IEEE 802.11v amendment, or of any other mechanism used to command a train access terminal to roam from one AP to another. The counter S1.sub.count is used to count 704 how many times the system has tried to roam the train access terminal 112 from AP.sub.i to AP.sub.next. An alert is sent 708 to the network administrator if S1.sub.count has surpassed 706 a maximum value (MAX_TRIES). Finally, the system transitions to state S2.

[0072] State S2 is shown in FIG. 8. When considering a centralized configuration, a central control station 122 is in charge of accepting or ignoring the roaming requests sent by the train access terminal 112. In a distributed configuration, each access point of the network performs this state S2 (in this case, the access points need to exchange some data among them). In the case that an access point AP.sub.j has received a roaming request from the train access terminal 112, which is checked in step 802, the system (i.e., the central control station 122 in a centralized configuration or each access point 102 of the network in a distributed configuration) checks 806 whether that access point AP.sub.j is the next access point (AP.sub.next), and if so, the roaming request is accepted 808 by the next access point (AP.sub.next). In the centralized distribution, the central control station 122 accordingly instructs the access point 102 to accept the roaming request; in a distributed structure, each access point is conveniently programmed to execute the roaming. In the case when the roaming request is received by another access point in the graph G, different from the next access point (AP.sub.next), such request is ignored 812 unless the counter S1.sub.count, checked in step 810, exceeds a maximum value (MAX_TRIES); otherwise, the next access point (AP.sub.next) accepts 808 the roaming request.

[0073] The system may additionally check in step 804 whether the access point AP.sub.j receiving the roaming request is included in the graph G. If the roaming request is received by an access point that is not included in the graph G, a graph repairing operation 816 is carried out to include the new node AP.sub.j in the graph G and the roaming request is ignored 812 (the new access point needs to be accepted by the network administrator).

[0074] Once a roaming request is accepted 808, the system transitions to state S0. If the system remains in state S2 during a time higher than a permanency time t.sub.w, checked in step 814, the system will immediately transition to state S1 to send a new roaming command to the train access terminal 112.

[0075] FIG. 9 depicts an example of message transfer for the state diagram of FIGS. 5 to 8 between the train access terminal 112, several access points 102 of the network (AP1, AP2, AP3) and the central control station 122 in a centralized configuration. The central control station 122 receives 902 an announcement of a train access terminal 112 newly connected to the network, detected by access point AP1 through an association request. The central control station 122 obtains the route (or a graph G corresponding to said route) and the direction of travel d of the train 110 in which the train access terminal 112 is installed (for instance by looking up a train database 124 in the central/remote data center (120, 130), which is updated by the railway operator), and updates the information 904 associated with said train access terminal 112. Knowing the access point currently associated (AP1) with the train access terminal 112, the graph G and the direction d, the central control station 122 can determine a list of candidate access points N.sub.i (in the example, the candidate is only AP2, the next access point in the route).

[0076] In this configuration, the central control station 122 instructs 906, through the access point currently associated (AP1), the train access terminal 112 to periodically scan the frequency band (e.g. by sending probe requests 910) in order to monitor 604 the quality of the signals received from all the access points 102. In the first attempt, the train access terminal 112 only receives the probe response 912 from the access point AP1, which is currently associated with the train access terminal 112, since the other access points (AP2, AP3) are out of range. The central control station 122 then computes the quality metric for each access point according to the radio measurement report within the radio measurement response 914 sent by the train access terminal. Afterwards, the central control station 122 checks compliance with the roaming criteria, but since the criteria are not met (the train access station 112 could not find a better access point) no roaming is ordered. When the train access terminal 112 finds a better candidate different from AP1, in the example AP2, and the roaming criteria are met 920, the central control station 122 commands 702 the train access terminal 112 to roam from the access point currently associated with the train access terminal 112, AP1, to the next access point, AP2. If a wrong access point, for example AP3, receives a roaming request from the train access terminal 112, the roaming request is transferred 926 to the central control station for acceptance; in this case, the central control station 122 orders the wrong access point AP3 to ignore the roaming request 812 since this access point (AP3) is not the next access point previously selected (i.e. AP2). When the correct access point, AP2, receives the roaming request from the train access terminal 112, it is remitted 932 to the central control station 122, which accepts 808 the roaming request. When the roaming process is finished and the central control station 122 is informed 942 by the new access point, AP2, the information 904 associated to the train access terminal 112 is accordingly updated (e.g. the access point currently associated with the train access terminal 112 is now AP2).

[0077] FIG. 10 shows, for a distributed configuration, an example of message transfer between the train access terminal 112, access points 102 of the network (AP1, AP2, AP3) and a global database 126 used by the access points 102 to store and share information 904 associated with the train access terminal 112. The information stored in the global database 126 may include, among other data, the access point AP.sub.i currently associated with the train access terminal 112, the graph G, the direction of travel d and the current value of the counter S1.sub.count. In this configuration, there is no central control station 122, and the access points 102 communicate with each other by using the aggregation network. Furthermore, the access points 102 store and share information through the global database 126.

[0078] Every time a train access terminal 112 is associated with an access point 102 (AP1 in the example of FIG. 10), the access point 102 checks whether it has no updated information 1004 of that train access terminal 112. In that case, the access point 102 queries 1006 the global database 126 to get the latest information of that train access terminal 112 (i.e. the graph G and the direction d associated with the route of that train access terminal). Afterwards, the access point 102 updates its local information 1004 related to that train access terminal 112 and shares 1008 that local information 1004 with the rests of access points 102 in G (AP2 and AP3 in the example of FIG. 10). Every access point 102 updates and shares its information 1004 for every newly associated train access terminal 112. Once shared that information 1004, the access point 102 starts monitoring 604 the quality of the signals received by the train access terminal from all the access points 102. The received signals quality monitoring step may be performed as explained in the example shown in FIG. 9.

[0079] When all roaming criteria are met, the access point 102 currently associated with the train access terminal 112 commands 702 the train access terminal 112 to roam from the access point currently associated with the train access terminal 112, AP1, to the next access point, AP2. If a wrong access point 102, for example AP3, receives a roaming request from the train access terminal 112, that wrong access point will ignore the roaming request 812 since this access point (AP3) is not the next access point. When the correct access point, AP2, receives the roaming request from the train access terminal 112, that correct access point will accept 808 the roaming request. Every access 102 point in G knows which is the next access point for a train access terminal 112 because the access point currently associated with the train access terminal 112 sends an ‘Update TAT Information’ message 1010 to all the access points in G whenever it changes its local information 1004 for that train access terminal 112. The ‘Update TAT Information’ message 1010 includes which is the next access point for the train access terminal indicated in the TAT ID field. When the roaming process is finished, the access point 102 currently associated with the train access terminal 112 informs 1012 the rest of access points 102 in G that it is the new access point wherein the train access terminal is associated to.

[0080] The invention described herein also proposes mechanisms to maintain, from one access point to another, the information used by the rate control algorithm, related to the quality of the radio link between the access point and the train access terminal, to decide which is the best modulation and coding scheme (MCS) to which data frames are transmitted. Current IEEE 802.11 networks do not consider mechanisms to exchange the rate control information, and hence, they are susceptible to be affected by the throughput degradation due to the operation of the rate control algorithm. In IEEE 802.11 networks, when a wireless device initiates a new communication with another wireless device, the rate control algorithm of each device commonly selects an initial MCS to start transmitting data. That MCS may be a randomly selected MCS, or an MCS pre-configured beforehand. Afterwards, the rate control algorithm of each wireless device changes the MCS according to the quality of the radio link between both devices. Therefore, after each roaming process, the rate control algorithm of each wireless device (i.e. train access terminal 112 and access point 102) starts transmitting with an initial MCS, normally different from the optimum MCS, and hence, train passengers perceive a degradation in their quality of service. An example of this degradation is shown in FIG. 13.

[0081] Prior-art rate control algorithms may use different metrics to select the MCS at which data frames are transmitted. For example, some rate control algorithms use the signal-to-noise-plus-interference ratio (SNIR). However, the most common practice is to use the MCS that provides the higher chance of satisfactory frame reception (e.g. the Minstrel rate control algorithm). In order to do so, the rate control algorithm maintains a local database where it stores the probability of satisfactory frame reception for each possible MCS. This local database is herein referred to as RCDL.sub.i for the downlink communication between the access point 102 and the train access terminal 112 and RCUL for the uplink communication between the access point 102 and the train access terminal 112. In IEEE 802.11 networks in infrastructure mode, a train access terminal 112 can only communicate with the access point to which is currently associated, and hence, its rate control algorithm only needs to maintain a local database for that access point (i.e. RCUL). Furthermore, when a train access terminal 112 stops being associated with an access point, the rate control algorithms of both wireless devices may delete the local databases associated with that communication.

[0082] A flow diagram showing the common operation of a rate-control algorithm of the prior art is depicted in FIG. 14 for the downlink communication between an access point 102 and its associated train access terminals 112, and in FIG. 15 for the uplink communication between a train access terminal 112 and an access point 102. As can be observed in FIG. 14, the rate control algorithm of the access point 102 firstly checks 1202 whether there is a newly associated train access terminal 112, and in that case, a new local database and a timer are initialized (1204, 1206) for that train access terminal 112. Furthermore, an initial MCS is configured 1208 to transmit data to that train access terminal 112. Otherwise, the rate control algorithm checks 1210 whether the timer associated with each of the train access terminal 112 has expired. Upon detecting that a timer has expired, the rate control algorithm analyzes 1212 its local database for the train access terminal TAT.sub.i associated with that timer (i.e. RCDL.sub.i) in order to determine 1214 which is the new MCS used to transmit data to that train access terminal TAT.sub.i. Finally, that MCS is configured 1216 in the radio driver 1218 and the timer for that train access terminal TATi is restarted 1220. The radio driver 1218 may accept a different configuration for each train access terminal 112. Furthermore, it is important to note that the information stored in the local database (RCDL) is updated 1222 as the radio driver 1218 sends data frames to each train access terminal TAT.sub.i. The process is performed for every train access terminal i currently associated with the access point.

[0083] On the other hand, as can be observed in FIG. 15 depicting the operation of a prior-art rate-control algorithm for the uplink communication between a train access terminal 112 and an access point 102, the rate control algorithm of the train access terminal 112 firstly checks 1302 whether the train access terminal 112 has just associated itself with an access point 102, and in that case, it initializes 1304 its timer and its local database (RCUL). Furthermore, it sets 1306 an initial MCS in the radio driver 1308. Otherwise, the rate control algorithm checks 1310 whether its timer has expired. If this last happens, the rate control algorithm analyzes 1312 its local database (RCUL) to determine which is the new MCS with which the radio driver must transmit data to the access point. Finally, it sets 1314 the chosen MCS in the radio driver 1308. The information stored in the local database (RCUL) is updated 1316 as the radio driver 1308 sends data to the access point.

[0084] As can be observed in FIG. 14 and FIG. 15, prior-art rate control algorithms neither provide mechanisms to exchange the local databases (RCDL.sub.i) between access points, nor mechanisms to maintain the local database RCUL when the train access terminal 112 roams from one access point to another. The invention described herein proposes mechanisms to exchange and maintain such databases in order to avoid the throughput degradation that normally occur just after a roaming process is finished (see FIG. 13). FIG. 16 shows the flow diagram, according to an embodiment of the present invention, for the rate control algorithm associated with the downlink communication between the access point and its associated train access terminals. The steps inside the dotted contour are new when compared to the prior-art method of FIG. 14. When the rate control algorithm detects, in step 1202, that there is a newly associated train access terminal (TAT.sub.i), it initializes (1204, 1206) the local database and the timer for that train access terminal TAT.sub.i (i.e. RCDL.sub.i). Afterwards, it queries 1402 if that train access terminal TAT.sub.i comes from another access point AP.sub.j in the graph G. If the train access terminal 112 does not come from another access point in the graph G, the rate control algorithm continues with its common operation, as previously discussed in FIG. 14. Otherwise, the rate control algorithm sends a rate control request (RC request, with a field TAT ID including the queried train access terminal, which is the train access terminal that is going to perform roaming) 1404 to the rate control algorithm of that access point AP.sub.j to obtain the local database for that train access terminal TAT.sub.i (RCDL.sub.i in AP.sub.j). Upon receiving an RC request, the corresponding rate control algorithm responds with an RC response including the queried local database RCDL.sub.i. Once the rate control algorithm receives an RC response, it copies 1406 the received database (i.e. RCDL.sub.i of AP.sub.j) into its local database (i.e. its RCDL.sub.i). Then, the rate control algorithm analyzes 1408 the local database RCDL.sub.i to determine which would be the best MCS to transmit data frames to that train access terminal TAT.sub.i. Finally, the rate control algorithm sets 1410 the selected MCS for that train access terminal TAT.sub.i in the radio driver 1218 and continues its common operation, as previously discussed in FIG. 14. It is important to take into account that RC requests can be sent at any time chosen by the rate control algorithm. For example, the rate control algorithm can be configured to transmit RC requests (RC Req.) just after its access point receives the reassociation request that is sent during a fast roaming process. Furthermore, the access point may transmit the reassociation response just after receiving the RC response in order to assure that the local database RCDL.sub.i for that train access terminal TAT.sub.i is analyzed before transmitting data frames to that train access terminal TAT.sub.i, as it is shown in the example of FIG. 18. In other embodiment, the rate control algorithm of each of the next access points in the graph G periodically sends RC requests to the access point where the train access terminal 112 is currently associated, see FIG. 19. This way, the time needed to reassociate a train access terminal TAT.sub.i during a fast roaming (FR) process (which starts with a “FR Req.” message) may be reduced because each of the next access points in the graph G already has an updated RCDL.sub.i. Other realizations may include a global database 126 where the access points update and query the database associated with every train access terminal 112. FIG. 20 shows an example where a global database 126 is used in the example shown in FIG. 18.

[0085] FIG. 17 shows the flow diagram of a preferred embodiment for the rate control algorithm associated with the uplink communication between the train access terminal 112 and the access point to which is associated. The steps inside the dotted contour are new when compared to the prior-art method of FIG. 15. When the rate control algorithm detects 1302 that its train access terminal 112 has just associated itself with an access point AP.sub.j, it initializes 1304 its timer and its local database (RCUL) and, afterwards, it queries 1502 whether its train access terminal 112 has roamed between two access points in the graph G (in this flow diagram, AP.sub.n=AP.sub.k and AP.sub.n+1=AP.sub.j). If the train access terminal 112 has not roamed between two access points in the graph G, the rate control algorithm continues with its common operation, as explained in FIG. 15. Otherwise, the rate control algorithm copies 1504 the local database associated with access point AP.sub.k (i.e. RCUL.sub.k) in the local database recently initialized for access point AP.sub.j (i.e. RCUL.sub.j). Then, it proceeds to analyze 1506 this local database RCUL.sub.j to determine which would be the best MCS to transmit data frames to access point AP.sub.j. Finally, the rate control algorithm sets 1508 the selected MCS in the radio driver 1308 and continues the common operation described in FIG. 15. Once the rate control algorithm has copied RCUL.sub.k into RCUL.sub.j, it may delete or temporarily maintain that RCUL.sub.k.

[0086] FIG. 21 shows an example of a table containing information RCDL.sub.i and RCUL.sub.j related to the quality of the radio links between the train access terminal TAT.sub.i and the access point associated with the train access terminal. This information is used by rate control algorithms in IEEE802.11 networks, such as the Minstrel rate control algorithm, to determine the best modulation and coding scheme (MCS). There are other known rate control algorithms, each of them using different type of gathered information to determine the MCS.