Efficient Multicast Schemes for Mobile Multiparty Gaming Applications

Transcription

1 Efficient Multicast Schemes for Mobile Multiparty Gaming Applications P6-6th semester 2006 Group ComNet Aalborg University 24th May 2006

2

3 Institut for elektroniske systemer Fr. Bajers Vej 7 Telefon Titel: Tema: Efficient Multicast Schemes for Mobile Multiparty Gaming Applications Komplekse distribuerede systemer Projektperiode: P6, forårssemestret 2006 Projektgruppe: Gruppe 681 Deltagere: Mads Verwohlt Martin H. Larsen Synopsis: Vejleder: Haibo Wang Hans Peter Schwefel Oplagstal: 5 Sidetal: 49 Bilagsantal og art: 4 Afsluttet den 30. Maj 2006

4

5 Institute for Electronic Systems Fr. Bajers Vej 7 Phone Title: Efficient Multicast Schemes for Mobile Multiparty Gaming Applications Theme: Complex distributed systems Project period: P6, spring semester 2006 Project group: Group 681 Group members: Mads Verwohlt Martin H. Larsen Abstract: Supervisor: Haibo Wang Hans Peter Schwefel Number printed: 5 Pages: 49 Appendix: XX Finished May 30th 2006

6 Preface

7 CONTENTS ComNet, AAU Contents 1 Introduction Motivation Introduction Goals Preliminary analysis Multiplayer games Multiplayer networks Multiplayer Online Games Wireless Communication Bluetooth Wireless LAN Mobile IP Packet delivery Multicast Multicast Compromise Overview of Multicast Routing Algorithms Multicast Forwarding Problem statement Problem Delimitation 19 3

8 Group 681 CONTENTS 3.1 Introduction Project description Problem description Delimitation Scenarios Scenario I Scenario II Scenario III Scenario IV Analysis Halflife: Counter Strike version data simulation flow Laboratory Setup Multicast Schemes PIM-Protocol independent Multicast Routing Architecture Configurating the routers Configurating Dense-Mode Configurating Sparse-Mode Synchronizing the Sender and the Receiver Sender and Receiver Multicast Sender Receiver A Bluetooth Core Protocols 43 4

9 ComNet, AAU Chapter 1 Introduction 1.1 Motivation Mobile devices are used for many different applications, each with different requirements. Many of these applications require wireless communication with other devices or the Internet, for example applications used for or file transfer. The demand for faster communication for video-communication and network gaming has raised within the last few years, but while the third-generation mobile communication has provided a solution for the video-communication, the demand for network gaming have not yet been solved. The problem is the high data rate, and reliable connection demanded by the more advanged multiplayer games. 1.2 Introduction The overall scenario; figur 1.1, contains four main areas which is important to look into. The areas are the server, the main multicast router, the subnets containing routers and access points, and the mobile notes. The setup of these main areas, will all effect the efficiency of the different multicast schemes. This project will investigate the efficiency of different multicast schemes in relation to the different system setup. 5

10 Group 681 CHAPTER 1. INTRODUCTION Figure 1.1: System overview. In order to test the multicast schemes, on a system with varying settings, the main settings that will be changed is: Game-server The game server basically depends on the chosen game since it will dictate the required data flow. Main multicast router The main router have the greatest impact on the test, since it is the bottleneck in the system. 6

11 1.2. INTRODUCTION ComNet, AAU Subnets Both subnets consist of a router and one or two access points using either the Bluetooth or Wireless LAN technology. The settings on router and the access points can be changed in order effect the efficiently of the schemes. Game-clients Game clients is regarding the data flow similar to the server depended on the game chosen. These mobile notes can be moved to force a handover between access points and subnets in order to test the efficiency of the schemes Goals There are some different aspects that would have to be investigated before the scenario can be tested. These aspects includes: Identify the features of mobile multi-party games. Identify the performance of wireless communications methods. Study which existing multicast schemes will be suitable. Make a test with the purpose of validating the performance of the multicast scheme for mobile gaming. There are many different kinds of multiplayer games, each of these have different features to consider for a mobile device, such as traffic volume, maximum quantity of users, game session length and real-time aspects. These aspects will be used when choosing the scenario Mobile devices are able to use different wireless communication methods, we will only look at two of them, Bluetooth and WLAN, each with its own advantage and disadvantage. The two methods will be examined and tested to determine the level of performance in the chosen scenario. 7

12 Group 681 CHAPTER 1. INTRODUCTION Another challenge is to study which type of existing multicast schemes, regarding multicast group management and multicast strategies, that will be suitable for a mobile multicast multiplayer gaming environment, and whether it need to be changed to fit the chosen scenario. A test bed will be used as an experimental validation of the performance of the selected multicast scheme for mobile gaming. 8

13 ComNet, AAU Chapter 2 Preliminary analysis 2.1 Multiplayer games This section will be the basis for choosing a game for further use in the project scenarios. A small selection of different multiplayer game types will be selected and an evaluation will be made from the projects point of view, which main parts includes multicasting and wireless communication. Later a specific game of the selected type will be chosen Multiplayer networks A multiplayer games can have two approaches to the network type. Multiplayer games can either use a server-driven or peer-to-peer network. Each with its own advantages and disadvantage regarding multicasting and Wireless communication. Server-Driven Games In a server-driven game, each player communicates only with a overall remote server. The server tracks all the clients actions and sends each client the information, it needs to know the game state. This is clearly a effectiv method for multicasting, since each client only are sending and receiving the data it needs, so the network traffic is low. There are also an disadvantage, someone has to provide the server and the bandwidth it uses. As an solution the developers can allow the users to setup its own server on the Internet.[1] 9

14 Group 681 CHAPTER 2. PRELIMINARY ANALYSIS Peer-to-Peer Games In a peer-to-peer game, no single client is considered server instead, all the clients talk directly to each other. Each machine keeps track of the overall game state, with checksums passed to ensure that they remain in sync. A peer-to-peer network will optimal to use with games which are not requiring a very high data communication since its biggest disadvantage is that the amount of data that needs to be exchanged increases exponentially when the number of players increases. This solution uses a lot of bandwidth when there are more than 3-4 players. So a peerto-peer game should be limited to a low maximum of clients. The most common peer-to-peer games are of the type real-time strategy, simulation, sports, cards and boardgames.[1] Multiplayer Online Games Multiplayer Online Games(MOGs) can be classified into five groups which are First Person Shooter(FPS), real-time strategy games, massive multi-player online roleplaying game(mmorpg), simulator games and turn-based games.[2] FPS A First-person shooter is a specific type of game with a first-person view, almost always centered around the act of aiming and shooting, in real-time environment in 3D graphics. The game type will usable for multicasting since all clients need to know, where the other client move their user.[3] Real-time strategy games Real-time strategy games are games where the clients controls a single player, group or nation, in a real-time environment on a variating size map. MMORPG This is a game where each player having a certain position. The players can give orders to the server to change the position, which is a slowly. This is an server-client 10

15 2.2. WIRELESS COMMUNICATION ComNet, AAU type of game, where players can play the game in many short sessions, rather than to play a single long session. Simulation Games A simulation game is a game that contains different game aspects, skills change and strategy to simulate the aspects of reality. Turn-based games In a turn-based game each player takes turn one after another. Each player generally takes some time to act, witch will result in multisecond latency. 2.2 Wireless Communication This section will describe the two wireless communication technologies used in this project. The two technologies, used are Wireless LAN and Bluetooth, since they are the most used on mobile devices like laptops and mobile phones Bluetooth Bluetooth operates on 79 channels in the 2.4 GHz band, with 1 MHz of carrier spacing. Each device performs frequency hopping with hops/second. An important feature in the context of Bluetooth is piconet. A piconet is a collection of Bluetooth devices, which are synchronized to the same hopping frequency. One device in the piconet has to act as a master, and the other devices have to act as slaves. The master sets the hopping pattern in the piconet. If a device wants to be active in the piconet, it has to synchronize to this hopping pattern. Beside active, a device can be parked, and in standby. In parked mode the device can be activated within a few milliseconds. Devices in standby mode cannot be activated by the piconet, but only by the device itself. When a device is assigned to a piconet it is given a 3 bit active member address (AMA), this gives a total of 7 slave devices and one master device in a piconet. All parked devices use an 8 bit parked member address (PMA). The Bluetooth protocol stack can be divided into a core and a profile specification 11

16 Group 681 CHAPTER 2. PRELIMINARY ANALYSIS A.1. The core specifies the protocols from physical layer to the data link control, including management functions. Profile specifications describe the many protocols and functions needed to adapt the Bluetooth technology to the different purposes. In next section the Bluetooth Core protocols will be described Wireless LAN Wireless LAN is a wireless local area network that uses radio frequencies for communication between mobile devices. The last link with the users is wireless, to give a network connection to all users in the surrounding area. It is based on a IEEE standard and is available in different versions. The original standard limited WLAN speed to 2 Mbps, but since that was not efficient enough, IEEE developed the b standard which supported a speed on up to 11 Mbps. At the same time they also released the a standard, with a maximum speed of 54 Mbps. The latest revision of the standard, and last,was made to combine the best features from a, its speed, and b,its stability. The last revision is called g and runs on the 2.4 GHz RF band. The g standard can push the speeds to 108 Mbps. In this project the WLAN will use the g standards, since it is the fastest and most stable, so this section will only describe the features of this standard. Dynamic Link Adaptation Dynamic Link adaptation is an effective way to improve the performance of the IEEE standard, when considering the throughput. Link adaptation works by decreasing the data rate which increases the transmission range of the WLAN. The IEEE g standard supports different speeds 1, 2, 5.5, 6, 9, 11, 12, 18, 22, 24, 33, 36, 48 and 54 Mbps all depending on the modulation techniques used. The G standard supports both the modulation techniques from the original(dqpsk and DBPSK) and B(DQPSK/CCK) standard, and then it supports OFDM/CCK.[4] 12

17 2.3. MOBILE IP ComNet, AAU Modulation Data rate(mbps) DBPSK 1 DQPSK 2 DQPSK/CCK 5.5, 11, 22, 33 OFDM/CCK 6, 9, 12, 18, 24, 36, 48, Mobile IP A mobile host connected to the Internet through an access point via IP that stays in the same sub-network, works just as an non-mobile host, and receives the packets required from the sub-net. But when a mobile note changes, through physical movement or other reason, to another access point i another sub-net, then the packets required in a the first sub-net will get lost. This is one of the problems while working with mobile Internet access, to solve this problem another protocol can be used named Mobile IP. Mobile IP is developed with the goal, summarized as: Supporting end-system mobility while maintaining scalability, efficiently, and compatibility in all respects with existing applications and Internet protocols.[5] Packet delivery When a mobile node changes network while communicating with a corresponding node, then the mobile IP hide the mobility of the mobile node and sets up a home agent between the Internet and the home network, and a foreign agent between the Internet and the foreign network

18 Group 681 CHAPTER 2. PRELIMINARY ANALYSIS Figure 2.1: Mobile IP.[6] When a corresponding note wants to send an IP packet through the Internet, to a mobile node, it sends it to the home network of the mobile note. If the mobile note has changed sub-net then the home agent intercepts the packet, instead of forwarding the packet into the home network it and encapsulates the IP packet and provides it with a additional header with a new destination source with is the current address of the mobile node and send the packet. When the packet arrives at the new destination, the foreign agent intercepts the packet, removes the additional header and forward into the foreign network, with the original source and destination address. Sending a packet form the mobile node to the corresponding node is a simpler. The mobile node sends the packet with then corresponding nodes IP-address as source address and the mobile node IP-address as destination address and then the foreign agent forward the packet to the corresponding node as a normal router would do. 2.4 Multicast Multicast communication gives an ability to open a UDP (User Datagram Protocol) socket and send a packet of data once and deliver this packet to many receivers. Instead of sending N packets to N receivers, one multicast packet can be send and received by all N. 14

19 2.4. MULTICAST ComNet, AAU A special range of IP addresses is assigned by IANA (The Internet Assigned Numbers Authority) to create a logical group of receivers. The group addresses will fall in the range of to [7]. By using this address the application programmer has the ability to send one or a stream of packets to this destination address and expect the network to deliver a copy of each packet to each receiver in the group. Multicast communication relies on additional functionality in the network to build a multicast forwarding tree between the sender and all the receivers in the group. The source is located at the root of the tree. From the root a packet stream flows up the different branches. At each branch in the tree the network receives an incoming packet, and copies it to each of the outgoing branches. Picture The functionality necessary to build and maintain the multicast trees on the Internet is slowly being deployed. This means that the functionality is being hard- and software implemented in switches and routers as well as in operating systems and applications Multicast Compromise Multicast offers a great deal of power. The ability for one host to send one packet and have it received by many receivers is powerful. But also the power in multicast is its scalability. Applications which has to deliver data to a larger number of receivers, unicast fails quickly [8]. Multicast scalability is a great feature, but the benefits are not without any costs. The compromise is complexity. The price comes to those who deploys multicast in the network and the application writers. The complexity with multicast comes from the fact that that it is only a delivery mechanism. At the transport layer, multicast only works with UDP not with TCP. UDP does not offer congestion control and does not have reliable delivery. The problem with reliable delivery and congestion control in multicast can be found in its complexity. Creating and managing all the variables and timers becomes rapidly a heavy burden. If there is more than one receiver, example , they could not all have different sending rate if you want to use multicast. Also there is no one to deal with acknowledgment packets, and resend lost packets. 15

20 Group 681 CHAPTER 2. PRELIMINARY ANALYSIS Overview of Multicast Routing Algorithms The data transmitted needs to be transferred from the sender to all the receivers. A spanning tree [9] has been considered one of the most efficient methods to perform data transmissions, since it minimizes duplications of data packets in the network. Messages are duplicated only when the tree branches, this prevents data loops. An efficient multicast routing algorithm will aim to build a Minimal Spanning Tree [10]. The type of tree to be used depends on how the receivers are distributed with high density or low density. Numbers of receivers does not matter. The receivers might too have some set of requirements like costs and delay which can be tolerated. Different types of trees to handle such special cases will be described here. Source Tree Source tree algorithms (also known as shortest path tree) builds a separate tree for each source 2.2. Reverse Shortest Paths (RSP) connects each receiver to the source. This is efficient for high data rate sources. It provides minimal delay for the cost expense. Whenever a source tree is used, a network with a high number of groups and each group having a larger number of sources, can stress the storage capability of the routers. Source trees consume more bandwidth for each individual multicast group. But their load is more evenly distributed than center based trees. [10] Figure 2.2: Host A Shortest Path Tree (Picture will be changed) [7]. 16

21 2.4. MULTICAST ComNet, AAU Shared Tree Shared tree algorithm builds a single tree to be used by all the sources. The data flow in the tree can be one way, or bi-directional. This is efficient for low rate sources and is efficient in the amount of information that needs to be maintained at each router. Shared trees use a single location in the network called core or the Rendezvous Point (RP) to which all packets from the sources are sent and from which packets are sent to all receivers. The path from a certain receiver to the source may be longer which may result in a delay. This can be a disadvantage for applications which relay on a low delay. The core is a potential bottleneck for data transmissions. The selection of the node to act as core is critical to performance of the protocol. The core can be selected from following: [10] Random Router (not necessarily a member of the group). Random Member. Topological Center for the entire network Topological Center of the multicast group (not necessarily member of the group) Topological center of the multicast group (member of the group) Random tree node (Only nodes belonging to the current multicast tree) Tree Center (Only nodes belonging to the center of the current tree) Figure 2.3: Shared Distribution Tree (Picture will be changed) [7]. 17

22 Group 681 CHAPTER 2. PRELIMINARY ANALYSIS Multicast Forwarding In a unicast routing environment, traffic is routed through the network along a single path, from source to destination. The router does not really care about the source address, but only destination and how to forward the data. The router scans through its routing table, and forwards a single copy of the packet out the correct interface. In multicast routing, the source sends traffic to a group of host, represented by the multicast group address. Therefore the router must determine which direction is upstream, (towards the source) and which is downstream. If there are multiple downstream paths the router replicates the packet and forwards the traffic down the appropriate downstream paths. This concept of forwarding multicast traffic away from the source, rather than to the receiver is called reversed path forwarding. [7] Reverse path forwarding Reverse Path Forwarding is utilized to build source-specific forwarding paths (SPT, shortest path tree), amongst which datagram s can flow more efficiently. Source specific multicast makes immediate use of this. Any source multicast usually switches from a centralized tree to the SPT on certain predefined conditions and for each source individually. This functionality is achieved by issuing source-specific joins towards the source, using the source address to look up a unicast routing table entry. This continues router by router until the source is reached. The source and the routers in between now start forwarding the traffic towards the direction the original join came from. The result is that the traffic is forwarded along the reverse path from the source back to the listener. While with symmetric routing, the reverse path is the same as the forward path, this is not necessarily true with asymmetric routing. Because the Internet is routed asymmetrically, the paths show significant differences quite often.[7] 2.5 Problem statement Which multicast-scheme is best suited for MO-FPS games, considering packet loss, delay and throughput in a wireless multicast environment 18

23 ComNet, AAU Chapter 3 Problem Delimitation 3.1 Introduction 3.2 Project description The preliminary analysis includes the information needed to start the main part of the project, which is the analysis of different multicast schemes, and it ends up with a problem statement in section 2.5 which is basis for the rest of the project. The present starting point is the overall scenario on figure 1.1, it shows that the system will be based on a central server system with direct access to a central multicast router. The central multicast router is connected to two subnets. The two subnets each include a switch or a router and a number of access points of either WLAN or Bluetooth, with a number of notes connected. 3.3 Problem description The setup will consist of four scenarios, a unicast scenario, a multicast scenario with unicast accesspoint, a multicast scenario with a multicast/broadcast accesspoint and last a handover scenario. In each of these scenarios some measurements will take place. Packets sent from the server will hold a packet number to determine how many packets are lost, and a timestamp to help determine the delay in the network. The total datavolumen in the network will be determined to see how much bandwith will be saved by using multicast. 19

24 Group 681 CHAPTER 3. PROBLEM DELIMITATION 3.4 Delimitation The delimitations are based on of the Preliminary analysis. PCs will be used as mobile devices There are a lot of mobile products available; which can handle communication via Bluetooth, WLAN or both. But PCs with WLAN and Bluetooth will be used to avoid the complexity included in using mobile phones or PDAs. Central server The main system consist of a central game-server, with handles all communication between the notes, directly connected to a central multicast router. The nodes are not able to directly communicate with each other. Other alternatives is either using peer-to-peer where all clients communicate with each other, or using one of the clients as server, where all the users communicate to the same client. The game type used is MO-FPS MO-FPS is chosen on the basis of the analyze of different game types in the section 2.1. It is the most interesting game type regarding its high demand for a low latency, and its relative high data communication rate. The main analysis will be centered on different multicast schemes. 3.5 Scenarios The overall scenario, 1.1, will be split up in tree scenarios. Each of the scenarios designed to test different problem. 20

25 3.5. SCENARIOS ComNet, AAU Scenario I The first scenario is a unicast scenario 3.1, and will be used to collect data in the network, such as packet loss, delay, and also the total amount of data in the network so the load on the network in multicast and unicast can be compared. The network will consist of a server, one router and two switches, a bluetooth AP and a WLAN accespoints connected to a number of nodes Figure 3.1: The first scenario is a network in Unicast mode, and it will used to compare unicast and multicast Scenario II The second scenario, figure 3.2, is simple and will just be used to test multicasting on a simple level. The point is to set up a multicast router with a number of notes connected through a unicast Bluetooth and Wlan accesspoint. The multicast router will be tested with different multicast schemes. Each multicast scheme will be tested to determine packet loss, delay and total amount of data. 21

26 Group 681 CHAPTER 3. PROBLEM DELIMITATION Figure 3.2: This scenario is the most simple with purpose of testing a multicast router with a number of notes Scenario III The third scenario 3.3 is almost equal to the second one. The only thing that differs is the Bluetooth accesspoint is configured as a broadcast accesspoint, and the Wlan accesspoint is configured as a multicast accesspoint. The same five multicast schemes will be tested to determine packet loss, delay and total amount of data. 22

27 3.5. SCENARIOS ComNet, AAU Figure 3.3: This scenario is a multicast scenario with accesspoints configured as multicast and broadcast accesspoints Scenario IV The fourth scenario, figure 3.4, is a handover scenario. A node will disconnect from one accesspoint and connect to another in the same subnet. the packets lost in the handover will be measured. The scenario will also test a handover from one subnet to another, and from WLAN to bluetooth. 23

28 Group 681 CHAPTER 3. PROBLEM DELIMITATION Figure 3.4: This scenario is used to test the handover time, and packet lost.. 24

29 ComNet, AAU Chapter 4 Analysis 4.1 Halflife: Counter Strike version 1.6 For the test of the scenarios we have choosen the game counter strike version 1.6 which is a modification of the game Halflife by Valve. We have choosen counter strike becourse it is the most popular FPS multiplayer game of all time.[11] data simulation flow Since counter strike are not a open source game, we had to simulate the data flow between the client and the server, in the game. The packets sent from the server to the individual game clients, has a packetsize of 127 byte, and are received with the rate of 16 packets/s. From the game client to the server, the mean size of the packets are 82 bytes and they arrive with a rate of 24 packets/s.[2] 4.2 Laboratory Setup To test the different settings, described later in this chapter, some equipment has to be used. The measurements will be performed in the IP laboratory. We used three identical routers from Cisco, the Cisco The Router has a IOS (internetwork Operating System) version c3620-i-mz.122-5d installed. Furthermore we used two cisco Aeronet AG1130 Series Accesspoints. Two Laptops with wireless network cards, and one desktop pc with FastEthernet network card. table shows the 25

30 Group 681 CHAPTER 4. ANALYSIS computers 4.2 and table 4.1 shows the other equipment. Equipment Number of Operating System Interfaces devices Version Cisco 3620 Router 2 c3620-i-mz.122-5d 2 FastEthernet 4 Serial Cisco Aeronet 1130AG 2 CHECK IT 1 FastEthernet wireless A/B/G Switch 1 8 FastEthernet Table 4.1: caption text goes here Computer Hardware Network Laptop1 Centrino 1.4 Ghz 256mb ram D-link DWL-G650 Laptop2 pentium Ghz 512mb ram IPW mb b/g Desktop Pentium mhz 128mb ram Onboard 100Mbit Ethernet card Table 4.2: caption text goes here These devices are used in the setup described later Fixme 4.3 Multicast Schemes The routing protocols are deployed on the routers in the network that makes up the path from the sender to the receivers. The protocols have to main responsibilities: To collect and maintain information for the routing algorithms in selecting the best path from the sender to the receiver by using a path selection procedure. Additionally the protocol is responsible for group management. Multicast routing protocols can be devided into dense and sparse mode protocols. PIM is one of the routing protocols that can operate in both modes. Sparse mode protocols offers the highest scalability and is most efficience, but the core can be a single point of failure. The differences between the two modes are listed in table

31 4.3. MULTICAST SCHEMES ComNet, AAU Different Characteristic Transmission Mechanism Distribution Tree Excisting Protocols Group Management Routers where state is maintaned Storage overhead in terms of routing entries Bandwidth overhead Dense-mode protocols Broadcast and Prune Source Distribution tree (Shortest Path) DVMRP, PIM-DM Maintains information of the hosts that are (positive) or not part of the group (negative) At all the routers, irrespective of wheter it is on the multicast tree. State can be positive or negative A routing entry for each (source, group) pair -either positive or negative. Total number of unwanted data packets transmittet over all network links along with the periodic prune messages Sparse Mode Core / Rendezvous Point (RP) based (Centralized group management.) Traffic restricted to the multicast group. Source Distribution tree or shared distribution tree or both CBT, PIM-SM Marintains information of hosts that are part of the group Only in routers on the packet deliviery tree The shortest path entries, shared path entries and the negative cache entries for paths that are in the switching process. Total number of PIM control messages. Table 4.3: Dense-Mode Vs. Sparse-Mode PIM-Protocol independent Multicast PIM is a multicast protocol which is able to operate in both Sparse and Dense mode. PIM Sparse-Mode protocol use join messages to set up a shared unidirectional shared distribution tree. Where the Dense mode only uses source distribution trees and uses RPF checking to determine if a packet has to be forwared. PIM Sparse-Mode: In sparse-mode, a node typically a router is selected as 27

32 Group 681 CHAPTER 4. ANALYSIS the Rendezvoux Point (RP), and all group communications takes place by sending the packet to this point. The router uses the unicast routing table for routing the decissions. Each source in the multicast group sends its packets to th RP which is the only place in the network where packets can be forwarded from, because of the unidirectional trees build from the RP. Any node who wants to join the multicast group, sends a request a rp to set up atunnel to the RP. If there are more than one router in the network the router with highest IP address has to become the Designated Router (DR) for the subnet, and becomes responsible for sending prune/join message to the RP. Information about the rp is obtained by sending Bootstrap messages. Pim sparse-mode allows switchinf from shared tree path to a source tree path. When a group has numerous active sources, the bandwith may be overloaded along the shared tree. Therefore can it be necessary to switch to shortest path to the RP. During the switch, packets may be lost, depending on the delay difference between the shared tree path, and the source tree path. PIM Dense-Mode: In dense-mode PIM works as a distance vector style algorithm that builds source based multicast trees. When a packet arraives at a router configured in PIM Dense-Mode, it sends the packet to all attached routers and awaits a response. If the attached router doesn t have any group members it returns a prune message. The attached router will no longer receive multicast packets send to this group. The prune state will time-out within a defined interval. If a multicast receiver connects after a prune message have been sent, and before the timeout, it has to send a graft message in the upstream. Dense-Mode is inefficient when the receivers in the group is sparsely spread in the network. In sparse-mode the PIM protocol builds its own routing table instead of reutilize the excisting unicast routing table. The router assumes that a packet is received on a RPF interface if it is received on an interface which it uses to send unicast packets to the source. If the packet arrives on a RPF interface the router forwards it out through the interface which are present in the outgoing interface multicast entry. If not received on the RPF the packets will be discarded to awoid loop-bas. The advantage of using the RPF is that the multicast packets are only sent where they are wanted. RPF Bootstrap Prune/join messages unidirectionally trees 28

33 4.4. ROUTING ARCHITECTURE ComNet, AAU 4.4 Routing Architecture This section will cover a general overwiev of a routers blocks and how packets are threated in a router, furthermore are more specific description of the cisco 3600 series will be described. First the general architecture will be described, and then the cisco mangler 4.5 Configurating the routers The Routers are configured from a laptop using a Serial RS232 cable to one of the routers. When connected to this router using a telnet session you can change the configuration of that router. From the one router you can telnet onward to the two other routers. First step is to configure the routers in to a tree mode fixme indsæt figur af de tre routere med IP er This is done by disconnecting all serial connection from the Aalborg Router except the two towards Delft and Frankfurt. From Delft and Frankfurt all serial connection are disconnected except the one towards Aalborg. The serial interfaces are given the IP-adresses shown on the figure. The five FastEthernet connections shown on the figure is running DHCP. 29

34 Group 681 CHAPTER 4. ANALYSIS Configurating Dense-Mode Aalborg Router Configuration Global configuring mode: ip multicast-routing Configuring mode interface ethernet0/0 ip address ip pim dense-mode Configuring mode interface serial 0/1 (towards Delft) ip address ip pim dense-mode Configuring mode interface serial 1/3(towards Frankfurt) ip address ip pim dense-mode 30

35 4.5. CONFIGURATING THE ROUTERS ComNet, AAU Delft Router Configuration Global configuring mode: ip multicast-routing Configuring mode interface ethernet0/0 ip address ip pim dense-mode Configuring mode interface ethernet0/1 ip address ip pim dense-mode Configuring mode interface serial 1/3(towards Aalborg) ip address ip pim dense-mode 31

36 Group 681 CHAPTER 4. ANALYSIS Delft Router Configuration Global configuring mode: ip multicast-routing Configuring mode interface ethernet0/0 ip address ip pim dense-mode Configuring mode interface ethernet0/1 ip address ip pim dense-mode Configuring mode interface serial 1/3(towards Aalborg) ip address ip pim dense-mode Configurating Sparse-Mode In this setup, the serial interface on Aalborg towards Delft is static set as the Rendezvous Point. All three routes know this point. 32

37 4.5. CONFIGURATING THE ROUTERS ComNet, AAU Aalborg Router Configuration Global configuring mode: ip multicast-routing ip pim rp-address Configuring mode interface ethernet0/0 ip address ip pim sparse-mode Configuring mode interface serial 0/1 (towards Delft) ip address ip pim sparse-mode Configuring mode interface serial 1/3(towards Frankfurt) ip address ip pim sparse-mode 33

38 Group 681 CHAPTER 4. ANALYSIS Delft Router Configuration Global configuring mode: ip multicast-routing ip rp-address Configuring mode interface ethernet0/0 ip address ip pim sparse-mode Configuring mode interface ethernet0/1 ip address ip pim sparse-mode Configuring mode interface serial 1/3(towards Aalborg) ip address ip pim sparse-mode 34

39 4.6. SYNCHRONIZING THE SENDER AND THE RECEIVER ComNet, AAU Delft Router Configuration Global configuring mode: ip multicast-routing ip rp-address Configuring mode interface ethernet0/0 ip address ip pim sparse-mode Configuring mode interface ethernet0/1 ip address ip pim sparse-mode Configuring mode interface serial 1/3(towards Aalborg) ip address ip pim sparse-mode 4.6 Synchronizing the Sender and the Receiver As described in section (fixme) each packet send, is given a timestamp to determin the delay in the network. When a packet is received, the timestamp is read out, and the delay is calculated. For this to work properly the sender and the receivers clocks has to be synchronized. This can be done with by using the Network Time Protocol. The Network Time Protocol is a protocol which is used for synchronizing computer clocks over a packet-switched network vith variable latancy. It uses UDP on port 123. NTPv4 can usually maintain time to within 10 milliseconds (1/100 s) over the public Internet, and can achieve accuracies of 200 microseconds (1/5000 s) or better in local area networks under ideal conditions. The NTP is updated each 64th second, in our case the computer clocks was able 35

40 Group 681 CHAPTER 4. ANALYSIS to synchronize within a few miliseconds. The offset between the computers can be read out in the NTP Time Server Monitor. 4.7 Sender and Receiver In order to be able to send and receive multicast packets with our needs, a multicast receiver and sender has been developed. This section will cover the functions offered by the sender and receiver Multicast Sender The Multicast sender is coded in java. Inspiration is found in [8]. The requirements to the Sender is following: Create a multicast group and set a multicast IP-address. Be able to send multicastpackets with variable intervals. This is done in order to be able to adapt to an excisting game traffic scheme, and to test the maximum throughput for the network. Be able to send multicast packets with variable UDP-payload. Be able to send a timestamp in each packet, so the delay can be calculated on the receiver. Each packet send has to be numbered in order. To create a group a valid Multicast ip has to be instantiated. In this example the multicast address is used. Next step is to instantiate the Multicast socket. When the socket is no longer used, the socket can be closed. /* Use inetaddress method to getbyname() to create an InetAdress instance of the ip address. */ mcaddress = InetAddress.getByName(" "); /* instantiate a MulticastSocket */ MulticastSocket sock = new MulticastSocket(); 36

41 4.7. SENDER AND RECEIVER ComNet, AAU /* Close the socket */ sock.close(); Next Step is to take the current system time and the packetnumber and add it to the UDP payload. The size of the payload is now 22 byte. 37

42 Group 681 CHAPTER 4. ANALYSIS while (! done){ /* Read out the current system time, and pass it to a string */ Date milisec = new Date(); // String time = Long.toString(milisec.getTime()); /*PacketCounter and time is added and converted to bytes. */ /*After the last "-" a string with the wanted packet size, -22 bytes can be added*/ SendString = packetcounter+"-"+time+"-"; sendbytes=sendstring.getbytes(); /* populate the DatagramPacket */ DatagramPacket packet = new DatagramPacket (sendbytes, sendbytes.length, mcaddress, mcport); /* send the packet */ sock.send(packet); /*Increase the packetnumber*/ packetcounter++; /*put the thread to sleep for the wanted number of miliseconds*/ try { Thread.sleep(62); }catch (Exception e) {} } Receiver The Multicast Receiver is also coded in java, Inspiration is found in [8]. The requirements to the sender is following: Join an existing multicast group. Re-Join the group when a handover has been carried out. Receive UDP multicast packets send from the multicast sender. Read out the timestamp from the UDP payload, and calculate the delay and write the delay into a file. 38

43 4.7. SENDER AND RECEIVER ComNet, AAU Read out the packetnumber received and write them to a file. First step is allowing the receiver to become a member of the multicast group. /* Use inetaddress method to getbyname() to create an InetAdress instance of the ip address. */ mcaddress = InetAddress.getByName(" "); /* instantiate a MulticastSocket */ MulticastSocket sock = new MulticastSocket(mcPort); /* join the multicast group */ sock.joingroup(mcaddress); Next step is to receive the Datagram Packages sent from the server. In the receiver you can define how many datagrams you want to receive. To calculate the delay between the datagram is sent and received, the time from the client is substracted with the one from the server, and is parsed to an array. The packet number from the server is also parsed to an array. When the number of wanted packages is received, the program will break the while loop, and the two arrays containing the delay, and package number is written to a file. 39

44 Group 681 CHAPTER 4. ANALYSIS /* loop until the number of packages you want is received*/ while ( count < runthrough){ /* create a new DatagramPacket with an empty buffer */ DatagramPacket packet = new DatagramPacket(buf, buf.length); if(count!=0 ){ Set a timeout on the socket. This is used when a handover occours. sock.setsotimeout(500); } /*wait to receive packet into the DatagramPacket instance */ sock.receive(packet); /*Get the client time */ Date milisec = new Date(); ctime = milisec.gettime(); datareceived = new String(packet.getData()); /*Splits the received string in two so the packetnumber and the Server timestamp can be handled. */ datareceivedsplittet = datareceived.split("-"); stime = Long.parseLong(new String(dataReceivedSplittet[1])); /*calculate delay between server and client and parse it to an array */ delayarray[count] = (ctime-stime); /*takes the packetnumber sent from the server and parse it to an array */ packetnumberarray[count] = Long.parseLong(new String(dataReceivedSplittet[0])); count++; } When a handover occours the sock.setsotimeout() will throw an exception. From this exception a new multicast socket will be instantiated, as soon the connection to the new accesspoint is availible. 40

45 BIBLIOGRAPHY ComNet, AAU Bibliography [1] Nokia. Overview of multiplayer mobile game design, version 1.1, December play Mobi v1 1 en.pdf. [2] Michael Kwok Jeff Diamond Yanni Ellen Liu, Jing Wang and Michael Toulouse. Capability of ieee g networks in supporting multi-player online games, October yliu/mypub/nime2006.pdf. [3] Wikipedia. Wikipedia, Marts [4] Wireless LAN Association. High-speed wireless lan options, May [5] Jochen Schiller. Mobile Communication, Second Edition. Addison Wesley, [6] Mobile Networking. Mobile ip. [7] Cisco Systems. Internet protocol multicast, Febuary doc/ipmulti.htm. [8] David Makofske and Kevin Almeroth. Multicast Sockets - A practical Guide for Programmers. Morgan Kaufmann Publishers, [9] Wikipedia. Spanning tree, Marts tree %28networks%29. [10] Pragyansmita Paul and S V Raghaven. Survey of multicast routing algorithms and protocols, August files/pub/pragyan/survey multicasting.pdf. 41

46 Group 681 BIBLIOGRAPHY [11] Wikipedia. Counter-strike, Marts strike. [12] Jennifer Bray. Masters and slaves: Roles in a bluetooth piconet, May

47 ComNet, AAU Appendiks A Bluetooth Core Protocols This section is based on the book Mobile Communications.[5] Figure A.1: Bluetooth protocol stack. The Bluetooth Core Protocol concerns following elements: 43 Radio Layer: Specification of the air interface, i.e. frequencies, modulation, and transmit power. Baseband Layer: Description of basic connection establishment, packet formats, timing and basic QoS parameters.

48 Group 681 APPENDIKS A. BLUETOOTH CORE PROTOCOLS Link Manager Protocol: Link set-up and management between devices including security functions and parameter negation. Logical link control and adaptional protocol (L2CAP): Adaptation of higher layers to the baseband (connectionless and connection-oriented services). Service Discovery Protocol: Device discovery in close proximity plus query of service characteristic. On top of L2CAP is the cable replacement protocol RFCOMM, which emulates a serial connection following the RS-232 standards. Radio Layer Bluetooth operates in 79 channels in the 2.4 GHz band, with 1 MHz carrier spacing. Each Bluetooth device performs its own random frequency hopping with 1600 hops/s. The time between two hops is called a slot, which has an interval of 625 microseconds. Bluetooth receivers and transmitters are available in three powerclasses: Power class 1: Power is between 1mW and 100 mw, and range is 100 metres without obstacles. Power class 2: Power is max. 2.5 mw, and min. is 0.25 mw. Nominal power is 1 mw. Range is 10 meters without obstacles. Power class 3: Maximum power is 1 mw, and range is 10 cm. Baseband layer The baseband layer has a number of important functions, such as defining the frequency hopping, physical links and many packet formats. The baseband layer determines the frequency selection from the master device, and each slave device participating in the piconet hops at the same time, to the same frequency. If a master sends data at f k the slave may answer at f k+1. 44

49 ComNet, AAU Figure A.2: Frequency selection during data transmission of 1, 3 and 5 slot packets [5]. The upper part of figure A.2 shows a 1 slot packet, meaning that the data transmission uses one 625 micro second slot. In each of these slots a device in the piconet may transmit data. It is also possible to send packets in lasting 3 and 5 slots for higher data rates. If a packet of three or five slot is sent, the radio transmitter remains in the same frequency, and after receiving the devices returns to the frequency required for its hopping sequence. Slaves which not are participating in the transmission will continue with the hopping sequence so all devices can stay syncronized. The components of the Bluetooth packet at baseband layer is shown in figure A.3. The packet consists of the following three fields: Figure A.3: The figure shows the Baseband packet format, which consist of an acces code, packet header and payload.[5] 45 Acces code: This field is used for synchronization of timing, and piconet identification. The access code consists of a 4 bit preamble, a 64 bit synchronization field and a 4 bit trailer.

50 Group 681 APPENDIKS A. BLUETOOTH CORE PROTOCOLS Packet header This field contains the features: address, packet type, flow and error control, and checksum. First field, Active Member Address (AMA) is the address of the slave, if a master sends data to a slave, is this field interpreted as the address of the slave, and if a slave wants to send data to a master, the field represents the field the address of the sender. The address 0 i, and only ones used for broadcast communication from the master to all slaves. The 4 bit type field determines the type of the packet. The different types of packets a listed in table A.1. Packets can carry control, asynchronous or synchronous data. One flow mechanism for asynchronous traffic, utilizes the 1-bit flow field. If a packet is received with flow equal to zero, all asynchronous traffic must stop, and as soon a packet with flow equal to 1 is received the transmission can resume. If any acknowledgement of packets is required, Bluetooth sends this in the slot after the data packet has been received. The packet header is also protected by a 1/3 rate error correction, this means that the header is sent three times because it valuable link information and should survive bit errors. The 18 bit header therefore requires 54 bit in the packet. Payload: The payload can be up to 343 bytes dependent of the structure and type of link of the packet. Type Payload (Byte) User payload FEC CRC Symmetric max rate (kbit/s) Asymmetric forward Max DM /3 Yes DH no Yes DM /3 Yes DH no Yes DM /3 Yes DH no Yes AUX no No HV1 na 10 1/3 No 64.0 na na HV2 na 20 2/3 No 64.0 na na HV3 na 30 no No 64.0 na na DV 1 D 10+ 2/3D No 64.0 na na Table A.1: Bluetooth baseband data rules. [5] Bluetooth offers two types of links, one synchronous connection-oriented link, and an asynchronous connectionless link. They will both be described here: Synchronous connection-oriented link (SCO): Normal telephone connection requires a symmetrical circuit switched, point-to-point connections, for 46