Copyright 1997 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.

The term wireless ATM seems to some degree an oxymoron. This is because today's wireless technology is mainly used for voice and low-speed (a few kilobits per second) data transmissions, whereas ATM (asynchronous transfer mode) is often associated with the transmission of multimegabit-per-second real-time multimedia data such as video. However, with more and more computing devices becoming portable and lightweight in design and at the same time equipped with multimedia processing capability, it is no wonder that considerable interest has begun to focus on the possibility of providing ATM access using wireless technology. From the market point of view, having a breakthrough technology like wireless ATM could accelerate the rapid market penetration of cellular phones and laptop PCs seen in the last few years. From the technology standpoint, the amount of research work reported recently in high-speed wireless technologies [1, 2], and the number of submissions to the ATM Forum [3] by major vendors have been extremely encouraging. All these factors indicate a good prospect of having commercialized wireless ATM in the near future.
So far most of the proposals seen in wireless ATM are for this technology to be integrated into the wired portion of the ATM network by adding the necessary hardware, as shown in Fig. 1, so that such a network will have both wired and wireless hosts connected to it. Furthermore, most of these proposals also call for seamless integration of ATM access from the application point of view; which means that ATM virtual channel (VC) connections are available to both the wired and wireless hosts. Thus, the difference from the host standpoint is in terms of the means of physical access and additional software components to handle the mobility of wireless hosts as they move from one wireless access point (AP) to another. From the overall VC connection management point of view, however, mobility means that extra signaling and location management capabilities must be provided to enable new VCs to be set up in the new location and old ones torn down whenever a wireless host moves within the network.
Another consideration is that a typical ATM network such as that shown in Fig. 1 should support different scales of mobility, sometimes referred to as roaming and handover, which correspond to large- or small-scale user movement, respectively. Support roaming means a user is allowed to travel to another network domain and attach his host to the network at the foreign location, whereas support handover means that the connections should be maintained when a user moves from one wireless AP or "cell" coverage area to another. It should therefore be made clear that mobility does not always have to involve a wireless (i.e., radio) setting. However, it is the intention of the work described here to concentrate on addressing mobility in a wireless setting. Such a solution should also be easily applicable to roaming mobility in a wired environment.
In this article we shall focus on proposing an integrated connection management solution for this purpose. To date, most of the components described in this article have been implemented in an in-house ATM network with fixed hosts consisting of multivendor switches. The wireless ATM part is currently being designed and developed by a team of researchers. When completed, it will be tested with the solution described here and the overall performance measured empirically. This work is based on the following key ideas.

Open Signaling

The work here adopts the open signaling approach (herewith referred to as opensig) first proposed by the Center for Telecommunication Research (CTR), Columbia University [4]. The basic concepts of opensig can be summarized as the use of programmable software architecture for network controls, while the originators of opensig have focused mainly on the issues of modeling network resources [4]. This idea is extended here in network connection services. The proposed solution therefore calls for the establishment of a signaling network that offers multicast connection management service.

Multicast as the Basis of All Connections

Another significant idea demonstrated by the work described here is to advocate the support of multicasting and the use of multicast connections as the basis for all ATM connections, including those unicast (one-to-one) connections which are treated as two-member groups. The consistent treatment of connections has the desirable impact of simplifying the semantics of connections and service flexibility.

Dynamic Logical Multicast Grouping for the Support of Host Mobility

Unlike the conventional unicast or one-to-one connection concept, which often needs the parties involved to specify the exact physical location of one another for a connection to be made, multicast groups are a logical concept with dynamic memberships. What this means is that member mobility can be supported naturally.

The Proposed Design

Figure 2 depicts an implementation of the proposed multicast service architecture in a small ATM network consisting of several multivendor switches. Components of the architecture include the multicast service agent (MSA), the host-end signaling interface called the service binding agent (SBA), and the switch-end signaling agent called the virtual switch (VirSwt). The way these components work is according to the following sequence. To join the group, an application (e.g., a videoconferencing application on a host) will first request to join the specific multicast group as either a sender, receiver, or both, by notifying the MSA through the SBA. The MSA, through its subagents (Fig. 2), will be responsible for adding the host to the multicast group and working out a suitable VC route before returning the assigned VC identifier(s) to the requesting host via the SBA. Similar sequence also applies to the group member leaving operation.
A prototype of the proposed multicast service over a group of six in-house ATM switches supplied by three leading vendors has been implemented. These switches are connected to both UNIX workstations (at 155 Mb/s, OC-3 multimode fiber) and PCs (at 25 Mb/s, UTP-5). It has been successfully tested on the setup of both multicast and one-to-one connections, as well as running video and audio applications over these connections. In the near future this will also include the wireless ATM components shown in Fig. 2. In the rest of this section, the various components of the proposed ATM multicast service are presented. The reader is also referred to [5, 6] for a more detailed description of the proposed design.

Host-End Interface -- Service Binding Agent

As described above, the SBA acts as the interface between the host and MSA for the purpose of accessing the multicast service. Given the goal of supporting various properties, similar to that of IP multicast, the SBA supports a programmatic interface similar to that of the Internet's Resource Reservation Protocol (RSVP) [7].
The way SBA is realized is clearly dependent on the intended platform and environment. For example, the SBA can be realized as a set of library calls which can be linked into a brand new networking application or run as a special program in an operating system to provide ATM multicast access. In our case, a version of an SBA was implemented as a World Wide Web Hypertext Markup Language (HTML) page.

Switch-End Interface -- Virtual Switch

In this section, we concentrate on the software that is added to operate alongside the ATM switches in order to provide the necessary multicast service. As shown in Fig. 2, the approach involves adding a software component called a virtual switch (VirSwt) in a host attached to each of the switches. This software provides a common interface to switch functions such as setting up and tearing down VCs, as well as modifying the quality of service (QoS) parameters associated with each VC. It is important to note that since different switch vendors have designed their switch interfaces differently, to perform the above switch-related functions on these various switches requires an appropriate switch-dependent code. Examples of these access mechanisms are via the switch-supplied serial-line (RS-232) management software; the Simple Network Management Protocol (SNMP), and, more recently, the General Switch Management Protocol (GSMP). VirSwts communicate directly with the MSA via the available communication channel (e.g., Ethernet interface) between them. Other than providing a common interface for MSA to perform VC-related operations, VirSwts also support and handle the functions of multicast data filtering and merging which are described in the next section.
Virtual Switch -- One of the biggest problems with ATM multicast support is that the native ATM hardware is designed to do just one thing well: forward cells in an inexpensive way. Currently there are no hardware supports for cell-level filtering; nor is there the ability to merge multiple VCs into one VC (i.e., many-to-one) which is essential for the proposed design to provide heterogeneous receiver-QoS multicast and merging of multicast data streams. To achieve these, a software solution is added to VirSwts. Conceptually one can view the use of VirSwts as giving the applications the ability to request application-oriented QoS parameters from the network, meaning that the parameters must be transferable to the application through the upper-layer protocols. This involves a negotiation process which has two phases: advertising and selection. The sender advertises the multicast data description in the advertising phase. Assuming ₀ is the multicast data source from the source, a set of new data ₁, ..., _m can be derived from ₀ by applying the user programs one or more times. The set of all possible user programs associated with ₀ can be expressed by = {₀, ₁, ..., _s}. Then we define a set of all the possible data sources as … = {₀, ₁, ..., _m}, where

such that _i = _k(_j). Therefore, the contents of an advertisement message consist of a formula list for each _i where _i = ¹ • ² • • • ^k(_j) and the ¹, ², ..., ^k . could be a small set of programs that includes filtering and merging algorithms. Users can select a sequence of these programs and invoke them from the VirSwts to process their data streams. In actual operation, the advertisement messages are first sent to all the receivers in the specified group. In the selection phase, each receiver selects the desired data streams according to the preference and capability of the user devices.

Multicast Service Agent (MSA)

In this section details of the various MSA components, first shown in Fig. 2, are described. Each MSA is expected to perform four functions: resource management, group management, routing, and physical connection management. For clarity, we will be describing each of these functions as independent "agents"; this does not, however, represent the way they are realized in the actual implementation. It is important to note that an MSA is expected to provide the proposed connection service to a specific group of switches/hosts (called "domain"); multiple MSAs will be required and deployed in a distributed fashion in a large network, which is described separately later.

Resource Management Agent (RMA)

The RMA of a network domain uses a link state database (LSD) to manage the network resources and provide connectivity information for routing computation. The physical link of a network domain is uniquely identified by the combination of the link's node identifier (ID) and a locally assigned port ID. For example, if the node is a switch, the switch-assigned ATM address is used as the node ID; for a host, it may be the host ID. The RMA manages each link in terms of link capacity, which includes the total available bandwidth, total available virtual path (VP)/VC ID (VPI/VCI) pairs, and the propagation delay on the link. In order to coexist with the standard signaling protocols, the RMA defines and utilizes a subset of the available VPI/VCI space on a link (e.g., space reserved for permanent virtual channels, PVCs).
RMA therefore manages the resource allocation for the connection setup requests from any host of its network "domain" with its LSD, and reflects accurately the available resource pattern in the network domain managed by its MSA. The link state information can be used to calculate the expected call admission behavior at each switch in the network domain. Whenever a resource query or connection request is received by the RMA, it performs a call admission control (CAC) function based on the traffic parameters and requested QoS of the connection. The RMA determines whether setting up the new connection violates the QoS guarantee of existing connections in the network domain.
The LSD also records the current connectivity information of the network domain. Therefore, the current network topology can be derived based on the connectivity information of the LSD. The topology of a network can be expressed by a connectivity matrix that varies according to the QoS requirement of a connection request. All the links that cannot satisfy the requested QoS are pruned from the set of all possible paths for the connection. With this reduced set of links, the routing algorithm can compute the shortest paths for any connection request in a network domain.

The Group Management Agent

The GMA provides an important function of the multicast service by managing the membership status and member join and leave activities. GMA keeps a database of multicast group names and the corresponding physical addresses of the existing group members (see later), so whenever a group operation is being performed, the relevant group information can be looked up or updated accordingly. Other information kept by GMA includes the terms of QoS parameters need to be guaranteed during the data transmission and the user specified filters at each VirSwt.
In a network where multiple MSA domains exist, a group management protocol is required to allow the respective GMAs to exchange individual domain group membership information. One significant observation made when designing GMA is that it also provides the location management function needed in a mobile environment. A process often referred to as location registration is carried out whenever a host moves from one location to a new one. This is so that the mobile host can subsequently be located and reached by the connection service. It is observed that the same function is provided in GMA whenever a host "leaves" a group but "joins" it again at a new physical location, leading to the conclusion that the proposed design can be made to handle mobile hosts with little or no change. With this intention in mind, a suitable group naming and host addressing scheme should therefore be proposed to ensure that GMA also plays the role of location manager. This is described next.
Host Addressing Scheme and Multicast Group Naming -- Any signaling protocol requires an addressing scheme to allow the signaling or routing protocols to locate the source and destinations of a connection. Most current host addressing schemes have dual natures such that an address not only identifies the name but also specifies the location of a host in the network. This type of addressing scheme is generally location-sensitive in that the exact location of a host is embedded in its address. In a mobile environment, the association of a mobile host name with a location is transient and should therefore be treated separately. In the proposed design, a name is an identifier of a host and is assigned for its lifetime, while the physical address indicates the current location of a host and is bound to a host temporarily. When a host is attached to the network the association of a host name and the physical address is registered with the GMA. Any connection setup call uses only the name of the destination host; the GMA is responsible for finding out the corresponding physical location. This is reasonable in a mobile network because the calling party need know only the name of the called party, and the actual physical address of the called party is resolved by the "network."
Furthermore, besides using individual host names as the group identifiers as described above when creating a multicast connection, other location-independent logical names can also be used to name a group. To facilitate multiple multicast groups in a host, a logical "session identifier" equivalent to the Internet Protocol (IP) port number should also be added to the group identifier. In summary, this section outlines the various considerations of a suitable group naming and host addressing scheme; the exact format, management, and assignment of the addressing scheme is beyond the scope of this article.

The Routing Agent

The RA computes a multicast tree that connects the source and destinations by using the link state information in the RMA, and the group membership information and negotiated agreement in the GMA. It also offers routing options to the receivers that may emphasize different factors of data transmission, such as reliability, real time, or cost effective paths. When the RA computes the multicast tree, it selects the strategic switches to invoke user-specified programs such as filters. The results of the RA are contracts for the (virtual) switches involved in the computed multicast tree.
QoS-Based Routing -- The network can be modeled as a graph of nodes connected by node-to-node links. Each link has the parameters maximum cell transfer delay (MCTD) and residual cell rate (RCR). These values are known to the routing algorithm and we use t, b to represent MCTD, RCR in the distance function. A simplified distance function d_ij reflects transfer delay t_ij, residual bandwidth b_ij is defined empirically for each direct link l_ij: d_ij(t_ij, b_ij) = ₁t_ij + ₂(1/b_ij)^a,where l_ij denotes the link from node i to node j. The exponential form of the residual bandwidth term compared with the transfer delay term's linear form shows the emphasis on bandwidth-exhaustive as a much more important factor affecting the distance function. The ₁, ₂ are weights of the two factors that can be changed by the users in the negotiation phase. Increasing the weight of a factor may change the emphasis of the routing algorithm. For instance, if a receiver wants to receive a real time data stream, it can increase the value of ₁ that leads to the routing algorithm placing more emphasis on the propagation delay during routing computation.
By using the Dijkstra algorithm, the shortest path from the source node to the destination nodes can be computed. If the paths leading to different receivers travel along the same link, they need to be merged into a single path. After all the common paths are merged, a multicast tree can be established. In the merging process, QoS reservations for different receivers need to be aggregated to form a resource reserved multicast tree. As a result, only the essential (i.e., minimum superset) common QoS is reserved on a link for a common path. A filter can be assigned with each outgoing path that is split from the common link to facilitate the selective data transmission. These filters select the requested data set for the specified receivers according to their QoS requests. Therefore, a logical multicast tree with various QoS reservations on different branches can be established. Note that all the actions described above, such as routing computation, resource reservation, and filter placement, are performed in the memory of the RA (i.e., we only have a logical multicast tree at this stage). Subsequently, the logical multicast tree will be converted into separate contracts for all the involved (virtual) switches to interpret and implement.
A Node Joining/Leaving a Multicast Tree -- A new member can join an existing multicast group through a join operation. In the operation, a one-to-one route is first computed from the source to the joining node by the RA based on the QoS request. Then the joining algorithm will try to merge this new route to the existing multicast tree. It first traces the new route from the joining node toward the source until it hits the first intermediate node of the existing multicast tree that has sufficient resources to meet the QoS requirements of the new joining node. This intermediate node is selected as the merging point for the remaining links to the source. In the worst case, the merging point is the source. Figure 3 shows an example of node R4 join on an existing multicast tree in which sender S is sending a data stream to receivers R1, R2, and R3 via a switch network involving Sw1, Sw2, Sw3, and Sw4. The one-to-one route from sender S to receiver R4 is indicated by the dashed lines. The merging point for the joining node is in Sw2. The one-to-one route from S to R4 has common paths with the existing multicast tree at link Sw1–Sw2 and S–Sw1. These common paths need to be merged with existing connections.
The leave operation removes the leaving node from all multicast trees currently sending data to it. As in the joining algorithm, the node is disconnected from each multicast tree separately. For instance, receiver R4 wants to leave the multicast tree in Fig. 3. The leaving algorithm traces the path from R4 toward source S. The tracing process will terminate at the switch where there exist connections with other group members in the same multicast session. In our example, the tracing process will terminate at Sw2 (i.e., the merging point). The leaving algorithm requests all the switches on the path from the merging point to the leaving node to release resources reserved for the leaving member. In our example, connections Sw2–Sw5 and Sw5–R4 will be released.

Connection Agent (CA)

Once routing contract for each switch is worked out, the CA is invoked to implement the actual multicast tree setup by sending the routing contracts into the designated switches via the links from the MSA to the switches. A multicast channel in a switch is thought to have one incoming VC and multiple outgoing VCs. The routing contract uses the inPort and outPort to specify the switch to be connected to the incoming VPI/VCI and the switches to be connected to the outgoing VPI/VCI. When switches (via VirSwts) receive their routing contracts, each can start to set up the upstream and downstream connections to establish the corresponding VPI/VCIs. The signaling of the switches for establishing upstream and downstream connections is a parallel process in which each switch works on its own contract independently. When the switches complete the contracts designated to them, response messages are sent back to the CA to confirm the success of the connection setup. The CA forwards the response message to the caller after it receives the responses from all the involved switches. Thus, the switches, sender, and receivers can be bound into one multicast session.

Wireless Host Mobility

Whenever a host moves among the APs of a wireless ATM network, a handover process takes place when the host decides to switch to communicate with a new AP from its existing AP as a result of its AP signal "evaluation metric," which can include criteria like signal strength and bit error rate. For a wireless ATM network, the handover process involves two steps: handover at the VC level and at the wireless or radio frequency (RF) level. Wireless handover involves the underlying hardware switching to the new AP's frequency and establishing a communication channel with it. This process is relatively simple and fast compared with VC-level handover, where new VCs have to be routed, negotiated, and set up, and the old VCs deleted. In this section, we shall focus on the procedures of VC-level handover from the point of view of the proposed connection management solution.
Up to now we have described a multicast connection management solution for a wired ATM network. We shall now focus on how the same solution can also work on networks supporting wireless ATM host access, as shown in Fig. 2. As described in various places the proposed solution, though designed mainly to realize multicast service, has many features that are suitable for supporting host mobility in the wireless setting. These are summarized here. First, by using a logical multicast group identifier to associate any connection, hosts can move and be connected freely anywhere in the network. Second, the leaf-initiated connection request supported via the SBA for both the sender and receiver ends allows maximum flexibility for each party to move independent of each other. More important (though not elaborated previously), the SBA can further support the concept of "advance-join," which allows join connection requests on a new location to be initiated in advance. Using this feature in the mobile environment, a mobile host is able to request in advance that a new connection be negotiated and set up in its next location before the lower-layer wireless handover takes place. Finally, the multicast group management that allows for multicast group members of the same group to discover each other fits nicely in the role of location management in a mobile environment.

VC-Level Handover

Whenever a handover is to take place, the proposed scheme involves first setting up one or more new multicast branches at the new AP based on the existing connections. Once the new connections have been negotiated and set up, a VC-level handover can take place by the hosts "leaving" the old connections, which will result these connections being deleted. This action is followed immediately by a wireless-level handover which will allow the new connections to become active and communications to resume. To help understand this better, below is a simple example of setting up a point-to-point connection between two mobile hosts followed by the subsequent movement of one of them which involves a handover. The reader should have no problem constructing a more complex multicast example using the information provided here.
To begin, each host will register (i.e., power up, determine the strongest AP signal) via its mobile version of the SBA (called the mobile service binding agent, MSBA) with its MSA by issuing a join (or create) operation to a logical group name which also identifies itself uniquely. Each MSA will in turn distribute this information to the other MSAs on the network via the group management agent (GMA). Whenever a connection is to be made from one host to another, the logical group name of the called part, as well as the logical name of the calling party will be made known to their respective MSAs. Other information to be supplied to the MSA via the MSBA includes the current physical location of the host and required QoS parameters. As soon as a suitable route is determined by the routing function, a physical VC will be set up to connect the two parties; as soon as the connection is made, the respective MSBAs will be notified and data can flow. Let us now further assume that one of the two hosts has been moving, and that a stronger signal "beacon" is detected by the wireless physical layer and triggers a handover. This handover information together with the address of the new wireless AP will be made known to the MSBA of the host in question via the wireless layer. Once received, the MSBA will initiate an advance-join request on the new AP. The result of this is that new multicast route(s) will be negotiated from the crossover switch to the new AP by the multicast member joining algorithm. Assuming that the new VC can be set up, the requesting MSBA will be notified, which in turn will initiate a lower-layer wireless handover via the MSBA.
From the preceding discussion, a component that is different between a fixed host and a wireless mobile host in the proposed design is the wireless mobile version of the SBA (MSBA). To begin, the MSBA will have an interface to the underlying RF layers. An MSBA performs all the functions of a SBA, but in addition it has an interface (wireless control channel) to the underlying air interface so that it can be told to initiate a handover as and when the conditions are satisfied. Furthermore, it should also be able to inform the air interface of the outcome of the higher-level handover and allow the air interface to take appropriate actions such as to switch over to the new AP. Similarly, the MSBA should also be notified when the wireless handover has been completed.

Scaling Up to Large Networks with Multiple MSAs

One-to-One Connection Setup

The growth in ATM users demands an increasing number of ATM switches to be interconnected to support a large number of ATM hosts. The current MSA was initially designed for a small ATM network with a few dozen nodes [5]. As the number of nodes continues to increase, the size of the databases in the MSA and the intensity of service requests to the MSA will continue to grow. To scale up for the future ATM Internet comprising a larger number of switches, the network needs to be partitioned into multiple domains. This is mainly because a single MSA will become a bottleneck when there are large amounts of connection requests. In addition, routing algorithms will also become inefficient when the number of nodes is large. An ATM network can be partitioned into nonintersection domains, and each assigned an MSA to handle all the connection requests within the domain; hence, we call it the domain MSA (D-MSA) in large ATM networks. The D-MSA not only processes all the required routing and connection setup activities, but also floods the summarized reachability information of its domain to all D-MSAs in other network domains. The reachability information includes the propagation delay and available resource information between each pair of border nodes in the same domain. Summarizing reachability information of the border nodes hides the internal connectivity information from other D-MSAs. With a flooding mechanism, each D-MSA can obtain detailed topological and link state information of its own domain plus the summarized topological and link state information of all other domains.
Once the link state information is obtained by all D-MSAs, they can use this information to compute routes for connection requests. In a mobility-enabled network, the actual location of a host is determined by the current attachment which is not traced by the D-MSA at the calling party's domain. Therefore, two phases are required for setting up a connection in our approach: The first phase is to discover the current location of a host, the second to set up the connections. For setting up a connection, the requests are always sent to the D-MSA of the caller's domain. When a caller's D-MSA receives a connection request with the names {caller, callee}, it checks the name of the callee in the GMA to examine whether it is in the same domain as the caller. If both the caller and the callee are in the same domain, the caller's D-MSA can handle the request with the intradomain routing and connection setup procedure, as described earlier. Otherwise, the caller's D-MSA multicasts a setup message to all other D-MSAs in the network. This message is extended to include the distance information from the caller to each border node in the caller domain. This distance information can be used for the D-MSA at the callee's domain to perform "destination" routing computation.
One of the most important routing issues is to find the shortest path from the source to the destination. In most source-based hierarchical routing protocols, the source router or switch normally has the detailed topological information of its own domain and the summarized information of other domains. The nonoptimal path problem arises when the source does not know the detailed topology of the destination domain. The reason is that the shortest paths from a source to different hosts in another domain may not necessarily travel to the same border node at the destination domain.
To solve the suboptimal route problem, we propose to use a "destination" routing scheme in which the D-MSA at the destination domain is responsible for setting up the connection from the source to the destination. The process for setting up a connection has two phases: host discovery and connection setup. The procedures of the two phases are described as follows.

The Host Discovery Phase Has Four Steps --
1A connection request is sent to the D-MSA of the source domain.
2The source D-MSA looks for the destination host in the GMA of the source domain. If the source and destination are in the same domain, the D-MSA of the source is responsible for setting up the connection by using intradomain routing and the connection setup protocol described earlier. Otherwise, go to step 3.
3The D-MSA sends an extended connection setup(S, D) message to all the D-MSAs in the network. The S and D stand for source and destination, respectively. The setup(S, D) message has the distance information from the source to each border node in the source domain.
4When the setup(S, D) message reaches the destination domain, the D-MSA at the destination domain obtains the distance information from the source host to the border nodes at the source domain, the detailed topology information of its own domain, and the summarized distance information of the intermediate domains. With all the information mentioned above, the destination D-MSA is able to compute a shortest path from the source to the destination.

The Connection Setup Phase Has Four Steps --
1The D-MSA of the destination domain computes the shortest path (SP) from the source to the destination by using the Dijkstra algorithm and constructs a set of routing contracts for each D-MSA in the domains the SP traverses. Each routing contract specifies the requirements for setting up the partial paths within the involved domains.
2The D-MSA of the destination domain sends the set of routing contracts to all the D-MSAs of the domains over which the SP traverses; the message is setup(contract). The contracts are encapsulated into a signaling packet, and the packet is transmitted from the destination D-MSA to the source D-MSA along the signaling path that connects all the involved D-MSAs in the domains the SP crosses. Each D-MSA takes the contract designated for its own domain and forwards the rest to its upstream D-MSA.
3Upon receiving the routing contracts:
* The D-MSA of the destination domain sets up the connection from the border node to the destination host and sets up the interdomain connection to the border node of its upstream domain on the SP.
* All the intermediate D-MSAs set up partial paths from the upstream border node to the downstream border node on the SP in their domains. They also set up subpaths from the downstream border nodes at their upstream domains to the upstream border node at their own domains.
* The source D-MSA is responsible for setting up connections from the source host to the border node on the SP at the source domain.
4A response message is sent from the destination D-MSA just after the setup(contract) message. The response message travels along the same route as the setup(contract) message. The function of the response message is to wait for each D-MSA to complete the tasks specified in the contract. When the response message reaches the source D-MSA, it will be forwarded to the source host to confirm the success of the connection setup.
Figure 5 is an interactive diagram which shows an example of setting up a connection from host a to host b in the network depicted by Fig. 4.

Multicast Connection Setup

The procedure for setting up multicast connections is similar to the one-to-one connection setup case. A multicast session consists of one data source and a number of receivers that form a group. Each multicast session is assigned a network-wide unique connection identifier. When a data source requests to send data to a group, the source D-MSA assigns a new connection_id to the multicast session. The source D-MSA multicasts a setup message to all the D-MSAs in the network. This setup message contains the group name and the unique connection_id. After receiving the setup message, each D-MSA looks up the GMA for the group members. If there are group members in its domain, the D-MSA performs a "destination" routing and connection setup procedure separately for each group member. When any intermediate D-MSA receives a setup contract message for its domain, it compares the connection_id of the new connection with the connection_id of the existing connections node by node from the downstream border node to the upstream border node in its domain. If the new connection_id is the same as an existing connection_id, and the upstream border nodes for the new connection coincide with the existing connection of the same connection_id, this D-MSA attempts to identify the common node for the two connections. The paths of the two connections can be merged from the common node to the upstream common border node such that only one upstream subpath is used for the common path of the two connections. If all the involved D-MSAs detect common nodes for the new connections and merge subpaths with the existing ones whenever possible, the multicast trees can be formed for the multicast sessions. Figure 6 shows the merging process for an existing connection C₁ = {c, h, g, f}, and a new connection C₂ = {d, e, h, g, f} that have node h as their common node and f as their common upstream border node. The subpath {h, g, f} of the new connection is merged with the existing one.

Conclusions

In this article an integrated connection management solution for the setting up ATM virtual channels for wireless ATM networks is described. The proposed solution supports and exploits the idea of multicast communications, which leads to many advantages over the existing standard solutions proposed by the ATM Forum. In particular, by advocating the use of multicast for all connections, the proposed solution realized an ATM multicast connection service that is much needed to support today's multimedia applications. In the near future, the overall performance of the proposed design will be addressed in greater detail.

Acknowledgments

The authors would like to thank members of the wireless ATM project team for many useful discussions. Pung Hung Keng also contributed many ideas in the early stage of this work.

References
[1] D. Raychaudhuri, "Wireless ATM Networks: Architecture, System Design and Prototyping," IEEE Pers. Commun., Aug. 1996, pp. 42–49.
[2] E. Ayanoglu, K. Y. Eng, and M. J. Karol, "Wireless ATM: Limits, Challenges, and Proposals," IEEE Pers. Commun., Aug. 1996.
[3] ATM Forum Wireless ATM WG, Document no. LTD-WATM-01.02, 1997.
[4] A. A. Lazar, K. S. Lim, and F. Marconcini, "Realizing a Foundation for Programmability of ATM Networks with the Binding Architecture," IEEE JSAC, Special Issues on Distributed Multimedia Systems, Sept. 1996, pp. 1214–27; also see http://comet.ctr.columbia.edu/xbind/.
[5] L. H. Ngoh, H. Y. Li, and H. K. Pung, "A Direct ATM Multicast Service with Quality of Service Guarantees," Proc. IEEE Int'l. Conf. Multimedia Comp. & Sys., June 1996, pp. 54–61.
[6] H. Y. Li, H. K. Pung , and L. H. Ngoh, "Active Multicast Service Architecture for User Customized Multimedia Data Transmission over ATM Networks," SPIE Proc. Multimedia Comp. and Networking '97, San Jose, CA, Feb. 1997, pp. 17–28.
[7] L. Zhang et al., "RSVP: A New Resource ReSerVation Protocol," IEEE Network, Sept. 1993; see also http://www.isi.edu/div7/rsvp/rsvp.html.

Additional Reading
[1] The MBone Information Page.
[2] M. Borden et al., "Integration of Real-Time Services in an IP-ATM Network Architecture," IETF RFC 1821, Aug. 1995.
[3] A. Alles, "ATM Internetworking," white paper, Cisco Systems, Inc., Mar. 1995.
[4] C. Semeria and T. Maufer, "Introduction to IP Multicast Routing," Internet draft, 1996.

Biographies
Lek-Heng Ngoh studied in the United Kingdom and received a B.Sc. (Honors) in computer systems engineering in 1986 from the University of Kent, and an M.Sc. and Ph.D. in computer science in 1987 and 1989, respectively, from the University of Manchester. He was with Hewlett-Packard Research Laboratories, Bristol, England, until 1992. His current research interests include broadband multimedia communications and network protocols.
Hongyi Li received a Ph.D. with Greatest Distinction and an M.Eng. from Vrije Universiteit Brussel in 1994 and 1991, respectively. He received a Postgraduate Diploma from Peking University and a B.Eng. from Beijing Institute of Information Technology in 1986 and 1984, respectively. He was a postdoctoral fellow at the National University of Singapore, 1995–1996. His areas of interest are broadband networking, wireless ATM, and signal and image processing.
Weiguo Wang received a B.E. degree in computer science and technology from the University of Science and Technology of China, Hefei, in 1983, and M.A. and Ph.D. degrees in computer science from Boston University, Massachusetts, in 1985 and 1990, respectively. He is the assistant program director of the Networking Services Program at ISS.