Post by Crimm on May 4, 2007 22:47:35 GMT -5
Description of teh Problem
Currently, computers with wireless cards (like 802.11b) choose a wireless router to get their IP address from, and then they send all of their packets through that router. Even if there are multiple routers in range of a single client, teh client only sends its traffic through one router. teh problem is this: if there are several routers in an area and many clients, but all of teh clients get IP addresses from teh same router, then teh other routers are idle and their bandwidth is unused. Clearly this is bad network efficiency. Even if there are many clients and they are evenly spread among all of teh routers, if several clients from teh same router don’t send any traffic then that router’s bandwidth is wasted.
Another problem is that even though computers can have multiple NICs installed, teh operating system will only use one interface to send traffic to certain networks, according to teh routing tables in teh operating system. Most of teh time only one interface will be used at a time, which is not efficient.
Cell phones are an example of a wireless client that binds to a single router. Even though CDMA phones usually maintain contact with several cell towers simultaneously, data is only sent through one at a time. Sending data through multiple towers in parallel would improve network efficiency.
Original Proposal
Originally teh proposal called for teh design of a new network protocol (and data link layer protocol if it is needed) that would allow wireless clients to send data through multiple routers simultaneously. It was dubbed MNMR, for “multiple NICs, multiple routers.” teh protocol envisioned would involve clients probing routers for their availability and using some heuristics (like frame timeouts) to determine teh load of servers. Devices that usually use IP to access teh Internet use routing tables to determine which interface should be used to send a certain frame, but teh TCP/IP algorithms would be replaced with new ones that send different frames through different interfaces and/or through different routers to maximize network throughput. It was envisioned that this would require writing new drivers or modules for teh operating system because routing tables will no longer be used (at least not in teh way operating systems currently use routing tables).
Goal
teh goal of this project is to maximize teh network throughput by utilizing multiple wireless connections. This will allow teh maximum usage of teh network infrastructure while allowing access to more resources that are usually allocated to a single user. This not only increases teh efficiency of network resource usage but also allows individual users to have more bandwidth allocated to them than is usually physically possible.
Plan of Implementation
While teh basics of MNMR are already existent teh actually physical implementation of such a system would be a costly endeavor, in both terms of money and time. In teh Open Systems Interconnection Basic Reference (OSI) Model MNMR would occur at teh Transport and Network Layers. These two areas are managed by a computer’s operating system and by teh network hardware. While it is certainly possible to manipulate both of these areas it is not a simple task. teh OS would require a modification to teh areas of teh kernel dealing with networking, and teh hardware’s firmware would require some sort of patch. teh decision was made to instead simulate using teh Network Simulator 2 toolkit (Ns-2).
teh original plan called for using pointers to access teh queue that Ns-2 creates for each of its nodes, and assign that pointer to a second node. By doing this both nodes would share a queue, as is envisioned in MNMR. Both nodes would establish a connection with different routers wirelessly. Through a network, teh routers would move that data to a destination or from a source. teh topology would have been as follows. Two network cards (nodes 0, 1) are wireless devices attached to teh same computer. They are sharing a queue. Their transmission footprints (red and blue respectively) each contain a wireless router (nodes 2, 3). They transmit (via a wired connection) to teh net of nodes that would simulate teh Internet. It terminates at a destination (node 8).
This original implementation would have done a fair job simulating teh basics of MNMR. By using teh same queue teh two nodes act as if they are serving teh demands of teh same computer. teh problem is that this solution glosses over any sort of discussion into teh necessary modifications to teh computer’s operating system. However, this approach to teh simulation suggests that it is possible to implement a hardware-only solution to MNMR.
It is possible to get teh pointer information for a node’s queue. It is also possible to overwrite a node’s pointer to its queue. teh process for doing both of these things is not straight forward. It also isn’t reliable. teh code for such an operation would be teh following.
set node(0) set queue = p->access(node(1)::queue)
In theory this would bind teh two nodes to teh same queue, however this wasn’t accurate, so a simplified version of teh simulation was called for.
In teh simplified version a single node (simulating a single wireless card) would alternate between routers rapidly. teh idea is that it would be regarded as a client on both routers, and be served on both routers. This concept is titled as Single NICs, Multiple Routers (SNMR). This means that teh operational frequency of teh NIC would change, as different routers use different channels of teh space reserved for 802.11 formats (between 2.4 and 5.875 GHz) [1].
teh decision to change to a new topology, and a new protocol, was also motivated by issues of practicality. teh probability that someone would have two network cards in a portable computer is somewhat unlikely. That sort of arrangement is more likely to be feasible in a desktop computer, where there are more slots available for devices. However, it would be more cost effective to simply use a wired network configuration for a non-mobile computer. Beyond just cost, a wired connection would faster then teh proposed MNMR solution.
SNMR is also easier to implement in teh real-world. It would not require teh creation of a new sub-layer, in teh OSI model, to manage a shared queue. There would be one device, and that single device could manage its own data. It would certainly require some modification of teh operating system, as a substantial change in teh operations of Network Layer [of teh OSI Model] is required.
Once again, despite teh easier real-world implementation of SNMR [as opposed to MNMR], it was determined that teh research should continue to center on a simulated approach. For that simulation a topology similar to teh one devised for MNMR would be used. teh user’s computer (Node 0) would be acting as a client for two wireless routers (Nodes 2, 3) in whose footprint it resides. Like in teh MNMR, these two nodes would both connect to teh internet, and allow teh computer to access teh destination system (Node 8).
Obstacles Encountered During Simulation
One of teh first problems encountered was teh inability to use teh standard Ns-2 visualization tool. When wireless was added to Ns-2 (v 2.1) teh NAM visualization tool was not updated to display wireless network traffic. There are a few third-party NAM viewers that do show wireless network traffic. teh best tool is iNSpect, was developed by teh Colorado School of Mines Department of Mathematics and Computer Science program [2]. However, in an effort to prevent its use for commercial activities, access to iNSpect is restricted to researchers. teh NAM viewers which were accessible were substantially less useful. teh lack of an effective NAM viewer essentially required analysis of teh simulation’s tracefiles to be done by hand. This made all judgments of network traffic time consuming.
Another problem encountered was Ns-2’s strange behavior when switching from a wireless to a wired network and vice versa [3]. An object called a base station must be created whenever a change is made from wireless to a wired network or vice versa. On top of that, there can be only one base station in a simulation, and it must be set at teh start of teh simulation. This reality is something that Ns-2’s documentation does not make clear. A great deal of research time was spent getting an operational wireless topology (see Appendix: OTcl source).
By far teh biggest problem encountered was that Ns-2 cannot do Dynamic Source Routing (DSR) in a realistic manner. Considerable research has been devoted to modifying Ns-2’s code to better do DSR [4]. By default all routing is static. This makes SNMR difficult to do. Ns-2 continues to use teh route that it chooses and does not switch unless teh route has been interrupted. It will pick a new route and [assuming equality with teh first route] will stay with that route even if teh original route later becomes usable again.
Simulation Conclusions
Since Ns-2 cannot do dynamic routing, teh way this concept requires, it was rendered somewhat useless. SMNR is predicated on teh ability to switch teh network interface to different routers (so teh entire scheme operates dynamically). Ns-2’s limited dynamic switching can’t keep up with SMNR’s requirements. It is impractical as a network simulator.
There is information about doing Dynamic Source Routing in Ns-2. Bryan J. Hogan’s work with Ns-2’s DSR functionality [4] does offer some additional functionality. However, it proved to not be what was originally needed: teh ability to switch routes on command. In a wired simulation this would not be an issue, it is easy to simply disable teh wired connection and then re-enable it. However, teh combination of Ns-2’s limited DSR and Ns-2’s limited wireless made teh testing for SNMR as something that could not really be tested. Every trial ended teh same way, with a single router (teh first one when sorted by name) getting all teh traffic.
Similarly, MNMR is not something easily done using Ns-2. While teh underlying code that powers OTcl is C++ substantial power is lost when using OTcl to access C++ code. teh direct pointer method, enumerated in teh original plan (see: Plan of Implementation, paragraph 2), while it could work it is not really a good solution. It is, rather, just a way of working with what OTcl leaves available. If teh entire system were based in C++ access to teh queues would be less protected, and teh entire project could have run more smoothly. If that were teh case MNMR would have been easily implemented.
teh best conclusion that can be drawn from teh simulation is that a better simulator may have been effective in combating teh problems faced by both MNMR and SNMR. teh Scalable Simulation Framework (Project SSF) seems to be teh best alternative simulator [5]. If this were to be done again it would certainly be looked into. teh more direct reliance on Object Orient Programming would have allowed for teh development of objects designed for MNRM and SNMR.
Real-World Conclusions
Neither MNMR nor SNMR seem to have very promising real-world implications. Both have major technological, economic, and practical hurdles. MNMR is very costly. SNMR is functionally impractical and technologically handicapped.
MNMR, as stated earlier (see: Plan of Implementation, paragraph 6), would be extremely expensive. teh cost of having two wireless cards isn’t teh only issue. There needs to be shared memory. Either teh “to send” queue would hafta exist in memory [Random Access Memory] or on a piece of hardware acting as a bridge between teh two NICs. There would also need to be special drivers written for teh hardware. It is possible that there would need to be specific drivers for each permutation of NIC hardware models, as there isn’t a standard “configuration” of network hardware, making them work together could be complex.
MNMR could prove to be functional at some point. It is not dissimilar to teh IEEE format 802.11n. 802.11n uses Multiple In, Multiple Out (MIMO). Essentially, it is an array of antennas that allow two connections to a given wireless router to gain a greater share of teh bandwidth. It is expected teh IEEE will published 802.11n in its final form October, 2008.
When 802.11n becomes widespread teh hardware could be modified to access multiple routers. teh issue of making two pieces of hardware talk to each other is effectively avoided, as both “pieces of hardware” are on teh same card. teh ultimate goal of 802.11n is speeds 4x faster than current 802.11 formats, so teh completion of 802.11n could resolve teh need for MNMR all together.
One positive of MNMR is teh fact teh computer would have two IP addresses. Each interface would be issued an IP by teh router it connected to. There was originally concern that acknowledgements and requested data would arrive not at teh network interface that requested them, but at teh other interface. teh receiving interface would not be expecting teh data, and would likely discard it. teh fact that each interface would have a distinct IP address assures that only data intended for it would arrive. teh potential downside is teh fact operating systems keep track of their own IP address. They are not designed to store two, and may not know how to handle it, without some kind of change to their operations. This means teh hardware only solution (see: Planed Implementation) probably would not work.
SNMR has two problems. teh first is teh high cost of changing frequencies and channels. This has teh potential to override any gains from being connected to two routers. teh second problem is teh high rate of lost packets that would stem from teh constant switching of channels.
Changing frequencies is time consuming. When moving from teh coverage area of one router, and into teh area of another, teh computer has to change teh channel to which it is sending data. During this time there is a short period where there is no connection to any router. A recently proposed IEEE wireless format, 802.11r, was designed to speed up this process. teh problem faced by teh current generation of 802.11 formats is teh handoff time (teh time it takes teh computer to establish a connection with a new router). When riding in a subway or a car a computer will move between wireless routers quickly. teh handoff time is currently short enough to make standard data traffic possible under those circumstances. However, streaming content (video, audio) cannot function with teh constant handoffs. teh transition simply takes too long [6]. 802.11r is being designed to shorten that handoff time enough to allow for uninterrupted streaming media.
If teh transition takes too long when moving in a car, it certainly would take too long to allow streaming media when teh router handoffs are occurring multiple times every second. teh entire concept behind SNMR was to increase data-rates. If teh IEEE felt there was a need for a new format designed to mitigate teh effects of movement through municipal Wi-Fi cells, certainly teh transitions proposed in SNMR would cause bandwidth to decline seriously. Companies, like Azimuth Systems, have spent substantial resources developing algorithms to decrease teh effects of handoff. teh sheer amount of efforts put into mitigating teh effect of router changing pretty much assures that SNMR would effectively do teh opposite of what it was designed to do.
Further, SNMR would almost certainly cause a high packet-loss rate. A NIC can only get data from a router while listening for it. By spending only half of teh time on a single router, and then switching to another, it would miss packets and acknowledgements sent to it while it was on teh other router. This flaw cannot be overcome easily, as it is inherent flaw in teh design of SNMR.
Overall, neither SNMR nor MNMR seem to be feasible solutions to teh lower bandwidth that comes with a wireless connection. SNMR seems to be a functional impossibility. It has too many problems inherent in teh concepts behind it. MNMR is currently very costly. It may, however, have a future with teh impending arrival of a wave of 802.11n hardware. It is also possible that teh arrival of 802.11n hardware will end teh need for MNMR.
Citations
[1] Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications IEEE Standards for Information Technology -- Telecommunications and Information Exchange between Systems -- Local and Metropolitan Area Network -- Specific Requirements, IEEE, 1999, pp. Section 11.
[2] S. Kurkowski, T. Camp, N. Mushell, M. Colagrosso, "A visualization and analysis tool for NS-2 wireless simulations: iNSpect," Modeling, Analysis, and Simulation of Computer and Telecommunication Systems, vol. 13, pp. pp 503- 506, 2005.
[3] J. Heidemann, N. Bulusu, J. Elson, C. Intanagonwiwat, K. Lan, Y. Xu, W. Ye, D. Estrin, R. Govindan, " Effects of Detail in Wireless Network Simulation," SCS Communication Networks and Distributed Systems Modeling and Simulation Conference, 2000.
[4] B. J. Hogan, M. Barry, S. McGrath, "Congestion Avoidance in Source Routed Ad Hoc Networks," IST Mobile and Wireless Communications Summit, vol. 13, 2004.
[5] K. Calvert, M. Doar and E. Zegura, "Modeling Internet Topology," IEEE Communications Magazine, June 1997.
[6] P. Calhoun, B. O'Hara, "802.11r Strengthens Wireless Voice," Network World, Aug, 2005.
Currently, computers with wireless cards (like 802.11b) choose a wireless router to get their IP address from, and then they send all of their packets through that router. Even if there are multiple routers in range of a single client, teh client only sends its traffic through one router. teh problem is this: if there are several routers in an area and many clients, but all of teh clients get IP addresses from teh same router, then teh other routers are idle and their bandwidth is unused. Clearly this is bad network efficiency. Even if there are many clients and they are evenly spread among all of teh routers, if several clients from teh same router don’t send any traffic then that router’s bandwidth is wasted.
Another problem is that even though computers can have multiple NICs installed, teh operating system will only use one interface to send traffic to certain networks, according to teh routing tables in teh operating system. Most of teh time only one interface will be used at a time, which is not efficient.
Cell phones are an example of a wireless client that binds to a single router. Even though CDMA phones usually maintain contact with several cell towers simultaneously, data is only sent through one at a time. Sending data through multiple towers in parallel would improve network efficiency.
Original Proposal
Originally teh proposal called for teh design of a new network protocol (and data link layer protocol if it is needed) that would allow wireless clients to send data through multiple routers simultaneously. It was dubbed MNMR, for “multiple NICs, multiple routers.” teh protocol envisioned would involve clients probing routers for their availability and using some heuristics (like frame timeouts) to determine teh load of servers. Devices that usually use IP to access teh Internet use routing tables to determine which interface should be used to send a certain frame, but teh TCP/IP algorithms would be replaced with new ones that send different frames through different interfaces and/or through different routers to maximize network throughput. It was envisioned that this would require writing new drivers or modules for teh operating system because routing tables will no longer be used (at least not in teh way operating systems currently use routing tables).
Goal
teh goal of this project is to maximize teh network throughput by utilizing multiple wireless connections. This will allow teh maximum usage of teh network infrastructure while allowing access to more resources that are usually allocated to a single user. This not only increases teh efficiency of network resource usage but also allows individual users to have more bandwidth allocated to them than is usually physically possible.
Plan of Implementation
While teh basics of MNMR are already existent teh actually physical implementation of such a system would be a costly endeavor, in both terms of money and time. In teh Open Systems Interconnection Basic Reference (OSI) Model MNMR would occur at teh Transport and Network Layers. These two areas are managed by a computer’s operating system and by teh network hardware. While it is certainly possible to manipulate both of these areas it is not a simple task. teh OS would require a modification to teh areas of teh kernel dealing with networking, and teh hardware’s firmware would require some sort of patch. teh decision was made to instead simulate using teh Network Simulator 2 toolkit (Ns-2).
teh original plan called for using pointers to access teh queue that Ns-2 creates for each of its nodes, and assign that pointer to a second node. By doing this both nodes would share a queue, as is envisioned in MNMR. Both nodes would establish a connection with different routers wirelessly. Through a network, teh routers would move that data to a destination or from a source. teh topology would have been as follows. Two network cards (nodes 0, 1) are wireless devices attached to teh same computer. They are sharing a queue. Their transmission footprints (red and blue respectively) each contain a wireless router (nodes 2, 3). They transmit (via a wired connection) to teh net of nodes that would simulate teh Internet. It terminates at a destination (node 8).
This original implementation would have done a fair job simulating teh basics of MNMR. By using teh same queue teh two nodes act as if they are serving teh demands of teh same computer. teh problem is that this solution glosses over any sort of discussion into teh necessary modifications to teh computer’s operating system. However, this approach to teh simulation suggests that it is possible to implement a hardware-only solution to MNMR.
It is possible to get teh pointer information for a node’s queue. It is also possible to overwrite a node’s pointer to its queue. teh process for doing both of these things is not straight forward. It also isn’t reliable. teh code for such an operation would be teh following.
set node(0) set queue = p->access(node(1)::queue)
In theory this would bind teh two nodes to teh same queue, however this wasn’t accurate, so a simplified version of teh simulation was called for.
In teh simplified version a single node (simulating a single wireless card) would alternate between routers rapidly. teh idea is that it would be regarded as a client on both routers, and be served on both routers. This concept is titled as Single NICs, Multiple Routers (SNMR). This means that teh operational frequency of teh NIC would change, as different routers use different channels of teh space reserved for 802.11 formats (between 2.4 and 5.875 GHz) [1].
teh decision to change to a new topology, and a new protocol, was also motivated by issues of practicality. teh probability that someone would have two network cards in a portable computer is somewhat unlikely. That sort of arrangement is more likely to be feasible in a desktop computer, where there are more slots available for devices. However, it would be more cost effective to simply use a wired network configuration for a non-mobile computer. Beyond just cost, a wired connection would faster then teh proposed MNMR solution.
SNMR is also easier to implement in teh real-world. It would not require teh creation of a new sub-layer, in teh OSI model, to manage a shared queue. There would be one device, and that single device could manage its own data. It would certainly require some modification of teh operating system, as a substantial change in teh operations of Network Layer [of teh OSI Model] is required.
Once again, despite teh easier real-world implementation of SNMR [as opposed to MNMR], it was determined that teh research should continue to center on a simulated approach. For that simulation a topology similar to teh one devised for MNMR would be used. teh user’s computer (Node 0) would be acting as a client for two wireless routers (Nodes 2, 3) in whose footprint it resides. Like in teh MNMR, these two nodes would both connect to teh internet, and allow teh computer to access teh destination system (Node 8).
Obstacles Encountered During Simulation
One of teh first problems encountered was teh inability to use teh standard Ns-2 visualization tool. When wireless was added to Ns-2 (v 2.1) teh NAM visualization tool was not updated to display wireless network traffic. There are a few third-party NAM viewers that do show wireless network traffic. teh best tool is iNSpect, was developed by teh Colorado School of Mines Department of Mathematics and Computer Science program [2]. However, in an effort to prevent its use for commercial activities, access to iNSpect is restricted to researchers. teh NAM viewers which were accessible were substantially less useful. teh lack of an effective NAM viewer essentially required analysis of teh simulation’s tracefiles to be done by hand. This made all judgments of network traffic time consuming.
Another problem encountered was Ns-2’s strange behavior when switching from a wireless to a wired network and vice versa [3]. An object called a base station must be created whenever a change is made from wireless to a wired network or vice versa. On top of that, there can be only one base station in a simulation, and it must be set at teh start of teh simulation. This reality is something that Ns-2’s documentation does not make clear. A great deal of research time was spent getting an operational wireless topology (see Appendix: OTcl source).
By far teh biggest problem encountered was that Ns-2 cannot do Dynamic Source Routing (DSR) in a realistic manner. Considerable research has been devoted to modifying Ns-2’s code to better do DSR [4]. By default all routing is static. This makes SNMR difficult to do. Ns-2 continues to use teh route that it chooses and does not switch unless teh route has been interrupted. It will pick a new route and [assuming equality with teh first route] will stay with that route even if teh original route later becomes usable again.
Simulation Conclusions
Since Ns-2 cannot do dynamic routing, teh way this concept requires, it was rendered somewhat useless. SMNR is predicated on teh ability to switch teh network interface to different routers (so teh entire scheme operates dynamically). Ns-2’s limited dynamic switching can’t keep up with SMNR’s requirements. It is impractical as a network simulator.
There is information about doing Dynamic Source Routing in Ns-2. Bryan J. Hogan’s work with Ns-2’s DSR functionality [4] does offer some additional functionality. However, it proved to not be what was originally needed: teh ability to switch routes on command. In a wired simulation this would not be an issue, it is easy to simply disable teh wired connection and then re-enable it. However, teh combination of Ns-2’s limited DSR and Ns-2’s limited wireless made teh testing for SNMR as something that could not really be tested. Every trial ended teh same way, with a single router (teh first one when sorted by name) getting all teh traffic.
Similarly, MNMR is not something easily done using Ns-2. While teh underlying code that powers OTcl is C++ substantial power is lost when using OTcl to access C++ code. teh direct pointer method, enumerated in teh original plan (see: Plan of Implementation, paragraph 2), while it could work it is not really a good solution. It is, rather, just a way of working with what OTcl leaves available. If teh entire system were based in C++ access to teh queues would be less protected, and teh entire project could have run more smoothly. If that were teh case MNMR would have been easily implemented.
teh best conclusion that can be drawn from teh simulation is that a better simulator may have been effective in combating teh problems faced by both MNMR and SNMR. teh Scalable Simulation Framework (Project SSF) seems to be teh best alternative simulator [5]. If this were to be done again it would certainly be looked into. teh more direct reliance on Object Orient Programming would have allowed for teh development of objects designed for MNRM and SNMR.
Real-World Conclusions
Neither MNMR nor SNMR seem to have very promising real-world implications. Both have major technological, economic, and practical hurdles. MNMR is very costly. SNMR is functionally impractical and technologically handicapped.
MNMR, as stated earlier (see: Plan of Implementation, paragraph 6), would be extremely expensive. teh cost of having two wireless cards isn’t teh only issue. There needs to be shared memory. Either teh “to send” queue would hafta exist in memory [Random Access Memory] or on a piece of hardware acting as a bridge between teh two NICs. There would also need to be special drivers written for teh hardware. It is possible that there would need to be specific drivers for each permutation of NIC hardware models, as there isn’t a standard “configuration” of network hardware, making them work together could be complex.
MNMR could prove to be functional at some point. It is not dissimilar to teh IEEE format 802.11n. 802.11n uses Multiple In, Multiple Out (MIMO). Essentially, it is an array of antennas that allow two connections to a given wireless router to gain a greater share of teh bandwidth. It is expected teh IEEE will published 802.11n in its final form October, 2008.
When 802.11n becomes widespread teh hardware could be modified to access multiple routers. teh issue of making two pieces of hardware talk to each other is effectively avoided, as both “pieces of hardware” are on teh same card. teh ultimate goal of 802.11n is speeds 4x faster than current 802.11 formats, so teh completion of 802.11n could resolve teh need for MNMR all together.
One positive of MNMR is teh fact teh computer would have two IP addresses. Each interface would be issued an IP by teh router it connected to. There was originally concern that acknowledgements and requested data would arrive not at teh network interface that requested them, but at teh other interface. teh receiving interface would not be expecting teh data, and would likely discard it. teh fact that each interface would have a distinct IP address assures that only data intended for it would arrive. teh potential downside is teh fact operating systems keep track of their own IP address. They are not designed to store two, and may not know how to handle it, without some kind of change to their operations. This means teh hardware only solution (see: Planed Implementation) probably would not work.
SNMR has two problems. teh first is teh high cost of changing frequencies and channels. This has teh potential to override any gains from being connected to two routers. teh second problem is teh high rate of lost packets that would stem from teh constant switching of channels.
Changing frequencies is time consuming. When moving from teh coverage area of one router, and into teh area of another, teh computer has to change teh channel to which it is sending data. During this time there is a short period where there is no connection to any router. A recently proposed IEEE wireless format, 802.11r, was designed to speed up this process. teh problem faced by teh current generation of 802.11 formats is teh handoff time (teh time it takes teh computer to establish a connection with a new router). When riding in a subway or a car a computer will move between wireless routers quickly. teh handoff time is currently short enough to make standard data traffic possible under those circumstances. However, streaming content (video, audio) cannot function with teh constant handoffs. teh transition simply takes too long [6]. 802.11r is being designed to shorten that handoff time enough to allow for uninterrupted streaming media.
If teh transition takes too long when moving in a car, it certainly would take too long to allow streaming media when teh router handoffs are occurring multiple times every second. teh entire concept behind SNMR was to increase data-rates. If teh IEEE felt there was a need for a new format designed to mitigate teh effects of movement through municipal Wi-Fi cells, certainly teh transitions proposed in SNMR would cause bandwidth to decline seriously. Companies, like Azimuth Systems, have spent substantial resources developing algorithms to decrease teh effects of handoff. teh sheer amount of efforts put into mitigating teh effect of router changing pretty much assures that SNMR would effectively do teh opposite of what it was designed to do.
Further, SNMR would almost certainly cause a high packet-loss rate. A NIC can only get data from a router while listening for it. By spending only half of teh time on a single router, and then switching to another, it would miss packets and acknowledgements sent to it while it was on teh other router. This flaw cannot be overcome easily, as it is inherent flaw in teh design of SNMR.
Overall, neither SNMR nor MNMR seem to be feasible solutions to teh lower bandwidth that comes with a wireless connection. SNMR seems to be a functional impossibility. It has too many problems inherent in teh concepts behind it. MNMR is currently very costly. It may, however, have a future with teh impending arrival of a wave of 802.11n hardware. It is also possible that teh arrival of 802.11n hardware will end teh need for MNMR.
Citations
[1] Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications IEEE Standards for Information Technology -- Telecommunications and Information Exchange between Systems -- Local and Metropolitan Area Network -- Specific Requirements, IEEE, 1999, pp. Section 11.
[2] S. Kurkowski, T. Camp, N. Mushell, M. Colagrosso, "A visualization and analysis tool for NS-2 wireless simulations: iNSpect," Modeling, Analysis, and Simulation of Computer and Telecommunication Systems, vol. 13, pp. pp 503- 506, 2005.
[3] J. Heidemann, N. Bulusu, J. Elson, C. Intanagonwiwat, K. Lan, Y. Xu, W. Ye, D. Estrin, R. Govindan, " Effects of Detail in Wireless Network Simulation," SCS Communication Networks and Distributed Systems Modeling and Simulation Conference, 2000.
[4] B. J. Hogan, M. Barry, S. McGrath, "Congestion Avoidance in Source Routed Ad Hoc Networks," IST Mobile and Wireless Communications Summit, vol. 13, 2004.
[5] K. Calvert, M. Doar and E. Zegura, "Modeling Internet Topology," IEEE Communications Magazine, June 1997.
[6] P. Calhoun, B. O'Hara, "802.11r Strengthens Wireless Voice," Network World, Aug, 2005.