Author: Martin

I have to admit that although I like video calls I haven't made one in quite a long time, mostly due to international video calls being prohibitively expensive and some network operators that still bar prepaid customers from receiving video calls. That severely limits my options… Anyway so for Christmas I called family and friends and some of them by now even have video call capable 3G phones. A very nice experience!

Despite many people arguing that video calling is a lost cause I still think it's a great opportunity for mobile network operators to offer a service only they can provide in a truly mobile and (almost) always-on fashion, at least for the moment. Don't get me wrong, I don't want all of my calls to be video calls but sometimes it would be very nice to get a video stream from the other side.

Unfortunately, there are still some significant hurdles to video calling even many years after the launch of 3G networks:

• 3G in-house coverage is still a big issue, especially for video calls. Femtos and UMTS on 900 MHz will help over time.

• As I said above, many network operators still limit video-calling to their post-paid subscribers. I can understand the notion of premium service and all, but after so many years I think it's time to open it up to all subscribers to create a critical mass.

• Pricing

• No interfaces to other video systems that are popular such as Skype

• No advertising around video-calls at all. Quite incredible and I wonder how many people are aware that they could actually make a video-call with their phone.

And while we are at it, it would also be nice to see someone implement features such as voice only at first and adding a video stream later or see-what-I-see on my phone.

Wait a second, some of you might think now, why is a cellular guy like Martin writing about Wi-Fi hotspots? The answer is simple: Along train routes, cellular coverage is often patchy but some train operators (such as Thalys or German Railways) offer Internet access over Wi-Fi with a land- or satellite based backhaul. While that works quite well in practice, there are a number of quite real security risks with non-encrypted public Wi-Fi hotspots: One of them is that all packets transmitted over the air interface can easily be eavesdropped on by another hotspot user with software that is publicly available. While that's not much of a problem for HTTPS encrypted web pages it's those unencrypted web pages using cookies for user authentication that can be easily intercepted and stolen.

The only way to get around this issue is to use a VPN (Virtual Private Network) solution to encrypt all traffic.  Some hotspot providers offer a free client for the purpose. But if you have a computer at home and a fast DSL line with a good uplink, you can also use it as a VPN gateway. All traffic is then encrypted and sent to the PC at home and from there to the Internet. Sounds difficult but it's rather easy to set up. All you need is:

• A Windows XP, Vista or Windows 7 machine to act as the PPTP VPN server. You can find a description of how to set it up here. A Linux server can of course also do the job but I don't have installation instructions at hand.

• A DSL/cable router that can update a dynamic dns server such as dyndns.org. This way, your VPN server can always be found from the Internet no matter how often the IP address of your fixed line connection is changed.

• The router must be able to forward tcp port 1723 to the computer with the VPN server and handle incoming PPTP sessions. Most DSL/cable routers are capable of that these days.

And that's pretty much it to secure your access. Have fun experimenting if you try!

After I have dealt with the most essential IPv6 features for me in parts 1 to 3 (see here, here and here) this part focuses on the bits and pieces that have to fall in place in 3GPP GSM, UMTS and LTE networks to make it work.

First of all, mobile devices need to support IPv6. Some already do, such as Nokia devices running on Symbian/S60.In fact, Nokia supports IPv6 already since 2003 as shown in this IPv6 presentation from way back then…

Next, mobile devices need to be able to get an IPv6 address when they connect to the network. In GSM and UMTS, the PDP context activation request message contains the necessary parameters to request one. In LTE the default/dedicated bearer activation procedures provide similar capabilities. Dual stack devices can ask for an IPv4 and IPv6 address in one request. In addition, IPv6 requires a Router Solictiation message being sent from the UE and a Router Advertisement answer from the GGSN to finalize the IPv6 address creation. This is done over the established user data bearer. More details can be found below.

While in theory, user data is sent transparently back and forth between the mobile device and the gateway to the Internet (the GGSN or the PDN-GW), the base station should perform IP header compression (RoHC). In practice this will become even more important due to the significantly increased size of the IP header due to the 128 bit long IPv6 addresses, especially for voice calls.

At the gateway to the Internet, the GGSN (GSM/UMTS) or the PDN-GW (LTE) must be able to assign IPv6 addresses and provide firewall functionalities for IPv6 based communication. Further, the Home Subscriber Server (HSS) must be updated to support IPv6 parameters on a per user basis. And last, but by far not  least, are the IP Multimedia Subsystem (IMS) network nodes that have to handle IPv6 on the network layer but also inside SIP messages.

All of this has been in the standards for years so there's a fair chance we'll see it in the network sooner or later. Here's a couple of links for further information:

• 3GPP TS 23.221 Rel 8, 'Architectural Requirements', Chapter 5.6 on IP addressing says that the mobile is free to change the host part of the IPv6 address at any time on it's own without updating the PS domain via a mechanism described in RFC 3041.

• 3GPP TS 23.060 describes the PDP context activation procedure for IPv6 in Chapter 9.2.1.1 in Figure 6.1 After the context is active, the UE sends a router solicitation message to the network (the GGSN) which then returns a Router Advertisement message. The information contain in this message is then used by the mobile to construct it's own IPv6 address.

Since I'm not an IPv6 guru, here's a question to all 3GPP IPv6 enthusiasts out there: Have I been missing an important point?

Yes, I like dynamic IP addresses and Network Address Translation because they help to protect my privacy. Google offers great online services, no doubt about it, but I am not willing to give up my privacy for them. Without some countermeasures though, it's difficult to keep Internet companies from collecting data without my consent even though I only use a single online service from Google. So here's a list of things I have put in place to stay as anonymous as possible when surfing the net:

• Whenever I connect to a 3G network I get a new IP address. Good, so I can't be followed via my IP address indefinitely.

• My DSL line is automatically interrupted and reconnected once a day and I get a new IP address each time. Same effect as above.

• I allow cookies in the browser but they are deleted as soon as I close the browser. To me that looks like a good compromise between functionality and privacy as my track runs cold as soon as I close the browser.

• For a few selected sites I've configured permanent cookies. Google is not among them…

• Adblock prevents Google Adsense to follow me around on the web via JavaScript plug-ins on pages.

• I deactivated Flash Cookies in the Macromedia configuration web page.

• On my mobile devices I use Opera Mini. There's a compressions server in the network that can follow me around and I assume they could follow my browing history. Not so nice from a privacy point of view, but at least it's not big G…

• As I use Google Reader on the mobile there's a cookie set by Google which probably allows them to track my searches as well. So I use Bing for searching on the mobile.

What do you think, am I missing something or could I do more? Any big loopholes?

3G is fast but it has a weakness in my eyes that is especially relevant for mobile web
browsing: When browsing to a page after having been idle for a long
time, the radio interface is in idle state and re-establishing a
bearer takes several seconds. In practice that means one has to wait
for the first page for quite some time. But there could be a simple
solution for this: Most of the time when I deactivate the keylock of
my mobile device I perform an online activity right afterwards such
as selecting the web browser and going to a new page. So instead of
waiting with the radio interface channel establishment until I select
the page, the phone could already establish the radio channel when I
unlock the phone. Agreed, if it does that and I do something else
after deactivating the keylock such as looking up something in my
device based calender, some energy and radio interface capacity is
wasted. But I'd be willing to make this compromise.

A year ago I was musing over the fact that despite there being quite a number of phones today that can do SIP over Wi-Fi, non are Wide Band AMR capable for superior sound quality. Quite a waste as without network based transcoders between the two parties there's no legacy technology to overcome and implementation is straight forward. Looks like Nokia might have changed that without making a big fuss about it:

When I recently traced the Wi-Fi SIP interaction of my new Nokia E75 (for details how this is done see here), I noticed that it announces that it's WB-AMR capable in a SIP invite message. A closer look at Forum Nokia confirmed this. Unfortunately I am missing a counterpart to try it out with but that might just be a matter of time. While my SIP provider Sipgate puts a proxy in the speech path of every call, it is capable of different codecs, as I've seen both G.711 and AMR run over it. So with a bit of luck, WB-AMR might work as well. I'll keep you posted. In the meantime, here's the E75's Session Description part of the Invite message:

Session Initiation Protocol
    Request-Line: INVITE sip:+xxxxxxxxxxxxx@sipgate.de SIP/2.0
    Message Header
    Message Body
        Session Description Protocol
            Session Description Protocol Version (v): 0
            Owner/Creator, Session Id (o): xxxxx xxxxx xxxxx IN IP4 192.168.xxx.xxx
            Session Name (s): –
            Connection Information (c): IN IP4 192.168.xxx.xxx
            Time Description, active time (t): 0 0
            Media Description, name and address (m): audio 49152 RTP/AVP 100 96 0 8 97 18 98 13
            Media Attribute (a): sendrecv
            Media Attribute (a): rtpmap:100 AMR-WB/16000
            Media Attribute (a): ptime:20
            Media Attribute (a): maxptime:200
            Media Attribute (a): fmtp:100 mode-change-period=2; mode-change-neighbor=1
            Media Attribute (a): rtpmap:96 AMR/8000
            Media Attribute (a): fmtp:96 mode-set=0,1,2,3,4,5,6,7; mode-change-neighbor=1
            Media Attribute (a): rtpmap:0 PCMU/8000
            Media Attribute (a): rtpmap:8 PCMA/8000
            Media Attribute (a): rtpmap:97 iLBC/8000
            Media Attribute (a): rtpmap:18 G729/8000
            Media Attribute (a): fmtp:18 annexb=no
            Media Attribute (a): rtpmap:98 telephone-event/8000
            Media Attribute (a): fmtp:98 0-15
            Media Attribute (a): rtpmap:13 CN/8000

Dual Carrier HSDPA is in the 3GPP standards for some time now and in the mid-term we'll probably see it deployed. So where to go with HSPA next? Well, 3GPP RAN discusses 4 Carrier HSDPA spread over different frequency bands. That's for 3GPP Release 10 I suppose. The report from the recent RAN#59 meeting gives some interesting details in chapter 5.4:

• Adjacent and non-adjacent 5 MHz carriers in a single band (e.g. 2.1 GHz)

• Use of several bands. Band combinations suggested: I and VIII (2.1 GHz + 900 MHz, Europe), II and IV (1900 + 1700, US), I and V (2.1 GHz, Europe + 850 US [???])

• MIMO support depending on the capabilities of the UE in a band. This is an interesting as with this sentence it is assumed that a future UE could support MIMO only in some of the bands it supports.

Obviously that's a big new challenge for UE chip designers. While today the mobile can select an operating band and a suitable front-end, using several bands simultaneously will require the parallel use of hardware components. A tricky thing.  Comments from the RF community on this are greatly appreciated.

Nothings written into stone yet (eh, into the standards I mean) but this is where things are likely to go.

Oh, and I learnt of a new company name: Alcatel-Lucent Shanghai Bell. An interesting combination!

Today follows part 3 of my IPv6 crash course. You can find the first two parts here and here.

ARP Becomes Neighbor Detection

To translate layer 3 IP addresses into layer 2 MAC addresses, the Address Resolution Protocol (ARP) was used in IPv4. In IPv6 a similar mechanism is used and referred to as Neighbor Detection (ND). In addition the good practice in IPv4 networks to check if an IP address that was assigned is already used by someone else by sending an ARP message prior to using the IP address is now a feature in IPv6.

DHCPv6 and DNSv6

As discussed in the previous post, the IP auto-configuration functionality does not supply a DNS address to the host during startup so it can't translate domain names into IP addresses. Therefore, DHCPv6 is likely the means to get this information, potentially together with the IP address of the default gateway and further IP addresses for the interface.

The current DNS service also gets an IPv6 counterpart because it has to deliver IPv6 addresses for a request. While in DNSv4 an 'A' record query is used to translate a domain name to an IP address, DNSv6 uses AAAA records. The four 'A's stem from the fact that an IPv6 address has four times the size compared to an IPv4 address.

Routing

Routing pretty much works as in IPv4 but has been simplified as the network and host part is fixed in IPv6 compared to net masks of different lengths and classless inter domain routing (CIDR) in IPv4. 

Tunneling IPv6 over IPv4 and Vice Versa

Needless to say that IPv4 and IPv6 can coexist on the same interface. In most cases, however, networks only offer IPv4 today. To access IPv6 hosts from an IPv4 only network today, IPv6 over IPv4 tunnels can be used for the purpose. There are several different variants but I won't go into the details here.

IPv6 only networks could also exist in the future as well. Should it be necessary for a node in such a network to reach an IPv4 host, IPv4 over IPv6 tunnels exist as well.

Summary

So that's my crash course overview of IPv6 for now. Agreed, this is very very simplified but I think those are the main concepts you need to get your head around from an end device's point of view. Next stop: How IPv6 is integrated in 3GPP.

This week saw a number of interesting press announcements on first voice over LTE calls: First was the VOLGA forum who announced the first voice call between two LTE networks, one in Bonn Germany with a Kineto VOLGA Access Controller and the other one in Stuttgart, Germany where Alcatel-Lucent runs a LTE trial network on their campus. A great accomplishment given that the specifications were put together in record time and only released recently. It's not that surprising, though, as VOLGA is based on the already existing GAN (Generic Access Network) 3GPP standard that is used by a number of wireless network operators to offer Voice over Wi-Fi at home.

Next was Nokia Siemens networks who announced that they've done their first LTE voice call with the recently established One Voice Profile that describes which bits and pieces of the IP Multimedia Subsystem (IMS) should be used for voice calls over LTE. Also hardly surprising since IMS standards exist for many years now and IMS voice calls have been made with prototype devices over 3G and other IP based networks. So I guess this announcement was mainly a reaction to the VOLGA announcement.

So this was step one which now has to be followed by the most difficult step: integration. On the mobile side I am sure integrators of both systems can't wait to get an LTE smartphone into their hands. So far, only USB LTE sticks have been announced and here voice functionality is not of prime importance. But once LTE mobile devices such as smartphones become available we'll see who can integrate their solution better, quicker and, foremost, seamlessly with 2G and 3G circuit switched calling. After all, it should be absolutely transparent for the user over which air interface the mobile establishes the voice call. IMS based solutions have struggled for years to pull this off, so let's see, maybe the One Voice Profile will help to unite the supporters of IMS around a single set of features. For VOLGA, things might be a bit simpler as it re-uses much of what has already been developed for GAN and already implemented and used in a range of mobile devices today.

Perhaps even more challenging is the integration on the network side for IMS One Voice. While a standalone IMS system is quickly installed (relatively speaking), it's the interworking with the cirucit switched infrastructure to enable seamless handovers when running out of LTE coverage that makes life difficult. Also it is important that a user can be reached by the same means (i.e. same phone number) no matter whether he/she is currently connected to the IMS over 3G or 4G or just reachable via 2G and the circuit switched infrastructure. IMS Centralized Services (ICS) and Single Radio Voice Call Continuity (SR-VCC) have been specified in 3GPP for the purpose and I've reported and linked to the specs here. Specifications are one thing, complexity quite another. On the complexity scale, ICS and SR-VCC are at the upper end of the scale and require software updates in the circuit switched infrastructure.

For VOLGA, things are a bit simpler. No modifications in the existing infrastructure are necessary and only a single gateway node, the VOLGA Access Network Controller (VANC), is required for a full implementation. To the circuit switched Mobile Switching Center, the VANC just looks like a 2G Base Station Controller or a 3G Radio Network Controller. For the LTE side the VANC is just a server on an IP network. Pretty much a straight forward thing to do.

Both initiatives good luck on their way forward and I hope that once I hold the first LTE smarthphone in my hand I won't be thrown back to GSM for voice calls.