Efficient Multicast Schemes for Mobile Multiparty Gaming Applications P6-6th semester 2006 Group 681 - ComNet Aalborg University 9th March 2006
Institut for elektroniske systemer Fr. Bajers Vej 7 Telefon 96 35 86 00 http://www.ies.aau.dk Titel: Tema: Efficient Multicast Schemes for Mobile Multiparty Gaming Applications Komplekse distribuerede systemer Projektperiode: P6, forårssemestret 2006 Projektgruppe: Gruppe 681 Synopsis: Deltagere: Mads Verwohlt Martin H. Larsen Vejleder: Haibo Wang Hans Peter Schwefel Oplagstal: 5 Sidetal: 17 Bilagsantal og art: 4 Afsluttet den 30. Maj 2006
Institute for Electronic Systems Fr. Bajers Vej 7 Phone 96 35 86 00 http://www.ies.aau.dk Title: Efficient Multicast Schemes for Mobile Multiparty Gaming Applications Theme: Complex distributed systems Project period: P6, spring semester 2006 Project group: Group 681 Abstract: Group members: Mads Verwohlt Martin H. Larsen Supervisor: Haibo Wang Hans Peter Schwefel Number printed: 5 Pages: 17 Appendix: XX Finished May 30th 2006
Preface
CONTENTS ComNet, AAU Contents 1 Introduction 4 1.1 Motivation............................... 4 1.2 Introduction.............................. 4 2 Preliminary analysis 7 2.1 Multiplayer games.......................... 7 2.2 Wireless Communication....................... 7 2.2.1 Introduction to Wireless Communication.......... 7 2.2.2 Bluetooth........................... 7 2.2.3 Bluetooth Core Protocols................... 8 2.2.4 Wireless LAN........................ 15 2.2.5 GPRS............................. 15 2.3 Routing................................ 15 2.4 Multicast............................... 15 2.5 Experimental parts.......................... 15 2.6 Problem statement.......................... 15 3 Analysis 16 3
Group 681 CHAPTER 1. INTRODUCTION 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 E-mail 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. 1.2 Introduction The overall problem in this project is to investigate the the different excisting multicast schemes for the purpose of multiplayer games for mobile devices- There are some overall challenges in this project, including: Investigating the different problems in multiplayer games for a mobil device. Determine the performance of different Wireless communication methods for mobile devices. Examine different multicasting schemes useable for the communication methods determinated. 4
1.2. INTRODUCTION ComNet, AAU There are many thing to consider when creating a multiplayer game for a mobile device, such as traffic volume, maximum quantity of users, game session length and real-time aspects. It will all be included in a senario. Mobile devices are able to use different wireless communication methods including GPRS, Bluetooth and WLAN, each of these have some avantage and disavantage. The different methods will be examined, to determine the level of performance in a certain senario. Another challenge is to study which type of existing multicast schemes, regarding multicast group management and multicast stratagies, that will be suitable for a mobile multicast multiplayer gaming environment, and whether it need to be changed to fit the senario A test bed will be used as an experimental validation of the performance of the selected multicast scheme for mobile gaming. 5
Group 681 CHAPTER 1. INTRODUCTION Figure 1.1: System overview. 6
ComNet, AAU Chapter 2 Preliminary analysis 2.1 Multiplayer games 2.2 Wireless Communication 2.2.1 Introduction to Wireless Communication 2.2.2 Bluetooth introduction This section is based on [1] Bluetooth operates on 79 channels in the 2.4 GHz band, with 1 MHz of carrier spacing. Each device performs frequency hopping with 1.600 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 frequence. One device in the piconet, and only one, 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). 7
Group 681 CHAPTER 2. PRELIMINARY ANALYSIS The Bluetooth protocol stack can be divided into a core and a profile specification 2.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. Figure 2.1: Bluetooth protocol stack. 2.2.3 Bluetooth Core Protocols The Bluetooth Core Protocol concerns following elements: 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. Link Manager Protocol: Link set-up and management between devices including security functions and parameter negation. Logical link control and adaptional protocol (L2CAP): Adaption of higher layers to the baseband (connectionless and connection-oriented services). 8
2.2. WIRELESS COMMUNICATION ComNet, AAU 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 metres 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 frequence. If a master sends data at f k the slave may answer at f k+1. 9
Group 681 CHAPTER 2. PRELIMINARY ANALYSIS Figure 2.2: Frequency selection during data transmission of 1, 3 and 5 slot packets [1]. The upper part of figure 2.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 2.3. The packet consist of the following three fields: Figure 2.3: The figure shows the Baseband packet format, which consist of an acces code, packet header and payload.[1] Acces code: This field is used for synchronization of timing, and piconet 10
2.2. WIRELESS COMMUNICATION ComNet, AAU identification. The access code consists of a 4 bit preamble, a 64 bit synchronization field and a 4 bit trailer. 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 is 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 2.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 DM1 1 0-17 2/3 Yes 108.8 108.8 108.8 DH1 1 0-27 no Yes 172.8 172.8 172.8 DM3 2 0-121 2/3 Yes 258.1 387.2 54.4 DH3 2 0-183 no Yes 390.4 585.6 86.4 DM5 2 0-224 2/3 Yes 286.7 477.8 36.3 DH5 2 0-339 no Yes 433.9 723.2 57.6 AUX1 1 0-29 no No 185.6 185.6 185.6 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 2.1: Bluetooth baseband data rules. [1] 11
Group 681 CHAPTER 2. PRELIMINARY ANALYSIS Bluetooth offers two types of links, one synchronous connection-oriented link, and an asynchronous connectionless link. They will both be describet here: Synchronous connection-oriented link (SCO): Normal telephone connection requires a symmetrical circuit switched, point-to-point connections, for this type of link, the master reserves two following slots (one for forward, and one for return) in fixed intervals. One master can support up to three simultaneous SCO links the same slave, or to different slaves, a slave supports up to two links from different masters, of up to three links from a single master. When using a SCO link, three different types of single slot packets can be used. HV1, HV2 and HV3, (see table 2.1). Each of these SCO links carries voice at 64 bit. Asynchronous connectionless link (ACL): Data application typically requires symmetrical or asymmetrical packet-switched transfer. The master in the piconet uses a pilling scheme, were the slaves only may answer if it has been addressed in the previous slot. Only one ACL link may exist between a master and a slave. Data using ACL may consist of 1,3 or 5 slots packets. These data can additionally be protected by using a 2/3 FEC scheme. This may help carrying data in noisy environments, with high error rates. But the overhead produced by FEC might be to high, therefore bluetooth offers a fast automatic repeat request, named ARQ, which secures reliable transmission. Figure 2.4 illustrates an example transmission between one master and two slaves. The master uses the even slots, and the odd slots are reserved for the slaves. In this example every sixth slot is used for a SCO (ex. f 0 ) transmission between the master and slave one. The ACL link provided uses a single (ex. (f 4 ) slot or multiple (ex. f 1 4) and provide an asymmetric transmission. 12
2.2. WIRELESS COMMUNICATION ComNet, AAU Figure 2.4: Example data transmission.[1] Blutooth offers a high level of robustness. This is based on several technologies. Bluetooth s 1/3 FEC simply sends three copies of each bit and then makes a majority decision. 2/3 FEC, can detect all double errors. Link Manager Protocol The link manager protocol (LMP) manages a number of various aspects of the radio links between a master and slave. LMP manages the baseband functionality, but higher layers can still directly access the baseband. LMP cover the following functions: Authentication, pairing and encryption. Synchronization Capability negotiation Quality of service negotiation Power control Link supervision State and transmission mode change L2CAP L2CAP (Logical link control and adaption protocol) is a data link control protocol on top of the baseband layer, which offers logical connections between devices. The 13
Group 681 CHAPTER 2. PRELIMINARY ANALYSIS L2CAP is only available for ACL packets (SCO packets have to use the baseband layer directly) L2CAP provides three types of logical channels: Connectionless: These one-way traffic is usually used for broadcasts. Connection-oriented: Each channel of this type is bi-directional and supports QoS in each direction. Signaling: This is only used for exchanging signalling messages between L2CAP layers. The L2CAP layer also provides segmentation. The layer accepts packets up to 64 kbyte, but a DH5 packet for example only carries a packet of 339 bytes payload. Therefore the packet has to be chopped. SDP The service device protocol defines the discovery of new services provided in an ad-hoc fashion. If a device wants to offer a form of service has to implement a SDP server. 14
2.3. ROUTING ComNet, AAU Bluetooth LAN 2.2.4 Wireless LAN 2.2.5 GPRS 2.3 Routing 2.4 Multicast 2.5 Experimental parts 2.6 Problem statement Which multicast-scheme is best suited for MO-FPS games, considering packet error rate, delay and jitter in a wireless multicast environment 15
Group 681 CHAPTER 3. ANALYSIS Chapter 3 Analysis 16
BIBLIOGRAPHY ComNet, AAU Bibliography [1] Jochen Schiller. Mobile Communication, Second Edition. Addison Wesley, 2003. 17