Presentation is loading. Please wait.

Presentation is loading. Please wait.

Analysis and Design of a VoIP Application over 802.15.4 platform for Rural Deployment Bhavish Aggarwal 04005018 Guide: Prof. Bhaskaran Raman Bhavish Aggarwal.

Similar presentations


Presentation on theme: "Analysis and Design of a VoIP Application over 802.15.4 platform for Rural Deployment Bhavish Aggarwal 04005018 Guide: Prof. Bhaskaran Raman Bhavish Aggarwal."— Presentation transcript:

1 Analysis and Design of a VoIP Application over 802.15.4 platform for Rural Deployment Bhavish Aggarwal 04005018 Guide: Prof. Bhaskaran Raman Bhavish Aggarwal 04005018 Guide: Prof. Bhaskaran Raman

2 Rural Indian Context  70% of Indians live in 6,00,000 villages.  Most are illiterate and extremely poor.  But need for communication technologies remains high!  70% of Indians live in 6,00,000 villages.  Most are illiterate and extremely poor.  But need for communication technologies remains high!

3 Existing Technologies  Cellular  High cost of handsets and value-added services for average rural consumer.  High infrastructural cost and low returns per user for companies keeps it from deployment in certain areas.  WiMax  Potential yet to be proven.  Again, costly.  VoIP over WiFi  Active research area.  Cheaper hardware and infrastructure and use of industrial standards can reduce cost to consumer.  Cellular  High cost of handsets and value-added services for average rural consumer.  High infrastructural cost and low returns per user for companies keeps it from deployment in certain areas.  WiMax  Potential yet to be proven.  Again, costly.  VoIP over WiFi  Active research area.  Cheaper hardware and infrastructure and use of industrial standards can reduce cost to consumer.

4 Introduction to 802.15.4  IEEE standard aimed at low-power, low- rate communication between resource constrained devices.  Specifies PHY and MAC layer.  Specified data rate is 250 kbits/sec.  IEEE standard aimed at low-power, low- rate communication between resource constrained devices.  Specifies PHY and MAC layer.  Specified data rate is 250 kbits/sec.

5 Advantages of 802.15.4 radio  Low operational power  Typical consumption of 50 mW with radio and MCU on.  Lowers operational cost and maintenance.  Cheap hardware  802.15.4 radio costs only $5.  The tmote platform with the radio costs $70. This can be reduced by customizing and optimizing the platform for our context.  Low operational power  Typical consumption of 50 mW with radio and MCU on.  Lowers operational cost and maintenance.  Cheap hardware  802.15.4 radio costs only $5.  The tmote platform with the radio costs $70. This can be reduced by customizing and optimizing the platform for our context.

6 Power Usage of 802.15.4 radio  Power consumed with mote radio on = 20 mW  Power consumed in phone call over 3 hops = (number of motes)*20mW = 6*20mW = 120mW With normal AA batteries with 2.5 Ah rating, system would support 750 minutes of calling.  Power consumed with mote radio on = 20 mW  Power consumed in phone call over 3 hops = (number of motes)*20mW = 6*20mW = 120mW With normal AA batteries with 2.5 Ah rating, system would support 750 minutes of calling.

7 Problem and Challenges  Problem statement To study the feasibility of voice transfer over a mesh of tmote sky motes and design the voice transfer application around specific platform constraints.  Challenges  High throughput across multi-hop connections  Low latency across multi-hop connections  Low power consumption  Platform limitations: tmote sky constraints  Problem statement To study the feasibility of voice transfer over a mesh of tmote sky motes and design the voice transfer application around specific platform constraints.  Challenges  High throughput across multi-hop connections  Low latency across multi-hop connections  Low power consumption  Platform limitations: tmote sky constraints

8 Assumptions and Approach  Number of simultaneous calls are less.  System design aimed at maximizing call quality; not to support higher number of calls.  Justified in a village context.  Approach  Dual-radio approach.  Transmit and receive simultaneously.  Improve overall throughput and lower latency  Number of simultaneous calls are less.  System design aimed at maximizing call quality; not to support higher number of calls.  Justified in a village context.  Approach  Dual-radio approach.  Transmit and receive simultaneously.  Improve overall throughput and lower latency

9 Contributions  Analysis of suitability of tmote platform for voice transfer based on latency requirements.  Identification of latency bottlenecks in the proposed tmote sky network.  Interconnection of two tmotes to make a dual- radio device over UART expansion connector with simple transfer mechanism and analysis of time taken for packet transfer.  Analysis of suitability of tmote platform for voice transfer based on latency requirements.  Identification of latency bottlenecks in the proposed tmote sky network.  Interconnection of two tmotes to make a dual- radio device over UART expansion connector with simple transfer mechanism and analysis of time taken for packet transfer.

10 Previous Work  Much research in VoIP over WiFi mesh.  Citymesh - covering entire city of Brussels.  Studies on improving VoIP capacity and call admissions.  Orthogonal to our assumption!  Much research in VoIP over WiFi mesh.  Citymesh - covering entire city of Brussels.  Studies on improving VoIP capacity and call admissions.  Orthogonal to our assumption!

11 Previous Work  Studies in using multi-radio nodes to increase throughput of VoIP over 802.11 mesh.  Show good improvement in call quality and capacity of network.  We want to apply same logic over 802.15.4 mesh.  Some work on VoIP over 802.15.4 done; but with single radio nodes.  Studies in using multi-radio nodes to increase throughput of VoIP over 802.11 mesh.  Show good improvement in call quality and capacity of network.  We want to apply same logic over 802.15.4 mesh.  Some work on VoIP over 802.15.4 done; but with single radio nodes.

12 Parameters of Voice Codecs  Sampling Rate: Rate at which audio input is sampled. Generally 8kHz.  Bandwidth: amount of data per sec generated by algorithm.  Payload width: Amount of time for which data is encoded in a packet.  Payload Size: Size of payload of each packet generated by codec.  Sampling Rate: Rate at which audio input is sampled. Generally 8kHz.  Bandwidth: amount of data per sec generated by algorithm.  Payload width: Amount of time for which data is encoded in a packet.  Payload Size: Size of payload of each packet generated by codec.

13 Codec requirements For our constrained bandwidth, power and CPU platform, we need:  Low bandwidth usage.  Low sampling rate.  Higher frame/payload width  Quality of the voice codec is not a very big factor. For our constrained bandwidth, power and CPU platform, we need:  Low bandwidth usage.  Low sampling rate.  Higher frame/payload width  Quality of the voice codec is not a very big factor.

14 Comparison of Voice Codecs GSM is suitable because of it’s low bandwidth requirement, low sampling rate and higher payload width.

15 Analysis of voice transfer The steps in analyzing latency of voice transfer are:  Time required to send a packet.  Single hop direct transmission from sender to receiver.  Intermediary bridge node where bridge node is a single tmote.  Intermediary bridge node where bridge node is a dual- radio device formed by coupling 2 tmotes. The steps in analyzing latency of voice transfer are:  Time required to send a packet.  Single hop direct transmission from sender to receiver.  Intermediary bridge node where bridge node is a single tmote.  Intermediary bridge node where bridge node is a dual- radio device formed by coupling 2 tmotes.

16 Time to Send Packet - 1  Objective to match BriMon results for sending packets.  Time interval between “Send” command at application layer and “sendDone” event being signaled.  Initial and random backoffs of 802.15.4 protocol disabled.  Objective to match BriMon results for sending packets.  Time interval between “Send” command at application layer and “sendDone” event being signaled.  Initial and random backoffs of 802.15.4 protocol disabled.

17 Time to Send Packet - 2 Last row indicates time required to send a GSM payload.

18 Time required with direct transmission  Time delay at each step should be < 20 ms  Time to send packet from starting node: 3.62 ms  Time to receive packet at end mote: 4.19 ms Each step has less than 20 ms delay. Hence, latency requirements of GSM are satisfied.  Time delay at each step should be < 20 ms  Time to send packet from starting node: 3.62 ms  Time to receive packet at end mote: 4.19 ms Each step has less than 20 ms delay. Hence, latency requirements of GSM are satisfied.

19 Time required with one bridge node - single tmote intermediary  Time delay at each step should be < 20 ms  Time to send packet from starting node: 3.62 ms  At bridge node:  Receive packet: 4.19 ms  Send packet: 3.62 ms  Total time: 7.81 ms  Time to receive packet at end mote: 4.19 ms Each step has less than 20 ms delay. Hence, latency requirements of GSM are satisfied.  Time delay at each step should be < 20 ms  Time to send packet from starting node: 3.62 ms  At bridge node:  Receive packet: 4.19 ms  Send packet: 3.62 ms  Total time: 7.81 ms  Time to receive packet at end mote: 4.19 ms Each step has less than 20 ms delay. Hence, latency requirements of GSM are satisfied.

20 Time required with one bridge node - dual-radio intermediary  Data rate of 250 kbit/s just enough for VoIP codecs. Techniques to improve throughput across multi-hops needed.  Interfaces on independent channels allows simultaneous transmission and reception  16 channels - minimize interference in both adjacent and non-adjacent links.  Unlike WiFi, no overflow was detected even when 2 adjacent channels were used simultaneously.  Data rate of 250 kbit/s just enough for VoIP codecs. Techniques to improve throughput across multi-hops needed.  Interfaces on independent channels allows simultaneous transmission and reception  16 channels - minimize interference in both adjacent and non-adjacent links.  Unlike WiFi, no overflow was detected even when 2 adjacent channels were used simultaneously.

21 Single Radio Node

22 Dual Radio Node

23 Steps in development  Connecting two tmotes over expansion connector.  Create interrupt driven communication link.  Data encapsulation within AM packets over wired link.  Protocol to access shared bus between radio and UART reliably.  Connecting two tmotes over expansion connector.  Create interrupt driven communication link.  Data encapsulation within AM packets over wired link.  Protocol to access shared bus between radio and UART reliably.

24 Hardware connection  Each mote has two expansion connectors.  UART and I2C interfaces available.  UART is simpler and has less overhead of ACKs.  Tinyos api doesn’t implement UART as interrupt based. We need signaling and interrupt mechanism.  2 more pins used in addition to UART pins.  Each mote has two expansion connectors.  UART and I2C interfaces available.  UART is simpler and has less overhead of ACKs.  Tinyos api doesn’t implement UART as interrupt based. We need signaling and interrupt mechanism.  2 more pins used in addition to UART pins.

25

26 Protocol for Packetized Transfer  RTS/CTS used to signal interrupt and acceptance.  Sender sends the number of bytes the receiver should look out for.  Data transferred.  RTS/CTS used to signal interrupt and acceptance.  Sender sends the number of bytes the receiver should look out for.  Data transferred.

27 Latency analysis of UART connection  The API allows only sending data byte-by-byte.  After sending a byte, the TxBufferEmpty flag is set.  When this flag is set, send next byte.  The time taken for flag to be set is 1.2 ms per byte which is 55 ms per GSM packet.  Unsuitable for GSM codec.  The API allows only sending data byte-by-byte.  After sending a byte, the TxBufferEmpty flag is set.  When this flag is set, send next byte.  The time taken for flag to be set is 1.2 ms per byte which is 55 ms per GSM packet.  Unsuitable for GSM codec.

28 Issues present  The bus between UART and radio is shared.  Only one transfer at a time.  Full benefit of two independent radios not achieved.  The time taken for packet transfer between the motes is slower than the requirement of the GSM codec.  The bus between UART and radio is shared.  Only one transfer at a time.  Full benefit of two independent radios not achieved.  The time taken for packet transfer between the motes is slower than the requirement of the GSM codec.

29 Present Status  The bottleneck in the setup has been identified.  The mechanism to make a dual-radio node is developed without time optimization.  The bottleneck in the setup has been identified.  The mechanism to make a dual-radio node is developed without time optimization.

30 Future Work  Work out a mechanism to transfer data over UART between 2 motes within time constraints.  Deploy VoIP over this network.  Run the GSM codec over tmotes instead of PCs.  Routing calls through the network using low power duty cycling mechanisms.  Work out a mechanism to transfer data over UART between 2 motes within time constraints.  Deploy VoIP over this network.  Run the GSM codec over tmotes instead of PCs.  Routing calls through the network using low power duty cycling mechanisms.

31 References  “ BriMon: A Sensor Network System for Railway Bridge Monitoring ”, Kameswari Chebrolu, Bhaskaran Raman, Nilesh Mishra, Phani Kumar Valiveti, Raj Kumar, In ACM MobiSys 2008, June 2008, Breckenridge, CO (USA).  Rahul Mangharam, Anthony Rowe, Raj Rajkumar and Ryohei Suzuki, “ Voice over Sensor Networks ”, In Proceedings of the 27th IEEE International Real- Time Systems Symposium (RTSS'06).  Xudong Wang, Abhishek Patil and Weilin Wang, “ VoIP Over Wireless Mesh Networks: Challenges and Approaches ”, WICON 2006.  “ BriMon: A Sensor Network System for Railway Bridge Monitoring ”, Kameswari Chebrolu, Bhaskaran Raman, Nilesh Mishra, Phani Kumar Valiveti, Raj Kumar, In ACM MobiSys 2008, June 2008, Breckenridge, CO (USA).  Rahul Mangharam, Anthony Rowe, Raj Rajkumar and Ryohei Suzuki, “ Voice over Sensor Networks ”, In Proceedings of the 27th IEEE International Real- Time Systems Symposium (RTSS'06).  Xudong Wang, Abhishek Patil and Weilin Wang, “ VoIP Over Wireless Mesh Networks: Challenges and Approaches ”, WICON 2006.

32 References (contd.)  Dragos Niculescu, Samrat Ganguly, Kyungtae Kim and Rauf Izmailov, “ Performance of VoIP in a 802.11 Wireless Mesh Network ”, In Proceedings of IEEE INFOCOM 2006, Apr. 2006.  Hung-yu Wei, Kyungtae Kim, Anand Kashyap and Samrat Ganguly, “ On Admission of VoIP Calls Over Wireless Mesh Network ”, In Proc. of ICC Next Generation Mobile Networks, Istanbul, June 2006.  Samrat Ganguly et al, “ Performance Optimizations for Deploying VoIP Services in Mesh Networks ”, IEEE Journal on Selected Areas in Communications, Vol. 24, No. 11, November 2006.  Dragos Niculescu, Samrat Ganguly, Kyungtae Kim and Rauf Izmailov, “ Performance of VoIP in a 802.11 Wireless Mesh Network ”, In Proceedings of IEEE INFOCOM 2006, Apr. 2006.  Hung-yu Wei, Kyungtae Kim, Anand Kashyap and Samrat Ganguly, “ On Admission of VoIP Calls Over Wireless Mesh Network ”, In Proc. of ICC Next Generation Mobile Networks, Istanbul, June 2006.  Samrat Ganguly et al, “ Performance Optimizations for Deploying VoIP Services in Mesh Networks ”, IEEE Journal on Selected Areas in Communications, Vol. 24, No. 11, November 2006.

33 Thank You! Questions?? Thank You! Questions??


Download ppt "Analysis and Design of a VoIP Application over 802.15.4 platform for Rural Deployment Bhavish Aggarwal 04005018 Guide: Prof. Bhaskaran Raman Bhavish Aggarwal."

Similar presentations


Ads by Google