thiquocduy
New Member
Download miễn phí Khóa luận Efficient core selection for multicast routing in mobile ad hoc networks
TABLE OF CONTENT
CHAPTER 1: INTRODUCTION 1
1.1 Overview 1
1.2 Problem’s description 1
1.3 Disposition 2
CHAPTER 2: MULTICAST ROUTING 4
2.1 Introduction 4
2.2 Common mechanism 4
2.3 Multicast routing in LAN 7
2.3.1 IGMPv1 8
2.3.2 IGMPv2 10
2.4 Multicast Routing in Internet 13
2.4.1 Distance Vector Multicast Routing Protocol (DVMRP) 13
2.4.2 Multicast Open Shortest Path First (MOSPF) 13
2.4.3 PIM 14
2.5 Multicast routing in ad hoc networks 15
2.5.1 Tree-based approaches 15
2.5.2 Mesh-based approaches 16
2.6 Conclusion 17
CHAPTER 3: AN EFFICIENT AND ROBUST MULTICASTING ROUTING PROTOCOL FOR MANETS 18
3.1 Introduction 18
3.2 Core based model 18
3.3 Message structures and connectivity list 19
3.4 Mesh Organization 22
3.5 Core election process 25
3.6 Forwarding data packet 26
3.7 Sequence Numbers Recycle 27
3.8 Conclusion 28
CHAPTER 4: AN ADAPTIVE CORE SELECTION BASED MULTICAST ROUTING PROTOCOL FOR MANETs 29
4.1 Introduction 29
4.2 Core-based multicast routing protocol 32
4.3 Core-based Tree Multicast for MANET 35
4.4 Properties of Centroids in Tree with Weights 36
4.5 Core migration process 37
4.6 Algorithm Outline 38
4.7 Conclusion 39
CHAPTER 5: OUR PROPOSITION AND RESULTS 40
5.1 Motivation 40
5.2 Protocol description 40
5.3 Pseudo code 42
5.4 Network Simulator 2 (NS2) 44
5.5 Peer-to-Peer content distribution in MANETs 44
5.6 Experimental result and analysis 44
5.6.1 Simulation environment 44
5.6.2 Control overhead 45
5.6.3 Packet delivery ratio 47
5.6.4 Delivery time 49
CHAPTER 6: CONCLUSION 52
REFERENCE 53
Để tải bản Đầy Đủ của tài liệu, xin Trả lời bài viết này, Mods sẽ gửi Link download cho bạn sớm nhất qua hòm tin nhắn.
Ai cần download tài liệu gì mà không tìm thấy ở đây, thì đăng yêu cầu down tại đây nhé:
Nhận download tài liệu miễn phí
Tóm tắt nội dung tài liệu:
ast group can reply. If a transitional node receives a join RREQ for a multicast group to which it is not a member, or, it receives a RREQ and not has a route to this group; it rebroadcasts the RREQ to its neighbors.2.5.2 Mesh-based approaches
Unlike a tree approach, mesh-based multicast protocols may have numerous paths between any source and destination. Presented studies show that tree-based protocols are not essentially best for the multicast in a MANET where network topology changes regularly. In such a situation, mesh-based protocols seem to do better than tree-based protocols due to the availability of alternative paths, which allows multicast datagram to be transmitted to the recipients even if the links stop working. This section presents an overview of some of the mesh-based approaches in a MANET.
On-Demand Multicast Routing Protocol (ODMRP) — ODMRP is a mesh-based protocol that uses a forwarding group concept. A soft state advance is taken in ODMRP to preserve multicast group members. No unequivocal control message is necessary to leave the group. In ODMRP, group membership and multicast routes are built and updated by demand of the source. When a multicast source has packets to transmit, having no route to the multicast group, it broadcast a Join-Query control packet to the whole network. This Join-Query packet is regularly broadcast to update member information and routes. When a transitional node receives a Join-Query packet, it keeps the source ID and sequence number in its message cache to identify any possible duplication. Routing table is updated with a proper node ID (i.e. backward knowledge) from which message is received. If the message is not a replica and TTL is greater than zero, it is rebroadcast.
Core-Assisted Mesh Protocol (CAMP) helps multicasting by creating a common mesh for each multicast group. Meshes then created Giúp maintain connection for multicast users, even with moving node. It based on concepts from CBT, but in contrast to CBT where all traffic flows through the central node, the central nodes in CAMP are used to limit the control traffic. The fundamental operation of CAMP includes construction and maintenances the multicast meshes for a multicast group. It requires a mapping service that gives routers with the addresses of groups identified by their names. It also involves access to router information from a unicast routing protocol. Each router maintains a routing table (RT). CAMP adapts this table when a multicast group must be inserted or removed. Based on RT, a multicast routing table (MRT) was built. A router can update its MRT based on topological changes or communication received from its neighbors.
2.6 Conclusion
Steve Deering wrote the first RFC for multicast mechanism in 1986. Nevertheless, a few years later, the huge demand for multicast mechanism has exploded, from a communication needs such as audio, video, TV programs ... Multicast also has been studied as a component of the Internet, known as Project Multicast backbone, Mbone. Today, as the need for a protocol that can be used for moving devices, such as cell phone, cars,.. many protocols for MANETs have been proposed such as CAMP, MAODV. It will be interesting to see how the deployment multicast routing in MANETs plays out over the next decade of computer networking.
CHAPTER 3: AN EFFICIENT AND ROBUST MULTICASTING ROUTING PROTOCOL FOR MANETS
3.1 Introduction
PUMA [5], as an abbreviation of Protocol for unified multicasting through announcement, is a multicast routing protocol. PUMA is a receiver-initiated shared mesh. PUMA has shown to perform better than most of the representative multicast routing protocols. PUMA, compares with other multicast routing protocol, achieves a better data delivery ratio with a very low control overhead. Furthermore, all transmissions in PUMA are broadcast, it does not require any unicast protocol to work.
Like CAMP [3] and MAODV [10], PUMA uses a receiver initiated approach in which a receiver joins a multicast group by using the address of a special node (core in CAMP or group leader in MAODV) without having to perform a network-wide flooding of control and data packets from every sources of the group. PUMA also bypasses the need for a unicast routing protocol and the assignment of cores to multicast groups beforehand.
3.2 Core based model
PUMA uses a distributed algorithm in order to select one of the recipients of a group to be the core of the group, and each router in the network, at the distance of at least one next-hop to the chosen core of each group is also informed about the core election. Within a limited time proportional to the time needed for the router to arrive to the router farthest away from the core of a group, each router almost have one or more path to the elected core.
Each receiver is connected to the core along all of the shortest paths between the receiver and the elected core. All nodes on shortest paths between any receiver and the core form the mesh collectively. A transmitter sends a data packet to the group along one of the shortest path. When a data packet arrived at the mesh, it then will be flooded within the mesh. As a result, all of the mesh member receive the packet. Each node maintains a packet ID cache to prevent packet duplication.
Especially, PUMA only uses a control message to maintain all of its functions, which is call multicast announcement. Each multicast announcement contains a sequence number, the group’s address (group ID), the core’s address (core ID), the distance to the core, a mesh_member flag which is set when the sending node is a member of the mesh and lastly, a parent preferred by the neighbor to reach the core. With the information retrieved by the announcements, nodes elect the core for the mesh, select the best routes to reach the core from outside of a multicast group, notify other nodes about the mesh’ state, and maintain the mesh.
3.3 Message structures and connectivity list
A node that believes it is the core of a multicast group periodically transmitted announcement messages for that group. As multicast message passing through the network, it established a connectivity list in every node in the network. Using the connectivity list, a node can set up a mesh, as a result, routes data packets from the sender to the receivers.
Every node store the necessary information acquired from the entire multicast announcement it received from its neighbors in its connectivity list... Newer multicast message from a neighbor (for example, with a higher sequence number) will replace entries in which the sequence numbers are lower for the same group. Thus, for a certain group, a node will have only one entry in the list of its connections from a given neighbor, and it just keeps that information with the latest sequence numbers for each core.
Each item in the connectivity list, in addition to storing multicast announcement messages, it also stores the time when the packet was received, neighbor from which it received. The node then creates its own multicast announcement message, by selecting the best entry in the connectivity list.
For announcement with same core ID, multicast message with the highest sequence number is chosen. For announcement with same core ID and same sequence number, then the message with smaller distances to the core is valid. If all of these criteria are the same, the multicast announcement that the first reach the nodes is considered better. After choosing the best-multicast announcement message, the node creates its multicast announcement follow by these rules:
Core ID: best-multicast announcement core-id
Group ID: Group id of the best-multicast announcement
Sequence number: Best-multicast announcement’s sequence number
Distance to core: The distance to core of the best-multicast announcement plus one
Parent: Neighbor from which this node received the best-multicast announcement
Mesh member: Flag
Figure 3: Connectivity List
The connectivity list stores information on one or more links that exist to reach the core. When a particular group undergoes a core change, then the node deletes all the entries in the old list of connectivity and built a new one. Figure 3 show the process of propagating multicast announcement messages and constructing the connectivity list. The bold arrows represent the neighbor from which a node gets its best multicast announcement message. Node 6 has three entries in its list of connectivity for the neighbors of 5, 1 and 7. However, it chose the entry that received from 5 as the best entry, because it has the shortest distance to the core, moreover, was received earlier than the message from node 1. Node 6 uses these inputs to generate its own multicast announcement, which specifies:
Group ID = 224.0.0.6,
Core ID = 11,
Sequence number = 79,
Distanc...