Category: Wireless VoIP

2 Day LTE Services Course at the University of Oxford

Oxford-logo
Great News: On April 20 and 21st, Ajit Jaokar of Open Gardens and I will host a 2 day course on LTE Services at the University of Oxford's Department of Continuing Education!

Here’s the agenda:

  • New services based on enhanced capacity of the network
  • IP based business models
  • Rich voice applications
  • New role of devices to handle rich content and social networks
  • Social networks based on rich content like video
  • Services unique to LTE and the core network
  • Greater role for user generated content and for rich media
  • Unified communications and beyond 3G networks
  • Fixed mobile integration – leveraging enhanced networks and learning from past mistakes
  • Integrated networks and connecting back to home networks
  • Network elements: Femtocells vs Wi-Fi in the home gateway and services based on these elements
  • Wireless sensor networks at home and their role and opportunity in an overall beyond 3G network

I am very happy to be part of this and it will be great to look at these topics from our two different angles. We've also put together a questionnaire to see what your angle is on this topic. If you have a minute and are interested, we'd be happy to get your feedback. We'll share the result with those who leave their e-mail address and of course with all course participants. Needless to say that all responses are treated confidentially.

So, if I have caught your interest, head over to the course's web site for the details. During this week, there’s also the yearly Forum Oxford Future Telecommunication Conference. More about that in an extra post once the details are sorted out.

Traffic Shaping the Way I Like It – And A SIP Surprise

Almost two years ago, I posted an article about how downlink traffic over my DSL line is severely impacted when at the same time I am sending a large amount of data in the uplink. This is due to the fact that acknowledgments are held up by other uplink data which slows down the traffic in downlink direction. I also mentioned then that some DSL routers are capable of prioritizing traffic such as TCP acknowledgments and VoIP packets to reduce this impact. Now two years later, I bought myself a Fritzbox DSL router and could finally put it to the test myself. Seeing is believing!

And indeed, the difference to a standard DSL router is quite amazing. The first picture below shows how the speed of an ongoing data download is severely reduced while I sent an e-mail with a large file attachment. Once the e-mail was sent, the speed returns again to what my DSL line is capable of, about 6 MBit/s. The same test with the Fritzbox shows quite a different behavior as shown in picture 2 below. While one can see a slight impact once the e-mail transfer starts, but the overall data rate remains pretty much the same as during times without the uplink being fully loaded (600 kbit/s).

Next on the test list was a VoIP call while both uplink and downlink were fully used. To my surprise both the standard DSL router I have and the Fritzbox managed to handle the SIP call both from my Nokia N95 and via a VoIP soft-client on the PC I used for the download without a glitch. Voice quality in both uplink and downlink direction to a PSTN line via a media gateway in the Internet was flawless, no packet loss and also no perceptible increase in delay. Quite a surprise indeed, I was expecting some problems with my standard DSL router in uplink direction. However, there were none which means those VoIP UDP packets must have sneaked through well despite the high load.

Picture 1: No QoS

Standard dsl router-no-qos
Picture 2: Same test with QoS:

Fritzbox-qos

My SIP Calls Are Proxied – And I Don’t Like it

I recently wanted to check out a couple of things concerning the SIP client on my Nokia phone when I stumbled over something I was not prepared for. In theory, the voice path between two SIP devices is supposed to be direct, i.e. one device sends the speech packets directly to the other device. In my case however, the SIP INVITE messages were always changed by the SIP Proxy to route the speech path packets through a media proxy in the network. I was quite perplexed.

Why would my SIP provider do that? Is someone spying on me? Is the government taping into my calls? Yes, maybe I am a bit paranoid, but this is not the way it is supposed to be. I ran a lot of different scenarios to see if the behavior changed like using different accounts, different SIP clients and different network configurations. However, no matter what I did, the INVITE message sent out and the INVITE message received on the other end were different and the speech path was relayed via a media proxy of my provider.

The Explanation

In the end, I contacted my SIP provider and asked them what was going on, not really expecting that I would get a qualified response. To my big surprise, I got a competent answer from one of the engineers explaining that they've had lots of trouble with Network Address Translation (NAT) in the past and have thus decided to route any call through one of their servers as soon as a NAT was detected in the transmission path. Calls from SIP clients without NAT in the way, he said, would not be routed that way. O.k. I thought, then let's test that, I believe it when I see it.

It's not that simple to set something up without a NAT in the IPv4 address space these days, specifically not behind DSL lines. However, with some VPN tunnels I finally managed to get a setup in which both SIP clients were not NATed. And sure enough, no media proxy in the speech path anymore. O.k. great, so I am not spied on, what a relief.

Open Questions

However, a couple of questions remain. Why all this fuss about "Simple Traversal of UDP over NATs" (STUN) when in the end the SIP proxy detects the NAT situation and deploys a countermeasure without the help of STUN? Is it really that unreliable? Also, sending practically all SIP to SIP calls through a media proxy must require a lot of resources in terms of bandwidth and computing power from my SIP provider for which he is not reimbursed since SIP to SIP calls are free of charge.

Lawful Intercept

This brings me to lawful interception of VoIP calls. Depending on the country you live in there are more or less strict laws in place these days that require that VoIP providers must be able to target all calls going through their system, which obviously includes direct SIP to SIP calls. The only way to do that, without the target knowing that somebody is listening in, is to route all calls through a media proxy. Bitcom, the German association representing the Internet industry is pushing very hard against this, saying that it is not practicable to proxy every call. Seems that that is not quite in line with what is already done anyway to get around NAT issues. A lot of hot air for nothing?

Summary

One way or the other, I don't like my calls being sent through a media proxy no matter for what reason. It's time IPv6 is finally marching in to rid us of NATs. If by the time law mandates commercial providers to media proxying all calls it might be time for my own Asterisk SIP server at home so at least "internal" calls are not proxied. Also, such a solution would provide for security and encryption of the call, both not supported by my SIP provider today.

But then, for those who really want to be sure nobody is listening in, they have to buy a pair of these or these.

SIP and AMR

Amr
Another post on SIP, yes I am doing a lot of experimenting around it these days. While we don't have AMR-Wideband yet on Nokia phones, one experiment has at least confirmed that for Nokia SIP to SIP device calls, the bandwidth efficient AMR (Adaptive Multi Rate) codec is used instead of the default G.711 codec. The figure on the left shows how this looks like in Wireshark. While the bandwidth requirement of G.711 is 2 x 85.6 kbit/s (uplink + downlink), AMR brings the transmission bandwidth, including Ethernet, IP, UDP and RDP header down to 2x 34.4 kbit/s. The codec rate itself is only 12.2 kbit/s, so 2/3 of the required bandwidth goes into packetization header overhead. While not much can be done about that in most parts of the network, Robust Header Compression (ROHC) in future wireless radio networks can reduce the overhead from 54 bytes down to just a few, thus making SIP calls almost as efficient as current wireless circuit switched calls.

Breakthrough for VoIP with Wideband Codecs?

I recently wondered why we are still using narrow band speech codecs for VoIP calls between two SIP devices. There were a number of interesting answers and as always the issue is multi-faceted. However, it seems that wideband codec capable devices are now appearing on the market and SIP phones such as the Siemens Gigaset 6XX are actually advertised with superior voice quality between two 'High Definition Sound Performance' (HDSP) phones these days. Here's a link to a web page that demonstrates the difference between today's voice quality and the wideband codec used by Siemens.

While it is difficult (but not impossible) to introduce wideband codecs in fixed and wireless circuit switched networks (e.g. due to the required tandem/transcoder free operation) things are pretty much straight forward in IP based networks. Here, devices negotiate the speech codec to be used directly and no interworking-, transcoding- and digitizing functions are required beyond the user's device that would force the use of a specific speech codec.

Let's hope we don't have to go through many years of fragmentation
where each vendor implements his own set of wideband codecs,
incompatible with those of the competition. But in the end I can very well imagine that  wideband
codecs are the missing piece to bring a real breakthrough for
VoIP. So far, VoIP offers little to nothing beyond circuit switched telephony to the average user. With wideband codecs, however, I am sure most people will start convincing others to switch once they've been on a wideband conversation with someone.

For true success, an important additional requirement is that VoIP providers connect their registrar servers with each other to avoid the call being routed into the circuit switched national network first before being thrown back into the VoIP domain. When this happens, there is no transparent VoIP connection in place and consequently the smallest common denomitator, today's G.711 narrow band voice codec, is used for the call.

Well, maybe it's not so straight forward after all… As always, theory and practice…

Why Are We Still Using Narrow Band Codecs for SIP to SIP Calls?

I really like the SIP Voice over IP implementation of the Wifi enabled Nokia Nseries phones such as the N95 and the N82. After all, they save me a lot of money these days as SIP to SIP calls for example even between different operators are free. On first thought, voice quality seems to be excellent, I can't tell the difference between a VoIP call and a traditional circuit switched call over a cellular network. But put into a different perspetive, that's a bit short sighted. For direct SIP to SIP calls that do not cross a circuit switched interface, why do the two SIP clients still use the backwards compatible G.711 narrow band voice codec released in 1972 or the narrowband AMR (Adaptive Multi Rate) codecs? Today, much better codecs such as Wideband AMR (AMR-WB) are available that have a similar audio quality as Skype to Skype calls. So why are we still stuck with a narrow band encoding? It can't be computing power, especially in the case of high end Nseries phones. Maybe license or patent issues? Ideas, anyone?

SIP providers miss a great opportunity to go beyond the limitations of circuit switched networks and offer subscribers a superior experience for direct VoIP to VoIP calls. And I think it would be a good selling argument once suddenly for some connections you have a much better audio quality than to someone still stuck in the circuit switched world (or in a SIP network that is not interconnected and thus has to use a circuit bridge). I can very well imagine that at some point conversations would start with "oh, you are still on an old phone line" 🙂

P.S.: Some details: The N95 SIP client supports AMR, G.711 a- and my-law, iLBC and G.729. All narrowband…

The Nokia 6300i and VoIP over Wifi

Back in April this year, Nokia announced the 6300i that comes with Wifi and VoIP (but no 3G support). At the time, it was not quite certain from the press release what kind of VoIP the phone would offer. Now that the mobile is available, the user guide gives further details on page 30. The word SIP is never used but based on the configuration information, it certainly looks like SIP like on the Nseries phones and not like UMA. For UMA, the 6300i seems to have a brother, the 6301. Together with Firmware Over the Air (FOTA) update capability, and Opera Mini coming pre-installed, it looks like Nokia has started an interesting test balloon in the sub 200 euro category (Amazon Germany has it for 179 euros, taxes and shipping included!). I'd really like to try the VoIP implementation. I wonder if it is as good as that of the N95? Or maybe even better?

CS Voice (And Other Services) over LTE

I've been speculating recently how voice calls could work in next generation 3GPP LTE networks. The politically and technically foreseen way is IMS, the IP Multimedia Subsystem, and a service platform running on top of IMS such as the IMS Centralized Services (ICS). ICS is quite promising as it includes a solution to bring GSM only handsets without any IMS extensions into an overall voice solution and can hand-over voice calls from LTE to GSM when leaving the coverage area. The major drawback of ICS is its complexity and its anyone's guess when we will see this in mobile devices for the general public.

In the meantime, there has been some support in 3GPP to investigate a different solution: How to extend the current circuit switched voice service of GSM to LTE. In 3GPP a number of companies started writing some proposals, which were gathered in 3GPP TR 23.879. In this paper, the main proposal is to connect the Media Gateway part of the Circuit Switched Mobile Switching Center (MSC) to the packet core and give the the MSC Server direct access to the Mobility Management (MME) Entity of the Access Gateway to the LTE Radio network.

This approach completely circumvents the IMS and reuses all upper signaling protocols already known from GSM. Only the lower protocol layers are replaced by TCP/IP. For the voice call itself, all higher layers of the voice transmission protocol are foreseen in the technical report to be kept, while the lower layers would be replaced by TCP/UDP/RTP between the mobile device and the MSC's media gateway.

Handovers would be supported via the interface between the LTE Access Gateway and the evolved MSC (eMSC). When the base station signals that a handover to a 2G GSM cell is required, the Access Gateway informs the evolved MSC via this interface of the handover and the intended target cell. The eMSC can then prepare a circuit switched channel in the 2G or 3G network and respond to the LTE Access Gateway with the necessary details which are then given to the mobile device by the base station in the handover command.

From a development point of view such an approach is much simpler than installing a full IMS system and put ICS on top. Also, all services available today, including SMS, are instantly available, without any further development.

Here are the main developments that I think would be required for such a solution:

  • Mobile device: The stack for voice telephony must be enhanced to put the signaling and voice data a packet switched connection while the device is attached to LTE. Also, the handover code must be enhance to not only support 2G to 2G, 3G to 2G, 2G to 3G handovers but also 4G to 2G or 3G and vice versa.
  • LTE Base station: The software needs a small enhancement to transparently forward the CS handover information it receives from the Access Gateway to the mobile device.
  • LTE Access Gateway: The MME in the Access Gateway needs to be enhanced to report a handover to the eMSC and to wait with the handover until the eMSC gives the go-ahead. Also, it would have to forward a transparent data container with information about the resources allocated in the circuit switched network to the mobile device.
  • MSC: Would have to be enhanced to communicate via DTAP over IP (instead of ATM, IuCS, BSSMAP and BSSAP) and to perform handovers from 4G to 3G or 2G and vice versa. Further, instead of assigning circuit switched traffic channels it would have to interact with the packet core to assign the correct QoS attributes which will ensure a smooth call and sets the scene for the MME to signal a 2G handover to the eMSC.

For further details, including how to deal with roaming subscribers, have a look at the technical report.

All in all, I would say that the enhancements required for 4G handovers are far less complicated than those required at the time to implement 3G to 2G handovers when UMTS was specified. 

From a technical point of view, this architecture has the drawback that voice calls to mobile clients would continue to use a protocol other than SIP, which is the dominant protocol in the fixed line VoIP world. The MSC and the Media Gateway would in effect act as a signaling protocol converter and, in case the call is handed over to a circuit switched 2G connection, as a voice codec transcoding function. Considering the comparatively small enhancements required in the handset and the newtork compared to a full IMS/ICS solution, this architectural imperfection could well be worth it.

From an IMS/ICS point of view the proposed solution looks of course "stone age". It would only support voice calls, i.e. no multimedia sessions, would not support several devices per account, no sessions, no instant messaging, you name it, just pure and simple voice and SMS (but with all the supplementary services that have been developed over the past 30 years!).

BUT: Due to its handover capabilities to 2G GSM and and seamless use over 2G, 3G and 4G networks, it might be the killer VoIP solution for operators to beat Internet based VoIP services (think Skype, etc) which are also pushing into wireless networks and devices today.

Strangely enough, the current work plan lists the technical report as "moved to Release 9" (look for "FS on CS Domain Services over evolved PS access"). I am not sure what that means but it sounds like it didn't meet the love of enough companies represented in 3GPP.

Place and Cost

I am at the European Telecommunication Standards Institute (ETSI) in Southern France this week and every now and then I have to give a call to some experts back in Germany. Interesting how a 5 minute call to the same number is priced depending on which calling option I use:

  • Using my French SIM card in my N95: € 3.50 (70 cents a minute)
  • Using my German SIM card in my N95: € 2.90 (58 cents a minute)
  • Using the N95 VoIP function via the Wifi network: € 0.09 (1.79 cents a minute)
  • Using the VoIP client on my PC via Wifi: € 0.00 (call is VoIP end to End)

In the end I mostly use the N95 VoIP option over Wifi as for some calls some privacy is needed which is not not provided in the meeting room where the PC is located. I could move the PC but the € 0.09 is a good tradeoff for the convenience.

I titled this post “place and cost” because it shows how cost dramatically drops when different access methods are available and compete with each other. In places with less competition like the car, the countryside, etc.) mobile operators take over and option 3 and 4 are no longer possible. Unless of course, the operator offers a reasonable 3G data plan which make VoIP calls affordable again. One might argue it is more expensive to operate nationwide mobile networks with good coverage compared to DSL networks but I doubt the difference is € 0.09 to € 3.50.

Breaking the Radio Silence with VoIP

In cellular networks, the primary rule for voice telephony is efficiency, efficiency, efficiency. Translated into practice, this means that the mobile device patiently waits till it receives a paging for an incoming call or until the user wants to establish an outgoing call. In the time between, there is complete radio silence, except for occasional short signaling exchanges once every few hours to confirm to the network that the device is still switched on. With always on mobile Internet devices, this is going to change significantly, as the following example shows:

In previous blog entries, I’ve described how well the SIP VoIP client works on the Nokia N95. It blends in very nicely with the rest of the phone’s functionality and I can’t tell the difference between a cellular call and a VoIP call over Wifi. On the radio layer, however, things could not be more different.

While the cellular telephony application remains silent while no call is ongoing, the VoIP part remains quite active on the IP layer. Per minute, there are at least 10 message exchanged between the mobile and the network for various reasons such as keeping communication ports open on NAT firewalls. While it doesn’t seem to be an issue for battery capacity, as there is still ample capacity left in the evening despite being logged into the SIP server over Wifi all day,  it does have implications for cellular networks once VoIP is used there, too. While not all messages exchanged over Wifi will appear in cellular networks, at least 6 of those 10 are relevant for that scenario as well.

Today, each cell serves about 2000 users. For the network, this is not a problem since most mobiles are dormant. In a world where most mobile devices are IP enabled and use a standard SIP VoIP client, 2000 x 6 (or even more) message exchanges per minute means 12,000 message exchanges per minute over a single cell for more or less nothing.

To stay with the SIP VoIP example, here’s an overview of what I traced with my Wifi Tracer during a typical 60 seconds time interval while the SIP client is running and the phone is connected to a Wifi network:

  • At 7 seconds into the minute, the N95 wakes up because it receives a notification from the access point that an IP packet has arrived. It sends ‘power save poll’ management frame and receives an IP packet from the STUN server or the SIP server. In total, the mobile transmits 4 frames and receives 4 frames during this message exchange (including acknowledgments at the MAC layer).
  • At 11 seconds into the minute, The N95 decides to return the polling gesture and sends 1 packet to the STUN server and 1 packet to the SIP server. The STUN server sends a confirmation. Afterwards, the mobile enters the Wifi sleep state and informs the network with a corresponding management frame. In total, the mobile transmits 4 frames and receives 3 frames.
  • At 12 seconds into the minute, the mobile has to turn on it’s transmitter again because there is some data waiting again. It sends a poll frame and receives an ARP broadcast as the access point queries all IP addresses in the subnet. The mobile answers the ARP request and goes back to sleep. In total, the mobile transmits 7 frames and receives 6 frames.
  • At 16 seconds into the minute, the mobile feels a sudden urge to check that the MAC address of the router is still valid. This is as unnecessary as the ARP request from the router at 12 seconds, but it’s happening at least once a minute. The mobile transmits 2 frames and receives 2 frames.
  • At 22 seconds into the minute, a keep alive frame is received from the SIP or STUN server. I stop counting frames at this point.
  • At 34 seconds into the minute, the router runs another ARP request for all IP addresses in the subnet.
  • At 35 seconds, the SIP/STUN server sends a keep-alive frame.
  • At 37 seconds, the mobile returns the favor.
  • At 46 seconds, the mobile returns to sleep state and signals this to the Wifi Access Point.
  • At 49 seconds, the SIP/STUN server sends a keep alive frame.
  • Silence until 4 seconds into the next minute.

And now imagine you have a push eMail client and Instant messenger running, which will create even more traffic and 2000 other mobiles in the cell doing the same.

Standards bodies seem to have become aware of this issue, at least to some degree and have started to specify radio interface enhancements to counter the challenge. In case of UMTS and HSPA, the following come to mind:

I am not sure how LTE and WiMAX handle such very low speed but persistent message exchanges on the MAC layer. If anyone can give me pointers to that, I’d really appreciate.