Author: Martin

Today I have some tidbits of information on the state of LTE deployment in St. Petersburg in addition to my previous post on 3G. Despite my Russian SIM card of MTS proclaiming '4G' I did not yet get LTE service. However, my mobile already picked up four LTE networks so activation is probably not far away anymore or has perhaps already happened in the networks for which I did not have a SIM card.

With some additional digging I was able to get some more details:

The four networks shown in the screenshot are actually three physical networks as Yota and Megafon share a single 15 MHz carrier in a MOCN (Multiple Operator Core Network) setup in LTE band 7 (2600 MHz). That's probably not surprising as a quick Google search revealed that Yota was bought by Megafon last year. SIB-5 announces a 5 MHz carrier in band 20 (digital dividend 800 MHz) but I didn't pick up a signal there. And finally my German SIM card was properly rejected with cause code #15 (no suitable cells in this tracking area) to encourage an Inter-RAT cell reselection to 2G or 3G.

MTS is also active in Band 7 (2600 MHz) but 'only' with a 10 MHz carrier. My German SIM card was somewhat rudely rejected with cause code #111 (protocol error unspecified). While it serves the purpose it doesn't encourage the mobile to do an InterRAT reselection instead of looking for an alternative network operator which might not be good for capturing roamers. Perhaps something to look at in case anyone from MTS reads this post… But at least the network didn't send an 'EPS and non-EPS services not allowed' which would have made the mobile never to try the network again. No, I'm not kidding, I've seen this reject cause in the past in other networks. As my Russian MTS SIM card does not get service on the LTE layer I assume that the network is not yet live for real customers. I also get this impression from the 'intraFreqReselection' parameter which is set to 'not allowed', which is quite unusual, even in test networks.

And finally, Beeline was also present in Band 7 (2600 MHz) with a 10 MHz carrier and my German SIM was also rejected with cause code #111 (protocol error unspecified).

So no LTE for me this year but perhaps there will be service should I return next year. Let's see.

 

… and a quick follow up on my previous post about my 3G experiences in St. Petersburg. While in some places one can buy a local SIM card directly at the airport, St. Petersburg doesn't seem to be one of them. So as I first had to get to the city before I could buy the local SIM card for Internet connectivity I had to use another means to get to my email after landing and to get the data for my GPS receiver to get a quick location fix.

Using my home network SIM for the purpose was out of the question, roaming charges in Russia are way beyond anything reasonable. But my Toggle SIM offered an almost reasonable rate for small data transfers, 1.34 (UK) pounds per megabyte, altough it thought I was in Abkhazia. Well, not quite 🙂 Looking at the billing records, the 1.34 pounds are charged for every PDP context activation so you better leave the context up if you are reasonably sure there is only little data transferred until you have the local SIM card.

Last year I had a devastatingly bad 3G experience in St. Petersburg and when returning this year I was a bit skeptical of how good my connectivity would be when not at the hotel or when using one of the almost ubiquitously distributed Wi-Fi hotspots in the city. So here's a little report of how it worked out this time:

Instead of a Beeline I went for Internet connectivity of MTS this time. Getting the SIM card took about 15 to 20 minutes of intensive interaction of the sales person with her computer terminal, still quite a different exprience compared to other countries where working SIM cards can be drawn out of machines at the airport in about 10 seconds.

Anyway, once activated I got reliable service inside the city and I saw sustained data rates of up to 6 Mbit/s in the downlink direction and around 1-2 Mbit/s in the uplink direction. That's solid service I would say. Thanks to Google's global APN lists in Android, there's also nothing to configure anymore on the mobile as the APN was set automatically to 'internet.mts.ru'.

Last year I came here with my Nokia N8 and could take great pictures but was a bit hampered distributing Internet connectivity to my other devices in the few cases I could get usable cellular connectivity. This year I had a couple of low- to mid range Android devices in tow and while Wi-Fi tethering capabilities made connectivity sharing easy, picture quality compared to last year visibly suffered. I just wished I could have it all in one (affordable) device. Next year perhaps.

Pricing for Internet is also quite affordable. I paid a total of 350 Ruble (around 7 Euros) for the SIM card including 300 Ruble balance on it. Out of those, unlimited Internet access for a month cost 250 Rubles, i.e. around 5 Euros. The daily cap is set to 100 MB after which the data rate is throttled. More than sufficient for my purposes. For the remaining 50 Rubles I sent a couple of SMS messages and made some local calls. Altogether a very positive experience!

P.S. While LTE seems to be available from MTS in Moscow and 4G is already printed on the SIM cards it's not yet available to the public in St. Petrsburg. However, there are already three LTE networks on air so it can't take long anymore now.

The title of this post is perhaps a bit long winded but it contains an interesting analogy I've recently come up with when I was explaining the concept of hosting my own cloud services at home to a friend rather than using similar services of large Internet based companies.

Having my own cloud services at home and maintaining them vs. using services of Internet based companies to me is like doing some real cooking versus just consuming instant food. Internet based companies offer services that are relatively easy to install and use, i.e. that's quite similar to instant food that heats up in microwave in a few minutes. There's a price to pay, however, less tasty in case of fast food, perhaps, and sharing your private data for analysis and use by an Internet company in the other.

Hosting your own services at home is obviously more work just as preparing a meal from fresh ingredients is more work. However, my data remains private and secure which is similar to a self prepared meal which is more tasty if the cook knows what he is doing.

I like the analogy because it also fits when people say "great that you do it but I lack the skills and time of doing it myself". I hear the same argument when people talk about instant food vs. cooking. Sure If you've never stood in front of a stove before, learning how to cook is likely to be a challenge and someone to help getting you started is surely a good thing. The same is true for hosting your own services at home or switching to an opern source operating system such as Ubuntu Linux.

To summarize: Yes, when it comes to using cloud based services and operating systems I definitely prefer cooking to instant food.

I am amazed at the current steady flow of intercepted phone calls that are leaked in some form or shape. Take the phone calls of the Turkish prime minister, the leaked phone call of the US diplomat who found quite strong words for the foreign politics of the EU or the phone call between the EU foreign representative and the Estonian foreign secretary discussing the situation in the Ukraine as prime examples. What few reports are asking is who intercepted those calls, who might have leaked them and what was their motive in doing so? Leaving the political questions aside in this post I think it is save to assume the majority of those phone calls were not lucky intercepts by a teenager but the work of professionals in the employment of one state or another. Also, I think it's a safe assumption that these leaks are just the peak of the ice berg. A nice thing of leaked phone calls is that they litterally speak for themselves compared to documents who's authenticity is much harder to prove to the public.

In the meantime it must dawn on most politicians that they simply have to assume that the majority of their calls are intercepted and recorded if no end-to-end encryption is used. Not that they don't want to use devices that offer end-to-end encrypted calls but from what I can tell they are still cumbersome to use and interoperability between devices of different makers is virtually non-existent. But perhaps this constant flow of leaked phone calls will trigger people to rethink their position and create a bigger demand for interoperable and easy to use devices and applications for end-to-end encrypted calls that are not only affordable for them but for the general public as well. I for one would welcome it as I think it's not only politicians who in the meantime have no privacy anymore when making a phone call.

Lots of people I talk to like the idea of having a box at home that can be accessed remotely from notebooks, smartphones and tablets to synchronize private data such as calendar and address book information. They' like it because they'd rather like to have their private data at home than to give it up to companies that store it in a country far far away and make money by analyzing their data and selling advertising in some form or shape. Sooner or later, however, there's always a sentence like 'yes, you [Martin] can do it, but I have no idea how to go about it'. At that point I'd really like to say, 'gee, no problem, just buy box 'X', connect it to your DSL or cable router at home and you are done. Unfortunately that's just not were we are today.

To make self hosted services for the masses a reality, however, it's exactly such a plug and play setup that is required. Anything less and it won't work. I have no problem to imagine how most setup steps could be automated. A company could take open source software such as Owncloud, package it on inexpensive hardware such as a Raspberry Pi or even a NAS disk station at home and write an intelligent setup software that automatically does tasks such as registering a DynDNS domain, registering an SSL certificate for the domain and coming up with really simple to configure mobile OS connectors for calendar and contact synchronization. Money can be made with all of these steps and if reasonably priced I think there's a market for this.

But there are also some technical hurdles that are a bit more tricky. The major one is Network Address Translation (NAT) in DSL and cable routers at home today. For tech savvy users it's obviously easy to configure a port forwarding rule but for the average user it is an insurmountable obstacle. The Universal Plug and Play (UPNP) protocol implemented in most residential gateways offers the means to do this automatically and is used by programs such as Skype. Unfortunately this functionality is a significant security risk and many router vendors and DSL/cable network operators have decided to disable it by default. On top, many DSL and cable networks today no longer assign public IPv4 addresses to residential connections, hence preventing even tech savy people to have their servers at home.

Basically, I can see two solutions for this: One would be to have Owncloud and other services integrated into the DSL/cable routers. That's probably the easiest way but it would limit the opportunity to the few companies working on residential routers. The other solution could be for the home cloud box to establish a VPN tunnel to an external service from which it gets a public IPv4 address. Possible, but not ideal as it would introduce a single point of failure.

So perhaps IPv6 will come to the rescue at some point!? Unfortunately, that help will not come tomorrow. In addition I can't help but wonder if DSL/cable routers will not include IPv6 firewall functionality at some point to block incoming connections for security reasons. If so, we are back to step 1 for which we need a clever, secure and standardized way to automate initial connectivity configuration.

One tiny downside of running cloud based services at home such Owncloud files, calender + address book synchronization, VPN services, Instant messaging server, etc. at home is that one becomes dependent on the power company and Internet provider to keep you connected to your services when you are not at home. And every now and then things go wrong. Back in December I had a two hour power outage that I managed to detect with my GSM enabled power socket that sent me an SMS once power was restored so that angle is covered. To survive DSL outages I have a fallback solution over wireless in place. And that's just what I needed recently when my DSL line failed for two days.

While it worked rather well it also demonstrated just how many self hosted services I used today and for which the fallback solution ensured service continuity and for which it didn't. So here's the story:

In addition to the DSL router for normal operation I have a cellular router in place for backup Internet connectivity over a different default gateway IP address. The router also registers a backup dynamic DNS address so I can still access the network remotely when the DSL line fails. One more thing I need to switch my services to the backup line is a way to remotely switch the default gateway addresses of my servers away from the DSL router during an outage and towards the cellular router For this purpose I use a secure shell (ssh) login on a box in the network that I can reach over the cellular connection. For this purpose I have a separate Raspberry Pi to which I have enabled port forwarding from the cellular router over a non-standard TCP port so I can securely reach it via SSL using the backup dynamic IP address. Once I'm logged into this machine I can ssh into my other routers to change the default gateway and DNS server and then restart the network stack on them.

The last thing that remains to be done during a DSL outage is to switch the dynamic DNS domain I used for my services away from the DSL router and towards the cellular router. Once that is done I have my main services back in operation. In addition, I can use the Raspberry Pi's vncserver to remotely get a GUI on a machine inside my home network and use a browser to access the web interface of the routers for maintenance. Again, the SSL connection helps to securely access the VNC server and I'll describe in a second post how that works.

So while this works very well there are a number of quirks:

The first is that most cellular network operators do not assign public IP addresses (anymore) which is, however, a requirement for this to work. Fortunately my cellular operator has a dedicated APN but it seems to be a rarity these days.

The second thing that makes the use of the backup solution somewhat of a pain in practice is that the cellular router doesn't recognize that when I'm at home and use my domain name to access my cloud services it should loop back the packets internally instead of sending them out to the network where they are lost. That means that while I'm in the home network I can't reach my services over the default domain name. My solution for this is use a VPN to connect to an external VPN service so the loopback is performed externally. Not ideal but the amount of data that goes back and forth is not very large.

Another thing is that my VPN service doesn't work while I'm using the backup solution because the cellular router doesn't have an option to create static routing entries to the IP address range and subnet used by my VPN server for the clients. While I could live without the VPN server for a while as I can also use an external VPN service it limits my ability for remote support when I am not at home as I use my home VPN service as part of that solution when I'm behind a NAT myself and thus not reachable for reverse VNC connections.

So while by and large the backup solution works there are some shortcomings that would take some more tinkering to overcome. But o.k. it's a backup solution so I can live with that for a while. And yes, agreed, this is not something non-techies would set up at their home so it's by no means a solution for the masses.

A little rant today on new buildings and coverage issues as I keep hearing such reports with increasing frequencies:

When GSM was launched in the 1990's the windows of most buildings were made of glass and while there was some signal loss through them, by and large things worked pretty well. Over the last couple of years however, new buildings, especially offices, are equipped with heat insulating windows that don't only keep the heat or cold out but also radio waves. Their effect is pretty dramatic. Excellent coverage outside the building, no coverage whatsoever inside the building. Hotels, offices, shopping malls, you name it, it's getting more difficult to get coverage into those buildings from macro cells on the outside. While shopping malls are often equipped with indoor coverage via repeaters or small cells, hotels and office buildings or usually not. An exception I have noticed are 4+ star hotels in Asia while their European counterparts usually don't bother. Sure, there are solutions for this that work great such as repeaters, distributed antenna systems, small cells, femto cells, etc. but they all require active interaction between network operators and the owner of the buildings, i.e. extra work. Extra work many building owners are so far unwilling to do. I wonder how much critical mass it will take in terms of new buildings before network operators are taking a pro-active approach to this!?