13.07.2015 Views

Page 2 Lecture Notes in Computer Science 2865 Edited by G. Goos ...

Page 2 Lecture Notes in Computer Science 2865 Edited by G. Goos ...

Page 2 Lecture Notes in Computer Science 2865 Edited by G. Goos ...

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

252 C.J. Colbourn, V.R. Syrotiuk, and A.C.H. L<strong>in</strong>gIntuitively, while Chlamtac and Faragó [2] strive to get one free slot per frame,Ju and Li [10] aim to get many free slots per frame.In both studies, however, the figure of merit is m<strong>in</strong>imum throughput measuredas number of free slots with<strong>in</strong> a frame divided <strong>by</strong> frame length. To employsuch an analysis, a transmitt<strong>in</strong>g node must be able to transmit multiple differentpackets with<strong>in</strong> a frame. How does it decide to transmit a “new” packet? Inthis environment, it is expected that collisions occur, and topology-transparencydictates that the collisions cannot be anticipated. Hence an acknowledgementscheme is needed. Both schemes based on orthogonal arrays can transmit <strong>in</strong> twoconsecutive slots, and <strong>in</strong>deed must send different packets <strong>in</strong> these slots to achievethe m<strong>in</strong>imum throughput <strong>in</strong> their analyses. Both propose an acknowledgementscheme that <strong>in</strong>volves <strong>in</strong>stantaneous acknowledgment of successful receipt withoutlengthen<strong>in</strong>g the slot. Naturally, this is an optimistic assumption to facilitatethe analysis. However, the analysis can be mislead<strong>in</strong>g if it leads us to seek manyfree slots <strong>in</strong> a frame without an acceptable (realistic) acknowledgment scheme.For purposes of comparison, we consider the throughput measures employed <strong>in</strong>[2,10,16]. We also adopt a more conservative approach.We consider a more realistic model for acknowledgements. Rather than a slot<strong>by</strong> slot acknowledgement, we assume we can piggyback an acknowledgement ontoa packet sent from the dest<strong>in</strong>ation. In the worst case, this might require that thesender wait an entire frame. Hence we def<strong>in</strong>e frame throughput as the throughputachievable on a per frame basis. This properly <strong>in</strong>corporates the length of theschedule <strong>in</strong> the throughput calculation.In this section we <strong>in</strong>vestigate three questions:1. What is the probability of a successful transmission <strong>in</strong> a frame?2. What is the expected throughput?3. What is the expected frame throughput?All are functions of the number of active transmitters among the neighboursof a node.Consider a situation with sender S and receiver R. Let S be a schedulefor sender S and T 1 ,...,T D−1 be the subsets that correspond to the schedulesof the other active neighbours of R (here, we assume the worst case, when allneighbours are transmitt<strong>in</strong>g). Let T D be the subset correspond<strong>in</strong>g to the schedulefor R, and assume that R is also active.The probability of successful transmission with<strong>in</strong> a frame is just the probabilitythat S has a slot that does not appear <strong>in</strong> T 1 ,...,T D . Expected throughputthen, is the expected number of such slots. The frame throughput is the expectednumber of slots over the frame length. This effectively normalizes the expectedthroughput <strong>by</strong> frame length allow<strong>in</strong>g easier comparison between Ste<strong>in</strong>er systems.We derive these measures analytically but present the derivations elsewhere.The most complex derivation is for expected throughput. We did this for schedulesthat correspond to orthogonal arrays <strong>in</strong> [16]. This formulation may be usedas a basis to derive expected throughput for schedules that correspond to Ste<strong>in</strong>ersystems.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!