Our approach, on the other hand, is gateway-centric (see figure). In the gateway-centric view, the subnet-to-subnet gateways are placed at the center of the architecture. Diverse wireless (and wired) networks are integrated through software that mediates between the mobile and the networks it could possibly connect to, supporting the mobile as it roams among the multiple wireless networks. The figure shows specific instances of commercially available wireless networks we are supporting in our gateway-centric architecture; those in black are networks provided by companies we are working with, those in gray are other networks of interest. These other networks, such as the militarily important multihop packet radio networks and the emerging multiple satellite systems (MSSs) scheduled for deployment in the latter part of this decade, are being considered during the design of the wireless overlay internetworking architecture.
The figure also introduces the important concept of cooperative wireless overlay networks. Most wireless networks, deployed by competing service providers (or in the military context, by somewhat distrusting coalition "allies"), provide little controllability above the subnet for routing, network management, or applications support purposes. We call such networks black pipes, because packets transfer between the wireline gateway at one end and a wireless link to/from the mobile at the other with no control over routing, priority, quality of service, etc. Cooperative networks, on the other hand, provide greater visibility of the network control functions to the gateway as well as application-level software, enabling management software to balance the network load among the cooperating networks or to choose a particular subnetwork for priority applications, etc. We intend to demonstrate cooperative interplay among in-building networks, and by showing the effectiveness of the approach, to influence future capabilities in wide-area wireless data networks still being designed.
Consider a mobile host receiving a continuous media packet stream while moving through a building. Its path is constrained by the building's physical layout. The figure shows a floor of a typical building, covered by four RF cells. It is not possible to traverse directly from Cell A to C. Knowledge of cell adjacency and likely routes enables "soft handoff." Packets routed to the mobile in cell A is multicast to the cells it can reach, i.e., B and D. As the mobile comes within range of one of these, the network chooses when to shift the routes from A to the new cell. The new basestation will have already been "precharged" with the packet stream. See figure. At the modest expense of additional buffering, backbone network bandwidth, and inter-basestation control communications, the network control is given flexibility in choosing when to handoff.
The tracking and handoff control processes run on processors in the backbone network and potentially cover multiple cells. To reduce the processing load, these could be allocated to highly interconnected "regions" of the building, such as a single corridor and adjacent offices, chosen so that inter-regional handoffs are significantly less frequent than intra-region handoffs. One could statically assign a tracking/handoff process per floor, with multiple processes allocated to different backend processors for those floors with particularly high traffic areas (e.g., conference rooms, classrooms). More generally, we are developing load balancing algorithms for network management that allocate processing resources based on the network's dynamic traffic patterns. For example, the algorithms will provide more processing cycles to manage handoff at the entrance and egress areas of the building at the beginning and end of the day, the classrooms in the morning, and the seminar/meeting rooms in the afternoon. These algorithms will be extensible, accommodating new users and cell sites dynamically, without requiring global reconfiguration.
When moving between overlays, registration and authentication latencies can be considerable. This can be reduced if they are cached, for a limited time set by policy, within the subnet gateways, this reducing multiple, high latency authentications back to mobile's home system.
For in-building networks, we will selectively violate strict network layering to expose information from below the network layer to higher level overlay management software. The will allow wireless subnets to cooperate in order to reduce vertical handoff latency as well as to better share connectivity and network loading between alternative overlays. Our cooperative overlays will be formed from independent in-building IR and RF physical networks. They will be treated as logically independent networks that can only be integrated through overlay management.
Consider a group of mobile users in a meeting room. The in-room IR network provides the preferred connectivity. But if its bandwidth becomes oversubscribed, resulting in poor service to the mobile hosts in the room, some hosts can be forced to handover to the RF network. Furthermore, since the overlays are cooperating, new connections can be set up in the RF overlay in advance of actual handoff, thereby ensuring that the handoff is executed with low latency. Several management mechanisms are possible. The IR network could refuse new connections to mobiles in the high density area, generating mobile-initiated handover to the RF network. Or the IR network management algorithms could "request" assistance from higher level management layers, with a more global view of the condition of the subnets under its control. Certain mobiles could then be selected for overlay handoff based on their current network performance needs.
For "black pipe" networks with no performance guarantees, it is still desirable to attempt to characterize end-to-end network performance. The network management layer will cooperate with the mobile hosts to inject periodic measurement packets into the subnet to characterize the route's latency and variability. This source-based rate control mechanism will be used by the application support layers in the mobile device to determine how aggressively it can pursue buffering, prefetching, and compression strategies. Wireless spectrum is far from "free," so readahead should be applied only when the application can expect a high hit rate in cached data.
Connection-oriented TCP performance can also be improved for wireless links. The standard protocol interprets lost packets as congestion, employing mechanisms that unnecessarily decrease the rate of transmission. Our approach caches the unacknowledged TCP packets in the basestation while performing aggressive local retransmissions over the wireless link and managing duplicate acknowledgements from the mobile host [Balakrishnan 95]. It requires no changes to TCP's semantics nor to any implementations of TCP in the wireline portion of the network, except at basestations under our control.