46

Chapter 4

A Hybrid Wireless Network Enhanced with Ad hoc Networking

4.1 Introduction

In the aftermath of a large-scale disaster such as an earthquake or a man-made

emergency, communication systems are required to be able to access networks quickly

and stably for rescue operations and to collect damage assessment information. A

centralized hierarchical network is well suited to acquire data from massive nodes

efficiently, as described in Chapter 3, provided that links between a base station (BS)

and nodes are maintained. The network is capable of communicating stably with even a

small power of 10 mW, provided that the links between BS and nodes maintain the link-

of-sight path. However, since each link of the network is configured with a single

connection, some of links could not maintain connectivity in a disaster. In the event,

especially, that a large-scale natural disaster happens, the network may have a potential

but an obvious issue that nodes cannot access BS directly due to deterioration of

propagation condition by damages on wireless units or by interruptions. In addition, the

deterioration of reachability demonstrated in Chapter 3 results in a short communication

range, that is, the communication range shrinks at the same output power. It is

concerned that the similar issue may take place in the future cellular network.

Meanwhile, several papers have described that the ad hoc network is feasible to work

effectively for disaster communications even if infrastructure facilities might not

perform sufficiently [48]. Ad hoc networking scheme allows a node to rebuild a

connection by diverted routes. However, we know that the connectivity of ad hoc

networks is vulnerable not only due to mobility or limited power but also due to other

issues such as interferences from hidden terminals [49]. When the number of

multihopping increases, route connectivity may decrease, besides, end-to-end delay

47

increases in proportion to the hop count. Consequently, the reliability of the network

may degrade by excessive multihopping. Those drawbacks hamper to disseminate ad

hoc networks to emergency communications. To overcome these issues, we propose a

hybrid wireless network scheme combining ad hoc networks with centralized network,

referred to as ECCA (Enhanced Communication Scheme Combining Centralized and

Ad hoc Networks) [66], [67]. The network scheme maintains connectivity by way of

multihopping, resulting in expansion of the coverage.

4.2 Network Architecture for Disaster Communications

We first discuss network architecture for disaster communications. One of the

important roles for disaster communications is to acquire damage assessment

information and/or emergency signals, and to send them to an operation center quickly

and stably. Therefore, the network has to maintain the connectivity to access a base

station and terminals. Regarding network configuration, a centralized hierarchical

network is suitable for efficient and stable data collection, on one hand. A meshed

network is capable of providing a robust connection, on the other hand.

Figure 4.1 shows a concept of proposed network architecture for disaster

communications. The network comprises a central control station (CS), several base

stations (BS) and massive terminals. The network is divided into multiple cells, each of

which contains a BS and several terminals. We assume that those terminals are installed

in a fixed location since the primary objective of the terminals is to detecting and/or

forwarding emergency signals.

CS collects damage assessment information or other information, and makes a plan

and performs emergency rescue activities based on the information. Several

infrastructured networks such as optical networks, dedicated networks, digital

subscriber line networks, or wireless networks are available to connect CS and BSs. We

can assume that those networks are robust sufficiently against disaster damages since it

is possible to conduct quakeproof design on the facilities. On the contrary, terminals or

branch lines of networks are vulnerable for a natural disaster since it is hard to take a

48

countermeasure for the disaster on massive facilities. Therefore, we primarily discuss

the network within a cell in this paper.

Though it is possible for a terminal to communicate with other terminals via CS or

BS, it might not be necessary to support such a function for disaster communications. In

fact, communications between terminals have a potential issue to make congestion in

disaster situations. Therefore, we do not discuss the communication that a node accesses

another node via CS or BS. Besides, though the network is capable of connecting to

backbone networks, e.g., the Internet, via CS, we do not discuss the function neither in

this paper.

BS performs resource management of the network in a cell, e.g., channel assignment

or addressing of local ID to each terminal. Regarding address mapping, the network

introduces a dedicated short address to shorten the address field of a packet header,

instead of MAC address or IP address, since the amount of terminals included in the

network can be roughly determined in advance. We assume the scale of the network

covered by CS, where the number of terminals is approximately one million or less, and

where the number of BS is less than one thousand. The length of the address field is,

thereby, available at 24 bits, which consist of 10 bits for the cell address as prefix and

14 bits for the local ID of a terminal. BS assigns the address to terminals when they join

the network. The correspondence between the unique address of terminals, if they have,

and the local address is managed in the registration table of BS and CS.

CS: Central Control Station, BS: Base Station, TM: Terminal

Figure 4.1 Concept of network architecture for disaster communications.

CS

Backbone

BS

TM

49

4.3 Network Model of ECCA

A hybrid wireless network, ECCA (Enhanced Communication Scheme Combining

Centralized and Ad hoc Networks), works for data communications within a cell, which

is configured with a centralized hierarchical network (CH-Net) and ad hoc networks

(AD-Net). The former is to connect a BS and terminals directly, and the latter is to

connect terminals each other to reach BS via multihopping, as depicted in Figure 4.2.

Regarding the operation mode, terminals transmitting data in the CH-Net operate in a

cellular mode, where the terminals maintain the connection to BS, as shown in Figure

4.3 (a). On the other hand, in the AD-Net, terminals operate in an ad hoc mode, where

the terminals communicate each other and dynamically build a route to BS via

neighboring nodes by way of multihopping, as shown in Figure 4.3 (b). The terminal

operating in the cellular mode is referred to as a direct connection node (DCN), and the

terminal in the ad hoc mode is an indirect connection node (ICN). Since DCN relays a

packet between AD-Net and CH-Net, it receives both data from BS and ICN, and

forwards the data, hence, it operates as a gateway node for both networks.

In normal circumstances, terminals operate in the cellular mode. If a disaster or an

emergency happens, some links between BS and terminals may be disconnected due to

damage or obstacles, then those terminals switch into the ad hoc mode, and attempt to

build a route to BS by way of multihopping. Given that a terminal discovers gateway

nodes which are able to transmit a packet to BS directly, or other nodes which already

have a route to BS via multihopping, the terminal requests one of those neighboring

nodes to forward a packet. The requested node relays a packet toward BS along the

route which has already been built. When source nodes or intermediate nodes transmit a

packet, they record routing information in a table. To send back a packet from BS to a

node, intermediate nodes decide a route to the destination according to the table.

In addition, considering disaster communications, it may be a proper approach to

transmit data in a short packet. ECCA networking scheme handles a short packet

focusing on transferring emergency data. Consequently, a number of nodes are capable

50

of transmitting data quickly and stably in the narrow bandwidth, while the amount of

data, which the nodes can transmit, is restricted.

4.4 Channel Structure

The Proposed network, ECCA, implements two kinds of communication channels,

one is a data channel to transmit user data between BS and nodes, and the other is a

control channel to send control data from BS to nodes and status or reply data from

nodes for maintaining connections. In addition, the control channel plays a major role to

transmit data by multihopping in ECCA, as described later.

BS: Base Station

Terminal

CH-Net link AD- Net link

CH-Net

BS

AD-Net

Figure .4.2 ECCA network model.

Cell

Figure .4.3 Operation modes in ECCA.

(a) Cellular mode

BS: Base station, D: Direct connection node

D

BS

D D

(b) Ad hoc mode

G: Gateway node, I: Indirect connection node

G

BS

I

G

II

II

I I

G

51

Figure 4.4 illustrates the frame structure of the data and control channels. Since the

data channels are designed in CDMA (Code Division Multiple Access) technique, they

are multiplexed with different spreading codes, as shown in Figure 4.4 (a), and as

described in the Chapter 3. In the figure, the number of multiplexed CDMA channels is

p, and the channels are divided into q timeslots, hence, the data channel operates in TD-

CDMA (Time Division Code Division Multiple Access) fashion [40]. Thereby, the

amount of channels to transmit data is p×q.

The access protocol for the data channels employs a contention manner. When a

node intends to transmit a packet in the data channel, it sends a request packet in any

one of slots of RTS (Request to send) sub-frame to reserve one of the data channels.

Provided that the request packet reaches BS successfully, BS allocates one of the data

channels to the node, and notify the allocation in CTS (Clear to send) sub-frame. Since

the CTS informs the allocation status of the data slots, the number of timeslots in CTS is

same as the data slots. Hence, CTS can inform the allocation of p×q channels.

The node, which made a reservation of a data channel, transmits a data packet in the

designated channel, and BS replies the acknowledgement (ACK) during the slot. In

addition, provided that the node has more packets in its buffer, the node sets the

piggybacking flag of the data packet header when transmitting data, resulting in

maintaining the channel allocated to the node.

On the other hand, the control channel periodically transfers control data from BS to

nodes, and each node transmits data to indicate its status in the control channel. The

control channel is divided into short mini-timeslots, and each node in a cell is assigned

in any one of the mini-timeslots, hence the channel operates in TDM (Time Division

Multiplexing) fashion. Every node shares the control channel, which is referred to as a

common communication channel (CCCH). Figure 4.4 (b) shows its frame structure. The

data packet of CCCH consists of the packet header, the payload (data) and the CRC

(Cyclic Redundancy Check code). The packet header includes the frame type, the

address of a source, a destination, a sender and a receiver (next hop), and the hop count

(Hop-CNT) which is used for route discovery, as described in the following section.

52

The system employs a fixed allocation scheme to assign node to one of the mini-

timeslots of CCCH. Hereby, nodes are capable of maintaining accessibility without

congestion, and are able to transmit data quickly and stably, while the message length of

the packet is restricted to a small size in order to satisfy the size of the timeslot.

Moreover, those channel structures require the synchronization of the slots.

Especially, the CCCH is faced with the issue to synchronize with distributed nodes. The

GPS clock is one of the solutions, however, the system for disaster communications

requires more flexible way. This issue is nontrivial in the physical layer, and several

institutes have studied to solve the issue [73], [74], [75]. We do not address the issue in

this paper, focusing on the second and third layer.

Header

Type Rx Tx Hop- CNT

Dest Src Data CRC

T1...Tn: Terminal ID, A: ACK, Rx: Receiver node ID, Tx: Sender node ID, Dest: Destination ID, Src: Source node ID, CRC: Cyclic redundancy check code

Figure .4.4 Frame format

(b) CCCH: Common Communication Channel

DT DT A A DT A DT A

T1 T2 T3 Tn

Frame

T4

DT A

T5

DT A

Mini-timeslot

Tx Type Rx CRC Data

(a) Data Channel

Code (1) Code (2)

Code (p)

Slot (1) Slot (2) Slot (q) Data (1,1) Data (2,1)

Data (p,1)

Data (1,2) Data (2,2)

Data (p,2)

Data (1,q)

Data (2,q)

Data (p,q)

RTS

RST DATA (+Piggyback flag) + ACK CST

Frame

CTS 1 q

p

53

4.5 Routing Protocol

Various routing protocols for ad hoc networking have been proposed [24], [25], [50],

and have stated that ad hoc networks are operable even in disaster circumstances. We

first discuss the suitability of some protocols for disaster communications. Then, we

propose a routing protocol for multihopping in ECCA to operate in disaster

circumstances. The proposed routing protocol aims to transmit a packet from nodes to

BS, and reply from BS to nodes efficiently and stably. Though it is available to deliver a

packet to others node like existing ad hoc routing protocols, we focus on the

communication between nodes and BS considering emergency communications.

4.5.1 Related Routing Protocols

A) DSR

The Dynamic Source Routing (DSR) protocol [27], [25] is an on-demand routing

protocol that is based on the concept of source routing. When a node has a packet to

send to some destination, it first consults its route cache to determine whether it already

has a route to the destination. If it has an unexpired route to the destination, it will use

this route to send the packet. If the node does not have such a route, it initiates route

discovery by broadcasting a route request (RREQ) packet. This RREQ message

contains the address of the destination along with the source node's address and a

unique identification number of the packet. Each node receiving the packet checks

whether it knows of a route to the destination. If it does not, it adds its own address to

the route record of the packet, and then forwards the packet along its outgoing links. To

limit the number of RREQ propagation on the outgoing links of a node, a node only

forwards the RREQ if the node has not yet seen the request, and if the node's address

has not appeared in the route record. A route reply (RREP) is generated when either the

RREQ reaches the destination itself, or when it reaches an intermediate node that

contains in its route cache an unexpired route to the destination. Until the packet reaches

either the destination or such an intermediate node, it contains a route records yielding

the sequence of hops taken.

54

Figure 4.5 illustrates the formation of the route record as the RREQ message

propagates through the network. If the node generating the RREP is the destination, it

places the route record contained in the RREQ into the RREP. If the responding node is

an intermediate node, it appends its cached route to the route record and then generates

the RREP. To return the RREP, the responding node must have a route to the source. If

it has a route to the source in its route cache, it may use that route. Otherwise, if

symmetric links are supported, the node may reverse the route in the route record from

the route request packet. If symmetric links are not supported, the node may initiate its

own route discovery and piggyback the RREP on a new RREQ.

Thus, the DSR protocol cannot specify the length of the route record since

intermediate nodes add their own addresses in sequence. This process has a potential

issue to result in an excessive overhead, sending a short message especially. Therefore,

it is not suitable for an efficient transmission in disaster communications, where the

frequency bandwidth is extremely restricted.

N1

N2

N6N3

N8N5

N7N4

N1 N1, N2 N1, N2, N5

N1 N1, N3

N1, N3, N4

N1, N3, N4, N6

N1, N3, N4, N6, N7

Destination

Source

(a) Building the route record during route discovery.

(b) Route reply with the route record.

N1

N2

N6N3

N8N5

N7N4

N1, N2, N5, N8N1, N2, N5, N8N1, N2, N5, N8

Figure 4.5 Route discovery process in DSR

55

B) AODV

The Ad hoc On-Demand Distance Vector (AODV) routing protocol [26], [25] is an

on-demand routing protocol that is based on the Destination Sequenced Distance Vector

(DSDV) algorithm [51], but does not exchange routing table. When a source node wants

to send a message to a destination node and does not have a valid route to that

destination, it initiates a path discovery process to locate the other node. It broadcasts a

route request (RREQ) packet to its neighbors, which then forward the request to their

neighbors, until either the destination or an intermediate node with a fresh route to the

destination is located, as shown in Figure 4.6 (a).

AODV uses destination sequence numbers to ensure that all routes are loop-free and

contain the most recent route information. The source node includes in the RREQ the

most recent sequence number it has for the destination. Intermediate nodes can reply to

the RREQ only if they have a route to the destination whose corresponding destination

sequence number is greater than or equal to that contained in the RREQ. During the

process of forwarding the RREQ, intermediate nodes record in their route tables that

addresses of neighbors from which the first copy of the broadcast packet was received,

thereby establishing a reverse path. If additional copies of the same RREQ are received

later, these packets are discarded.

Once the RREQ has reached the destination or an intermediate node with a fresh

route, the destination or the intermediate node responds by unicasting a route reply

(RREP) packet back to the neighbor from which it first received the RREQ, as shown in

Figure 4.6 (b). As the RREP is routed back along the reverse path, nodes along this path

set up forward route entries in the route tables that point to the node from which the

RREP came. The source node can begin data transmission as soon as the first RREP is

received and can later update its routing information if it discovers a better route.

Associated with each route entry is a route timer, which causes the deletion of the

entry if it is not used within a specified lifetime. Since an RREP is forwarded along the

path established by an RREQ, AODV only supports the use of symmetric links.

56

Sending a message packet by unicasting in AODV, the packet header includes the

addresses of the source node, the destination node and the next hop node. Thereby, the

length of the header can be fixed. This scheme is reasonable to transmit a small message

in the restricted frequency bandwidth. However, AODV also uses broadcasting

technique to discover a route. In the event that a disaster happens and the conditions of

wireless links are deteriorated, massive route request packets may be generated

simultaneously, and lapsing into heavy congestion. Furthermore, when increasing the

node density, the issue becomes serious.

N1

N2

N6N3

N8N5

N7N4

Destination

Source

(a) Broadcasting for route discovery.

(b) Route reply by unicasting.

N1

N2

N6N3

N8N5

N7N4

Figure 4.6 Route discovery process in AODV

57

C) DSDV

The Destination Sequence Distance Vector (DSDV) routing protocol [51] is a

proactive table-driven routing protocol. Each node in the ad hoc network maintains a

routing table in which all of the possible destinations and the number of routing hops to

each destination are recorded. Figure 4.7 shows the process to add a link in DSDV,

where node-A joins the network. The node-A first transmits the routing information:

<node-ID, sequence number, hop count>, e.g., <A, 101, 0>. Node-B receiving the data,

inserts the information into the routing table. Then, the node-B propagates new route

information to neighbors: <A, 101, 1>. Likewise, other nodes update their routing table,

and continue propagation of the information. Hence, routing information is always

made readily available, regardless of whether the source node requires a route or not.

Updating information of a routing table is sent periodically throughout the network to

maintain table consistency. Therefore, this may generate a lot of control traffic in the

network, resulting in an inefficient utilization of network resources. DSDV introduces

two types of route update packets to alleviate this problem, one is a full dump packet,

and the other is a smaller incremental packet. However, these are not an essential

method of settlement. It may be hard to operate well in disaster circumstances since the

propagation conditions of massive nodes may be changed simultaneously.

B

D

C

E A

A, 101, 0

Figure 4.7 Link addition in DSDV in case that the node-A adds the network.

A, 101, 1

A, 101, 1

A, 101, 2 Dest Seq Next Metric

B's Route Table

B 132 B 0 C 144 C 1 D 202 D 1 E 155 D 2 A 101 A 1

58

D) ZRP

The Zone Routing Protocol (ZRP) [25], [87] is a hybrid protocol incorporating the

merits of on-demand and table-driven routing protocols. A routing zone is similar to a

cluster with the exception that every node acts as a cluster head and a member of other

clusters. Zones can overlap, and each node specifies a zone radius in terms of hops. The

size of a chosen zone, therefore, can affect ad hoc communication performance. In ZRP,

a routing zone comprises a few mobile nodes within one, two, or more hops away from

where the central node is formed. Within this zone, a table-driven-based routing

protocol is used. This implies that route updates are performed for nodes within the

zone. Each node, therefore, has a route to all other nodes within the zone. If the

destination node resides outside the source zone, an on-demand search-query routing

method is used.

ZRP itself has three sub-protocols:

• The proactive Intra-zone Routing Protocol (IARP)

• The reactive Inter-zone Routing Protocol (IERP)

• The Broadcast Resolution Protocol (BRP)

IARP can be implemented using existing link-state or distance-vector routing. The

routing information is propagated to the border of the routing zone. The IARP relies on

an underlying neighbor discovery protocol to detect the presence and absence of

neighboring nodes, and therefore, link connectivity to these nodes. Its main role is to

ensure that each node within the zone has a consistent routing table that is up-to-date

and reflects information on how to reach all other nodes in the zone.

IERP relies on border nodes to perform on-demand routing to search for routing

information to nodes residing outside its current zone. Instead of allowing the query

broadcast to penetrate into nodes within other zones, the border nodes in other zones

that receive this message will not propagate it further. IERP uses the broadcast

resolution protocol.

Because parts of an ad hoc route are running different routing protocols, their

characteristics will be different. Some part of the route is dependent on proper routing

59

convergence, while the other part is dependent on how accurate the discovered inter-

zone route is. This can make assurance of routing stability very difficult. Without proper

query control, ZRP may actually perform worse than standard flooding-based protocols.

ZRP's route discovery process is, therefore, route table lookup and/or inter-zone route

query search. When a route is broken due to node mobility, if the source of the mobility

is within the zone, it will be treated like a link change event and an event-driven route

update used in proactive routing will inform all other nodes in the zone. If the source of

the mobility is a result of the border node or other zone nodes, then route repair in the

form of a route query search is performed, or in the worst case, the source node is

informed of route failure.

The routing zone reduces overhead of the route discovery procedure. However, it

adds the other overhead of maintaining zone membership and routing information

within each zone [88].

4.5.2 Requirements for Routing Protocols in Disaster Communications

Considering the requirements of routing protocols in disaster communications, we

first assume that the network handles data of a small size such as emergency signals

instead of a large data like an image. Reducing the size of the data part in a packet, the

packet header should be small enough for efficient data transmission.

In addition, communication congestion is a critical issue. In the event that a disaster

happens, a number of terminals, which detect emergency signals from various sensors,

try to transmit data to a specified destination. Assuming an on-demand routing protocol,

the terminals will start the route discovery process simultaneously, lapsing into

congestion or collision by the route request packets. While lasting the change of

propagation conditions, the route discovery process may be repeated, not only

immediately after the event but also during several hours or more. The process induces

a lot of transmission and includes a potential issue of congestion. Therefore, in addition

to the performance comparison for several routing protocols, as shown in many papers,

e.g., [89], [90], we need to discuss their congeniality for disaster communications, as

listed in Table 4.1., considering the bandwidth consumption due to the route request.

60

In the case of DSR, a source node designates a route to transmit a packet, and

accumulates in the packet header the addresses of multiple intermediate nodes along the

route. Provided that the multihopping range increases, the header length also increases,

thereby, the packet header should be variable length. In conditions where the disaster

communication system transmits a short data, route addressing of DSR is not reasonable

in terms of efficiency. In addition, since DSR broadcasts a route request packet to

discover a route, it may result in flooding storm in the aftermath of a disaster.

On the other hand, in the case of AODV, since each intermediate node decides a

route and forwards a packet according to the routing table, it is able to fix the packet

header length. The addressing manner is preferable when transmitting a short data in

disaster communications. However, AODV also broadcasts a route request packet to

discover a route, and then similar issue to DSR may occur in disaster circumstances.

DSDV requires updating the routing table periodically. Especially, in the aftermath

of a disaster, the transmission may happen massively, entailing heavy traffic congestion.

As well as ZRP, since IARP (Intra-zone Routing Protocol) uses a table-driven-based

routing protocol, the same issue as DSDV may happen, even though the impact is

limited within the zone. Moreover, IERP (Inter-zone Routing Protocol) may generate

on-demand route discovery simultaneously, the traffic status may be confused.

Table 4.1 Comparison of Ad hoc routing protocols for disaster communications.

DSR AODV DSDV ZRP

Classification Reactive Reactive Proactive Hybrid

Routing Link state Distance vector Distance vector Distance vector + On-demand

Route discovery Broadcast Broadcast Table Inside: Table Outside: Broadcast

Route maintenance ACK / Route Error Hello Table dump Table dump

Header length Variable Fixed Fixed Variable

Bandwidth consumption ∆ ∆ × ×

Stability × × ∆ ∆

Feat

ures

for

disa

ster

com

m

Congeniality × ∆ × ×

61

4.5.3 Management of Route Discovery Process

In the event that a link of the hierarchical network disconnected, who initiates the

route discovery process, BS or nodes?

(1) Center-centric:

In case that BS initiates the process, we refer to the policy as center-centric, BS

needs to decide that each link is available or not. Provided that BS notices data from a

node has not reached BS via neither a direct path nor a multihopping path for a specified

period, it initiates the process for route discovery, and broadcasts a route request packet

[70]. If BS knows the area where the desired node is located, it is available to send a

request packet by designating a node, which is located near the desired node. If not, BS

must broadcast a request packet to whole network.

In Figure 4.8 (a), when BS attempts to find T1, it sends a route request packet to Ta

since BS has connection to Ta, and knows T1 is located near Ta. Then, Ta forwards the

route request by broadcasting. The request packet is transferred to T1 via T3 and T2, or

T3, T4 and T5. T1 may select the route via T2 and T3, and sends back the reply to Ta,

finally, Ta sends back the reply to BS. However, if T1 is broken, the BS cannot know

whether the node is not available or the route is not available, then it may repeat the

route discovery while the route reply does not arrive. This approach is an open-end

process, and then results in confusion.

(2) Node-centric:

In case that a node initiates the route discovery process, we refer to the policy as

node-centric. Nodes are capable of detecting by themselves that they cannot access BS

directly nor via multihopping since they have not received any reply from BS for a

specified period. In conditions where a node transmits the route request to neighbors,

and any neighboring node receives the request, and then the neighboring node sends

back the acknowledgement. If a node cannot operate any more, it does not output any

power, and does not interfere for neighboring nodes. It means that the node-centric

manner is superior to the center-centric on the route discovery in a disaster, where

62

massive nodes may be broken.

Figure 4.8 (b) shows the process of the node-centric route discovery. Since T1 cannot

access BS, it broadcasts a route request packet. The request is relayed via T2 and T3, or

T5, T4 and T3 by broadcasting. Assuming Ta has connection to BS, and receiving the

request via two routes, it may select the route via T3 and T2, and send back the reply.

As a result, T1 can build a route to BS via T2, T3, and Ta.

However, if a node cannot receive a reply for the route request, it may transmit the

route request again. As a result, such a node may invoke a heavy traffic. Thus, the node-

centric may also have a potential issue, though the manner has an advantage. We will

propose a routing protocol to overcome these issues in the next section.

REPLY to T2

(a) Center-centric routing process

BS

Ta

Distressed area

R-REQ (T1)

T3

T2

T1

T5 T4

REPLY to T3

REPLY to Ta

REPLY

Route request

Data

Reply

R-REQ

R-REQ

Figure 4.8 Node-centric / Center-centric route discoveries.

(b) Node-centric routing process

BS

Ta

Damaged node T3

T2

T1

T5 T4

T6

Route request

Data

Reply

R-REQ

R-REQ

REPLY

Data

63

4.5.4 Routing Protocol: LISNER

We propose a routing protocol for ECCA, which aims to build a route to BS without

an extra communication such as route request or exchanging a routing table. The

scheme is based on communications monitoring, thereby, referred to as LISNER (Listen

& Search Neighbor Environment Routing Protocols) [66], [67].

A) Outline

In the ECCA scheme, a node which has a route to BS transmits a control data

periodically using the CCCH channel, operating in either the cellular mode or the ad

hoc mode. In the event that the node cannot access BS, it monitors communications of

neighboring nodes. If the node receives a packet by overhearing, it checks the hop count

contained in the packet header. Recognizing that the neighboring node is able to access

BS with the hop count, the node requests the neighboring node to relay its packet. The

neighboring node forwards the packet to the next hop node which has been discovered

in advance. The packet is relayed, and finally reaches BS. Then, BS sends back the

reply message to the source node via the same route.

B) Route Discovery

In the event that a node cannot access BS in cellular mode, the node switches into the

ad hoc mode, and then initiates the route discovery process. The process does not

broadcast a route request packet, instead, monitors communications of neighboring

nodes. The route discovery scheme employs "hop-count" (Hop-CNT) as a metric, which

indicates the hopping range to reach BS and is included in the packet header, as

depicted in Figure 4.4 (b). The node knows the neighbor have a route to reach BS by the

number of the Hop-CNT.

Provided that a node overhears surrounding communications on the CCCH and

acquires a packet which any node transmits to another node or BS, it recognizes the

hopping range to reach BS by checking the Hop-CNT. The node transmits a packet

increasing the Hop-CNT by one to the discovered neighboring node to confirm that the

neighbor can forward a packet. If the node receives the acknowledgement from the

64

neighbor, it can decide the route to reach BS. If not, the node does not store the

neighboring node as the relay node, and monitors the channel again.

To maintain the routing information, each node has an entry table and a route table,

as shown in Table 4.2 and 4.3. The entry table contains a destination address, a next hop

node address, and a hop count of the next hop node. The table is used for transmitting a

packet toward BS. In conditions where the Hop-CNT contained in the packet is smaller

than the value stored in its entry table, the node updates the information of the entry

table. That is, the node maintains the entry that has the smallest hop count. If there are

multiple accessible nodes at the smallest hop count, it can select one of them randomly.

The amount of data of the table depends on the memory capacity of the node. Since the

proposed routing protocol chooses the shortest path, the number of the accessible nodes

is a trivial issue, though it may influence on the redundancy of alternative paths.

In the event that a node notices it cannot overhear the communication of a

neighboring node recorded in the table during the time to live (TTL) designated as a

system parameter in advance, the node deletes the entry to the neighboring node. When

a node notices by overhearing that the Hop-CNT of the next neighbors has changed, it

updates the data of its entry table. In addition, immediately after the Hop-CNT of an

intermediate node has changed, when the node receives a packet, and the Hop-CNT is

inconsistent with the record of the table, then the intermediate node replies the negative

acknowledgment (NAK) to inform the inconsistency of the Hop-CNT. The node

received the NAK retransmits the packet to the neighbor or to the other neighboring

nodes recorded in the table, after updating the Hop-CNT.

On the other hand, the route table contains route information to reply a packet, i.e.,

source node and sender node addresses, as illustrated by an example in Table 4.3. Those

data are set up when relaying packets toward BS. When sending back a reply to the

source node, the node transmits the reply packet to the sender node address recorded in

the table. In the event that a relaying node notice that it has not received a packet from a

certain source node for the TTL designated as a system parameter in advance, the node

deletes the record of the route table.

65

Table 4.2 Entry table of node-s for multihopping. Table 4.3 Route table of node-f.

Thus, nodes discover a route to BS, and maintain the route by monitoring the

surrounding communications. Each node knows the addresses of the next hop nodes.

Thereby, every node transmit a packet by designating the receiver i.e., by unicasting. It

allows nodes to transmit a packet stably, and to prevent generating extra

communications by broadcasting.

Figure 4.9 shows the scenario of the route discovery. When node-s cannot access BS,

it listens for the surrounding communications, and then captures a packet. The node-s

checks the sender node address (node-i) and the Hop-CNT. Then, the node-s records in

its entry table the address of node-i as the next hop node and the Hop-CNT (=k), as

listed in Table 4.2. When the node-s sends a packet to the node-i, which has a route to

reach BS, it sets the Hop-CNT of the packet as k+1. Receiving the packet, the node-i

relays the packet to node-f according to its own entry table. Finally, the packet reaches

BS by way of multihopping. If the node-s may hear a signal from another node (node-j),

it records the address and the Hop-CNT of node-j. Since the Hop-CNT of node-i is k

hops and node-j is k+1 hops, node-s, thereby, selects node-i as the next hop node

because of the smaller hop count.

Destination Next hop Hop-CNT

BS node-i k

BS node-j k+1

Source Sender

node-s node-i

node-t node-h

Figure 4.9 Route discovery

G1

G2

BS

kk

k+1 1

k+1

k+1

kk+1

1i

S

j g

f

ht

66

C) Upward and Downward Routes

This paper refers to the route toward BS as "Upward", and the route from BS to

nodes as "Downward". As mentioned above, an upward packet is transmitted to BS

according to the entry table of each node, on one hand. On the other hand, a downward

packet is sent back according to the route table. An example of each table is shown in

Table 4.2 and 4.3. When an intermediate node (node-f) is required to relay a packet by

node-i in Figure 4.9, it forwards the packet to the next hop node according to the entry

table. Concurrently, the node-f records in its route table the address of node-i as the next

send-back address, and the address of node-s as the destination for the downward.

Likewise, receiving a packet from node-h, which was initiated by node-t, node-f records

the address of node-h and node-t for the downward. When a downward packet

addressed to node-s arrives at node-f, the node-f can decide to relays the packet to node-

i according to the route table. Finally, the packet is delivered to node-s along the

downward route.

D) Route Error and Route Maintenance

In the event that an intermediate node detects failure in forwarding a packet, though

the node may retransmit a packet via another route, it does not carry out the retrans-

mission in ECCA scheme. If some intermediate nodes execute retransmission to another

route, it may take a long time for a source node to detect the failure, despite requiring a

short delay to deliver packets to BS. Besides, the stale message may rove during

retransmission, and may hamper other communications in the network.

Alternatively, ECCA introduces an idea to handle communication failure that an

intermediate node replies a route-error message or an expiration message to the

downward node if it detects the failure. The route-error message is replied in case that

the node has another route to be able to forward the message. On the other hand, the

expiration message is replied in case that the node has no route to forward the message.

Therefore, when the source node receives the route-error message, it can retransmit the

packet to the same next hop node, because the intermediate nodes have an alternative

67

path. When the source node receives the expiration message, it must send the packet to

another next hop node to transmit via another route.

Figure 4.10 demonstrates a scenario to reply either a route-error message (r-err) or

an expiration message (exp). In the event that an intermediate node (node-i) detects

failure at link-3 when forwarding a packet to the next hop node (node-f ), deletes the

entry to node-f from the entry table of node-i. If the entry table contains another route,

link-4, the node-i replies r-err to the downward node (node-r) according to the route

table. If node-i does not have any next hop node in the entry table, it returns exp to

node-r. Since intermediate nodes do not execute the retransmission process in ECCA,

node-r relays to the next downward node (node-s) the r-err received from node-i. If

node-r receives the exp from node-i, it deletes the route to node-i from the table, and

relays the exp. Only if the node-r has an alternative path in the entry table when

receiving the exp, it sends back to its downward node (node-s) the r-err instead of the

exp, since the node-r can choose an alternative path to forward a packet in the next

transmission. When the r-err arrives at the source node (node-s), the node can

retransmit the same packet to the same next hop node, or can select another next hop

node. If the node-s transmits a packet to the node-r again, the node-r forwards the

packet to the alternative node, node-j, according to the entry table of node-r. When the

node-s receives the exp, it must select another next hop node (node-k). If there is no

entry in the table of the source node, it must wait for transmitting the packet, until

overhearing communications of neighbors and discovering another route.

Concerning route maintenance, since each node transmits a packet periodically in

ECCA scheme, it can update the freshness of routes automatically, resulting in

maintaining the connectivity between neighboring nodes. Moreover, since this protocol

does not transmit a search packet such as a route request or a hello message by

broadcasting to inform connectivity for neighboring nodes, nodes do not induce

interference. It leads to stable transfer of packets.

68

Figure 4.10 Route error and route maintenance.

i

f

G1

r

G2

BS S

g

link-1 link-2

link-3

link-4

k

l mG3

jlink-5

link-6

err / experr / exp

Next Hop

i j

3 4

Entry table

Next Hop

r k

4 4

Entry table

Next Hop

fg

22

Entry table

69

4.6 Medium Access Control Protocol

The medium access control (MAC) protocol is a key factor to avoid collision of

packets or communication congestion in wireless networks. Most protocols have been

proposed to aim achieving the best-effort performance instead of accessibility. This

section proposes a MAC protocol based on time scheduling to ensure channel access in

disaster or emergency circumstances. We first discuss the classification of related

wireless MAC protocols, and then describe a protocol for ECCA.

4.6.1 Classification of MAC Protocols

Wireless MAC protocols are broadly classified into two categories; distributed

protocols and centralized protocols, according to the type of network architecture.

Reference [52] has further classified them into a random access protocol, a guaranteed

access protocol, and a hybrid access protocol. The hybrid access protocol is further

classified into reservation access and demand assignment. To discuss the feature of the

ECCA MAC protocol, we have reviewed them, and have classified the protocols into

random, reservation, scheduling and channelization access protocols, as shown in Table

4.4, considering the allocation fashion.

We briefly review some wireless MAC protocols. First, Table 4.4 lists fundamental

protocols, CSMA/CA and ALOHA [53] as the random access protocol in the distributed

manner, which contend for access to the medium. Regarding the reservation access

protocol, it is much efficient to transmit data. Some existing protocols, MACA [54],

MACAW [55], FAMA [56] and IEEE 802.11-DCF [57], [58] are listed in the table.

They acquire the channel with handshaking of RTS and CTS between nodes. When a

node overhears RTS or CTS, the node is inhibited to transmit a packet during the

designated time. In addition to the RTS-CTS manner based on MACA and MACAW,

IEEE 802.11-DCF introduces virtual carrier sensing, which is achieved by using time

fields in the packets to indicate the duration of the current transmission to other nodes.

The time field is called the Network Allocation Vector (NAV). When all nodes hears

the RTS or CTS, they back off NAV amount of time before sensing the channel again.

70

This protocol achieves high performance by the best efforts as known well in the

wireless LAN. However, when the node density becomes higher, the efficiency

deteriorates due to exposed and hidden node problem [49], [59], [60], [61]. Regarding

the scheduling access in distributed MAC protocols, USAP is proposed in [65], which is

a distributed TDMA slot assignment protocol. It allows a transmitter to choose one or

more slots from the pool of unassigned slots in its neighborhood, coordinate the

announcement and confirmation of the assignment with the neighboring nodes up to two

hops away, and detect and resolve conflicting assignments that result from unfortunate

timing and mobility of the nodes.

Second, the access protocol in cellular network is categorized as channelization

access, which statically allocates channels to mobile stations, and it is used for voice

communication. Those protocols allow a mobile station to acquire a channel stably, if

the network affords the number of channels, otherwise, call blocking may occur. We

know well that the access scheme is vulnerable for heavy phone use especially in

disaster circumstances.

Third, the random access protocol and the reservation access protocol in centralized

wireless MAC protocols are access manners based on contention scheme using a master

station. Table 4.4 lists some examples with reference to [52]; ISMA [62] is for random

access, and PRMA [63] and DQRUMA [64] for reservation access. In ISMA, a central

station broadcasts "Idle signal (IS)" when it detects that the channel is idle. All nodes

that have data in the buffer transmit with a probability p. If more than two nodes

transmit a packet for the same IS, the probability that collision occurs is p2 or less. In

case of reservation access protocols, PRMA handles voice and data. A voice node

transmits a packet in a vacant slot with a probability p. A successful voice packet

reserves that slot for the following packets in the stream until the end of talk. A data

node also contends similarly, however, no reservation is made for a successful data

node. That scheme gives priority to the voice node over the data node. In DQRUMA,

the uplink and downlink are frequency duplexed. The uplink consists of a request

channel and a packet-transmission data channel. The former is used to send requests by

contention, and the latter to send data based on reservation. Before transmitting data, a

71

node attempt to reserve a channel with a small request packet in contention-based

random access. If the node successfully made a reservation, it is informed by

broadcasting the ID of the node on the downlink acknowledgement (ACK) channel, and

is allowed to transmit data on data channel without collision.

Fourth, the scheduling access protocol guarantees the channel access by way of

polling or dedicated channel allocation. IEEE 802.11-PCF (Point Coordination

Function) mode allows nodes to ensure contention-free access with an access point

polling nodes in order.

4.6.2 MAC Protocol for ECCA

ECCA network scheme is based on the centralized MAC protocols. The channels of

ECCA, the data channel (DCH) and the common communication channel (CCCH),

introduce individual MAC protocols in order to satisfy the requirements.

The DCH connecting between BS and nodes directly employs the reservation access

manner due to transmitting data flexibly and efficiently, as categorized in Table 4.4. The

channel is mainly used for normal data transmission, not for emergency

Channel Allocation Access Centralized MAC Protocols Distributed MAC Protocols

Static allocation Channelization FDMA, TDMA, CDMA

ECCA-CH(*)

Random ISMA CSMA/CA, ALOHA

Reservation PRMA, DQRUMA ECCA-DCH

802.11-DCF MACA, MACAW, FAMA

Dynamic allocation

Scheduling Polling

802.11-PCF ECCA-AD(*)

USAP

(*) CCCH channel of ECCA network operates by two modes; one is for the cellular mode, the other is for the ad hoc mode. This scheme is described the later section.

Table 4.4 Classification of wireless MAC protocols based on access methods.

72

communications. When a node have a packet, it sends a small request packet in a

channel of RTS sub-frame by selecting a timeslot and a CDMA code randomly to make

a reservation of data channel, as shown in the previous Figure 4.4. Provided that the

base station receives the request successfully, the base station assigns to the node a

timeslot and a CDMA code of the data channels, and notifies the allocation information

by CTS sub-frame. Receiving the notification, the node transmits a data packet using

the designated data channel. In conditions where the node has more packets in its buffer,

the node sets the piggybacking flag when transmitting data. Thereby, the node is able to

maintain the channel. Thus, nodes can transmit data in the data channel without

collision.

On the other hand, each timeslot of the common communication channel (CCCH) is

assigned to every node in advance, and maintains the allocation until the node removes

from the network. In case of CH-Net, each node transmits data in the designated

timeslot; hence, it is the channelized access manner, as classified in Table 4.4. The

access manner can ensure access to BS. In case of AD-Net by multihopping, each node

transmits data in the dynamically scheduled and designated channel. The protocol

referred to as MICS is described in the next section. Thus, the channel access protocol

in ECCA, especially on CCCH, aims to transmit data quickly and stably for disaster

communications.

4.6.3 Comparison of MAC Protocols

The Data channel of ECCA, DCH, is based on CDMA and TDMA channels, and

employs the reservation access scheme for the MAC protocol, as described above. The

CDMA manner provides the benefits to improve the frequency band efficiency and the

noise-interference characteristics. The TDMA provides the efficient allocation of

channels. Since the data transmission is carried out on demand, not periodically, and the

data size is rather a large, the reservation access manner is more adequate than

scheduling or random access. Hereby, several nodes can access the channels quickly

and stably, and transmit data efficiently in normal conditions.

73

The CCCH is required to guarantee to access. The channelization access manner

such as FDMA, TDMA and CDMA, are capable of providing stable data transmission

for allocated nodes, though those manners have a definite limitation due to the capacity.

In conditions where the ECCA is used in the network that the number of nodes can be

supposed, and where the data transferred on CCCH is restricted to small size to handle

emergency data, the CCCH can employ the channelization access manner. Especially,

CCCH in the CH-Net between a base station and nodes satisfies those conditions.

Therefore, the CCCH in the CH-Net, referred to as ECCA-CH in Table 4.4, employs the

access scheme. Each node is assigned in one of the timeslots by fixed allocation. Hereby,

the access of those channels is ensured, in conditions where the link between the base

station and the node is maintained.

Meanwhile, in case of multi-hopping on CCCH, if several nodes require a certain

node to relay a packet and the intermediate node relays the packet based on the

channelization such as ECCA-CH, the node may be congested with forwarding packets.

If the node accesses CCCH by random access or reservation access, it cannot ensure

quick data transmission. Hereafter, we propose a protocol for multihopping based on

scheduling manner.

4.6.4 Multihop Access Scheduling: MICS

ECCA needs to deliver a packet at the short delay even in multihop transmission. We

discuss a multihop access scheduling scheme, MICS (Multihop Access on Initial Channel

by Scheduling). In conditions where a node has discovered a route to BS via an adjacent

node in ad hoc networks, the node sends its own packet and relaying packets via

neighbors. If a number of packets arrive at a node, the node has to accumulate the

packets in the queue and send them sequentially, when acquiring a channel. Since all

packets converge at BS due to the network topology, the network may suffer congestion

at BS or around direct connection nodes (DCNs) even in ECCA. In particular, the

network lapses into a long delay to deliver packets in a large-scale disaster, since the

number of DCN is reduced and the number of multihopping range is increased.

74

In the medium access scheme of ECCA, when a node sends an own packet to the

adjacent, the source node transmits it in the designated own timeslot. Since the timeslot

is allocated only to the node, this channel can transmit a packet without contention. An

intermediate node, however, is required to relay packets by multiple nodes. In

conditions where the intermediate node can use only a designated slot to forward the

packets, those packets are stacked in the queue of the intermediate node, and then the

packets result in a long delay even when the intermediate node sends an own packet.

This scheme may bring another issue on fairness that the node cannot send even own

packets.

To overcome this issue, ECCA proposes a dedicated protocol for multihop access

scheduling, MICS (Multihop Access on Initial Channel by Scheduling) [66], [67], based

on TDM (Time Division Multiplexing) to transmit data by way of multihopping. When

a source node transmits a packet, it transmits it on the designated timeslot, on one hand.

When an intermediate node, on the other hand, relays packets, the node transmits them

on the timeslots designated to the source nodes, not on the timeslot of the intermediate

node. Therefore, even if packets converge from several nodes to the intermediate node,

the node can complete to relay the packets in the next frame without packets stacked in

the queue. However, source nodes have to wait for sending the next packet while other

nodes occupy its timeslot to relay the packet. Though this protocol requires the source

nodes to impose a restriction, it achieves an efficient and fair transmission on

intermediate nodes. The MICS protocol requires BS to send back a reply packet

(REPLY) to indicate the idle state of the timeslot to the source node.

Figure 4.11 shows the access scheduling in multihop by MICS protocol. Each node

is assigned at one of timeslots. They can transmit their own packets at the designated

timeslot. In the figure, T1 is a DCN; it can transmit a packet in every slot, and receive

the REPLY piggybacked on the ACK packet between BS and the node. A multihopping

node sends its own packet to a neighbor at the designated slot; T2 sends its packet to T1

at T2's slot. An intermediate node, on the other hand, does not relay the packet on its

own slot, but relays it on the slot of source node. In the figure, T1 relays the packet of T2

on the T2's slot, and sends back the REPLY on the T2's slot as well. Likewise, Tn

75

transmits its packet on the Tn's slot, while the intermediate nodes, Ti, Tj, etc relay the

packet on the Tn's slot. Finally the packet reaches BS, and vice versa.

In this protocol, since an intermediate node can forward every packets at the next

frame, there is no stacked packet in the queue of the node, even though several

neighbors require to forward their packets. Despite the advantage, the source node has

to wait for the REPLY during the duration (td), which is the transmission delay for two-

way, in the case of the node Tn, as illustrated in Figure 4.11.

Regarding the error process, a node received a packet replies ACK at the same

timeslot. Note the symbol of ACK is omitted in Figure 4.11. If a node does not receive

the ACK, it knows the failure by the time-out process. The node does not retransmit the

packet in the MAC protocol, while the failure is informed to the upper layer. The node

sends back the error message in the downward route, according to the routing protocol,

as described in the previous section. In fact, the failure happens on the REPLY, the node

is not possible to transfer the error message, has to discard the message. The source

node decides the failure by the error message or by time-out process in case of the lack

of REPLY. Since the source node knows the transmission delay (td) in advance in this

protocol, provided that retransmission process is not carried out, the node is possible to

detect the failure after td.

Actually, restricted retransmissions in the MAC layer might be useful if the

retransmission process is optimized for a specific condition. However, since the

optimization of the retransmission is not a primary discussion in this paper, we do not

discuss about it in detail.

76

DATA (Uplink) REPLY (Downlink)

Figure 4.11 Multihop access scheduling protocol: MICS.

(T1)

(T2)

(T3)

(Tn)

Slot Frame

k

k+1

T2 T1 BS

(T1)

(T2)

(T3)

(Tn)

(T1)

(T2)

(T3)

(Tn)

(T1)

(T2)

(T3)

(Tn)

k+2

k+m

fram

e

Time

Tn

timeslot

Tran

smis

sion

Del

ay =

t d

Ti Tj

77

4.7 Scenario for Route Discovery and Multihopping

We have presented a route discovery protocol, LISNER, and a multihop access

scheduling protocol, MICS, for ECCA to operate in disaster communications. We

demonstrate the scenario for the protocols, based on the operation of Figure 4.11 and

Figure 4.12.

We assume that T1 is able to access BS directly (Hop-CNT=1), and T2 and T3 are

disconnected from BS. T2 locates near T1, T3 near T2, respectively, as depicted in

Figure 4.12. While T1 periodically transmits a packet to BS, if T2 can hear the

communications of T1, it recognizes that T1 is able to reach BS, and the Hop-CNT is

one (1). Then, T2 records in the entry table the address of T1 as the next hop node, and

requests T1 to forward a packet to BS, setting the Hop-CNT at two (2). The packet

header from T2 to T1 includes the followings, Rx=T1, Tx=T2, Dest=BS, Src=T2 and

Hop-CNT=2. When receiving the packet from T2, T1 relays the packet in T2's slot of the

next frame, setting the Hop-CNT at one (1). Concurrently, T1 records the downward

route in the route table to reach T2; i.e., the source node is T2, the sender is also T2.

When a reply packet for T2 arrives at T1 from BS, T1 decides the route to T2 according

to the route table, and then relays the reply packet to T2.

Likewise, T3 recognizes that T2 can reach BS at two hops by monitoring the

communications, as depicted in Figure 4.12. When T3 sends T2 a packet in its own slot,

T2 relays the packet to T1 in T3's slot according to the entry table. As a result, the packet

of T3 reaches BS via T2 and T1. Even if packets from several nodes converge to T1, T1 is

capable of forwarding packets of them within one frame since it can use timeslots of the

source nodes.

In the event that T2 cannot receive ACK from T1 due to communication failure, T2

detects the failure in the MAC layer, and then informs it to the network layer. The

network layer of T2 sends back the expiration message to T3 in the next frame, since the

node has no route in the entry table. If receiving the expiration message, the source

node T3 waits during the transmission delay (td), and then retransmits the packet in

another route via Ta even if it takes four hops from T3 to BS. In the event that T2 cannot

78

receive REPLY from T1, T1 is not possible to deliver the error message to the downward

node. Consequently, though T3 cannot receive any error message, it recognizes the

failure by time-out process, waiting during the duration (td). After that manner, T3 can

retransmit the packet via an available route.

Figure 4.12 Scenario for multihopping in ECCA

BS

Hop=1

T1T2

Hop=1

Hop=2T3

Hop=2

Hop=3

T4

T5

Hop=2

Hop=2

Src Send T3 T3

Route table

BSNext Hop

0

Entry table

Src Send T2T3

T2T2

Route tableT1

Next Hop 1

Entry table

Ta Tk

T2 Next Hop

2

Entry table

Ta 3

79

4.8 Summary

We have presented a hybrid wireless network scheme, ECCA, which combines ad

hoc networks with a centralized network, to satisfy the requirements for connectivity

and accessibility of the network in disaster communications. The routing protocol,

LISNER, allows a node to find an available route via neighboring nodes by monitoring

scheme, not using a control packet such as the route request. The protocol can achieve

multihop transmission by unicasting, resulting in stable communications. The MAC

protocol for multihopping, MICS, provides forwarding a packet quickly even in the

congested state in the network. Hence, ECCA satisfies the requirements in disaster

communications to ensure accessibility without an extra-delay and to provide a robust

connection with ad hoc networking. ECCA can provide the stable routing process and

the feature for congestion avoidance.