How Power Adjustment Diminishes Slot Congestion

Chapter 3 Preliminaries

3.3 How Power Adjustment Diminishes Slot Congestion

The basic idea to resolve the channel (slot) congestion problem is by adjusting the transmission power. As shown in Figure 4, by shrinking the transmission power of node A so that is covers only nodes B and C (without covering node D), slot 3 is free to node A. Thus, node A can transmit its FI on slot 3 if there is no other node reserving the same slot for an entire frame. In this way, we can avoid that nodes A and F use the same slot to send their FIs, which in turn, incurs a collision at node D.

Figure 4. Node A adjusting its transmission power to achieve a slot

3.4 Challenges

From the above example, we can see that reducing the transmission power can improve the spatial re-use in the network and resolve slot congestion. However, how to determine the transmission power for congested nodes? Such as the case in Figure 5, the default power is 35 meters. Suppose that node A adjusts its transmission power from 35 to 34 meters, the slot congestion problem still exists, since the power range remains too large to infer with other nodes. On the other hand, if node A reduces its transmission range to 24 meters, the transmission range is too smaller. As shown in Figure 6, it may cause a larger end-to-end delivery delay. When node A broadcast a message, node F receives the message four hop counts later (i.e., A -> C -> B -> D ->

F). But, the best path should be A -> B -> D -> F. Even worse, node A will disconnect to other nodes if node A adjusts its transmission range below 20 meters as shown in Figure 7. After adjusting power levels it must create unidirectional links (i.e., a lower power node might not be received at a higher power node). Such as that node A can receive FI from nodes B, D, but nodes B, D cannot receive FI from node A as shown in Figure 6. These are the significant challenges what need to overcome.

A Figure 5. The power level is too larger.

Figure 6. The power level is too smaller.

Figure 7. The power level is too smaller and node A disconnect to other nodes.

Chapter 4 Protocol Design

In this chapter, we present the Power-Control ALOHA (PC ALOHA). First, we describe the main idea that how we control the power. Then, we define a unique data structure, called Extended Frame Information (EFI) in our protocol. After that, an adaptive power control mechanism is presented. We also discuss how we handle the symmetric and connectivity problem in our protocol. The algorithm of PC-ALOHA is summarized in the last part.

4.1 Main idea

In the Chapter 3, we have observed that a node can reserve a reserved slot if reducing the power so that a receiving node will not be interfered by the two nodes and the most challenging problem is to determine the transmission power for the congestion nodes.

Our goal is to reduce the power for congested nodes with the least increment to the frame size, i.e. the least increment to the end-to-end delay. The main idea is explained as follows: As a node is congested, we intend to reduce the least amount of the node’s transom power such that any transmission from the node will not interfere to any neighboring node at a certain slot. At the same time, we avoid the network be partitioned to different groups. As shown in Figure 8, it is sufficient to obtain a free slot 3 if the congestion node A only reduces the power to cover nodes B and C. Why

we select to re-use slot 3, because there aren’t any one-hop neighbors use the slot 3. In this way, it has the least reduction of power, which avoids the possibility of increasing end-to-end delay when node A wants to broadcast a message to its neighbors.

Figure 8. Adjust the congestion node A power levels.

4.2 Extended Frame Information

To discover the possible spatial reusability according to the positions additionally carried in the FI, called extended FI (EFI). The content of FI is shown in Figure 9. ID indicates the identifier of the node that sends this FI. Length indicates the FI packet length. X, Y, Z indicates the X, Y, Z coordinate system information from Global Positioning System (GPS). Slot Information (SI) contains the status (FREE or BUSY) of the corresponding slot.

Figure 9. Information recorded in EFI.

Each node will maintain an EFI table includes the slot status, distance to the one-hop node, and which node is using the slot as shown in Table 1. We establish a definition as:

Definition: A slot can be recorded as “FREE”, “BUSY by node i” or “RESERVED by node i” by node j:

1. “BUSY by node i”: When node j receives the FI from node i, and the information will be written into its broadcasting EFI.

2. “RESERVED by node i”: The information come from its one-hop neighbors. It means that a two-hop neighbor has occupied this slot, so node j cannot contend for this slot or collisions may happen somewhere. And Node j won’t write this record into its broadcasting EFI.

3. “FREE”: The slot is free. Node j can contend for this slot.

slot 1 2 3 4 5

id B C D E

status BUSY BUSY FREE BUSY RESERVED

distance 25m 20m 30m 20

Table 1. EFI table.

4.3 Adaptive Power Control

Before we present how reservation works, we should present some definitions as shown in Table 2.

Vi ：the node i

Dij ：Distance from node i to node j OH ：One-hop member

TH ：Two-hop member

SOH ：Slot using by one-hop member STH ：Slot using by twp-hop member

P  ：The minimum amount of power range decrease

Padj ：The transmission power range after adjusting P_maxt ：The node maximum transmission power range

Dji ：The distance from the transmission node j to received node i Table 2. Symbol table.

The node V join the network, if _i V can find a FREE slot from (_i S_OH  S_TH), send the EFI on the FREE slot. Otherwise, when the channel is congestion (i.e., V _i cannot find any more FREE slot from EFI table, we can choice a S_TH slot that can make its own EFI table as FREE through shrinking the transmission radius as

P

P_adj^t  _ij . Now, V can contend for the FREE slot. After adjusting power range, _i it will create unidirectional links. The V must maintain the EFI table carefully. _i When V receives an EFI from _i V_j, V must take care about the _i D^r_ji between two

nodes. If V finds _i P_adj^t D^r_ji, V still need mark _i S_OH as BUSY. But, V must _i mark S_TH as FREE. However, two different OHs maybe share the same S_TH information at same time, we just record the Min{D^r_ji,D_ki^r } in the EFI table. Where Min{D^r_ji,D_ki^r} is the shortest transmission range between them.

A C

Figure 10. channel congestion at node A

As shown in Figure 10, the frame size is 5. Node A receives the EFI from its one hop members (i.e., B, C and D) and maintains its own EFI table. Node A cannot transmit its EFI since there is no more free slot. Before node A adjusts its transmission power, node A selects a RESERVED slot 3 (or 5) to send its EFI with maximum transmission power 35 meters, node A will incur a collision at D (or C).

As shown in Figure 11 and Table 2, the slot 3 is only used by two-hop member (i.e., node F). After node A adjusts power range to 30 - P_ meters, node A can mark the slot 3 as FREE as shown in Table 2 and then node A can send its EFI at slot 3 without colliding at node D. At same time, node A still marks slot 4 as “slot 4 BUSY by node D”.

Figure 11. Controlling power for channel congestion at node A

slot 1 2 3 4 5

id B C D E, G

status BUSY BUSY FREE BUSY RESERVE

distance 25m 20m 30m dist to C

20=min{20, 30}

Table 3. Controlling power for channel congestion at node A

4.4 How to maintain network Connectivity

The Gabriel Graph (GG) is a connection scheme proposed by Gabriel and Sokal (1969) [22], two points are connected when the circle associated with the diameter that has the two points as endpoints does not have another point within its circumference. Mathematically, the GG is defined as follows: An edge

 

u,v exists between vertices u and v if no other vertex w is present within the circle whose

diameter is uv . In equational form : wu,v: d_uv² d_uw² d_vw² . As shown in Figure 12, points u and v are Gabriel neighbors. Otherwise, the presence of point w within the circle prevents points u and v from being Gabriel neighbors as shown in Figure 13.

u v

Figure 12. Points u and v are Gabriel neighbors.

u v

Figure 13. Points u and v are not Gabriel neighbors.

From the definition of GG, we can try to adjust the transmission power of the dumb node(s) (i.e., a node cannot reserve any free slot.), if we can find a node w as shown in in Figure 13 from the one hop neighbors. At this time, the dumb node(s) can re-use the time slot(s) and maintain network connectivity at same time. The significant difference between Figure 16 and Figure 17 is that we can guarantee the network still connectivity when frame size is 5. For our application, the algorithm should be run in a distributed fashion by each node in the network, where a node needs information only about the positions of its one-hop member(s) as the algorithm's input.

A C

Figure 14. Network topology of RR-ALOHA MAC protocol

A C

Figure 15. Network topology of PC-ALOHA MAC protocol

4.5 How to handle in symmetricity

Adjusting transmission range will create unidirectional links (i.e., node C can receive EFI from nodes node A, but nodes A cannot receive EFI from node C) as shown in Figure 16. When the new join node A try to reserve slot 5 for sending the EFI and the power range can cover to C, because it cannot get any slot status from C’s EFI(i.e., A cannot know E exist.). At this time, both nodes A and E would transmit their EFI at slot 5 that incur a collision at C (i.e., C’s EFI will mark the slot 5 as FREE, because it cannot receive any EFI at slot 4 in last frame). Then, E will find one EFI of its one-hop neighbor(s) don’t mark slot 5 as “BUSY by node E”. Now, node E will detect that incur a collision at somewhere. Node E just need to re-entrance the network and it won’t cause any chain reaction.

Figure 16. Network symmetricity

4.6 PC-ALOHA Protocol

We summarize the above describe into a series of protocols the main operation of PC-ALOHA at each slot when node join the network, operation of EFI sending and receiving routine, and Power Control of congestion node in Figure 17~20. And the PC-ALOHA flow chart has shown in Figure 21.

Protocol 1: Operation of PC-ALOHA at each slot timer Protocol:

/* parameters and Flag defined

WAITING : waiting to contend for a slot CONTENDING : occupation or contending for a slot Status : status of the node

5 set Status=CONTENDING of the node

6 else

7 reset Timer of the node

16 if there isn’t any collision (feedback from receive algorithm) then

17 send the EFI call. call sendFI()

18 set Status=CONTENDING of the node

19 return

20 else // Collision

21 Set Status=CONTENDING of node and contend for slot again.

22 reset Timer of the node

23 Timer of system++

24 return

25 else

26 Timer of system++

27 receive EFI and maintain EFI table only

28 return

Figure 17. Operation of PC-ALOHA at each slot timer Protocol

---

Protocol 2 Operation of EFI sending routine:

--- /*

Parameters and Flag defined

1 if my contending slot is coming then

2 send the EFI packet by transmission power piggybacking my X, Y, 3 and Z coordinate and slot using status of my one-hop neighbors 4 return

Figure 18. Operation of EFI sending routine Protocol.

---

Protocol 3 Operations at the reception of an EFI ---

Parameters and Flag defined

1 if my transmission power >= distance to the transmission node then 2 maintain slot status, distance to the transmission node and who 3 use the slot in its EFI table

4 else

5 mark the slot that only using by two-hop neighbors as FREE 6 return

Figure 19. Operations at the reception of an EFI Protocol

---

Protocol 4 Power Control of congestion node ---

4 check each one-hop neighbor

5 if we can find one-hop node didn’t satisfy GG constraint then 6 set release flag =TRUE

Figure 20. Power Control of congestion node Protocol.

The details of protocol 1 are described as follows:

- line 1: Check if the node is waiting to contend for slot, after listening to the slots occupation for an entire frame

- line 2~5: If the incoming slot is free and the node try to contend for the free slot.

First, the node must send out an EFI packet and change the node status.

- line 6~8: If the node don’t contend for the incoming free slot, it would wait the next free slot coming and repeat line 2~5 steps.

- line 9~14: If the node cannot find any free slot, the node can follow the GG constraint to shrink its transmission power for re-using the reserved slot.

- line 15~24: Check whether all the one-hop neighbors received my EFI. If agree, sends out the EFI packet at the coming slot again. Otherwise, try to wait another free slot coming and contend for it.

- line 25~28: Just listening the EFI packets from one-hop neighbors and maintaining EFI table.

The details of protocol 2 are described as follows:

- line 1~4: Nodes share their perceived information and X, Y, Z coordinate to each other by properly broadcasting packet EFI.

The details of protocol 3 are described as follows:

- line 1~3: If our power range can cover to the transmission nodes, we will record all EFI information from one-hop neighbors in EFI table.

- line 4~6: We must consider unidirectional links. When our power range cannot cover to the transmission nodes, we can mark the slot which using by two-hop neighbor only as FREE.

The Power Control of congestion nodes are described as follows:

- line 1~2: Find out the slot only used by two-hop neighbor from our EFI table

- line 3~6: Find out a one-hop node which didn’t satisfy GG constraint when we adjust the power range. Then, we can guarantee the network still connectivity.

- line 7~8: Go to next step.

- line 9~10: Go to next step.

- line 11~13: If we can find out the one-hop neighbor, shrink our transmission power for re-using the reserved slot.

As shown in Figure 23, we demonstrate the flow chart of PC-ALOHA Protocol.

Figure 21. PC-ALOHA flow chart

As shown in Figure 2, there are 7 nodes contending for 5 slots. After a listen interval, each node has to contend to reserve an available slot and use the slot in subsequent frames. According to our protocol and flow chart, the simulation statuses of each node shown in Figure 22 and described as follows:

-- In Frame 1:

Node B: Try to send an EFI to contend slot 1 for its transmission, and set up the status from WAITING to CONTENDING at same time.

Node C: Try to send an EFI to contend slot 2 for its transmission, and set up the status from WAITING to CONTENDING at same time.

Node F: Try to send an EFI to contend slot 3 for its transmission, and set up the status from WAITING to CONTENDING at same time.

Node D, G: Try to send an EFI to contend slot 4 for its transmission, and set up the status from WAITING to CONTENDING at same time. Actually, the EFIs will collision at node F. In next frame (i.e., frame 2), EFI from its one-hop neighbor, Node F, does not indicate that slot 4 was marked as BUSY by node D or G.

Node A, E: Try to send an EFI to contend slot 5 for its transmission, and set up the status from WAITING to CONTENDING at same time. The EFI will collision at node C. So, node A and E need to listen a frame interval and contend a free slot for its transmission again.

-- In frame 2:

Node B, C and F:

The contending is successful and nodes B, C and F will use the slot 1, slot 2 and slot 3 in subsequent frames as long as the node has packets to send.

Node A, D, E and G:

The contending is unsuccessful. Nodes A, D, E and G have to listen a frame time and try to reserve a free slot again. All of them must set up the status from CONTENDING to WAITING at same time.

-- In frame 3:

Node A: It does not contend a free slot for its transmission in frame 3.

Node D: Send an EFI to contend other slot 4 for its transmission, and set up the status from WAITING to CONTENDING.

Node E, G: Try to wait another free slot 5 coming and contend for it. And set up the status from WAITING to CONTENDING. Nodes E and G are not two-hop neighbor, so they will reserve slot 5 for theirtransmission successfully.

-- In frame 4:

Node A: Node A can not find any free slot for its transmission end of frame 3.

According to our power control protocol shown in Figure 21, it will find slot 3 can be re-used. All of Node A~G will reserve a slot for their transmission in subsequent frames

Figure 22. Reserved slot of each node

☆

Chapter 5 Simulation Results and Analysis

5.1 Simulation Environment

In this section, we compare the performance of the proposed PC-ALOHA MAC protocol with that of RR-ALOHA MAC protocol in ns-2 [23]. The duration of each simulation is 10 seconds. Each simulation runs 20 times. The data rate is 2 Mbps (802.11b). All nodes are assumed to be stationary and their maximum transmission ranges are 250 meters. The EFI frame length is fixed at 80 bytes. The slot time is fixed at 2ms. The numbers of default nodes are 100 nodes, and the deployment region is 1000*1000 meters.

5.2 Results Analysis

A). Frame size vs. Reserving rate:

First, the aim of this experiment is to study the reserving rate relate to the frame size. As shown in Figure 22, the number of nodes is inversely proportional to the percentage of reserved nodes on RR-ALOHA. On the other word, PC-ALOHA needs a fewer slots to achieve 100% reserving rate than RR-ALOHA in a dense network. A larger frame size may incur a larger delay since each node has to wait for a longer period of time before the next frame coming. Otherwise, the smaller frame size can update the message more quickly.

collision

0 50 75 100 125 150

Figure 23. Frame size vs. Reserving rate

B) Single-hop performance:

As shown in Figure 23, RR-ALOHA requires 33 slots to achieve 100% of reserving rate, but PC-ALOHA requires only 28 slots to achieve 100% of reserving rate. PC-ALOHA can save about 15% frame size (28/33 =84.5%). PC-ALOHA frame size is smaller than RR-ALOHA, PC-ALOHA has a lower message update delay. It shows clearly, the slot reserving rate of RR-ALOHA is related to the frames size.

PC-ALOHA always keeps the nodes reserving rate upon 98%. However, it is a dangerous when the channel is congestion in RR-ALOHA network. Because of many nodes have neither the right to transmit nor the guarantee of receiving packet from all its neighbors. In other words, the congestion nodes do not join to the network.

As shown in Figure 24, in order to enhance the slot reserving rate, PC–ALOHA need to reduce the transmissions range for slot time re-using. If the frame size is smaller, nodes will transmit at a smaller transmission range.

0 22 24 26 28 30 32 34 36 38 40

Figure 25. average transmission range C) Convergence :

Although schedule-based MAC protocol can provide each node a contention-free opportunity for data transmission without collision, the node still need to contend for slot reservation by using RR-ALOHA or PC-ALOHA. Especially when it comes to

result, it may take several frames until all the reservation processes complete.

As shown in Figure 25 and Figure 26, the RR-ALOHA protocol slot reserving rate almost can upon 100%. It means that the channel is not congestion. So the power control mechanism did not need to be triggered often. As a result, the PC-ALOHA

在文檔中具壅塞控制能力之低延遲分散式分時多工無線隨意網路存取協定 (頁 20-0)