Future Network Design Project (2011)

Published on January 2017 | Categories: Documents | Downloads: 35 | Comments: 0 | Views: 212
of 8
Download PDF   Embed   Report

Comments

Content

6.267: Heterogeneous Networks

Design Project 2: Seismic Warning MAC Network
December 12, 2011 Instructor Vincent W. S. Chan Authors Matthew Bremer Bruchon Lars Kristian Johansen Surat Teerapittayanon

1

Design Overview
The purpose of this network is to report earthquakes with a high level of reliability within a short time frame. We designed a modified CSMA system which begins with contention slots, after which the central base station assigns data communication slots based on the priority of each monitoring station. This repeats after all allotted communication slots have elapsed.

Assumptions
To focus on analyzing the link layer and MAC design, we assumed the following: ● All of the stations use GPS clocks which are all synchronized, and channel delay is constant. These two assumptions together allow us to ensure there is no interference due to overlapping transmissions. ● The channel is homogeneous; the same ionosphere properties apply to all of the stations in California. ● Transmissions from the base station have a negligible failure rate. This is very idealized, but not entirely unreasonable, as the base station has no power constraints and a better transmitter than the other stations. It is also not strictly needed, since our design includes a period in which monitoring stations acknowledge packets from the base station. ● Our forward error correction code is assumed optimal. Please refer to that section for details. ● Erasure probability is 10-8.

Design variables
P_be, bit error rate = 10^-2 P_e, erasure probability = 10^-8 T_p, propagation delay R_l, low channel data rate = 4kbps R_h, high channel data rate = 40kbps n, number of monitoring stations = 100 bs, base station

Techniques
We use the following techniques in our design. Please see the references for more information. Random Linear Coding We used Random Linear Coding (RLC)1 for packet delivery. Choosing large enough field size (e.g. 256), with high probability each packet will be linearly independent. Then, the expected number of packets until decode is n/(1-P_e) where P_e is the erasure probability and n is the number of packets. Reed Solomon Codes We used Reed Solomon Codes (RSC)2 for per-packet forward error correction. Reed Solomon Codes satisfies the singleton bound.3 Then, the number of bits needed to correct a packet is
1

Ho, T.; Medard, M.; Koetter, R.; Karger, D.R.; Effros, M.; Jun Shi; Leong, B.; , "A Random Linear Network Coding Approach to Multicast," Information Theory, IEEE Transactions on , vol.52, no.10, pp.4413-4430, Oct. 2006.

2

m/(1-2P_be) where P_be is bit error rate and m is the number of bits.

Medium Access Control Layer Design
Our MAC layer uses CSMA scheme modified with a slotted contention period, forward error correction, allocation of a dynamic number of slots after each contention period, and periodic testing of channel properties.

Figure 1: Overall Scheme with Contention and Feedback Period Details Stage 1: Contention Period Each of the 100 stations is given a slot in which to send their contention packet. The contention packet is simply two bits corresponding to the priority of their pending transmission: ● 11: emergency signal ● 10: emergency data dump ● 01: hourly data dump ● 00: no transmission pending

2

"Reed Solomon Error Correction." Wikipedia, The Free Encyclopedia. Wikimedia Foundation, Inc. Accessed 11 December 2011. http://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correction 3 "Singleton Bound." Wikipedia, The Free Encyclopedia. Wikimedia Foundation, Inc. Accessed 11 December 2011. http://en.wikipedia.org/wiki/Singleton_bound

3

Each station’s contention period is assigned in Stage 2. In the “starting” case of resetting or initial startup of the system, the synchronization of the contention periods is used: if no contention schedule is established yet, some statically agreed upon time (e.g., the start of the next minute) would start the contention period and each station would have an agreed upon slot (e.g., Station 3 would use the third slot). In this special start case, the lower data rate would be used. Stage 2: Feedback Period After processing the data from the contention period and determining which stations can send data, the central station broadcasts the following feedback: ● The current channel capacity, as determined in Stage 5; this can be one bit since there are only two channel states. ● The time at which the first data packet should be sent. This can be done in 7 bits, since we only send the number of stations that are to be allocated data slots, and since this allocation is of fixed size, the monitoring stations can calculate when the first data packet will be sent. ● The time at which the next contention period will begin, which depends on channel capacity and the number of stations allocated a slot for data transmission. It also depends on which type of data packets there is to be sent. Since there are only two different types, this can be done in 7+7 bits, since we send the number of stations to send data and also the number of stations of one of the types. Out of that, each monitoring station can calculate when the next contention period will begin. At this point, the station sends allocation data packets which include a station ID, slot size allocated in bits, and how many of the small and large data packets that are to be sent before him. This can be done with 22 bits, 1 bit for type of data and 7 for the station ID and 14 to tell how many small and large data packets there are to be sent before him. If a station’s contention is denied, no allocation data packet is sent for it. Every monitoring station listens for allocation data packets of fixed length either until it receives a packet addressed to its own station ID, or until the first data packet slot. It then stops listening for allocation packets. In order to ensure a high level of responsiveness to earthquakes, during normal operation (i.e., the only transmissions are hourly data dumps or software updates), only one station would be allowed to transmit its data at a time. This way, each data transmission stage would be very short, and the contention period would happen very frequently, allowing for more emergency signaling to start much faster. Stage 3: Data Transmission Based on feedback from Stage 2, each station knows when its slot begins and at what rate to send data. Each slot is either 511 bits or 674 bits including error correction. Data dumps are split into multiple packets across cycles from Stage 1 to 5, and use RLC as discussed in the “Analysis” section. Packet types If we classify packets by data block, there are three types: ● Short data block, including emergency signal packets ● Long data block, including emergency data dump packets, hourly data dump packets, and software update packets 4



Arbitrarily long data blocks, including software update packets

Packet size In our design, every packet has 500 content bits plus some redundancy. The number of redundancy bits is different depending on what type of packets. For short data block (500bits) The size of short block packet is 500/(1-2P_be) ~ 511bits, where P_be is 10^-2. For fixed-length long data blocks (10kbits) and arbitrarily long data blocks We divide the 10kbits block into 20 packets of 500bits, and use RLC [1]. Assume operating on GF256, RLC incurs 20*8=160 additional header bits per packet. Then, we apply RSC [3] to 660bits. The total packet size is 660/(1-2P_be) ~ 674bits. Software updates function similarly, except that the total length of the transmission (i.e., the size of the software update) can be arbitrarily long. Stage 4: Acknowledgment The base sends an acknowledgement (1 ACK bit plus 1 error correction bit) to each station. If a negative acknowledgment is sent, then that station will re-send its previous delivery at the same priority level. The exception is if the station detects an earthquake in this interval, in which case the lower-priority data is deferred and the emergency signal (priority 11) is sent next. In this stage, the monitoring stations also send acknowledgements to the base station in a similar manner; this is needed when the software updates are being sent by the base station. Stage 5: Channel Testing An arbitrary station (assigned by the base during Stage 2) attempts to send an arbitrary bitstream of 50 bits to the base at the fast data rate of 40 kbps. This bitstream is statically defined and known by all stations. The base compares the received data to the expected bitstream. If its accuracy is below a threshold, e.g., more than half of the bits are incorrect, the lower data rate is used until Stage 5 tests the channel again. Software Updates The base station sends an update to one station at a time, so that the system cycle will not be too long.

Analysis
1. System cycle Note that the below times do not include the transmission delay; this is because our design is synchronized and waits until the Acknowledgement period to report whether data was received correctly. To the total system cycle time, a RTT delay would be added (to account for the delay of 5

sending data once plus the delay to hear an acknowledgement between the data transmission and acknowledgement stages). Size Contention Period Feedback Period Data Transmission Acknowledgment Channel Testing 200 bits [22,2222] bits [0,67400] bits 400 bits 50 bits Transmission Time for 4kbps (ms) 48.8ms [5.4,542]ms [0,16.45]s 100ms 12.5ms Transmission Time for 40kbps (ms) 4.8ms [0.54,54.2]ms [0,1.645]s 10ms 1.25ms

Feedback Period Upper bound: 1+14+7+22*100 bits. Lower bound: 1+14+7 bits. - 1 bit for decision of data rate. - 14 bits for next contention, 7 bit for the number of data packets and 7 bit for the number of one of the kinds. - 7 bits to tell when the first data packet begins. - 22 bits to tell a station when to send its allocated data packet. Time: For 4kbps: Upper bound: 0.5424 seconds. Lower bound: 0.00537 seconds. For 40kbps: Upper bound: 0.05424 seconds. Lower bound: 0.000537 seconds. Data Transmission Size in bits: Upper bound: 674*100 bits Lower bound: 0 bits Time: For 4kbps: Upper bound: 16.85 seconds Lower bound: 0.0 seconds For 40kbps: Upper bound: 1.685s Lower bound: 0.0 seconds 6

Total System Cycle Time Upper bound: T_system_cycle = 17.15 seconds, using all 100 data packet slots with the largest data packet for all of them. Lower bound: T_system_cycle = 336.6 ms, only this data packet is transmitted out of all the possible data packets to transmit in a cycle. To reduce the system cycle time during normal operation, we impose a limit on how many packets can be transmitted during the data transmission stage. In fact, we would limit the number of transmitting stations to one, so that the system cycle time would equal the lower bound of 336.6 ms. 2. Transmission Time of 10kbits block using RLC Given a poor channel with a slower data rate, the expected number of packets transmit before success is 20/(1-P_e) ~ 20.0000002, where P_e is 10^-8. Thus, the time takes to transmit 10kbits block is ~ 20*T_system_cycle = [6s,343s]. 3. Decoding Time of 10kbits block using RLC We use Gaussian Elimination to decode the block. The complexity is O(n^2k) where n is the number of packets and k is the packet length in 8bits chunks. In our case, k is 500/8 and n is 20. The number of operation required is 500/8*20=1250 operations. Assume the processor is 1Ghz. Decoding time is 0.00125 ms which is negligible, compared to T_system_cycle.

Discussion
1. What is the efficiency in normal operation (i.e. when there isn't an earthquake alert in progress)? We consider here detailed data reports and software updates, which use the same size data blocks. Both are transmitted using RLC. Expected time it takes is around 336ms*20*100 = 672s to send updates to all stations and to receive detailed data report from all stations, given a poor channel. Note that during normal operation, we allow only one station to transmit data; this is a tradeoff that sacrifices efficiency during normal operation to improve responsiveness to earthquakes. 2. When an earthquake alert occurs, what is the probability that all emergency alerts will be received correctly within 15 seconds? Assuming the worst case, 4kbps case, our system takes (48.8+112.8+2495+100+12.5)ms=2.769 seconds to transmit the emergency alerts, based on the values found in the “Analysis” section. To this we must add a “waiting time” which represents the worst-case in which the earthquake is first detected immediately after the contention period (Stage 1) ends during normal operation. Because

7

during normal operation, only one station at a time is given a slot in which to transmit data, the delay time is (using values from the table in the “Analysis section): 48.8ms + 10.7ms + 164ms + 100ms +12.5ms = 336ms So the total time to send all alerts, in the worst case, is 3.105 seconds. 3. What is the probability that all critical detailed data reports will be received correctly within 90 seconds? We assume that at most 20 monitoring stations will need to transfer the critical detailed data reports to the base station, so our analysis is based on this number. When this happens the base station does not allocate data slots to any other monitoring stations for either hourly data dumps or software updates, it just allocates the critical data dump packets for the stations that requests it. Therefore the time needed to transmit all of the detailed data reports is (using values from the table in the “Analysis” section): 20*(48.8ms+112.8ms+3.29s+100ms+12.5ms)=71.30s. This time must be added to the total time needed to send all emergency alerts, including the initial “waiting time”. So the total time is 3.10s + 71.3s = 74.4 seconds.

8

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close