<%BANNER%>

Multimedia delivery in a wireless environment

University of Florida Institutional Repository

PAGE 1

M U LTIM ED IA D ELIV ER Y IN A W IR ELESS EN V IR O N M EN T B y PETER H A N D EL A TH ESIS PR ESEN TED TO TH E G R A D U A TE SC H O O L O F TH E U N IV ER SITY O F FLO R ID A IN PA R TIA L FU LFILLM EN T O F TH E R EQ U IR EM EN TS FO R TH E D EG R EE O F M A STER O F SC IEN C E U N IV ER SITY O F FLO R ID A 2002

PAGE 2

iiTABLE OF CONTENTSABSTRACT.iiiCHAPTER1 INTRODUCTION.................................................................................................12 MULTIMEDIA......................................................................................................4Video Formats.......................................................................................................4Requirements........................................................................................................73 MULTIMEDIA DELIVERY SYSTEM................................................................8Internet Basics.......................................................................................................8TCP and UDP Layer...........................................................................................10Unicast vs. Multicast...........................................................................................11Streaming............................................................................................................13Current Streaming Technology...........................................................................144 MULTIMEDIA DELIVERY IN THE MOBILE ENVIRONMENT..................17Supporting Multicast of Video in Wireless LANs..............................................17Proposed Protocol...............................................................................................18Interesting Issues.................................................................................................235 SIMULATION AND EXPERIMENTAL EVALUATION ................................ 256 CONCLUSION....................................................................................................29BIBLIOGRAPHY...................................................................................................30APPENDIX: NETWORK SIMULATION SCRIPT..............................................32BIOGRAPHICAL SKETCH..................................................................................36

PAGE 3

iii A bstract of Thesis Presented to the G raduate School of the U niversity of Florida in Partial Fulfillm ent of the R equirem ents for the D egree of M aster of Science M U LTIM ED IA D ELIV ER Y IN A W IR ELESS EN V IR O N M EN T B y Peter H andel D ecem ber 2002 C hair: Professor A bdelsalam H elal M ajor D epartm ent: C om puter and Inform ation Science and Engineering O ur society is definitely infatuated w ith m ultim edia. W ith high quality video and audio com es a steep bandw idth requirem ent, w hich is often im possible to satisfy. W hen one considers this high bandwidth cost across a large audience coupled with our already saturated Internet backbones, traditional unicast quickly becomes a poor choice. M ulticasting allow s transm ission of rich m ultim edia to a large audience, often m itigating the bandw idth im pact equivalent to a single unicast stream As mobile computing and wireless technology become less expensive and m ore w idely adopted, m obile users have com e to dem and a location-transparent quality of service which is difficult if not impossible to satisfy using current data transmission protocols. I propose a multimedia delivery protocol based on the current m ulticasting protocol, using a custom rebroadcasting extension.

PAGE 4

1 C H A PTER 1 IN TR O D U C TIO N I h av e alw ay s b een in terested in th e co n cep t o f co n n ectiv ity w h ile m o b ile. The one aspect of this which may become the Killer App which the public embraces as the must-have technology of the next century is the ability to efficiently deliver m ultim edia across a constrained netw ork. Various other technologies help provide a certain level of quality of service, such as Q oS-aw are routers and operating system s. They attem pt to prioritize packets b a s e d o n a s e t o f ru le s w h ic h a re o fte n s tru c tu re d to fa v o r tim e -s e n s itiv e p a c k e ts (such as video conferencing and telnet) and penalize bulk packets (such as ftp). Even these great advances m ake only a m iniscule dent in the bandw idth requirem ents of full motion video and high quality audio, and thus a new paradigm is required. This new paradigm is even more necessary in the mobile environment, where bandwidth and energy constraints are m uch m ore difficult to appease. This thesis addresses the scenario of a single presentation, which is accessed by m any different clients. In the traditional sense, each client w ould require one unique stream, which would quickly exceed the bandwidth available to the server. In addition, som e m obile clients m ay not be close enough to the server to tune in to the broadcast, but may be close enough to a client that is currently viewing the program. These clients could rebroadcast the stream but how can w e do this efficiently?

PAGE 5

2 The primary goal of this thesis is to first present the constraints high-quality m u ltim ed ia d eliv ery faces in th e m o b ile en v iro n m en t, an d th en to p resen t a cu sto m extension to a w ell-know n protocol, w hich addresses the issues raised. To this goal, the next chapter clarifies not only the m agnitude of the problem that w ide dissem ination of high-quality m ultim edia poses to the backbone of the internet, but also the size of the audience requesting this service. C h ap ter 3 b eg in s w ith a b rief rev iew o f th e b asic p ro to co ls o f th e In tern et, necessary as a foundation for any discussion of multimedia transfer over the Internet. It then examines the concept of streaming, and discusses current streaming technology and its limitations. T his includes RealPlayer (with over 20 million users), QuickTime, and the Microsoft MediaPlayer, along with the mbone, which is a network of m ulticast-aware com puters and routers that, when necessary, unicast to each other over non-multicast-aware computers and routers. It also evaluates currently proposed yet not widely implemented multicasting technologies, such as the m ulticasting extensions of IPv6. T h e u n iq u e ad d itio n al difficulties mobility affords multimedia transfer is presented in Chapter 4. Here, I discuss the problem mobility presents, certain assumptions on which the code presented relies, and then finally my custom approach, the extension to the com m on m ulticasting protocol, w hich exploits certain ad hoc properties to extend the usable range of a m ulticasting protocol. Chapter 5 presents the results of my experimentation and simulation, pitting unicasting against m ulticasting in the rebroadcast of data to clients outside the base stations range yet w ithin range of another client.

PAGE 6

3 The conclusion, Chapter 6, summarizes the results of the coding experiment a n d th e sim u la tio n e x p e rim e n t, a n d th e n a p p lie s th e se re su lts to m y v isio n o f fu tu re m ultim edia broadcasting.

PAGE 7

4 C H A PTER 2 M U LTIM ED IA V ideo Form ats A quick glance at the 2001 Q4 Nielsen// N etRatings dow nload statistics for popular media delivery clients such as RealPlayer, QuickTime, and Windows Media Player readily convince us that the delivery of m ultim edia is arguably one of the m ost so u g h t-a fte r a n d h e a v ily u se d se g me n ts o f th e in te rn e t. Hig h -p ro file we b d e stin a tio n s draw magnitudes of users with high-resolution and high-frame rate multimedia, while the backbones of the Internet groan under the immense weight of the bandwidth these streams require. As users grow accustomed to media with higher resolution and higher fram e rates, the bandw idth required increases rapidly. R ich video and m ultim edia only exacerbate the bandw idth constraints especially prevalent in todays m obile environm ent. Full m otion video at N TSC resolution and 16-bit color requires a data transmission rate of approximately 20MB/sec, which is about 160Mbit/sec 720x486 x 16-bit color x 30 fps. Putting this into perspective, a 56k m odem has a m axim um transm ission rate of 0.056M bit/sec, and the standard SCSI protocol can transfer 40M bit/sec. Since almost no Internet users have access to this speed of service, compression is used to dramatically reduce the amount of data transmitted. Compression, however, can only do so much, as the level of com pression (using a lossy algorithm) is inversely related to the quality of the transm itted data.

PAGE 8

5 A ll com pression m ethods fall under one of tw o categories: lossless (also known as non-lossy) and lossy. Lossless com pression prom ises to com press data without any loss of information; the compressed data can then be expanded to an exact replica of the original information. In other words, the former promises to reduce the size of the data by detecting redundancy in data with low entropy without losing any information contained in the original data. Commonly used forms of lossless compression include Zip (by PkZip), G zip, and StuffIt. Lossy com pression, on the other hand, uses various techniques to rem ove superfluous data from the original audio and video stream Som e of the m ore popular lossy algorithm s include JPEG PN G and A V I. Figure 1 dem onstrates the difference betw een lossy and lossless com pression. Figure 1 The original (left), versus JPEG com pression (right) A s w e see on the right, som e artifacts of the JPEG com pression are visible around the lettering and the top edge. N ext, in Figure 2, w e zoom in on the top left corner of the processor of each photo, w here the reliance on interpolation becom es m uch m ore evident.

PAGE 9

6 Figure 2 Zoom ing in, the original (left), versus JPEG com pression (right) For audio, the easiest and most commonly employed lossy technique for reducing the data requirements is to lower the sampling rate from 44.1khz (CD quality) to 22khz or even 11khz, and then reducing the bit depth from 16 bits to 8 bits or low er. W hile effective, these m ethods severely deteriorate the quality of the audio. Psychoacoustic models, on the other hand, promise extreme levels of compression w ith m inim al loss of sound quality by exploiting certain facts about how our ears interpret sounds. A com m on high-quality com pression/reduction m ethod called Perceptual Coding removes sound information that our brain would anyways discard by eliminating quiet sounds that occur immediately after louder sounds. This method is used in the popular M P3 audio form at. To easily reduce the size requirements of a video stream, the video resolution, fram e rate, and color depth m ay be reduced, but this often results in unacceptable video, as m otion m ay appear jerky and the picture m ay not even be recognizable. Instead, a better approach w ould be to first com press each fram e using a lossy algorithm such as JPE G and then transm it only the differences betw een fram es. W hile better than m erely reducing the resolution and fram e rate, this m ethod does not exploit any of the commonalities between frames. The MPEG format addresses this issue, and is consequently based on the following concept: it sends three types of fram es, nam ely I, B and P. The I fram e contains all the inform ation necessary for

PAGE 10

7 one complete frame of video, and is therefore used to start a stream. The B and P fram es contain inform ation describing the differences betw een video fram es. W hen the differences between video frames are low, a higher percentage of the smallersized B and P frames suffice for smooth video. However, when the changes between video frames become large (such as in a scene change), more I frames are needed, as neighboring fram es m ay have nothing in com m on. R equirem ents The requirem ents for traditional transm ission of m ultim edia content is a server with abundant amounts of bandwidth availability [BAG99], and the processing power and m em ory to handle m ultiple client requests sim ultaneously.

PAGE 11

8 C H A PTER 3 M U LTIM ED IA D ELIV ER Y SY STEM Internet B asics T h e In tern et can b e seen in its mo st simp le fo rm as a g ro u p o f co mp u ters wh ich are co n n ected E v ery co m p u ter is ab le to reach ev ery o th er co m p u ter, eith er directly or indirectly. T he most basic example of a network is two computers that are directly connected to each other, as shown in Figure 3. T hey may be connected in any number of ways including E thernet cable, wireless connection, RS-232 cable, and m any m ore. Figure 3 B asic netw ork betw een tw o laptops The next logical step is to add m ore hosts, as show n in Figure 4. H ere, a packet of information sent from C1 to C3 travels through C2. Depending on the transmission method, C2 may realize that the packet is not meant for it at either the link or IP layer. The advantage of filtering packets at the link layer is that the processor need not spend valuable resources on deciding w hether the packet is

PAGE 12

9 destined for itself. T he disadvantage to this method is that the network interface must im plem ent additional hardw are. Figure 4 Three-host netw ork A s the num ber of clients is increased, routers and sw itches are added to segment the network, acting as a policeman directing traffic. This is show n in Figure 5, w here w e forw ard packets of inform ation w hich are destined for a m achine w hich isn't w ithin the local netw ork by using m ultiple routers. Figure 5 A m ore com plex netw ork

PAGE 13

10 The main difference between a switch and a router is that a switch uses the packet address rather than the protocol itself to determ ine how to filter traffic and therefore w here a packet should go. A dding sw itches and routers not only increases available bandw idth in busy environm ents but also adds a level of security, as a host on an endpoint cannot snoop packets m eant for another host. As our imperfect world may inject anomalies into the data stream, a m echanism of detecting and recovering from data corruption becom es necessary. Therefore, the TCP/IP protocol suite is made up of four different layers: the link layer, the netw ork layer, the transport layer, and the application layer. These layers are designed to ensure that data arrives to the correct recipient uncorrupted and optionally in the sam e order as sent. The link layer is the layer closest to the actual hardware media. Its purpose is to take care of sending and receiving IP packets and handling A R P/R A R P requests and replies. T he netw ork layer consists m ainly of the Internet P rotocol (IP ) and Internet G roup M anagem ent Protocol (IG M P) protocols, w hich are used as a delivery service, as they contain the source and destination address, along with other inform ation used to help the packet get to its destination. H andling data corruption and optionally packet retransm ission and reordering, the transport layer consists of the TCP and UDP protocols. The application layer, as the name implies, is the application itself, such as N etscape or R ealPlayer. T C P and U D P L ayer W ithin an IP packet, we find encapsulated either a T CP or UDP packet. While the IP layer deals with where a packet comes from and where it is going, the

PAGE 14

11 T C P & U D P lay ers m ak e su re th at th e p ack et d id n 't b eco m e m an g led alo n g th e w ay b y u sin g 1 6 b it c h e c k su m s. U D P is th e m in im a lists c h o ic e a s it o n ly p ro v id e s a checksum and therefore only guarantees that the data is not corrupted. TC P goes a step fu rth er an d g u aran tees n o t o n ly th at th e d ata is n o t co rru p ted b u t also th at it is delivered. TCP also uses a sequence numbering system to ensure that packets arrive at the application layer in the order in w hich they w ere sent [PO S80a, PO S80b]. W hen w riting an application designed to transm it m ultim edia in a stream ing fashion, UDP is the preferred protocol, as the extra features TCP provides are su p erflu o u s an d n o t w o rth th e o v erh ead th ey im p o se. R eo rd erin g an d p ack et lo ss recovery m ay be done easily and efficiently at the application level, allow ing the use of U D P. U nicast vs. M ulticast Multimedia is most commonly delivered using a unicast connection between a server and a client. A packet is labeled as a unicast packet if its destination is a single host. A multicast packet, on the other hand, is a packet destined for a set of hosts that belong to a m ulticast group [STE94, pg. 8]. W hile the destination address of a u n ic a st p a c k e t is a sin g le h o st, th e d e stin a tio n a d d re ss o f a m u ltic a st p a c k e t is a special class D IP address, ranging from 224.0.0.0 to 239.255.255.255 [M EY98]. Therefore, when a client desires to start receiving a multicast feed [HAN99a, HAN99b], the IP address of the transmission must be known, and a request to receive packets must be made to the first router (as shown in Figure 6). If client B were interested in receiving a broadcast from the server, it would first inform router D via IGMP by sending a Group Join message. Router D then informs router C, which

PAGE 15

12 finally informs router A to begin sending a stream towards router C [DEE89, DEE99, FEN 97]. Figure 6 Standard broadcasting m odel T h u s o n e s tr e a m o f p a c k e ts f r o m th e s e r v e r c a n b e u s e d to s a tis f y a la r g e number of clients [PUL99], as the routers take it upon themselves to duplicate the stream as often as necessary [A R M 92, B A SIC ]. This duplication, along w ith other inherent m ulticast differences, can introduce som e unexpected bandwidth and latency constraints [D U B 98]. Currently, the overwhelming majority of multimedia transmission on the In te rn e t is d o n e th ro u g h u n ic a stin g T h is is d u e to n o t o n ly th e h ig h c o st a n d ra rity o f multicasting-aware server software, but also to the fact that many of the routers on the Internet today are not configured to support multicasting. There are a few techniques that can be em ployed to overcom e the lack of support: nam ely, tunneling and proxies. Tunneling uses the concept of encapsulation to overcom e m ulticastingdisabled or m ulticasting-unaw are routers by placing a m ulticast packet inside of a

PAGE 16

13 standard unicast packet. A unicast connection is therefore used to bridge the m u ltic a stin g -d isa b le d ro u te r. In th e e x a m p le b e lo w (F ig u re 7 ), th e se rv e r a n d c lie n t are separated by three routers, of which the first and last are multicasting-enabled [C IS02]. Figure 7 M ulticasting across a non-m ulticast router Stream ing The concept of stream ing has been directly responsible for the explosion of high-quality audio and video on the Internet. B efore stream ing, Internet users w ere required to dow nload an entire m edia clip before playback w ould start. This m ade the dissemination of live real-time video impossible; sampling large media clips was likew ise difficult, as m ost Internet users had only a very lim ited am ount of bandw idth at their disposal (usually a 28.8k m odem or slow er). W ith the advent of stream ing, users are now able to begin viewing a multimedia presentation as soon as the first few blocks of data for the transmission arrive. Not only is this more convenient for users

PAGE 17

14 on low -bandw idth connections, it also opens up the realm of live m ultim edia broadcasts over the Internet. W h en stream in g m u ltim ed ia, th e co m p ressio n fo rm at em p lo y ed m ay b e eith er stateless or stateful. Stateless implies that any packet of received information can be used, regardless of whether any other packets have been received, have been corrupted, or have been received out-of-order. A stateful connection, on the other h an d req u ires th e co rrect d eliv ery o f certain p rev io u s p ack ets fo r later p ack ets to b e u sefu l. T h e b en efit o f a statefu l co n n ectio n is th at o n ce a certain state h as b een established, subsequent packets w ill not require as m uch inform ation. The Real-Time Streaming Protocol (RTSP) is an open standard for streaming data. The difference betw een stream ing via standard H TTP and R TSP is as follow s: RTSP streaming may be defined as the transfer of multimedia over a network while it is playing, as opposed to downloading the data and storing it locally before playing it. With HTTP streaming, the movie data is sent to you as fast as your network connection can handle it. Once enough data has been received, the m ovie w ill begin to play. W ith R TSP stream ing, only the m ovie data is sent as you need it, so the data rate of your stream has to be smaller than the netw ork's current speed. [A PP02] Surprisingly, all the m ajor m edia players have adopted this open standard, and play m ultim edia transm itted via R TSP as w ell as their ow n proprietary form ats. C urrent Stream ing T echnology Currently, there are a few solutions for multicasting audio and video, but none have good support for mobile clients. Here, I will examine a few of the more popular multicasting solutions, and later discuss why they fall short when applied to the w ireless environm ent.

PAGE 18

15 With over 21 million users per month as of April 21, 2000 and a whopping 115 million unique registered users, RealPlayer is arguably the most widespread m edia player application in use today. The current G 2 version supports num erous features attractive to m obile users, such as the ability to dynam ically reduce and increase the quality of the broadcast based on changing network conditions. As n e tw o rk c o n d itio n s w o rse n Re a lP la y e r e m p lo y s v a rio u s o th e r tric k s to m a in ta in th e p ercep tio n o f th e o rig in al v id eo q u ality T o ach iev e a certain targ et frame rate, th e RealPlayer client may create tween frames, which are frames interpolated by the client from received neighboring frames to increase the frame rate and overall smoothness of the video clip. Creating tween frames, however, currently requires copious amounts of processing power, and is therefore not done as consistently as we w ould like. The W indow s M edia Player, w hile not nearly as old or as ubiquitous as RealPlayer, is still rather widely used, with approximately 8.6 million monthly users as of April 2000. In side-by-side evaluations with RealPlayer at a transmission rate of 80kbit/sec, fram e rates have been shown to be higher, at the cost of fram e resolution and color accuracy. Apple, being the newest streaming media player, has had a surprising 7.5 million monthly users of its QuickT ime player as of April 2000. T his is most likely due to the availability of the Star Wars Episode I: The Phantom Menace trailers exclusively in the QuickTime format. After performing side-by-side comparisons of the frame rate of a presentation at a certain bandwidth, it becomes clear that the Q uicktim e player, in its current version, does not perform as w ell as expected,

PAGE 19

16 especially w hen com pared to the M icrosoft W indow s M edia Player (ironically also available for the Macintosh MacOS) and the RealPlayer G2. This may be due to the different codecs em ployed by the various players. The currently proposed solutions are also m ainly based on the current multicasting technology. The new IPv6 protocol [CRA98] proposes to change numerous core elements of the current IPv4 networking. While the main goal driving the creation of IPv6 was to expand the usable number of IP addresses to 128 bits, the designers also decided to rem ove broadcasting, as it had proven to be difficult to im plem ent w ithout excessive w asted bandw idth. "There are no broadcast addresses in IPv6, their function being superseded by multicast addresses" [HIN98, pg 2]. IPv6 also offers a built-in (and therefore more finely grained) quality of service control, allowing the system administrator to easily and precisely prioritize bandwidth availability.

PAGE 20

17 C H A PTER 4 M U LTIM ED IA D ELIV ER Y IN TH E M O B ILE EN V IR O N M EN T Supporting M ulticast of V ideo in W ireless L A N s T he multicasting protocol works surprisingly well given the fact that the In tern et was d esig n ed fo r an d n o w alm o st ex clu siv ely carries unicast transmissions. However, once we move to a mobile environment, many fundamental assumptions must be changed: bandwidth may diminish or temporarily become completely unavailable as the client moves away from the base unit. Sensitivity towards power usage is also im perative as m obile com puters have a very lim ited pow er source. The base m odel for these experim ents is the follow ing: Figure 8 Standard configuration

PAGE 21

18 H ere in Figure 8, the server transm its one stream to the first router, w hich splits the stream based on the location of listening clients. In this case, this router duplicates the one stream from the server into only two streams, and sends them to th e re sp e c tiv e a c c e ss p o in ts o n th e ir re sp e c tiv e lo c a l n e tw o rk s. T h e ro u te rs com m unicate am ongst them selves via one of the num erous m ulticast routing protocols [B A L 97, E ST 98, M O Y 94a, M O Y 94b, T H A 99, W A I88] to decide w hether a router requires a copy of the stream Proposed Protocol The W ireless M ulti-M edia D elivery Protocol (W M M D P) proposed here is designed to sit on top of the m ulticasting protocol: Figure 9 W ireless M ulti-M edia D elivery Protocol The extension protocol I propose uses both the Ad Hoc and Infrastructure transmission modes to interface with the standard multicasting protocol, which allows for efficient broadcast of data over the internet. This proposal involves only the last hop of a standard multicast. The server begins sending data regardless of any client initiation. It is the responsibility of the first router to discard all packets if no clients are listening.

PAGE 22

19 The first client of a subnet to request a certain broadcast will negotiate with its router via IGM P the fact that it wishes to receive this broadcast. T he routers then handle getting a stream of the m ultim edia to the router closest to the client via PIM or any other m ulticast routing protocol. The client for this Wireless Multimedia Delivery Protocol (WMDP) listens on port 3845 for the multicast stream. Once the data arrives, it streams the data to a tem p o rary file u sed to b u ffer th e d ata, an d also to k eep o ld er p ack ets fo r o th er clien ts w ho m ay request previously used packets. Each client w ill also listen on port 4845 for com m unication from other clients. This inter-client com m unication w ill consist m ainly of requests for m issed packets. Each packet w ill have em bedded w ithin itself th e p ack et n u m b er (b y th e p ro to co l, as UDP d o es n o t en su re in -o rd er p ack et d eliv ery ) and the source address (by the netw ork stack). When a client C1 notices that it has missed receiving a packet P1 within a sm all tim eout, it sends a request for retransm ission of this packet P1 to any nearby client C 2. The different responses C 2 provides are discussed below : Standard M ode In Standard M ode (SM ), C2 simply sends C1 the packet via a standard ad hoc U D P connection. This is the straightforw ard approach.

PAGE 23

20 M ulticast M ode In the Multicast Mode (MM), a nearby client, C2, which has received P1, will begin rebroadcasting the stream to C 1 via ad hoc m ode by sending the packets to the special ad hoc m ulticast address. The sim ulation w ill show the affect of the three rebroadcast situations on stream availability: 1. No rebroadcasting. The clients will need to stay relatively close to the base station within 300ft in an office setting, and within 2000ft outdoors. W e w ill use 500ft as an average range. 2. Sim ple direct rebroadcasting. H ere, the range is extended beyond the base station, but excessive netw ork utilization w ill saturate the 2M bit/sec bandw idth available. 3. M ulticast rebroadcasting. Clients rebroadcast to the m ulticast address rather than to the specific client in need. W e w ill exam ine optim izations to cut dow n the num ber of clients rebroadcasting w ithin a certain range. A n arbitrary assignm ent of five states w ill be m ade to aid in differentiating betw een the different situations that m ay occur in the course of client m obility. Each client can be in only one of five states: 0. Standard state; client listening to a stream 1. O ur client receives a request for help, and w e w ill help 2. W e need a rebroadcast, but have not received a helper 3. W e need a rebroadcast, and have received a helper 4. W e are receiving help, and another client needs our help

PAGE 24

21 Each client itself listens on three channels: C hannel A : Listens via infrastructure m ode to the broadcast C hannel B : Listens via ad hoc m ode to the broadcast C hannel C : Listens via ad hoc m ode to the control channel C hannel C is used to send and receive help requests from and to clients. Figure 10 show s the clients possible states. The arrow s betw een states indicate the only possible state changes a client m ay perform State 0: { R em ain in 0: C lient continues listening to the broadcast G o to 1: C lient receives request for help, and helps G o to 2: W e w ander out of range, and require help } Figure 10 W W M D P State D iagram

PAGE 25

22 State 1: { R em ain in 1: Som e client(s) still require assistance; w ill continue helping R eturn to 0: Either helped client sends no longer needed, or does not respond to acknow legem ent G o to 2: W e have gone out of range. A ny clients using our services also suffer. } State 2: { R em ain in 2: W e still need help, and have not received any G o to 3: W e have received help from som eone G o to 0: W e have w andered back into the range of the infrastructure broadcast } State 3: { R em ain in 3: W e continue requiring rebroadcasts from another helping client G o to 0: B ack in range of the base station, w e can now once again use infrastructure G o to 4: A nother client needs help from us; w e oblige } State 4: { R em ain in 4: W e continue to need help, and also continue to rebroadcast for others G o to 1: W e reenter the infrastructure range, but continue helping others G o to 3: If client w e are helping sends no longer needed or doesnt respond }

PAGE 26

23 Interesting Issues Several interesting issues m ay arise due to the m obile nature of the clients. Here, I examine a few of the more common possibilities/occurrences, such as hop count optimization, isthmus effect optimization, and the effect of lazy acknow ledgem ent. If we track the num ber of hops each client is from the infrastructure area, we may use this to make wise decisions during rebroadcast negotiations where multiple c lie n ts a re a v a ila b le If a c lie n t h a s a c h o ic e to re c e iv e a re b ro a d c a st fro m e ith e r a distant (high hip count) or close (low hop count) client, it should choose the closer, as n o t o n ly will it h av e a lo wer laten cy stream b u t also m ay in d icate th at it is less m obile and therefore m ore likely to continue receiving the stream The isthmus effect is a routing dilemma where, to reach a certain client B from a machine A, packets must be routed in a physically opposite direction. This dilem m a in the w ired environm ent is reduced to an optim ization problem here. W hile we d o n o t co n cern o u rselv es with th e u n d erly in g ad h o c ro u tin g p ro to co l, we d o wan t to be confident in our decisions on w hom to ask to continue rebroadcasting. Lazy acknow ledgem ent becom es extrem ely useful w hen w e attem pt to prune the amount of clients rebroadcasting the stream. W e ask for each client who is listening to our rebroadcast to send us an acknowledgement every 30 seconds. If two consecutive acknow ledgem ents are m issed, w e prune that specific client from the list of clients listening to our rebroadcast. When the number reaches zero, we know that w e m ay stop rebroadcasting; however, if a mobile client moves into our area and uses

PAGE 27

24 our rebroadcast stream without our knowledge, that client m ust initiate com m unication w ith us and negotiate rebroadcasting.

PAGE 28

25 C H A PTER 5 SIM U LA TIO N A N D EX PER IM EN TA L EV A LU A TIO N A s m e n tio n e d in th e fin a l p a ra g ra p h s o f C h a p te r 5 th e c u s to m e x te n s io n to th e m u ltic a stin g p ro to c o l p ro p o se d w o u ld ta k e in to a c c o u n t th e ra p id ly flu c tu a tin g bandwidth available to the mobile client based on the distance from the base station. This is done by rebroadcasting packets from clients receiving the stream to clients wishing to receive the stream yet tragically out of range of the base station. T he three m ajor cases considered w ere: 1) no rebroadcasting, 2) sim p le d ire c t rebroadcasting, an d 3 ) m u lticast reb ro ad castin g Also, how many nodes must be present in a given area to provide coverage to all nodes? Before performing any experiments, the following hypothetical outcome seems mo st lik ely : In an area with a sp arse n u mb er o f clien ts, th e d an g er o f flo o d in g the local area w ith duplicate packets is m inim al. If m any clients converge to one physical area, the resulting duplication w ill flood the w ireless netw ork and becom e counterproductive. For the following simulations, we assume a clear 800 feet by 600 feet area w ith a base station at position 400, 300. B oth the base station and the individual nodes use a w ireless card w ith a range of 150 feet, w hose signal strength falls off logarithm ically at the edge of their range.

PAGE 29

26 Based on the general principles of cell bandw idth availability and range, here is a theoretical graph of the percentage of packets received versus the distance from the base station: 0 100 200 300 400 500 600 700 800 900 1000 S1 S3 0 10 20 30 40 50 60 70 80 90 100 Percent of Packets Received Distance (feet) D istance vs. Packet Loss Figure 11 D istance vs. Packet Loss graph The standard case (blue), with no rebroadcasting, perform s w ell up to the edge of its range (500ft). The unicast rebroadcast m ode (red) also perform s w ell, but past the range of the base station, m any clients are requesting a rebroadcast, w hich floods the cell with many duplicate packets. The multicast rebroadcast mode (yellow) s tro n g ly re d u c e s th e a m o u n t o f d u p lic a te p a c k e ts a s m a n y c lie n ts c a n s h a re o n e m ulticast rebroadcast. N etw ork Sim ulation I perform ed num erous sim ulations of the W M D P using the Berkley N etw ork S im ulator version 2. T hese sim ulations w ere designed to differentiate the perform ance of the three rebrodacasting options m entioned throughout this thesis: the

PAGE 30

27 standard straightforw ard no-rebroadcasting configuration, the unicast-rebroadcasting configuration, and the m ulticast-rebroadcast configuration. After working around numerous incompatibilities between the multicasting package and the wireless package by using suboptimal approximations, we see that the hypothesis above was confirmed. However, since these approximations were suboptim al, it seem ed that w riting a new netw ork sim ulator from scratch w ould be best. M y netw ork sim ulator sim ulates one base station in the m iddle of a field, and adds the specified number of mobile clients w hich m ay or m ay not m ove in a random direction. T his sim ulation is run for 60 seconds, after w hich it show s the average percentage of the grid coverage and the average percentage of nodes that received the stream. F or example, if all nodes were in range of the base station, then the grid coverage w ould be 12% and the nodes-received percentage w ould be 100% Each 60-second simulation was run 50 times, and then the percentages were averaged. The results are show n below num erically in Figure 12, and graphically in Figure 13.

PAGE 31

28 N um ber of N odes G rid Percentage N ode Percentage 2 12 9.12 4 12.66 15.36 8 15.96 22.26 12 24.88 31.14 16 40.92 48.12 24 65 67.16 Figure 12 Sim ulation results Figure 13 N um ber of N odes vs. C overage 2 4 8 12 16 24 Grid Percentage Node Percentage 0 10 20 30 40 50 60 70 % Covered Num ber of Nodes Nu mber of Nodes vs. Coverage Grid Percentage Node Percentage

PAGE 32

29 C H A PTER 6 C O N C LU SIO N In c o n c lu s io n m u ltic a s tin g p ro m is e s to d ra s tic a lly re d u c e th e a m o u n t o f bandwidth required by a server to satisfy a large number of clients requesting a broadcast of multimedia. However, multicasting by itself does not adequately address availability issues, as m obile users m ay roam away from the base transm itting station. The proposed extension to the multicasting protocol restores a large amount of m obility previously lost to the range of the base transm itting station, and extends this range based on the num ber of listening clients w ithin close proxim ity.

PAGE 33

30 B IB LIO G R A PH Y A PP02 A pple C om puter, Q uickTim e Stream ing July 2002, http://w w w .apple.com /quicktim e/authoring/hinttrack.htm l V erified: January, 2002. A R M 92 A rm strong, S., Freier, A ., and M arzullo, K ., R FC 1301: M ulticast Transport Protocol February 1992, http://w w w .ietf.org/rfc/rfc1301.txt V erified: N ovem ber 8, 2002. B A G 99 B agnall, P., B riscoe, R ., and Poppitt, A ., R FC 2729: Taxonom y of C om m unication R equirem ents for Large-scale M ulticast A pplications D ecem ber 1999, http://w w w .ietf.org/rfc/rfc2729.txt V erified: N ovem ber 8, 2002. B A L97 B allardie, A ., R FC 2201: C ore B ased Trees (C B T) M ulticast R outing A rchitecture Septem ber 1997, http://w w w .ietf.org/rfc/rfc2201.txt V erified: N ovem ber 8, 2002. C IS02 C isco IP M ulticast G roups External H om epage ftp://ftpeng.cisco.com /ipm ulticast/index.htm l V erified: N ovem ber 8, 2002. C R A 98 C raw ford, M ., Transm ission of Ipv6 Packets over Ethernet N etw orks D ecem ber 1998, http://w w w .ietf.org/rfc/rfc2464.txt V erified: N ovem ber 8, 2002. D EE89 D eering, S., R FC 1112: H ost Extensions for IP M ulticasting A ugust 1989, http://w w w .ietf.org/rfc/rfc1112.txt V erified: N ovem ber 8, 2002. D EE99 D eering, S., Fenner, W ., and H aberm an, B ., R FC 2710: M ulticast Listener D iscovery (M LD ) for IPv6 O ctober 1999, http://w w w .ietf.org/rfc/rfc2710.txt V erified: N ovem ber 8, 2002. D U B 98 D ubray, K ., R FC 2432: Term inology for IP M ulticast B enchm arking O ctober 1998, http://w w w .ietf.org/rfc/rfc2432.txt V erified: N ovem ber 8, 2002. EST98 Estrin, D ., Farinacci, D ., H elm y, A ., Thaler, D ., D eering, S., H andley, M ., Jacobson, V ., Liu, C ., Sharm a., P., W ei, L., R FC 2362: Protocol Independent M ulticast Sparse M ode (PIM -SM ): Protocol Specification June 1998, http://w w w .ietf.org/rfc/rfc2362.txt V erified: N ovem ber 8, 2002. FEN 97 Fenner, W ., R FC 2236: Internet G roup M anagem ent Protocol, V ersion 2 N ovem ber 1997, http://w w w .ietf.org/rfc/rfc2236.txt V erified: N ovem ber 8, 2002.

PAGE 34

31 H A N 99a H andley, M ., Schulzrinne, H ., Schooler, E., R osenberg, J., R FC 2543: SIP: Session Initiation Protocol M arch 1999, http://w w w .ietf.org/rfc/rfc2543.txt V erified: N ovem ber 8, 2002. H A N 99b H anna, S., Patel, B ., and Shah, M ., R FC 2730: M ulticast A ddress D ynam ic C lient A llocation Protocol (M A D C A P) D ecem ber 1999, http://w w w .ietf.org/rfc/rfc2730.txt V erified: N ovem ber 8, 2002. H IN 98 H inden, R ., and D eering, S., R FC 2373: IP V ersion 6 A ddressing A rchitecture July 1998, http://w w w .ietf.org/rfc/rfc2373.txt V erified: N ovem ber 8, 2002. M EY 98 M eyer, D ., R FC 2365: A dm inistratively Scoped IP M ulticast July 1998, http://w w w .ietf.org/rfc/rfc2365.txt V erified: N ovem ber 8, 2002. M O Y 94a M oy, J., R FC 1584: M ulticast Extensions to O SPF M arch 1994, http://w w w .ietf.org/rfc/rfc1584.txt V erified: N ovem ber 8, 2002. M O Y 94b M oy, J., R FC 1585: M O SPF: A nalysis and Experience M arch 1994, http://w w w .ietf.org/rfc/rfc1585.txt V erified: N ovem ber 8, 2002. PO S80a Postel, J., D O D Standard Transm ission C ontrol Protocol January 1980, http://w w w .ietf.org/rfc/rfc761.txt V erified: N ovem ber 8, 2002. PO S80b Postel, J., U ser D atagram Protocol A ugust 1980, http://w w w .ietf.org/rfc/rfc768.txt V erified: N ovem ber 8, 2002. PU L99 Pullen, M ., M yjak, M ., and B ouw ens, C ., R FC 2502: Lim itations of Internet Protocol Suite for D istributed Sim ulation in the Large M ulticast Environm ent February 1999, http://w w w .ietf.org/rfc/rfc2502.txt V erified: N ovem ber 8, 2002. STE94 Stevens, W R ichard, TC P/IP Illustrated, V olum e I C opyright 1994 by A ddison-W esley, R eading, M A TH A 99 Thaler, D ., R FC 2715: Interoperability R ules for M ulticast R outing Protocols O ctober 1999, http://w w w .ietf.org/rfc/rfc2715.txt V erified: N ovem ber 8, 2002. W A I88 W aitzm an, D ., Partridge, C ., and D eering, S., R FC 1075: D istance V ector M ulticast R outing Protocol N ovem ber 1988, http://w w w .ietf.org/rfc/rfc1075.txt V erified: N ovem ber 8, 2002.

PAGE 35

32APPENDIX NETWORK SIMULATION SCRIPT ## Copyright (c) 1996 Regents of the University of California.# All rights reserved.## Redistribution and use in source and binary forms, with or without# modification, are permitted provided that the following conditions# are met:# 1. Redistributions of source code must retain the above copyright# notice, this list of conditions and the following disclaimer.# 2. Redistributions in binary form must reproduce the above copyright# notice, this list of conditions and the following disclaimer in the# documentation and/or other materials provided with the distribution.# 3. All advertising materials mentioning features or use of this software# must display the following acknowledgement:# This product includes software developed by the MASH Research# Group at the University of California Berkeley.# 4. Neither the name of the University nor of the Research Group may be# used to endorse or promote products derived from this software without# specific prior written permission.## THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE# ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF# SUCH DAMAGE.## @(#) $Header: /usr/src/mash/repository/vint/ns-2/tcl/ex/mcast.tcl,v 1.121999/09/10 22:08:41 haoboy Exp $# updated to use -multicast on and allocaddr by Lloyd Wood## Simple multicast test. It's easiest to verify the# output with the animator.# We create a four node start; start a CBR traffic generator in the center# and then at node 3 and exercise the join/leave code.## See tcl/ex/newmcast/mcast*.tcl for more mcast example scripts# ======================================================================# Define options# ======================================================================set opt(chan) Channel/WirelessChannel ;# channel typeset opt(prop) Propagation/TwoRayGround ;# radio-propagationmodelset opt(netif) Phy/WirelessPhy ;# network interface typeset opt(mac) Mac/802_11 ;# MAC type

PAGE 36

33 set opt(ifq) Queue/DropTail/PriQueue ;# interface queue type set opt(ll) LL ;# link layer type set opt(ant) Antenna/OmniAntenna ;# antenna model set opt(ifqlen) 50 ;# max packet in ifq set opt(nn) 15 ;# number of mobilenodes set opt(adhocRouting) DSDV ;# routing protocol set opt(cp) "" ;# connection pattern file set opt(sc) "scen" ;# node movement file. set opt(x) 2000 ;# x coordinate of topology set opt(y) 2000 ;# y coordinate of topology set opt(seed) 0.0 ;# seed for random number gen. set opt(stop) 500 ;# time to stop simulation set opt(ftp1-start) 160.0 set opt(ftp2-start) 170.0 set opt(udp-start) 0 set num_wired_nodes 2 set num_bs_nodes 1 # ============================================================================ # check for boundary parameters and random seed if { $opt(x) == 0 || $opt(y) == 0 } { puts "No X-Y boundary values given for wireless topology\n" } if {$opt(seed) > 0} { puts "Seeding Random number generator with $opt(seed)\n" ns-random $opt(seed) } set ns [new Simulator -multicast on] $ns node-config -addressType hierarchical AddrParams set domain_num_ 2 ;# number of domains lappend cluster_num 2 1 ;# number of clusters in each domain AddrParams set cluster_num_ $cluster_num lappend eilastlevel 1 1 [expr $opt(nn) + 1] ;# number of nodes in each cluster AddrParams set nodes_num_ $eilastlevel ;# of each domain set tracefd [open out.tr w] set namtrace [open out.nam w] $ns trace-all $tracefd $ns namtrace-all-wireless $namtrace $opt(x) $opt(y) # Create topography object set topo [new Topography] # define topology $topo load_flatgrid $opt(x) $opt(y) # create God create-god $opt(nn) set god_ [God instance] #create wired nodes set temp {0.0.0 0.1.0} ;# hierarchical addresses for wired domain

PAGE 37

34 for {set i 0} {$i < $num_wired_nodes} {incr i} { set W($i) [$ns node [lindex $temp $i]] } # configure for base-station node $ns node-config -adhocRouting $opt(adhocRouting) \ -llType $opt(ll) \ -macType $opt(mac) \ -ifqType $opt(ifq) \ -ifqLen $opt(ifqlen) \ -antType $opt(ant) \ -propType $opt(prop) \ -phyType $opt(netif) \ -channelType $opt(chan) \ -topoInstance $topo \ -wiredRouting ON \ -agentTrace ON \ -routerTrace OFF \ -macTrace OFF $ns color 1 red # prune/graft packets $ns color 30 purple $ns color 31 bisque set temp {1.0.0 1.0.1 1.0.2 1.0.3 1.0.4 1.0.5 1.0.6 1.0.7 1.0.8 1.0.9 1.0.10 1.0.11 1.0.12 1.0.13 1.0.14 1.0.15 1.0.16 1.0.17 1.0.18 1.0.19 1.0.20} ;# hier address to be used for wireless ;# domain set BS(0) [$ns node [lindex $temp 0]] $BS(0) random-motion 0 ;# disable random motion #provide some co-ord (fixed) to base station node $BS(0) set X_ 1.0 $BS(0) set Y_ 2.0 $BS(0) set Z_ 0.0 #configure for mobilenodes $ns node-config -wiredRouting OFF for {set j 0} {$j < $opt(nn)} {incr j} { set node_($j) [ $ns node [lindex $temp \ [expr $j+1]] ] $node_($j) base-station [AddrParams set-hieraddr \ [$BS(0) node-addr]] } $ns duplex-link $W(0) $W(1) 5Mb 2ms DropTail $ns duplex-link $W(1) $BS(0) 5Mb 2ms DropTail $ns duplex-link-op $W(0) $W(1) orient down $ns duplex-link-op $W(1) $BS(0) orient left-down set mproto DM set mrthandle [$ns mrtproto $mproto {}] set group0 [Node allocaddr] set udp0 [new Agent/UDP] $ns attach-agent $node_(1) $udp0 $udp0 set dst_addr_ $group0 $udp0 set dst_port_ 0

PAGE 38

35 set cbr0 [new Application/Traffic/CBR] $cbr0 attach-agent $udp0 set rcvr [new Agent/LossMonitor] for {set j 0} {$j < $opt(nn)} {incr j} { $ns attach-agent $node_($j) $rcvr $ns at 1.2 "$node_($j) join-group $rcvr $group0" } $ns at 1.0 "$cbr0 start" $ns at $opt(stop).0002 "puts \"NS EXITING...\" ; $ns halt" $ns at $opt(stop).0001 "finish" proc finish {} { global ns $ns flush-trace puts "running nam..." exec nam out.nam & exit 0 } $ns run

PAGE 39

36BIOGRAPHICAL SKETCHPeter Handel was born in 1976 to two professors in St. Louis, MO, where hestarted using computers at the age of five. He received his bachelors degree inphysics from St. Olaf College, and is currently finishing a masters degree incomputer science at the University of Florida Gainesville. He accepted a position asSenior Engineer on the MacOS X project at Apple Computer, Inc., in the summer of2000.


Permanent Link: http://ufdc.ufl.edu/UFE0000542/00001

Material Information

Title: Multimedia delivery in a wireless environment
Physical Description: Mixed Material
Creator: Handel, Peter ( Author, Primary )
Publication Date: 2002
Copyright Date: 2002

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0000542:00001

Permanent Link: http://ufdc.ufl.edu/UFE0000542/00001

Material Information

Title: Multimedia delivery in a wireless environment
Physical Description: Mixed Material
Creator: Handel, Peter ( Author, Primary )
Publication Date: 2002
Copyright Date: 2002

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0000542:00001


This item has the following downloads:


Full Text












MULTIMEDIA DELIVERY IN A WIRELESS ENVIRONMENT


By


PETER HANDEL













A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2002
















TABLE OF CONTENTS


A B S T R A C T ............. ........................................................ iii

CHAPTER
1 INTRODUCTION .. .......... .................... ...... ........ .......... 1

2 MULTIMEDIA........................... .... .......... 4
V ideo Form ats................................................................................. 4
Require ents .......................................................... ........ 7

3 MULTIMEDIA DELIVERY SYSTEM ................... ............... 8
Internet Basics .................................... ........................... 8
TCP and UDP Layer ............................................. ..................... 10
U nicast vs. M ulticast.......... ............................ .... ........ .......... ..... 11
Stream ing ..................................... ................... ........................ 13
Current Streaming Technology................................................................. 14

4 MULTIMEDIA DELIVERY IN THE MOBILE ENVIRONMENT................ 17
Supporting Multicast of Video in Wireless LANs ............................................ 17
Proposed Protocol ........................................................... 18
Interesting Issues.................................................... 23

5 SIMULATION AND EXPERIMENTAL EVALUATION ................................ 25

6 C O N C L U SIO N ............................ ........................................................... 29

BIBLIOGRAPHY ................. ................ 30

APPENDIX: NETWORK SIMULATION SCRIPT ......................................... 32

B IO G R A PH IC A L SK E TCH .......... .................................... .............................. 36















Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science

MULTIMEDIA DELIVERY IN A WIRELESS ENVIRONMENT


By

Peter Handel

December 2002


Chair: Professor Abdelsalam Helal
Major Department: Computer and Information Science and Engineering

Our society is definitely infatuated with multimedia. With high quality video

and audio comes a steep bandwidth requirement, which is often impossible to satisfy.

When one considers this high bandwidth cost across a large audience coupled with

our already saturated Internet backbones, traditional unicast quickly becomes a poor

choice. Multicasting allows transmission of rich multimedia to a large audience,

often mitigating the bandwidth impact equivalent to a single unicast stream.

As mobile computing and wireless technology become less expensive and

more widely adopted, mobile users have come to demand a location-transparent

quality of service which is difficult if not impossible to satisfy using current data

transmission protocols. I propose a multimedia delivery protocol based on the current

multicasting protocol, using a custom rebroadcasting extension.















CHAPTER 1
INTRODUCTION

I have always been interested in the concept of connectivity while mobile.

The one aspect of this which may become the "Killer App" which the public

embraces as the must-have technology of the next century is the ability to efficiently

deliver multimedia across a constrained network.

Various other technologies help provide a certain level of quality of service,

such as QoS-aware routers and operating systems. They attempt to prioritize packets

based on a set of rules, which are often structured to favor time-sensitive packets

(such as video conferencing and telnet) and penalize bulk packets (such as ftp). Even

these great advances make only a miniscule dent in the bandwidth requirements of

full motion video and high quality audio, and thus a new paradigm is required. This

new paradigm is even more necessary in the mobile environment, where bandwidth

and energy constraints are much more difficult to appease.

This thesis addresses the scenario of a single presentation, which is accessed

by many different clients. In the traditional sense, each client would require one

unique stream, which would quickly exceed the bandwidth available to the server. In

addition, some mobile clients may not be close enough to the server to tune in to the

broadcast, but may be close enough to a client that is currently viewing the program.

These clients could rebroadcast the stream, but how can we do this efficiently?






2


The primary goal of this thesis is to first present the constraints high-quality

multimedia delivery faces in the mobile environment, and then to present a custom

extension to a well-known protocol, which addresses the issues raised. To this goal,

the next chapter clarifies not only the magnitude of the problem that wide

dissemination of high-quality multimedia poses to the backbone of the internet, but

also the size of the audience requesting this service.

Chapter 3 begins with a brief review of the basic protocols of the Internet,

necessary as a foundation for any discussion of multimedia transfer over the Internet.

It then examines the concept of streaming, and discusses current streaming

technology and its limitations. This includes RealPlayer (with over 20 million users),

QuickTime, and the Microsoft MediaPlayer, along with the mbone, which is a

network of multicast-aware computers and routers that, when necessary, unicast to

each other over non-multicast-aware computers and routers. It also evaluates

currently proposed yet not widely implemented multicasting technologies, such as the

multicasting extensions of IPv6.

The unique additional difficulties mobility affords multimedia transfer is

presented in Chapter 4. Here, I discuss the problem mobility presents, certain

assumptions on which the code presented relies, and then finally my custom

approach, the extension to the common multicasting protocol, which exploits certain

ad hoc properties to extend the usable range of a multicasting protocol.

Chapter 5 presents the results of my experimentation and simulation, pitting

unicasting against multicasting in the rebroadcast of data to clients outside the base

stations range yet within range of another client.






3


The conclusion, Chapter 6, summarizes the results of the coding experiment

and the simulation experiment, and then applies these results to my vision of future

multimedia broadcasting.















CHAPTER 2
MULTIMEDIA

Video Formats

A quick glance at the 2001 Q4 Nielsen//NetRatings download statistics for

popular media delivery clients such as RealPlayer, QuickTime, and Windows Media

Player readily convince us that the delivery of multimedia is arguably one of the most

sought-after and heavily used segments of the internet. High-profile web destinations

draw magnitudes of users with high-resolution and high-frame rate multimedia, while

the backbones of the Internet groan under the immense weight of the bandwidth these

streams require. As users grow accustomed to media with higher resolution and

higher frame rates, the bandwidth required increases rapidly.

Rich video and multimedia only exacerbate the bandwidth constraints

especially prevalent in today's mobile environment. Full motion video at NTSC

resolution and 16-bit color requires a data transmission rate of approximately

20MB/sec, which is about 160Mbit/sec 720x486 x 16-bit color x 30 fps. Putting this

into perspective, a 56k modem has a maximum transmission rate of 0.056Mbit/sec,

and the standard SCSI protocol can transfer 40Mbit/sec. Since almost no Internet

users have access to this speed of service, compression is used to dramatically reduce

the amount of data transmitted. Compression, however, can only do so much, as the

level of compression (using a lossy algorithm) is inversely related to the quality of the

transmitted data.









All compression methods fall under one of two categories: lossless (also

known as non-lossy) and lossy. Lossless compression promises to compress data

without any loss of information; the compressed data can then be expanded to an

exact replica of the original information. In other words, the former promises to

reduce the size of the data by detecting redundancy in data with low entropy without

losing any information contained in the original data. Commonly used forms of

lossless compression include Zip (by PkZip), Gzip, and Stufflt. Lossy compression,

on the other hand, uses various techniques to remove superfluous data from the

original audio and video stream. Some of the more popular lossy algorithms include

JPEG, PNG, and AVI. Figure 1 demonstrates the difference between lossy and

lossless compression.











Figure 1 The original (left), versus JPEG compression (right)

As we see on the right, some artifacts of the JPEG compression are visible around the

lettering and the top edge. Next, in Figure 2, we zoom in on the top left corner of the

processor of each photo, where the reliance on interpolation becomes much more

evident.
















Figure 2 Zooming in, the original (left), versus JPEG compression (right)

For audio, the easiest and most commonly employed lossy technique for

reducing the data requirements is to lower the sampling rate from 44.1khz (CD

quality) to 22khz or even 11khz, and then reducing the bit depth from 16 bits to 8 bits

or lower. While effective, these methods severely deteriorate the quality of the audio.

Psychoacoustic models, on the other hand, promise extreme levels of compression

with minimal loss of sound quality by exploiting certain facts about how our ears

interpret sounds. A common high-quality compression/reduction method called

Perceptual Coding removes sound information that our brain would anyways discard

by eliminating quiet sounds that occur immediately after louder sounds. This method

is used in the popular MP3 audio format.

To easily reduce the size requirements of a video stream, the video resolution,

frame rate, and color depth may be reduced, but this often results in unacceptable

video, as motion may appear jerky and the picture may not even be recognizable.

Instead, a better approach would be to first compress each frame using a lossy

algorithm such as JPEG and then transmit only the differences between frames.

While better than merely reducing the resolution and frame rate, this method does not

exploit any of the commonalities between frames. The MPEG format addresses this

issue, and is consequently based on the following concept: it sends three types of

frames, namely I, B, and P. The I frame contains all the information necessary for









one complete frame of video, and is therefore used to start a stream. The B and P

frames contain information describing the differences between video frames. When

the differences between video frames are low, a higher percentage of the smaller-

sized B and P frames suffice for smooth video. However, when the changes between

video frames become large (such as in a scene change), more I frames are needed, as

neighboring frames may have nothing in common.

Requirements

The requirements for traditional transmission of multimedia content is a server

with abundant amounts of bandwidth availability [BAG99], and the processing power

and memory to handle multiple client requests simultaneously.















CHAPTER 3
MULTIMEDIA DELIVERY SYSTEM

Internet Basics

The Internet can be seen in its most simple form as a group of computers

which are connected. Every computer is able to reach every other computer, either

directly or indirectly. The most basic example of a network is two computers that are

directly connected to each other, as shown in Figure 3. They may be connected in any

number of ways including Ethernet cable, wireless connection, RS-232 cable, and

many more.












Figure 3 Basic network between two laptops

The next logical step is to add more hosts, as shown in Figure 4. Here, a

packet of information sent from Cl to C3 travels through C2. Depending on the

transmission method, C2 may realize that the packet is not meant for it at either the

link or IP layer. The advantage of filtering packets at the link layer is that the

processor need not spend valuable resources on deciding whether the packet is







destined for itself. The disadvantage to this method is that the network interface must
implement additional hardware.


Client 1 Client 2 Client 3


Figure 4 Three-host network

As the number of clients is increased, routers and switches are added to
segment the network, acting as a policeman directing traffic.
This is shown in Figure 5, where we forward packets of information which are
destined for a machine which isn't within the local network by using multiple routers.


1


Figure 5 A more complex network


1Wi









The main difference between a switch and a router is that a switch uses the

packet address rather than the protocol itself to determine how to filter traffic and

therefore where a packet should go. Adding switches and routers not only increases

available bandwidth in busy environments but also adds a level of security, as a host

on an endpoint cannot snoop packets meant for another host.

As our imperfect world may inject anomalies into the data stream, a

mechanism of detecting and recovering from data corruption becomes necessary.

Therefore, the TCP/IP protocol suite is made up of four different layers: the link

layer, the network layer, the transport layer, and the application layer. These layers

are designed to ensure that data arrives to the correct recipient uncorrupted and

optionally in the same order as sent.

The link layer is the layer closest to the actual hardware media. Its purpose is

to take care of sending and receiving IP packets and handling ARP/RARP requests

and replies. The network layer consists mainly of the Internet Protocol (IP) and

Internet Group Management Protocol (IGMP) protocols, which are used as a delivery

service, as they contain the source and destination address, along with other

information used to help the packet get to its destination. Handling data corruption

and optionally packet retransmission and reordering, the transport layer consists of

the TCP and UDP protocols. The application layer, as the name implies, is the

application itself, such as Netscape or RealPlayer.

TCP and UDP Layer

Within an IP packet, we find encapsulated either a TCP or UDP packet.

While the IP layer deals with where a packet comes from and where it is going, the









TCP & UDP layers make sure that the packet didn't become mangled along the way

by using 16 bit checksums. UDP is the minimalists choice, as it only provides a

checksum and therefore only guarantees that the data is not corrupted. TCP goes a

step further and guarantees not only that the data is not corrupted, but also that it is

delivered. TCP also uses a sequence numbering system to ensure that packets arrive

at the application layer in the order in which they were sent [POS80a, POS80b].

When writing an application designed to transmit multimedia in a streaming

fashion, UDP is the preferred protocol, as the extra features TCP provides are

superfluous and not worth the overhead they impose. Reordering and packet loss

recovery may be done easily and efficiently at the application level, allowing the use

of UDP.

Unicast vs. Multicast

Multimedia is most commonly delivered using a unicast connection between a

server and a client. A packet is labeled as a unicast packet if its destination is a single

host. A multicast packet, on the other hand, is a packet "destined for a set of hosts

that belong to a multicast group" [STE94, pg. 8]. While the destination address of a

unicast packet is a single host, the destination address of a multicast packet is a

special class D IP address, ranging from 224.0.0.0 to 239.255.255.255 [MEY98].

Therefore, when a client desires to start receiving a multicast feed [HAN99a,

HAN99b], the IP address of the transmission must be known, and a request to receive

packets must be made to the first router (as shown in Figure 6). If client B were

interested in receiving a broadcast from the server, it would first inform router D via

IGMP by sending a "Group Join" message. Router D then informs router C, which








finally informs router A to begin sending a stream towards router C [DEE89, DEE99,

FEN97].

Router A Router B



Router C Cl
Client A




(I.. iwc
Router D -,
Server Client B

Figure 6 Standard broadcasting model

Thus, one stream of packets from the server can be used to satisfy a large

number of clients [PUL99], as the routers take it upon themselves to duplicate the

stream as often as necessary [ARM92, BASIC]. This duplication, along with other

inherent multicast differences, can introduce some unexpected bandwidth and latency

constraints [DUB98].

Currently, the overwhelming majority of multimedia transmission on the

Internet is done through unicasting. This is due to not only the high cost and rarity of

multicasting-aware server software, but also to the fact that many of the routers on the

Internet today are not configured to support multicasting. There are a few techniques

that can be employed to overcome the lack of support: namely, tunneling and proxies.

Tunneling uses the concept of encapsulation to overcome multicasting-

disabled or multicasting-unaware routers by placing a multicast packet inside of a









standard unicast packet. A unicast connection is therefore used to bridge the

multicasting-disabled router. In the example below (Figure 7), the server and client

are separated by three routers, of which the first and last are multicasting-enabled

[CIS02].



Router 1 Router 3











Server Router 2
(multicasting-d disabled) Client

Figure 7 Multicasting across a non-multicast router

Streaming

The concept of streaming has been directly responsible for the explosion of

high-quality audio and video on the Internet. Before streaming, Internet users were

required to download an entire media clip before playback would start. This made

the dissemination of live real-time video impossible; sampling large media clips was

likewise difficult, as most Internet users had only a very limited amount of bandwidth

at their disposal (usually a 28.8k modem or slower). With the advent of streaming,

users are now able to begin viewing a multimedia presentation as soon as the first few

blocks of data for the transmission arrive. Not only is this more convenient for users









on low-bandwidth connections, it also opens up the realm of live multimedia

broadcasts over the Internet.

When streaming multimedia, the compression format employed may be either

stateless or stateful. Stateless implies that any packet of received information can be

used, regardless of whether any other packets have been received, have been

corrupted, or have been received out-of-order. A stateful connection, on the other

hand, requires the correct delivery of certain previous packets for later packets to be

useful. The benefit of a stateful connection is that once a certain state has been

established, subsequent packets will not require as much information.

The Real-Time Streaming Protocol (RTSP) is an open standard for streaming data.

The difference between streaming via standard HTTP and RTSP is as follows:

RTSP streaming may be defined as the transfer of multimedia over a network
while it is playing, as opposed to downloading the data and storing it locally
before playing it. With HTTP streaming, the movie data is sent to you as fast
as your network connection can handle it. Once enough data has been
received, the movie will begin to play. With RTSP streaming, only the movie
data is sent as you need it, so the data rate of your stream has to be smaller
than the network's current speed. [APP02]

Surprisingly, all the major media players have adopted this open standard, and play

multimedia transmitted via RTSP as well as their own proprietary formats.

Current Streaming Technology

Currently, there are a few solutions for multicasting audio and video, but none have

good support for mobile clients. Here, I will examine a few of the more popular

multicasting solutions, and later discuss why they fall short when applied to the

wireless environment.









With over 21 million users per month as of April 21, 2000 and a whopping

115 million unique registered users, RealPlayer is arguably the most widespread

media player application in use today. The current G2 version supports numerous

features attractive to mobile users, such as the ability to dynamically reduce and

increase the quality of the broadcast based on changing network conditions. As

network conditions worsen, RealPlayer employs various other tricks to maintain the

perception of the original video quality. To achieve a certain target frame rate, the

RealPlayer client may create tween frames, which are frames interpolated by the

client from received neighboring frames to increase the frame rate and overall

smoothness of the video clip. Creating tween frames, however, currently requires

copious amounts of processing power, and is therefore not done as consistently as we

would like.

The Windows Media Player, while not nearly as old or as ubiquitous as

RealPlayer, is still rather widely used, with approximately 8.6 million monthly users

as of April 2000. In side-by-side evaluations with RealPlayer at a transmission rate

of 80kbit/sec, frame rates have been shown to be higher, at the cost of frame

resolution and color accuracy.

Apple, being the newest streaming media player, has had a surprising 7.5

million monthly users of its QuickTime player as of April 2000. This is most likely

due to the availability of the Star Wars Episode I: The Phantom Menace trailers

exclusively in the QuickTime format. After performing side-by-side comparisons of

the frame rate of a presentation at a certain bandwidth, it becomes clear that the

Quicktime player, in its current version, does not perform as well as expected,









especially when compared to the Microsoft Windows Media Player (ironically also

available for the Macintosh MacOS) and the RealPlayer G2. This may be due to the

different codecs employed by the various players.

The currently proposed solutions are also mainly based on the current

multicasting technology. The new IPv6 protocol [CRA98] proposes to change

numerous core elements of the current IPv4 networking. While the main goal driving

the creation of IPv6 was to expand the usable number of IP addresses to 128 bits, the

designers also decided to remove broadcasting, as it had proven to be difficult to

implement without excessive wasted bandwidth. "There are no broadcast addresses

in IPv6, their function being superseded by multicast addresses" [HIN98, pg 2]. IPv6

also offers a built-in (and therefore more finely grained) quality of service control,

allowing the system administrator to easily and precisely prioritize bandwidth

availability.















CHAPTER 4
MULTIMEDIA DELIVERY IN THE MOBILE ENVIRONMENT

Supporting Multicast of Video in Wireless LANs

The multicasting protocol works surprisingly well given the fact that the

Internet was designed for and now almost exclusively carries unicast transmissions.

However, once we move to a mobile environment, many fundamental assumptions

must be changed: bandwidth may diminish or temporarily become completely

unavailable as the client moves away from the base unit. Sensitivity towards power

usage is also imperative as mobile computers have a very limited power source.

The base model for these experiments is the following:


Clerl A


PFnt


Cl ant C


ClBnt E


Cent B


-j Accs
Pokil


/oulers

',


ISe
Server


ClBnt D


Clent F


Figure 8 Standard configuration


I








Here in Figure 8, the server transmits one stream to the first router, which

splits the stream based on the location of listening clients. In this case, this router

duplicates the one stream from the server into only two streams, and sends them to

the respective access points on their respective local networks. The routers

communicate amongst themselves via one of the numerous multicast routing

protocols [BAL97, EST98, MOY94a, MOY94b, THA99, WAI88] to decide whether

a router requires a copy of the stream.

Proposed Protocol

The Wireless Multi-Media Delivery Protocol (WMMDP) proposed here is

designed to sit on top of the multicasting protocol:


WMMDP

Ad Hoc Infrastructure

Multicasting Protocol


Internet


Figure 9 Wireless Multi-Media Delivery Protocol

The extension protocol I propose uses both the Ad Hoc and Infrastructure

transmission modes to interface with the standard multicasting protocol, which allows

for efficient broadcast of data over the internet.

This proposal involves only the last hop of a standard multicast. The server

begins sending data regardless of any client initiation. It is the responsibility of the

first router to discard all packets if no clients are listening.









The first client of a subnet to request a certain broadcast will negotiate with its

router via IGMP the fact that it wishes to receive this broadcast. The routers then

handle getting a stream of the multimedia to the router closest to the client via PIM or

any other multicast routing protocol.

The client for this Wireless Multimedia Delivery Protocol (WMDP) listens on

port 3845 for the multicast stream. Once the data arrives, it streams the data to a

temporary file used to buffer the data, and also to keep older packets for other clients

who may request previously used packets. Each client will also listen on port 4845

for communication from other clients. This inter-client communication will consist

mainly of requests for missed packets. Each packet will have embedded within itself

the packet number (by the protocol, as UDP does not ensure in-order packet delivery)

and the source address (by the network stack).

When a client Cl notices that it has missed receiving a packet P1 within a

small timeout, it sends a request for retransmission of this packet P1 to any nearby

client C2. The different responses C2 provides are discussed below:


Standard Mode

In Standard Mode (SM), C2 simply sends Cl the packet via a standard ad hoc

UDP connection. This is the straightforward approach.










Multicast Mode

In the Multicast Mode (MM), a nearby client, C2, which has received P1, will

begin rebroadcasting the stream to Cl via ad hoc mode by sending the packets to the

special ad hoc multicast address.

The simulation will show the affect of the three rebroadcast situations on

stream availability:

1. No rebroadcasting. The clients will need to stay relatively close to the base

station-within 300ft in an office setting, and within 2000ft outdoors. We

will use 500ft as an average range.

2. Simple direct rebroadcasting. Here, the range is extended beyond the base

station, but excessive network utilization will saturate the 2Mbit/sec

bandwidth available.

3. Multicast rebroadcasting. Clients rebroadcast to the multicast address rather

than to the specific client in need. We will examine optimizations to cut down

the number of clients rebroadcasting within a certain range.

An arbitrary assignment of five states will be made to aid in differentiating between

the different situations that may occur in the course of client mobility. Each client

can be in only one of five states:

0. Standard state; client listening to a stream

1. Our client receives a request for help, and we will help

2. We need a rebroadcast, but have not received a helper

3. We need a rebroadcast, and have received a helper

4. We are receiving help, and another client needs our help






Each client itself listens on three channels:
Channel A: Listens via infrastructure mode to the broadcast
Channel B: Listens via ad hoc mode to the broadcast
Channel C: Listens via ad hoc mode to the control channel
Channel C is used to send and receive help requests from and to clients.
Figure 10 shows the clients possible states. The arrows between states
indicate the only possible state changes a client may perform.
State 0: {
Remain in 0: Client continues listening to the broadcast
Go to 1: Client receives request for help, and helps
Go to 2: We wander out of range, and require help
}


C


C


1-----'(Z


Figure 10 WWMDP State Diagram









State 1: {

Remain in 1: Some clients) still require assistance; will continue helping

Return to 0: Either helped client sends "no longer needed," or does not respond to
acknowlegement

Go to 2: We have gone out of range. Any clients using our services also suffer.

}

State 2: {

Remain in 2: We still need help, and have not received any

Go to 3: We have received help from someone

Go to 0: We have wandered back into the range of the infrastructure broadcast

}

State 3: {

Remain in 3: We continue requiring rebroadcasts from another helping client

Go to 0: Back in range of the base station, we can now once again use infrastructure

Go to 4: Another client needs help from us; we oblige

}

State 4: {

Remain in 4: We continue to need help, and also continue to rebroadcast for others

Go to 1: We reenter the infrastructure range, but continue helping others

Go to 3: If client we are helping sends "no longer needed" or doesn't respond











Interesting Issues

Several interesting issues may arise due to the mobile nature of the clients.

Here, I examine a few of the more common possibilities/occurrences, such as hop

count optimization, isthmus effect optimization, and the effect of lazy

acknowledgement.

If we track the number of hops each client is from the infrastructure area, we

may use this to make wise decisions during rebroadcast negotiations where multiple

clients are available. If a client has a choice to receive a rebroadcast from either a

distant (high hip count) or close (low hop count) client, it should choose the closer, as

not only will it have a lower latency stream, but also may indicate that it is less

mobile and therefore more likely to continue receiving the stream.

The isthmus effect is a routing dilemma where, to reach a certain client B

from a machine A, packets must be routed in a physically opposite direction. This

dilemma in the wired environment is reduced to an optimization problem here. While

we do not concern ourselves with the underlying ad hoc routing protocol, we do want

to be confident in our decisions on whom to ask to continue rebroadcasting.

Lazy acknowledgement becomes extremely useful when we attempt to prune

the amount of clients rebroadcasting the stream. We ask for each client who is

listening to our rebroadcast to send us an acknowledgement every 30 seconds. If two

consecutive acknowledgements are missed, we prune that specific client from the list

of clients listening to our rebroadcast. When the number reaches zero, we know that

we may stop rebroadcasting; however, if a mobile client moves into our area and uses






24


our rebroadcast stream without our knowledge, that client must initiate

communication with us and negotiate rebroadcasting.















CHAPTER 5
SIMULATION AND EXPERIMENTAL EVALUATION

As mentioned in the final paragraphs of Chapter 5, the custom extension to the

multicasting protocol proposed would take into account the rapidly fluctuating

bandwidth available to the mobile client based on the distance from the base station.

This is done by rebroadcasting packets from clients receiving the stream to clients

wishing to receive the stream yet tragically out of range of the base station. The three

major cases considered were: 1) no rebroadcasting, 2) simple direct rebroadcasting,

and 3) multicast rebroadcasting. Also, how many nodes must be present in a given

area to provide coverage to all nodes?

Before performing any experiments, the following hypothetical outcome

seems most likely: In an area with a sparse number of clients, the danger of flooding

the local area with duplicate packets is minimal. If many clients converge to one

physical area, the resulting duplication will flood the wireless network and become

counterproductive.

For the following simulations, we assume a clear 800 feet by 600 feet area

with a base station at position 400, 300. Both the base station and the individual

nodes use a wireless card with a range of 150 feet, whose signal strength falls off

logarithmically at the edge of their range.










Based on the general principles of cell bandwidth availability and range, here

is a theoretical graph of the percentage of packets received versus the distance from

the base station:


Distance vs. Packet Loss







4)




a--




Distance (feet) 900 1000

Figure 11 Distance vs. Packet Loss graph


The standard case (blue), with no rebroadcasting, performs well up to the edge

of its range (500ft). The unicast rebroadcast mode (red) also performs well, but past

the range of the base station, many clients are requesting a rebroadcast, which floods

the cell with many duplicate packets. The multicast rebroadcast mode (yellow)

strongly reduces the amount of duplicate packets, as many clients can share one

multicast rebroadcast.

Network Simulation

I performed numerous simulations of the WMDP using the Berkley Network

Simulator version 2. These simulations were designed to differentiate the

performance of the three rebrodacasting options mentioned throughout this thesis: the









standard straightforward no-rebroadcasting configuration, the unicast-rebroadcasting

configuration, and the multicast-rebroadcast configuration.

After working around numerous incompatibilities between the multicasting

package and the wireless package by using suboptimal approximations, we see that

the hypothesis above was confirmed. However, since these approximations were

suboptimal, it seemed that writing a new network simulator from scratch would be

best. My network simulator simulates one base station in the middle of a field, and

adds the specified number of mobile clients which may or may not move in a random

direction. This simulation is run for 60 seconds, after which it shows the average

percentage of the grid coverage and the average percentage of nodes that received the

stream. For example, if all nodes were in range of the base station, then the grid

coverage would be 12% and the nodes-received percentage would be 100%.

Each 60-second simulation was run 50 times, and then the percentages were

averaged. The results are shown below, numerically in Figure 12, and graphically in

Figure 13.












Number of
Nodes
2
4
8
12
16
24


Grid
Percentage
12
12.66
15.96
24.88
40.92
65


Node
Percentage
9.12
15.36
22.26
31.14
48.12
67.16


Figure 12 Simulation results





Number of Nodes vs. Coverage


% Covered


F Node Percentage
Grid Percentage


Number of Nodes 24


SGrid Percentage 0 Node Percentage


Figure 13 Number of Nodes vs. Coverage















CHAPTER 6
CONCLUSION

In conclusion, multicasting promises to drastically reduce the amount of

bandwidth required by a server to satisfy a large number of clients requesting a

broadcast of multimedia. However, multicasting by itself does not adequately

address availability issues, as mobile users may roam away from the base transmitting

station. The proposed extension to the multicasting protocol restores a large amount

of mobility previously lost to the range of the base transmitting station, and extends

this range based on the number of listening clients within close proximity.















BIBLIOGRAPHY


APP02 Apple Computer, "QuickTime Streaming" July 2002,
http://www.apple.com/quicktime/authoring/hinttrack.html Verified: January, 2002.

ARM92 Armstrong, S., Freier, A., and Marzullo, K., "RFC 1301: Multicast
Transport Protocol" February 1992, http://www.ietf.org/rfc/rfcl301.txt Verified:
November 8, 2002.

BAG99 Bagnall, P., Briscoe, R., and Poppitt, A., "RFC 2729: Taxonomy of
Communication Requirements for Large-scale Multicast Applications" December
1999, http://www.ietf.org/rfc/rfc2729.txt Verified: November 8, 2002.

BAL97 Ballardie, A., "RFC 2201: Core Based Trees (CBT) Multicast Routing
Architecture" September 1997, http://www.ietf.org/rfc/rfc2201.txt Verified:
November 8, 2002.

CIS02 "Cisco IP Multicast Groups External Homepage"
ftp://ftpeng.cisco.com/ipmulticast/index.html Verified: November 8, 2002.

CRA98 Crawford, M., "Transmission of Ipv6 Packets over Ethernet Networks"
December 1998, http://www.ietf.org/rfc/rfc2464.txt Verified: November 8, 2002.

DEE89 Deering, S., "RFC 1112: Host Extensions for IP Multicasting" August 1989,
http://www.ietf.org/rfc/rfcl 112.txt Verified: November 8, 2002.

DEE99 Deering, S., Fenner, W., and Haberman, B., "RFC 2710: Multicast Listener
Discovery (MLD) for IPv6" October 1999, http://www.ietf.org/rfc/rfc2710.txt
Verified: November 8, 2002.

DUB98 Dubray, K., "RFC 2432: Terminology for IP Multicast Benchmarking"
October 1998, http://www.ietf.org/rfc/rfc2432.txt Verified: November 8, 2002.

EST98 Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M.,
Jacobson, V., Liu, C., Sharma., P., Wei, L., "RFC 2362: Protocol Independent
Multicast- Sparse Mode (PIM-SM): Protocol Specification" June 1998,
http://www.ietf.org/rfc/rfc2362.txt Verified: November 8, 2002.

FEN97 Fenner, W., "RFC 2236: Internet Group Management Protocol, Version 2"
November 1997, http://www.ietf.org/rfc/rfc2236.txt Verified: November 8, 2002.









HAN99a Handley, M., Schulzrinne, H., Schooler, E., Rosenberg, J., "RFC 2543:
SIP: Session Initiation Protocol" March 1999, http://www.ietf.org/rfc/rfc2543.txt
Verified: November 8, 2002.

HAN99b Hanna, S., Patel, B., and Shah, M., "RFC 2730: Multicast Address
Dynamic Client Allocation Protocol (MADCAP)" December 1999,
http://www.ietf.org/rfc/rfc2730.txt Verified: November 8, 2002.

HIN98 Hinden, R., and Deering, S., "RFC 2373: IP Version 6 Addressing
Architecture" July 1998, http://www.ietf.org/rfc/rfc2373.txt Verified: November 8,
2002.

MEY98 Meyer, D., "RFC 2365: Administratively Scoped IP Multicast" July 1998,
http://www.ietf.org/rfc/rfc2365.txt Verified: November 8, 2002.

MOY94a Moy, J., "RFC 1584: Multicast Extensions to OSPF" March 1994,
http://www.ietf.org/rfc/rfc1584.txt Verified: November 8, 2002.

MOY94b Moy, J., "RFC 1585: MOSPF: Analysis and Experience" March 1994,
http://www.ietf.org/rfc/rfcl585.txt Verified: November 8, 2002.

POS80a Postel, J., "DOD Standard Transmission Control Protocol" January 1980,
http://www.ietf.org/rfc/rfc761.txt Verified: November 8, 2002.

POS80b Postel, J., "User Datagram Protocol" August 1980,
http://www.ietf.org/rfc/rfc768.txt Verified: November 8, 2002.

PUL99 Pullen, M., Myjak, M., and Bouwens, C., "RFC 2502: Limitations of Internet
Protocol Suite for Distributed Simulation in the Large Multicast Environment"
February 1999, http://www.ietf.org/rfc/rfc2502.txt Verified: November 8, 2002.

STE94 Stevens, W. Richard, TCP/IP Illustrated, Volume I Copyright 1994 by
Addison-Wesley, Reading, MA.

THA99 Thaler, D., "RFC 2715: Interoperability Rules for Multicast Routing
Protocols" October 1999, http://www.ietf.org/rfc/rfc2715.txt Verified: November 8,
2002.

WAI88 Waitzman, D., Partridge, C., and Deering, S., "RFC 1075: Distance Vector
Multicast Routing Protocol" November 1988, http://www.ietf.org/rfc/rfc 1075.txt
Verified: November 8, 2002.




















APPENDIX
NETWORK SIMULATION SCRIPT



# Copyright (c) 1996 Regents of the University of California.
# All rights reserved.

# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
# notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the distribution.
# 3. All advertising materials mentioning features or use of this software
# must display the following acknowledgement:
# This product includes software developed by the MASH Research
# Group at the University of California Berkeley.
# 4. Neither the name of the University nor of the Research Group may be
# used to endorse or promote products derived from this software without
# specific prior written permission.

# THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS "AS IS'' AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.

# @(#) $Header: /usr/src/mash/repository/vint/ns-2/tcl/ex/mcast.tcl,v 1.12
1999/09/10 22:08:41 haoboy Exp $
# updated to use -multicast on and allocaddr by Lloyd Wood


# Simple multicast test. It's easiest to verify the
# output with the animator.
# We create a four node start; start a CBR traffic generator in the center
# and then at node 3 and exercise the join/leave code.

# See tcl/ex/newmcast/mcast*.tcl for more mcast example scripts

# - - - - - - - - - - - - - - - - - -
# Define options
# - - - - - - - - - - - - - - - - - -
set opt(chan) Channel/WirelessChannel ;# channel type
set opt(prop) Propagation/TwoRayGround ;# radio-propagation
model
set opt(netif) Phy/WirelessPhy ;# network interface type
set opt(mac) Mac/802 11 ;# MAC type












opt (ifq)
opt (11)
opt (ant)
opt(ifqlen)
opt (nn)
opt(adhocRouting)


set opt(cp)
file
set opt(sc)


Queue/DropTail/PriQueue
LL
Antenna/OmniAntenna
50
15
DSDV


;# interface queue type
;# link layer type
;# antenna model
;# max packet in ifq
;# number of mobilenodes
;# routing protocol

;# connection pattern


scene ;# node movement file.


set opt(x) 2000
set opt(y) 2000
set opt(seed) 0.0
gen.
set opt(stop) 500

set opt(ftpl-start)
set opt(ftp2-start)
set opt(udp-start)

set num wired nodes
set num bs nodes


;# x coordinate of topology
;# y coordinate of topology
;# seed for random number

;# time to stop simulation


160.0
170.0
0

2
1


# check for boundary parameters and random seed
if { $opt(x) == 0 I $opt(y) == 0 1 {
puts "No X-Y boundary values given for wireless topology\n"
}
if {$opt(seed) > 01 {
puts "Seeding Random number generator with $opt(seed)\n"
ns-random $opt(seed)
}


set ns [new Simulator -multicast on]

$ns node-config -addressType hierarchical
AddrParams set domain num 2 ;# number of domains
lappend cluster num 2 1 ;# number of clusters in each domain
AddrParams set cluster num $cluster num
lappend eilastlevel 1 1 [expr $opt(nn) + 1] ;# number of nodes in each
cluster
AddrParams set nodes num $eilastlevel ;# of each domain

set tracefd [open out.tr w]
set namtrace [open out.nam w]
$ns trace-all $tracefd
$ns namtrace-all-wireless $namtrace $opt(x) $opt(y)

# Create topography object
set topo [new Topography]

# define topology
$topo load flatgrid $opt(x) $opt(y)

# create God
create-god $opt(nn)
set god [God instance]

#create wired nodes
set temp {0.0.0 0.1.0} ;# hierarchical addresses for wired domain


"" YY











for {set i 0} {$i < $num wired nodes} {incr i} {
set W($i) [$ns node [lindex $temp $i]]
}

# configure for base-station node


$ns node-config -adhocRouting $opt(adhocRouting)
-1lType $opt(ll) \
-macType $opt(mac) \
-ifqType $opt(ifq) \
-ifqLen $opt(ifqlen) \
-antType $opt(ant) \
-propType $opt(prop) \
-phyType $opt(netif) \
-channelType $opt(chan) \
-topolnstance $topo \
-wiredRouting ON \
-agentTrace ON \
-routerTrace OFF \
-macTrace OFF

$ns color 1 red
# prune/graft packets
$ns color 30 purple
$ns color 31 bisque

set temp {1.0.0 1.0.1 1.0.2 1.0.3 1.0.4 1.0.5 1.0.6 1.0.7 1.0.8 1.0.9 1.0.10
1.0.11 1.0.12 1.0.13 1.0.14 1.0.15 1.0.16 1.0.17 1.0.18 1.0.19 1.0.20}
;# hier address to be used for wireless
;# domain
set BS(0) [$ns node [lindex $temp 0]]
$BS(0) random-motion 0 ;# disable random motion


#provide some co-ord (fixed) to base station node
$BS(0) set X 1.0
$BS(0) set Y 2.0
$BS(0) set Z 0.0

#configure for mobilenodes
$ns node-config -wiredRouting OFF

for {set j 0} {$j < $opt(nn)} {incr j} {
set node ($j) [ $ns node [lindex $temp \
[expr $j+l]] ]
$node ($j) base-station [AddrParams set-hieraddr \
[$BS(0) node-addr]]

ns duplexlink W() W(1) 5 2ms DropTail

$ns duplex-link $W(1) $BS() 5Mb 2ms DropTail
$ns duplex-linkop $W() $BSW(1) orient5Mb 2ms DropTail
$ns duplex-link-op $W(1) $BSW() orient ledowndown
$ns duplex-link-op $W(1) $BS(0) orient left-down

set mproto DM
set mrthandle [$ns mrtproto $mproto {}]
set group [Node allocaddr]

set udp0 [new Agent/UDP]
$ns attach-agent $node (1) $udp0
$udp0 set dst addr group0
$udp0 set dst port 0











set cbr0 [new Application/Traffic/CBR]
$cbr0 attach-agent $udp0


set rcvr [new Agent/LossMonitor]

for {set j 0} {$j < $opt(nn)} {incr j} {
$ns attach-agent $node ($j) $rcvr
$ns at 1.2 "$node ($j) join-group $rcvr groupp"
}

$ns at 1.0 "$cbr0 start"

$ns at $opt(stop).0002 "puts \"NS EXITING...\" ; $ns halt"
$ns at $opt(stop).0001 "finish"

proc finish {} {
global ns
$ns flush-trace

puts "running nam..."
exec nam out.nam &
exit 0
}


$ns run















BIOGRAPHICAL SKETCH

Peter Handel was born in 1976 to two professors in St. Louis, MO, where he

started using computers at the age of five. He received his bachelor's degree in

physics from St. Olaf College, and is currently finishing a master's degree in

computer science at the University of Florida Gainesville. He accepted a position as

Senior Engineer on the MacOS X project at Apple Computer, Inc., in the summer of

2000.