Working on my thesis I need to create a simulation for video transmission in a normal WLAN to detect how much the quality is reduced depending on the number of devices or quality of originating transmission.
I was using NS-3 for this when someone proposed to me to use my home devices (I have a number of computers, tablets, E-readers, video game consoles etc).
It seemed to me like a good idea since I have a fast enough WiFi I can just use my Mac as the hotspot and connect all devices through it then sniff the packets with wireshark and limit the speed of the transfer using "Network Link Conditioner" my question is, would limiting the speed of transfer with the network link conditioner affect the devices using my computer as a hotspot? or does it only affect my personal computer and I need to figure another way of limiting the speed to successfully simulate what I need?
I am not 100% sure what you are after, but seeing you mentioned limiting bandwidth on your Mac, this may be in use:
Basically, you'll need a PC that can run FreeBSD and two network interfaces (e.g. a built in NIC plus one other card). You then setup the box to bridge those two cards.
Check out this tutorial to see how Network Bandwidth Latency and Delay Simulation Tutorial
Once setup you can then control the parameters of that bridge using the ipfw command in FreeBSD, allowing you to change bit rates, latency and simulate packet loss.
With this box in between your video sources (the internet?) and with a wifi router on the other side to connect your devices to, you'd be able to simulate a variety of conditions.
[Note: credit for digging this out this link needs to go to a colleague of mine, but I used this on a project once he'd set it up and it was very powerful]
Related
To test bluetooth scalability, I want the same device (a Raspberry Pi or a laptop) to emit several BLE advertisements. So far, I have tried using bleno (NodeJS), hcitool and CoreBluetooth for OSX, but I can not setup more than one.
Is this a hardware/system/bluetooth limitation? Has somebody managed to do this?
Different bluetooth devices have different maximum advertising rates. These typically range from 10Hz to 40Hz. Some bluetooth devices have the ability to spoof their MAC address so different advertisements appear to come from different physical devices. This is often important for scalability testing, because some receivers keep track of unique devices by MAC address.
As #Emil says in his answer, it is possible to "interleave" advertisements such that you change the advertisement (and ideally the MAC address) every few hundred milliseconds so it appears by receiving devices that there are multiple advertisers around. I have done this with both Raspberry Pi and iOS transmitters, but in neither case could I alter the MAC address.
It is important to understand, though, that the actual number of packets received when you do this does not change. So while you may be testing scalability of unique advertisements detected, you will not be doing the same thing as testing with multiple physical advertisers.
That's not possible by the Bluetooth specification. However you can start off with one data then set a timer in your app that stops advertising. Then you start off again with the next data. And so on.
I'm a newbie software developer who develops SIP/RTP Voip software.
For sure, I am using UDP protocol and Video Codec for this video is H264.
Since I am new to this Voip area, I am so confused and suffering painful network issues a lot.
I would like to ask experts something related to Network specifically dealing with RTP/RTCP issues on Jitter / Packet loss.
After SIP successfully creates media session, I get some issue for QoS.
Problems I am facing up is just like this below.
Wifi network(latency : 11.1m/s download speed : 14.9mbps upload speed : 3.27mbps) :
http://www.youtube.com/watch?v=epm01c6IT5Q&feature=youtu.be
3G network(latency : 26.4M/s Download speed : 1.94Mbps upload speed : 2.42Mbps) :
http://www.youtube.com/watch?v=-iG156_wdQE&feature=youtu.be
as you see, through 3G that has low upload and download and unstable latency, video quality including video issue coloured green and video's delay is better than Wifi.
using 3G network slower than Wifi , I can always take better user experience than Wifi.
I didn't analyse RTP/RTCP packets deeply but the thing I can tell is ...
At the problem situation, when Wi-fi was used for the application, Jitter was strangely high enough and packet loss was obviously high as well.
To sum up,
As you can see, video quality is better when I use 3G network slower than Wifi.
When Wifi works there, Jitter and packet loss are obviously high as I can analyse packet using wire-shark on the receiver side.
at that morning time, video problem(green pixel of video, video delay) was much more serious but as time went, at the afternoon and night, problem had been recovered a bit.
As far as I know, it would be related to network bandwidth and network congestion.
I am not sure that it is proper diagnosis and also need to solution to this.
I'm sorry that I have not enough background information yet.
Thanks.
You area going to have to look at the RTCP or RTCP-XR messages to see what is going wrong. If that fails then like the other posts have said you will need to use wireshark to determine what the issue is.
There is most likely a network layer issue that is causing this so do what you can to test your connection to the other side. A traceroute might be a good place to start to see what the difference is between how the 3G routes vs the wifi.
Wifi can have many issues related to jitter and packet loss that your cell network might not depending on your signal strength (and other things). If you can test with a hard wire connection then you can rule out wifi as an issue and if you still have issues it has to be network/ISP related. If a hardwired connection resolves your issues then you know it was the wifi and you can troubleshoot accordingly.
The green is most likely an artifact of the jitter/packetloss. Normally in the US, for voice, a ptime of 20ms is used. Which means that audio packets (and video if used) are send every .02 seconds. If your jitter is higher than 20ms or you have high packetloss or burst packetloss then you will likely see and hear distortions because the packets either arrive out of order and are dropped or are lost. The green screen is just one of many you could see depending on the app you are using. I work mostly with audio so I am sorry I can't be more helpful with the exact meaning of that artifact.
I want to find a solution to broadcast voice over WiFi for the people in a march. Since Android and IPhone is the most popular devices among the people in the march, it would be great if i can find a solution for audio broadcast over wifi with limited budget.
I know that people in occupy movement use different app on their cell, but it is not suitable in a march in my city. As the authority in my country may temporarily shutdown the data over mobile network to disable the app.
If i can develop an app to gather the broadcast message (SSID) from a powerful wifi AP with a long-length directional antenna, I should able to deliver message among the people in the march. Is it a possible solution?
Also, is it possible to modify the AP to allow any device to join the AP without further acknowledgment and broadcast message to all devices in that network?
Any idea or opinion is welcome.
Many Thanks.
This will be difficult, especially with a large number of users. Since you only need to send audio in one direction, that will at least be a bit easier.
First, you're going to want to put that AP in the middle of the crowd with an omnidirectional antenna. Perhaps, in a backpack or something. Each phone on that network needs to "hear" when other phones are transmitting, or it will be a mess. Even though your application is one-way, 802.11 isn't.
Now, when you write your application, use UDP packets sent to the broadcast address. No need for TCP packets, as they will clog up your network anyway.
Use a simple voice codec, such as AMR. The codecs available vary from platform to platform. See this document for a list on Android: http://developer.android.com/guide/appendix/media-formats.html
Honestly, the easiest solution would be to go buy a small FM transmitter, since many phones have receivers in them anyway.
we want to route the call to ip network instead of GSM network. for that purpose first we are connecting our mobile phone to a PC through bluetooth. So we want to transfer the real time audio data to that PC over bluetooth. Could you please help..
If you can trick the mobile phone to function as a bluetooth headeset [profile] -- which I doubt any phones would support because phones are, well, the consumers of such headset devices -- then you could use it like any other "headset" device. (It would be much more feasible to just purchase a headset or plug in a microphone.)
As far as "where the real time audio data is stored?" -- well, that just won't go anywhere. The "data" (perhaps already in an encoded/delta form) is briefly (like milliseconds!) "stored" in a few small buffers / integrated circuits in the radio circuitry. This circuity will vary based upon phone/radio module used and is not accessible from a PC.
Happy doing productive things.
I have created a bandwidth meter application to measure total Internet traffic. I need to test the application with relatively high data transfer rates, such as 4 Mbps. I have a slow Internet connection, so I need a simulator to test my application to see the behavior with high throughput rates.
As an option, you can run some HTTP server in one virtual machine with NAT'ed network adapter and test your bandwidth meter against it from the host system or a similar VM.
There are commercial packet generators that do this, and also a few freely available ones like PackETH and Bit-Twist.
There are also other creative solutions. For example, do the packets need to be IP packets for your purpose? If not, you could always get a "dumb" switch or hub (no spanning-tree or other loop protection) and plug a crossover cable into it. (or a straight-through Ethernet cable would work if the switch supports Auto-MDIX) The idea would be that with a loop in your network, the hub/switch will flood the network to 100% for you since it will continually re-forward the same packets.
If you try this, be sure yours is the only computer on the network, since this technique will effectively render it useless. ;-)
You could always send some IP broadcast packets to "seed" the loop. Otherwise, the first thing I think you'd likely see is broadcast ARP packets, which won't help if you're measuring layer 3 traffic only.
Lastly, (and especially if this sounds like too much trouble) I recommend you read up on dependency injection and refactor your code so you can test it without the need for a high-speed interface. Of course, you'll still need to test your code in a real high-speed environment, but doing this will give you much more confidence in your code.