Academia.eduAcademia.edu

Figure 14 – uploaded by Jiazi Yi

See full PDFdownloadDownload figure
Table 6.1: Parameters for NS2 simulation

Table 6 1: Parameters for NS2 simulation

Related Figures (150)

Figure 1.1: The OSI reference model (extracted from (Tanenbaum, 2003))
Figure 1.1: The OSI reference model (extracted from (Tanenbaum, 2003))
Figure 1.2: TCP/IP and OSI reference model (extracted from (Tanenbaum, 2003)) and flow control. It is widely used for one-shot, client-server-type request-reply queries and appli- cations in which prompt delivery is more important than accurate delivery, such as transmitting speech or video. The Internet Layer is to permit hosts to inject packets into any network and have them trave independently to the destination (potentially on a different network). It defines an official packe format and protocol called IP (Internet Protocol). The job of the internet layer is to deliver II packets where they are supposed to go. Packet routing is clearly the major issue here, as is avoiding congestion. For these reasons, it is reasonable to say that the TCP/IP internet layer is simila in functionality to the OSI network layer. A comparison of OSI and TCP/IP reference model i: presented in Figure 1.2.
Figure 1.2: TCP/IP and OSI reference model (extracted from (Tanenbaum, 2003)) and flow control. It is widely used for one-shot, client-server-type request-reply queries and appli- cations in which prompt delivery is more important than accurate delivery, such as transmitting speech or video. The Internet Layer is to permit hosts to inject packets into any network and have them trave independently to the destination (potentially on a different network). It defines an official packe format and protocol called IP (Internet Protocol). The job of the internet layer is to deliver II packets where they are supposed to go. Packet routing is clearly the major issue here, as is avoiding congestion. For these reasons, it is reasonable to say that the TCP/IP internet layer is simila in functionality to the OSI network layer. A comparison of OSI and TCP/IP reference model i: presented in Figure 1.2.
Figure 1.3: The electromagnetic spectrum dependent. It is important to choose the appropriate physical layer for the specific wireless trans- mission.
Figure 1.3: The electromagnetic spectrum dependent. It is important to choose the appropriate physical layer for the specific wireless trans- mission.
Figure 1.4: The IEEE 802 family The base 802.11 specification includes the 802.11 MAC and several physical layers: a frequency hopping spread-spectrum (FHSS) physical layer and a direct-sequence spread-spectrum (DSSS) The base 802.11 specification includes the 802.11 MAC and several physical layers: a frequency
Figure 1.4: The IEEE 802 family The base 802.11 specification includes the 802.11 MAC and several physical layers: a frequency hopping spread-spectrum (FHSS) physical layer and a direct-sequence spread-spectrum (DSSS) The base 802.11 specification includes the 802.11 MAC and several physical layers: a frequency
Figure 1.5: Wireless Mesh Network’s Coverage at Taiwan Universtity
Figure 1.5: Wireless Mesh Network’s Coverage at Taiwan Universtity
Figure 1.6: Nortel Wireless Mesh Network Architecture
Figure 1.6: Nortel Wireless Mesh Network Architecture
Figure 1.7: Intelligent Transportation System technology provided by MeshNetworks Inc. The wireless mesh network allows anybody to display, at more than 40 locations throughout the city, real-time information on transportation services, such as where his/her bus is, its ultimate destination, and when it is scheduled to arrive. The same system is also expected to be used to address and alleviate transportation congestion problems, control pollution, and improve transportation safety and security.
Figure 1.7: Intelligent Transportation System technology provided by MeshNetworks Inc. The wireless mesh network allows anybody to display, at more than 40 locations throughout the city, real-time information on transportation services, such as where his/her bus is, its ultimate destination, and when it is scheduled to arrive. The same system is also expected to be used to address and alleviate transportation congestion problems, control pollution, and improve transportation safety and security.
Figure 1.8: Route Discovery example: from Node A to Node E Route maintenance It is the process of repairing a broken route or finding a new route in the presence of a route failure. Route maintenance procedure monitors the operation of the route anc informs the sender of any routing errors.
Figure 1.8: Route Discovery example: from Node A to Node E Route maintenance It is the process of repairing a broken route or finding a new route in the presence of a route failure. Route maintenance procedure monitors the operation of the route anc informs the sender of any routing errors.
Figure 1.9: Flooding without MPR (left) and with MPR (right)
Figure 1.9: Flooding without MPR (left) and with MPR (right)
Figure 1.10: The different components of the ZRP The fact that the topology of the local zone of each node is known can be used to reduce traffic when global route discovery is needed. Instead of broadcasting packets, ZRP uses a concept called bordercasting. Bordercasting utilizes the topology information provided by IARP to direct query request to the border of the zone. The bordercast packet delivery service is provided by the Bordercast Resolution Protocol (BRP).
Figure 1.10: The different components of the ZRP The fact that the topology of the local zone of each node is known can be used to reduce traffic when global route discovery is needed. Instead of broadcasting packets, ZRP uses a concept called bordercasting. Bordercasting utilizes the topology information provided by IARP to direct query request to the border of the zone. The bordercast packet delivery service is provided by the Bordercast Resolution Protocol (BRP).
Figure 1.11: APR decomposes route replies into links states in order to reconstruct shorter, more diverse APR routes
Figure 1.11: APR decomposes route replies into links states in order to reconstruct shorter, more diverse APR routes
The type field specifies the type of message. For example, a secure RREQ message may se the type field to 64, indicating an RREQ message, and 65 is for RREP message. The length fielc defines length of the type-specific data, not including the Type and Length fields of the extensio1 in bytes. The hash function field s set by the originator of the RREQ pecifies the hash function selected. The max hop count field i to the TTL value. The top hash value is calculated by applyins the hash function to a randomly selected number, called the seed, max hop count times. Th« signature field is the signature of the all the fields in the AODV packet that are before this fiel but the Hop Count field. This field has variable length, but it must be 32-bits aligns. Tr “Ma rKrTtr ‘ee Fy r if nna UTM TTT esl 1 the type field to 64, indicating an RREQ message, and 65 is for RREP message. The length field
The type field specifies the type of message. For example, a secure RREQ message may se the type field to 64, indicating an RREQ message, and 65 is for RREP message. The length fielc defines length of the type-specific data, not including the Type and Length fields of the extensio1 in bytes. The hash function field s set by the originator of the RREQ pecifies the hash function selected. The max hop count field i to the TTL value. The top hash value is calculated by applyins the hash function to a randomly selected number, called the seed, max hop count times. Th« signature field is the signature of the all the fields in the AODV packet that are before this fiel but the Hop Count field. This field has variable length, but it must be 32-bits aligns. Tr “Ma rKrTtr ‘ee Fy r if nna UTM TTT esl 1 the type field to 64, indicating an RREQ message, and 65 is for RREP message. The length field
Figure 1.13: nOLSRv2 Implementation
Figure 1.13: nOLSRv2 Implementation
Figure 1.14: nOLSRv2 Campus Testbed
Figure 1.14: nOLSRv2 Campus Testbed
Figure 1.15: The Yamakoshinet in rural mountain area about 1 mile from the branch office, and connected to the office with the broadband wireless access systems using 5 GHz band, respectively. The branch office is directly connected to Niigata Uni- versity with the 100 Mbps commercial wide-area Ethernet service. In order to provide the wireless LAN spot service in the whole area, the newly developed mesh access points are installed on the power poles in each settlement.
Figure 1.15: The Yamakoshinet in rural mountain area about 1 mile from the branch office, and connected to the office with the broadband wireless access systems using 5 GHz band, respectively. The branch office is directly connected to Niigata Uni- versity with the 100 Mbps commercial wide-area Ethernet service. In order to provide the wireless LAN spot service in the whole area, the newly developed mesh access points are installed on the power poles in each settlement.
Figure 1.16: Funkfeuer mesh network in Vienna
Figure 1.16: Funkfeuer mesh network in Vienna
Figure 1.17: Experiment scenarios for video stream testbed with 4 nodes in the library building with topology line-of-sight (left) and behind the walls (right)
Figure 1.17: Experiment scenarios for video stream testbed with 4 nodes in the library building with topology line-of-sight (left) and behind the walls (right)
Figure 1.18: Cisco Aironet 350 Series PC card The results obtained from these few testbeds show that the multipath routing protocol can provide shorter average route recovery time and higher throughput.
Figure 1.18: Cisco Aironet 350 Series PC card The results obtained from these few testbeds show that the multipath routing protocol can provide shorter average route recovery time and higher throughput.
Figure 2.1: Two consecutive frames from football sequence with large homogeneous region
Figure 2.1: Two consecutive frames from football sequence with large homogeneous region
Figure 2.3: Sampling of a video sequence
Figure 2.3: Sampling of a video sequence
(b) Image with high number of sampling points
(b) Image with high number of sampling points
Figure 2.5: Structure of H.264/AVC video encoder (extracted from (Wiegand et al., 2003))
Figure 2.5: Structure of H.264/AVC video encoder (extracted from (Wiegand et al., 2003))
types are 32-bit values and usually chosen to be four printable characters, for ease of inspection and editing.
types are 32-bit values and usually chosen to be four printable characters, for ease of inspection and editing.
Figure 3.1: Communication channel model They have ideal property that if k of the n transmitted symbols are received then the original k source symbols can be recovered.
Figure 3.1: Communication channel model They have ideal property that if k of the n transmitted symbols are received then the original k source symbols can be recovered.
where (k,l) defines the location of an image pixel, b is the index of a bin and A(n) is the Kronecker delta function equal to 1 when n = 0 and zero otherwise. The equation 6 = —kq + pl presents the line of projection, i.e. the set of projected pixels. Invertible projections can be obtained not only with addition but using any linear discrete operation; other practically useful operations include modulo 256 addition and bitwise XOR. The Mojette transform, M7; f, corresponds to the set of I projections as Myf = {Mp,.q,,1 <i <I}. The pixel is used for image processing. For more general purpose, it can be replaced by izel, which can be any information element. a e pi i i ae i a (a a i - a: a ae an ey fe ee, a ine. cnn, i. enn
where (k,l) defines the location of an image pixel, b is the index of a bin and A(n) is the Kronecker delta function equal to 1 when n = 0 and zero otherwise. The equation 6 = —kq + pl presents the line of projection, i.e. the set of projected pixels. Invertible projections can be obtained not only with addition but using any linear discrete operation; other practically useful operations include modulo 256 addition and bitwise XOR. The Mojette transform, M7; f, corresponds to the set of I projections as Myf = {Mp,.q,,1 <i <I}. The pixel is used for image processing. For more general purpose, it can be replaced by izel, which can be any information element. a e pi i i ae i a (a a i - a: a ae an ey fe ee, a ine. cnn, i. enn
The main difference from the classical Radon transform is the sampling rate on each projection, which is no longer constant but depends on the chosen angle as 1/\/p? + q? . The number of bins, B(i), for each projection depends on the chosen direction vector (p;, qi), and for a P x Q image is found as
The main difference from the classical Radon transform is the sampling rate on each projection, which is no longer constant but depends on the chosen angle as 1/\/p? + q? . The number of bins, B(i), for each projection depends on the chosen direction vector (p;, qi), and for a P x Q image is found as
Figure 3.3: An error correcting code for erasure channels (extracted from (Guédon, 2009)’ 3.1.2 Redundancy of Mojette Transform To measure the redundancy of the Mojette Transform, the following equation is defined:
Figure 3.3: An error correcting code for erasure channels (extracted from (Guédon, 2009)’ 3.1.2 Redundancy of Mojette Transform To measure the redundancy of the Mojette Transform, the following equation is defined:
Figure 3.4: An example of a UEP scheme where buffer i is dedicated to priority i packets (for i = 1,2,3). Two, three and four projections (out of four) are necessary to reconstruct buffer 1, buffer 2 and buffer 3, respectively (extracted from (Parrein et al., 2007)).
Figure 3.4: An example of a UEP scheme where buffer i is dedicated to priority i packets (for i = 1,2,3). Two, three and four projections (out of four) are necessary to reconstruct buffer 1, buffer 2 and buffer 3, respectively (extracted from (Parrein et al., 2007)).
Figure 3.5: (a) 3x3 image, I(x, y). (b) Examples of each of the four distinct directions for discrete lines of projection in the FRT over 3 x 3, « = my +t(mod p) for 0 <m < pand y =t(mod p) for m = p (c) The resulting FRT of I(x, y), Rm(t). The adg in (0,0) stands for a+ d-+ g (extracted from (Kingston, 2005)). Figure 3.5(a) shows an example of a 3 x 3 discrete data set, with arbitrary pixel values labeled from a to i, as indicated. In the FRT, the set of discrete projections R(t) of an image I(z, y) is generated by repeated displacement of a vector (m,1), for 0 < m < p, and the vector (1,0) for R,(t) (or Rf (t)). The origin of the vector displacements occurs at translate t, where 0 < t < p. Figure 3.5(b) depicts the pixels summed by the projection vectors (shaded grey) for t = 1 over all m = 0, 1, 2 and 3. We take x (and ¢) to increase in unit pixel steps from left to right across the top row of J and take y to increase in unit steps from top to bottom. Choosing the data array size to be square and furthermore restricting the length of the array sides to be a prime number (p) of pixels makes each projection unique, because of the way it samples each and every element of the p X p image array once and only once. The resulting set of projection values is shown in Figure 3.5(c) (where ¢ increases along the rows and m increases down each column). The perpendicular projection R, (also denoted Rq ) is taken as sums along the data rows, with translate ¢ here increasing with y.
Figure 3.5: (a) 3x3 image, I(x, y). (b) Examples of each of the four distinct directions for discrete lines of projection in the FRT over 3 x 3, « = my +t(mod p) for 0 <m < pand y =t(mod p) for m = p (c) The resulting FRT of I(x, y), Rm(t). The adg in (0,0) stands for a+ d-+ g (extracted from (Kingston, 2005)). Figure 3.5(a) shows an example of a 3 x 3 discrete data set, with arbitrary pixel values labeled from a to i, as indicated. In the FRT, the set of discrete projections R(t) of an image I(z, y) is generated by repeated displacement of a vector (m,1), for 0 < m < p, and the vector (1,0) for R,(t) (or Rf (t)). The origin of the vector displacements occurs at translate t, where 0 < t < p. Figure 3.5(b) depicts the pixels summed by the projection vectors (shaded grey) for t = 1 over all m = 0, 1, 2 and 3. We take x (and ¢) to increase in unit pixel steps from left to right across the top row of J and take y to increase in unit steps from top to bottom. Choosing the data array size to be square and furthermore restricting the length of the array sides to be a prime number (p) of pixels makes each projection unique, because of the way it samples each and every element of the p X p image array once and only once. The resulting set of projection values is shown in Figure 3.5(c) (where ¢ increases along the rows and m increases down each column). The perpendicular projection R, (also denoted Rq ) is taken as sums along the data rows, with translate ¢ here increasing with y.
Figure 3.6: (a) The FRT projections of Figure 3.5a. (b) Back-projection of (a), is the first step to recover the original data. Subtracting Isum = abcde fghi from each pixel and dividing p = 3 completes the reconstruction (extracted from (Kingston, 2005)).
Figure 3.6: (a) The FRT projections of Figure 3.5a. (b) Back-projection of (a), is the first step to recover the original data. Subtracting Isum = abcde fghi from each pixel and dividing p = 3 completes the reconstruction (extracted from (Kingston, 2005)).
Table 4.1: The sub-projects of SEREADMO and their participants
Table 4.1: The sub-projects of SEREADMO and their participants
Figure 5.1: Generalized MANET Packet Format
Figure 5.1: Generalized MANET Packet Format
Figure 5.2: The MP-OLSR network topology graph 5.1.2 Link Sensing and Neighbor Detection
Figure 5.2: The MP-OLSR network topology graph 5.1.2 Link Sensing and Neighbor Detection
Figure 5.3: Packet processing and forwarding
Figure 5.3: Packet processing and forwarding
Based on the topology information of 1-hop and 2-hop neighbor, each node must select, from among its willing symmetric 1-hop neighbors, a subset of nodes as MPRs. MPRs are used to flood control messages from a node into the network, while reducing the number of retransmissions that will occur in a region. The use of MPR optimizes the classical flooding mechanism and reduces the shared topology information in the network. among its willing symmetric 1-hop neighbors, a subset of nodes as MPRs. MPRs are used to flood 5.1.3. Topology Discovery
Based on the topology information of 1-hop and 2-hop neighbor, each node must select, from among its willing symmetric 1-hop neighbors, a subset of nodes as MPRs. MPRs are used to flood control messages from a node into the network, while reducing the number of retransmissions that will occur in a region. The use of MPR optimizes the classical flooding mechanism and reduces the shared topology information in the network. among its willing symmetric 1-hop neighbors, a subset of nodes as MPRs. MPRs are used to flood 5.1.3. Topology Discovery
broadcasting and processing of TC messages, the topology information that more than two hops aways can be saved in the Topology Set.
broadcasting and processing of TC messages, the topology information that more than two hops aways can be saved in the Topology Set.
Figure 5.7: An example of multipath Dijkstra algorithm that tries to find two paths
Figure 5.7: An example of multipath Dijkstra algorithm that tries to find two paths
Figure 5.8: Multipath Dijkstra Algorithm in sparse case. The node disjoint path is non-desirable after node A, B, and G are removed.
Figure 5.8: Multipath Dijkstra Algorithm in sparse case. The node disjoint path is non-desirable after node A, B, and G are removed.
Figure 5.9: Obtaining different path sets by using different cost functions. Path S+A—~C—B-D will first be chosen and second one might be different depending on the choice of cost functions
Figure 5.9: Obtaining different path sets by using different cost functions. Path S+A—~C—B-D will first be chosen and second one might be different depending on the choice of cost functions
Figure 5.10: Finding different number of paths by Multipath Dijkstra Algorithm after the first step, it is impossible to obtain the second path.
Figure 5.10: Finding different number of paths by Multipath Dijkstra Algorithm after the first step, it is impossible to obtain the second path.
Figure 5.14: An example of route recovery. S is the source and D is the destination. The movment of G makes the link from E to G unavailable.
Figure 5.14: An example of route recovery. S is the source and D is the destination. The movment of G makes the link from E to G unavailable.
Figure 5.15: An example of loop in the network. The movement of node C results in inconsistency of the information bases in node A and B. One transient loop is formed between A and B.
Figure 5.15: An example of loop in the network. The movement of node C results in inconsistency of the information bases in node A and B. One transient loop is formed between A and B.
Figure 5.16: The monitor function for queue length. x(t) is the instant real queue length, f(t) is the modeled queue length. Figure 5.17: TLV_ Queue_ Length added to the HELLO message and broadcasted to the whole network.
Figure 5.16: The monitor function for queue length. x(t) is the instant real queue length, f(t) is the modeled queue length. Figure 5.17: TLV_ Queue_ Length added to the HELLO message and broadcasted to the whole network.
Figure 5.18: Weight function with different slope coifficients a; = 315 and ag = 3200 7 Compatibility of MP-OLSR and OLSR 5.7.1 Challenges
Figure 5.18: Weight function with different slope coifficients a; = 315 and ag = 3200 7 Compatibility of MP-OLSR and OLSR 5.7.1 Challenges
The NS2 architecture closely follows the IP reference model. The code of NS2 is split between for its core engine and OTcl for configuration and simulation scripts, as shown in Figure 6.1. The reason to use two kinds of language is that for a simulator, there are two issues to handle. Firstly, to implement a detailed simulation of the protocol, a high-performance language is needed to process the packet and packet header very quickly. Those algorithms need to run numerous times so that the speed is very important. Secondly, a lot of the research is based on the configuration and parameters of the networks. In another words, the simulation scenario scripts need to be modified frequently. In the meantime, those configuration scripts just need to run once for each scenario at the beginning of the simulation, so the speed is less important. 6.1.1.1 Structure of NS2
The NS2 architecture closely follows the IP reference model. The code of NS2 is split between for its core engine and OTcl for configuration and simulation scripts, as shown in Figure 6.1. The reason to use two kinds of language is that for a simulator, there are two issues to handle. Firstly, to implement a detailed simulation of the protocol, a high-performance language is needed to process the packet and packet header very quickly. Those algorithms need to run numerous times so that the speed is very important. Secondly, a lot of the research is based on the configuration and parameters of the networks. In another words, the simulation scenario scripts need to be modified frequently. In the meantime, those configuration scripts just need to run once for each scenario at the beginning of the simulation, so the speed is less important. 6.1.1.1 Structure of NS2
Figure 6.2: The structure of a unicast node in NS2
Figure 6.2: The structure of a unicast node in NS2
Figure 6.3: The procedure to take for NS2 simulation
Figure 6.3: The procedure to take for NS2 simulation
Figure 6.4: Delivery ratio of the NS2 simulations
Figure 6.4: Delivery ratio of the NS2 simulations
Figure 6.5: Routing load of the NS2 simulations
Figure 6.5: Routing load of the NS2 simulations
Figure 6.6: Average end-to-end delay of the NS2 simulations
Figure 6.6: Average end-to-end delay of the NS2 simulations
Figure 6.8: The Qualnet GUI
Figure 6.8: The Qualnet GUI
Figure 6.10: Qualnet scenario creation
Figure 6.10: Qualnet scenario creation
Figure 6.11: Qualnet Protocol Stack
Figure 6.11: Qualnet Protocol Stack
Table 6.2: Qualnet Simulator Parameter Set
Table 6.2: Qualnet Simulator Parameter Set
Table 6.3: OLSR and MP-OLSR Parameters
Table 6.3: OLSR and MP-OLSR Parameters
Figure 6.12: The simulation topology with 81 nodes network. The initial position of the nodes is as shown Figure 6.12.
Figure 6.12: The simulation topology with 81 nodes network. The initial position of the nodes is as shown Figure 6.12.
Figure 6.13: Delivery Ratio of MP-OLSR implementations with or without route recovery and loop detection
Figure 6.13: Delivery Ratio of MP-OLSR implementations with or without route recovery and loop detection
Figure 6.14: Number of packets dropped because the TTL comes to 0
Figure 6.14: Number of packets dropped because the TTL comes to 0
Figure 6.15: Average end-to-end delay of MP-OLSR implementations with or without route recov- ery and loop detection
Figure 6.15: Average end-to-end delay of MP-OLSR implementations with or without route recov- ery and loop detection
Figure 6.16: Topology of the 2 path scenario, node 1 is the source and node 2 is the destination. Two paths are possible: 1+3-4-5-6—7-2 (6 hops) and 138-9 10-11-12-13-52 (7 hops)
Figure 6.16: Topology of the 2 path scenario, node 1 is the source and node 2 is the destination. Two paths are possible: 1+3-4-5-6—7-2 (6 hops) and 138-9 10-11-12-13-52 (7 hops)
Figure 6.17: Delivery ratio of the 2 path scenario with different data rates
Figure 6.17: Delivery ratio of the 2 path scenario with different data rates
Figure 6.18: Delay of the 2 path scenario with different data rates
Figure 6.18: Delay of the 2 path scenario with different data rates
Figure 6.19: Total packets dequeued in each node in a 2 path scenario with 120 packets/s
Figure 6.19: Total packets dequeued in each node in a 2 path scenario with 120 packets/s
Figure 6.20: Average time in queue in each node in a 2 path scenario with 120 packets/s
Figure 6.20: Average time in queue in each node in a 2 path scenario with 120 packets/s
Figure 6.21: Average jitter of the 2 path scenario with different data rates
Figure 6.21: Average jitter of the 2 path scenario with different data rates
Figure 6.22: Delivery ratio of MP-OLSR and OLSR in a scenario of 81 nodes and 4 CBR source:
Figure 6.22: Delivery ratio of MP-OLSR and OLSR in a scenario of 81 nodes and 4 CBR source:
Figure 6.23: Average end-to-end delay of MP-OLSR and OLSR in a scenario fo 81 nodes and 4 CBR sources
Figure 6.23: Average end-to-end delay of MP-OLSR and OLSR in a scenario fo 81 nodes and 4 CBR sources
Figure 6.24: Average time in queue of MP-OLSR and OLSR in a scenario of 81 nodes, 4 CBR sources
Figure 6.24: Average time in queue of MP-OLSR and OLSR in a scenario of 81 nodes, 4 CBR sources
Figure 6.25: Packet spacing difference D(i,i—1) of a CBR flow of MPOLSR and OLSR in a scenario of 81 nodes, 4 CBR sources
Figure 6.25: Packet spacing difference D(i,i—1) of a CBR flow of MPOLSR and OLSR in a scenario of 81 nodes, 4 CBR sources
Figure 6.27: Total control messages (HELLO and TC) generated by MP-OLSR and OLSR in a scenario of 81 nodes, 4 CBR sources Figure 6.26: Distribution of delay of received packets in a scenario of 81 nodes, 4 CBR sources
Figure 6.27: Total control messages (HELLO and TC) generated by MP-OLSR and OLSR in a scenario of 81 nodes, 4 CBR sources Figure 6.26: Distribution of delay of received packets in a scenario of 81 nodes, 4 CBR sources
Figure 6.28: Delivery Ratio of AODV and DSR in a scenario of 81 nodes and 4 CBR sources
Figure 6.28: Delivery Ratio of AODV and DSR in a scenario of 81 nodes and 4 CBR sources
Figure 6.29: Average end-to-end elay of AODV and DSR in a scenario of 81 nodes and 4 CBR sources
Figure 6.29: Average end-to-end elay of AODV and DSR in a scenario of 81 nodes and 4 CBR sources
Figure 6.30: Delivery ratio of MP-OLSR and OLSR in a scenario of 81 nodes and 10 CBR sources
Figure 6.30: Delivery ratio of MP-OLSR and OLSR in a scenario of 81 nodes and 10 CBR sources
Figure 6.31: Average end-to-end delay of MP-OLSR and OLSR in a scenario of 81 nodes and 10 CBR sources
Figure 6.31: Average end-to-end delay of MP-OLSR and OLSR in a scenario of 81 nodes and 10 CBR sources
overhead of the TLV_ Queue_ Length will not affect the performance of the network. Figure 6.32: Packet delivery ratio of MP-OLSR with queue length metric in low traffic scenarios
overhead of the TLV_ Queue_ Length will not affect the performance of the network. Figure 6.32: Packet delivery ratio of MP-OLSR with queue length metric in low traffic scenarios
Figure 6.33: Average end-to-end delay of MP-OLSR with queue length metric in low traffic sce- narios
Figure 6.33: Average end-to-end delay of MP-OLSR with queue length metric in low traffic sce- narios
the MP-OLSR using queue length metric can still provide better performance than the one using hop-count metric. Figure 6.34: Packet delivery ratio of MP-OLSR with queue length metric in high traffic scenaric
the MP-OLSR using queue length metric can still provide better performance than the one using hop-count metric. Figure 6.34: Packet delivery ratio of MP-OLSR with queue length metric in high traffic scenaric
Figure 6.35: Average end-to-end delay of MP-OLSR with queue lenght metric in high traffic scenaric
Figure 6.35: Average end-to-end delay of MP-OLSR with queue lenght metric in high traffic scenaric
Figure 6.36: Total bytes of routing message
Figure 6.36: Total bytes of routing message
Figure 6.37: Ratio of delivered packets for a network of 81 OLSR and MP-OLSR mobile nodes, with MP-OLSR source nodes
Figure 6.37: Ratio of delivered packets for a network of 81 OLSR and MP-OLSR mobile nodes, with MP-OLSR source nodes
Figure 6.38: Average end-to-end delay for a network of 81 OLSR and MP-OLSR mobile nodes, with MP-OLSR source nodes
Figure 6.38: Average end-to-end delay for a network of 81 OLSR and MP-OLSR mobile nodes, with MP-OLSR source nodes
Figure 6.39: Ratio of delivered packets for a network of 81 OLSR and MP-OLSR mobile nodes, with OLSR source nodes
Figure 6.39: Ratio of delivered packets for a network of 81 OLSR and MP-OLSR mobile nodes, with OLSR source nodes
Figure 6.40: Average end-to-end delay for a network of 81 OLSR and MP-OLSR mobile nodes, with OLSR source nodes
Figure 6.40: Average end-to-end delay for a network of 81 OLSR and MP-OLSR mobile nodes, with OLSR source nodes
Table 7.1: Parameters of eeePC 901
Table 7.1: Parameters of eeePC 901
Figure 7.1: The testbed with mobile nodes, analyze machine and sniffer
Figure 7.1: The testbed with mobile nodes, analyze machine and sniffer
Figure 7.2: Some ASUS eeePCs 901 before deployment at the headquarters of the testbed
Figure 7.2: Some ASUS eeePCs 901 before deployment at the headquarters of the testbed
Table 7.2: Implementation of OLSR protocol 7.1.1.3 OLSR prototype
Table 7.2: Implementation of OLSR protocol 7.1.1.3 OLSR prototype
Figure 7.3: A file transmission by using UFTP
Figure 7.3: A file transmission by using UFTP
Figure 7.4: Implementation of OLSRd in Linux
Figure 7.4: Implementation of OLSRd in Linux
Figure 7.5: Implementation of MP-OLSR in Linux
Figure 7.5: Implementation of MP-OLSR in Linux
Figure 7.6: Test day of the SEREADMO
Figure 7.6: Test day of the SEREADMO
Table 7.3: Results of scenario 1, OLSR and MP-OLSR with 4 paths, data rate = 62 KB/s
Table 7.3: Results of scenario 1, OLSR and MP-OLSR with 4 paths, data rate = 62 KB/s
Figure 7.7: Network topology of the scenario 1: OLSR and MP-OLSR with 4 paths. 10.0.0.100 is the source and 10.0.0.98 is the destination
Figure 7.7: Network topology of the scenario 1: OLSR and MP-OLSR with 4 paths. 10.0.0.100 is the source and 10.0.0.98 is the destination
Figure 7.8: Wireshark trace of scenario 1 with rate=62KBytes/s
Figure 7.8: Wireshark trace of scenario 1 with rate=62KBytes/s
Figure 7.9: Network topology of scenario 2: OLSR and MP-OLSR with 3 paths, 10.0.0.100 is the source and 10.0.0.98 is the destination
Figure 7.9: Network topology of scenario 2: OLSR and MP-OLSR with 3 paths, 10.0.0.100 is the source and 10.0.0.98 is the destination
Figure 7.10: Quality of links in scenario 2: OLSR and MP-OLSR with 3 paths
Figure 7.10: Quality of links in scenario 2: OLSR and MP-OLSR with 3 paths
Table 7.4: Results of scenario 2, OLSR and MP-OLSR routing with 3 paths With OLSR, the UFTP connection stopped after sending several packets beofre the transmission completed. This is because compared to multiple paths, the unstable paths have more negative effects on the single path routing protocol. So the file transmission failed in the end because of time out. Test results are presented in Table 7.4.
Table 7.4: Results of scenario 2, OLSR and MP-OLSR routing with 3 paths With OLSR, the UFTP connection stopped after sending several packets beofre the transmission completed. This is because compared to multiple paths, the unstable paths have more negative effects on the single path routing protocol. So the file transmission failed in the end because of time out. Test results are presented in Table 7.4.
Figure 7.11: Semi-realistic IPNE testbed, with UF TP application
Figure 7.11: Semi-realistic IPNE testbed, with UF TP application
Figure 7.12: Wireshark trace of UFTP source and destination nodes, 81 nodes OLSR ad hoc network the same period, the file successfully reached the destination in the end. This result is consistent with the real testbed.
Figure 7.12: Wireshark trace of UFTP source and destination nodes, 81 nodes OLSR ad hoc network the same period, the file successfully reached the destination in the end. This result is consistent with the real testbed.
Figure 8.1: Prediction structures for temporal scalability, coding with hierarchial B-pictures (T; > 0), (extracted from (Schwarz et al., 2007))
Figure 8.1: Prediction structures for temporal scalability, coding with hierarchial B-pictures (T; > 0), (extracted from (Schwarz et al., 2007))
Figure 8.2: Multilayer structure with additional inter-layer prediction for enabling spatial scalable coding (extracted from (Schwarz et al., 2007)). scalability with dyadic temporal enhancement layers can be efficiently provided with the concept of hierarchical B-pictures.
Figure 8.2: Multilayer structure with additional inter-layer prediction for enabling spatial scalable coding (extracted from (Schwarz et al., 2007)). scalability with dyadic temporal enhancement layers can be efficiently provided with the concept of hierarchical B-pictures.
Figure 8.3: SVC NAL unit structure (extracted from (Amon et al., 2007))
Figure 8.3: SVC NAL unit structure (extracted from (Amon et al., 2007))
Table 8.1: Packet statistic of football video sequence
Table 8.1: Packet statistic of football video sequence
Figure 8.4: (D,T,P) graphical representation of an SVC stream. White cubes represent empty data sets (extracted from (Amonou et al., 2006)).
Figure 8.4: (D,T,P) graphical representation of an SVC stream. White cubes represent empty data sets (extracted from (Amonou et al., 2006)).
Table 8.2: Packet statistic of football video sequence without type 14 NAL units
Table 8.2: Packet statistic of football video sequence without type 14 NAL units
Figure 8.5: The impact of packet loss from different temporal layers to the quality of the football video
Figure 8.5: The impact of packet loss from different temporal layers to the quality of the football video
Figure 9.1: The evaluation framework SVCEval for H.264/SVC
Figure 9.1: The evaluation framework SVCEval for H.264/SVC
Figure 9.3: An example of Qualnet application trace Figure 9.2: An example of H.264/SVC bitstream trace (packet trace) Then the BitStreamExtractor (provided by JSVM) is used to generate the bitstream trace from the given bitstream with the option -pt:
Figure 9.3: An example of Qualnet application trace Figure 9.2: An example of H.264/SVC bitstream trace (packet trace) Then the BitStreamExtractor (provided by JSVM) is used to generate the bitstream trace from the given bitstream with the option -pt:
The SVCEval framework can be adapted to different kinds of networks. Figure 9.4 presents an example of the quality of video transmission in various network scenarios: wired network, MP- OLSR static mesh/ad hoc with 250m transmission range, and MP-OLSR static mesh/ad hoc with 200m transmission range. We can conclude from the figure that the peroframcne of wired networks is much bettern than ad hoc networks (up to 5dB). And in the scenarios with mobility and low connectivity (range of 200m), the quality becomes unacceptable (PSNR below 25 dB). So it will be interesting to use FEC coding to protect the data during transmission. In section 9.3, the performance of different protocols in ad hoc networks will be further studied based on SVCEva framework. Figure 9.4: SVCEval in different networks 9.2. Forward Error Correction for H.264/SVC
The SVCEval framework can be adapted to different kinds of networks. Figure 9.4 presents an example of the quality of video transmission in various network scenarios: wired network, MP- OLSR static mesh/ad hoc with 250m transmission range, and MP-OLSR static mesh/ad hoc with 200m transmission range. We can conclude from the figure that the peroframcne of wired networks is much bettern than ad hoc networks (up to 5dB). And in the scenarios with mobility and low connectivity (range of 200m), the quality becomes unacceptable (PSNR below 25 dB). So it will be interesting to use FEC coding to protect the data during transmission. In section 9.3, the performance of different protocols in ad hoc networks will be further studied based on SVCEva framework. Figure 9.4: SVCEval in different networks 9.2. Forward Error Correction for H.264/SVC
Figure 9.5: Systematic FRT encoding Se KS SS Sl oe Se le lh aS ee Oe ee eee ee Oe ele ee Oe Ee lhUrFe ee Ree ewe Ss ee Incorporation of a known level of redundancy into data and projection spaces enables the use of forward error correction to recover the exact, original data when network packets are lost o1 corrupted during data transmission. Figure 9.5 shows data packed into a k x (p—1) (p is always prime) subset of a p x (p—1) data. The content of the r x (p—1) redundancy area is designed sc that the full image projections sum to zero for r sequential rows of the FRT space. If r or less data rows are missing, the the projected sums in the FRT contain an exact copy of the missing data. The data can be recovered from its projected form. For detailed information, please refer to previous work in (Normand et al., 2010). PFEC over multipath routing
Figure 9.5: Systematic FRT encoding Se KS SS Sl oe Se le lh aS ee Oe ee eee ee Oe ele ee Oe Ee lhUrFe ee Ree ewe Ss ee Incorporation of a known level of redundancy into data and projection spaces enables the use of forward error correction to recover the exact, original data when network packets are lost o1 corrupted during data transmission. Figure 9.5 shows data packed into a k x (p—1) (p is always prime) subset of a p x (p—1) data. The content of the r x (p—1) redundancy area is designed sc that the full image projections sum to zero for r sequential rows of the FRT space. If r or less data rows are missing, the the projected sums in the FRT contain an exact copy of the missing data. The data can be recovered from its projected form. For detailed information, please refer to previous work in (Normand et al., 2010). PFEC over multipath routing
Figure 9.6: Mulitpath transmission with PFEC
Figure 9.6: Mulitpath transmission with PFEC
Figure 9.7: The FECSim framwork for FEC simulation
Figure 9.7: The FECSim framwork for FEC simulation
Figure 9.8: Network scenario with video tream (red line) and backgournd traffic (green lines)
Figure 9.8: Network scenario with video tream (red line) and backgournd traffic (green lines)
multipath routing because it can provide higher overall bandwidth. Figure 9.9: The delivery ratio of different protocols (with or with out FEC code) Figure 9.10 compares the quality of the video transmission by using different kinds of protocols. Compared to OLSR, MP-OLSR has worse quality in very low-mobility scenarios (1m/s and 2m/s). As the node speed increases, the quality of OLSR drops quickly and MP-OLSR outperforms OLSR. This result is consistent with the conclusion from our previous work that the single path routing might have better delivery ratio than MP-OLSR in the network with very less topology changes. However, in these low-mobility scenarios, the MP-OLSR can make use of single path also because the MP-OLSR is compatible with OLSR.
multipath routing because it can provide higher overall bandwidth. Figure 9.9: The delivery ratio of different protocols (with or with out FEC code) Figure 9.10 compares the quality of the video transmission by using different kinds of protocols. Compared to OLSR, MP-OLSR has worse quality in very low-mobility scenarios (1m/s and 2m/s). As the node speed increases, the quality of OLSR drops quickly and MP-OLSR outperforms OLSR. This result is consistent with the conclusion from our previous work that the single path routing might have better delivery ratio than MP-OLSR in the network with very less topology changes. However, in these low-mobility scenarios, the MP-OLSR can make use of single path also because the MP-OLSR is compatible with OLSR.
Figure 9.10: The quality of video transmission through the different protocols (with or without FEC code)
Figure 9.10: The quality of video transmission through the different protocols (with or without FEC code)
Figure 9.11: Packet delivery ratio of different temporal scalable layers
Figure 9.11: Packet delivery ratio of different temporal scalable layers
Figure 9.12: Screenshots of the football video sequence
Figure 9.12: Screenshots of the football video sequence
Figure 9.13: The quality of foreman video transmission of different protocols
Figure 9.13: The quality of foreman video transmission of different protocols
Figure 9.14: Screenshots of the foreman video sequence
Figure 9.14: Screenshots of the foreman video sequence
Figure A.1: Different layers in NS2 simulation
Figure A.1: Different layers in NS2 simulation
Figure A.2: Queue length in source node at 100 packets/s, OLSR
Figure A.2: Queue length in source node at 100 packets/s, OLSR
Figure A.3: Queue length in source node at 100 packets/s, MPOLSR
Figure A.3: Queue length in source node at 100 packets/s, MPOLSR
Figure A.4: Queue length in source node at 40 packets/s, OLSR
Figure A.4: Queue length in source node at 40 packets/s, OLSR
Figure A.5: Queue length in source node at 40 packets/s, MPOLSR
Figure A.5: Queue length in source node at 40 packets/s, MPOLSR
Figure A.6: Queue length in source node at 40 packets/s, single path MPOLSR
Figure A.6: Queue length in source node at 40 packets/s, single path MPOLSR
Figure A.7: Packet travels different layers in the source node without congestion
Figure A.7: Packet travels different layers in the source node without congestion
Figure B.1: The g_cur_ser_tc_tab for the toplogy in plugin of olsrd four fields:
Figure B.1: The g_cur_ser_tc_tab for the toplogy in plugin of olsrd four fields:
Table B.1: The order of ser_tc_ token
Table B.1: The order of ser_tc_ token
Figure B.2: The 1-hop neighbors in olsrd
Figure B.2: The 1-hop neighbors in olsrd
olsr_ link It corresponds to a unidirectional link between two nodes. The structure mainly a a includes:
olsr_ link It corresponds to a unidirectional link between two nodes. The structure mainly a a includes:
Figure C.1: Output log file of ErrorPatternGenerator
Figure C.1: Output log file of ErrorPatternGenerator
Figure D.1: An example of the output log file of Qualnet TraceParser
Figure D.1: An example of the output log file of Qualnet TraceParser
Figure E.2: An example of QualnetF ECTraceParser log
Figure E.2: An example of QualnetF ECTraceParser log
Related topics:
HumanitiesPolitical ScienceH.264 SVCMANET-Mobile Ad-hoc Network
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved