WirelessMoves

LTE has been great so far because of its speed and because it brings high speed wireless Internet to the German countryside.  One major downside of LTE on my smartphone so far, however, have been the very long call establishment times for incoming and outgoing voice calls due to the required fallback to GSM or UMTS.

In practice I observed typical CSFB (circuit switched fallback) times of about 2.5 seconds in live networks in addition to the normal 3G call setup time. A call from an LTE to LTE smartphone thus takes 5 seconds longer than a 3G mobile to mobile call establishment, which is around 5 seconds. 5 vs. 10 seconds, it almost felt like eternity.

Recently, to my surprise however, setup times have significantly reduced in my network of choice and CSFB calls from between two LTE mobiles are now established almost as fast as pure 3G-3G calls. The difference is around half a second at most. Something that one can quite live with.

Kudos to the network engineers, LTE is now finally usable for me on smartphones!

A couple of weeks ago I wrote about my re-discovery of the fascination and use of the electronics kits I experimented with in my youth and how I wanted to make good use of them again in combination with a Raspberry Pi. The project I had in mind and which has borne some fruits now is a water alarm system with Internet connectivity.

I'm a practical guy so playing around with new hardware and software always has to have an application for me. When you enter the kitchen in the morning and are welcomed by a pool of water on the floor you instantly know something is wrong. In my case it was a leak in the rooftop that subsequently proved to be a bit difficult to find so we went through a trial and error phase. During the trial and error phase I wanted to know at once when water started accumulating on the kitchen floor again to take the appropriate counter measures.

A perfect application for the Raspberry Pi that could warn me of a new water pool building on the floor via email. The Pi itself has some I/O pins that are, however, not well protected so I decided to buy one of the hardware extension boards that offers buffered and protected I/O ports. There are a number of different boards available and my choice fell on the Pi-Face as it's the same size as the Raspberry Pi and hence I could fit it into a small casing. As the Pi-Face is only a generic I/O board I needed additional hardware to detect water on the floor. This is were my electronics kit came in for prototyping a detector as seen on the first picture on the left.

Once this was working I decided to go for the real thing and build five of those sensors on a real board so I could place five detectors at different locations on the floor. The second picture on the right shows how the final solution looks like: The casing contains the Raspberry Pi with a tiny Wi-Fi adapter below the PiFace which is connected to the self made electronic board via a number of cables. From there 2x five 3m sensor cables leave the casing on the right to different locations on the floor. On the other end I just taped the uninsulated cables to the floor. Water between the ends of two cables change the resistance between the two cables which is detected by the detector on my self soldered board.

When one of the detectors on the board recognizes a change in resistance at the end of the cable it drives an input port on the PiFace which in turn is detected by a Phython program running on the Pi. The Phython program in turn will immediately send me an eMail to notify me of the event. The program also sends me regular status updates of all input ports and also notifies me in case an input is switched off again, i.e. the water has disappeared again.

Sending an email with Python by the way is pretty much straight forward as there are already libraries that can even handle encryption via secure SMTP. I've attached the source to this part of the program at the end of this post as this could come in quite handy for other projects you might to want to try.

Quite frankly I wouldn't have gone through the whole thing if I just had a water leak. But a RasPi project, real world interaction, connectivity to the Internet, a little electronics project and a real world problem to solve was too hard a thing to resist.

And here's the source for sending email in Python:

As I wanted the email transmission to be independent from the rest of the alarm system I decided to spawn the python email code in an independent process. If something fails here, the system would still work and continue to monitor the alarm sensors and show the result on the LEDs on the PiFace. Also should one email task get stuck for one reason or another I would still get informed of the problem with the next periodic status email. Here's the code to spawn a new independent task without waiting for it to be finished:

EMAIL_SCRIPT_WITH_PATH = "/home/pi/send-email.py"
EMAIL_FROM = "test-name@domain.com"
EMAIL_TO = "my-name@another-domain.com"
EMAIL_SERVER = "smtp.my-domain.com"
EMAIL_PASSWORD = "very-secret-of-course"
EMAIL_PORT = "587"

    syslog.syslog ('sending status email')
    subprocess.Popen([EMAIL_SCRIPT_WITH_PATH, EMAIL_FROM,
                      EMAIL_TO,
                      "System status: " + PrintString,
                      "Status of monitoring system " + PrintString,
                      EMAIL_SERVER,
                      EMAIL_FROM,
                      EMAIL_PASSWORD,
                      EMAIL_PORT]).pid

And on the other end, send-email.py looks like this:

#!/usr/bin/env python

# send a text email from the command line using python
#
# version 1.0
#
# Original code found at http://www.cs.cmu.edu/~benhdj/Mac/unix.html#smtpScript
#
# NOTE: if smtp username is "" then code will not use the smtp authentication method
#
# input parameters
#    sys.argv[1] is the sender email address
#    sys.argv[2] is the reciever email address,
#        this can be a comma separated string for multiple recievers
#    sys.argv[3] is the subject text
#    sys.argv[4] is the body text
#    sys.argv[5] is the smtp host
#    sys.argv[6] is the smtp username
#    sys.argv[7] is the smtp password
#    sys.argv[8] is the smtp port
#

import smtplib, email, sys, time
import syslog
from email.mime.text import MIMEText

# check to make sure the number of arguments is correct
if len(sys.argv) != 9:
  print 'Usage: pythonEmail.py <sender> <receiver> <subject> <bodyText> <smptHost> <username> <password> <port>'
  sys.exit(1)

# get the argv variables
sender = sys.argv[1]
receiver = sys.argv[2]
subj = sys.argv[3]
bodyText = sys.argv[4]
smtpHost = sys.argv[5]
username = sys.argv[6] # use "" if no SMTP authentication is required
passwd = sys.argv[7] # ignored if no SMTP authentication is required
port = sys.argv[8] # ignored if no SMTP authentication is required
 
# create a list from the receiver in case we have a comma separated string of multiple receivers
rList = []
rList = receiver.split(',');

# setup the message header
msg = MIMEText(bodyText)
msg['Subject'] = subj
msg['From'] = sender
msg['To'] = receiver

# determine if a passworded smpt host is being used and connect as necessary
if username == "":
    server = smtplib.SMTP(smtpHost) # smtp server is not password protected
else:
    server = smtplib.SMTP(smtpHost, port)
    server.login(username, passwd)

failed = 0
failed = server.sendmail(sender, rList, msg.as_string())
server.quit()

# return the status
if failed:
  print 'send-email.py: Failed:', failed
  syslog.syslog('send-email.py: Failed: ' + str(failed))
else:
  print 'send-email.py: Finished with no errors.'
  syslog.syslog('send-email.py: OK: ' + str(failed))

Have fun hacking!

Perhaps I'm old school but I have a presence dilemma. I'm referring of course to the presence status of many instant messaging applications that show all my contacts whether I'm currently online, offline or in a state in between.

For me the dilemma is that I feel that there is a difference between being online and having time or being in the mood to engage in a conversation. When I receive an instant message out of the blue and don't have time to respond I sometimes don't feel comfortable to reject the conversation as that might be seen by the other party as rude, especially if he or she is also 'old school'. Also I have to remember to 'text back' once I have time. Also not ideal.

I could of course set my client to 'invisible' but then I would forget later on to switch it back to 'available' when I am or feel reachable again. And no, I don't want to go fully offline with my instant messaging client as sometimes I still want to be reachable for a select audience.

Yes, human interaction is complicated (or perhaps it's just me?) and instant messaging presence is far from reflecting my reachability status.

Next to the London tube, New York's underground transportation system is one of the few places I have noticed over the years that still lack wireless coverage on a broad scale. It looks like things are changing though as I was positively surprised to have coverage in one of New York's metro stations recently. Have a look at the picture on the left to see how the antennas look like. I had to smile a bit because the cables and antennas are significantly bigger than those in the Paris metro for example. Also one antenna in the Paris metro suffices for four networks while New York needs three. But then, everything seems to be a bit bigger in the US.

Anyway, I did a bit of background research to see how far the project has come so far. Looks like there are currently 36 stations covered but there is no talk of the tunnels in between the stations. For details see here. Better than nothing but that's lacking a bit of ambition. I am sure some will point to the fact that the New York metro is old and tunnels are narrow. That hasn't stopped in-tunnel coverage in Paris though where similar conditions can be found.

The article linked above has some interesting details concerning who pays for the deployment and how much it costs. It looks like a separate company called Transit Wireless was established to bundle all technical and financial matters:

Transit Wireless and the carriers are paying 100 percent of the cost of
the project, estimated at up to $200 million [MS: for around 280 stations], including the cost of NYC
Transit forces that provide flagging, protection and other support
services. The MTA and Transit Wireless evenly split the revenues from
occupancy fees paid by the wireless carriers and other sub-licensees of
the network. Transit Wireless is paying MTA a minimum annual
compensation that will grow to $3.3 million once the full build out of
the network is complete.

When dividing the $200 million by 280 base stations and potentially 4 network operators (leaving the Wi-Fi coverage that is also part of the project out of the equation for the moment) the cost of covering one station is about $180k per network operator. I can imagine that this is more than the costs of setting up a base station site above ground but it still seems to be a reasonable sum to me, especially when compared to the tens of thousands of people that pass through a station daily that generate traffic and revenue.

The post above then also describes some technical details of how coverage is distributed to the underground stations:

Wireless carriers […] co-locate their Base Stations with Transit Wireless’ Optical distribution equipment at a Transit Wireless Base Station Hotel, which is a resilient, fault-tolerant commercial facility with redundant air-conditioning and power.

[…] These Base Stations connect to Transit Wireless’ Radio Interface and Optical Distribution System in the Base Station Hotel. Radio signals are combined, converted to optical signals and distributed on Transit Wireless’ fiber optic cable through ducts under city streets to subway stations where the optical cables connect to multi-band Remote Fiber Nodes.

Remote Fiber Nodes are located on every platform, mezzanine and at various points within public access passageways. Coaxial cable is connected to each Remote Fiber Node and extends signals to strategically located antennas throughout each subway station. Utilizing this approach, low-level radio signals are evenly distributed providing seamless coverage from above ground to underground stations.

According to the article, the deployment includes free Wi-Fi as well which is good news for international travelers that are reluctant to use cellular data services due to high roaming charges.

Do you want to learn about VoLTE but you are not sure where to start? If so, here's a tip for you:

Learning how VoLTE works in a reasonable amount of time is not an easy task, there's just so many things to learn. Reading the 3GPP specifications to get up to speed as a first step is probably the last think one should do as there is just too much detail that confuses the uninitiated more than it helps. The get the very basics, my books probably serve the purpose. As they don't focus only on VoLTE however, that might be too little for people who want to focuson VoLTE. This is where Miikka's Poikselkä book on VoLTE comes in that he has written with others such as Harri Holma and Antti Toskala, who are also very well known in the wireless industry.

If you are involved in Voice over LTE, you have probably heard the name Miikka Poikselkä before. He must have been involved in IMS since the beginning as he's published a book on IMS already many years ago and he is also the maintainer of the GSMA specifications on VoLTE and other topics (e.g. GSMA IR.92). In other words, he's in the best position to give a picture of how VoLTE will look like in the real world vs. just a theoretical description.

I've spent a couple of quality time hours so far reading a number of different chapters of the book and found it very informative, learned quite a few new things and got a deeper understanding of how a number of things influence each other along the way. The topic of the book could have easily filled 500 pages but that would have looked a little overwhelming to many. But I am quite glad it wasn't that much and in my opinion the 240 pages of the book strike a very good balance between too much and too little detail.

The book is perhaps not for beginners as many concepts are only quickly introduced without going deeper, which, however, suited me just fine. In other words, you'll do fine if you have some prior knowledge in wireless networks. With my background I found the introduction chapters on deployment strategies and the VoLTE system architecture, that also dig down a bit to the general LTE network architecture to be just at the right level of detail for me to set things into context. This is then followed by the VoLTE functionality chapter that looks at radio access and core network functionalities required for VoLTE, IMS basics on fifty pages, IMS service provisioning on an equal level of detail and finally a short into to the MMTel (Multimedia Telephony) functionality. Afterward, there's a detailed discussion about VoLTE End-to-End signaling that describes IMS registration, voice call establishment and voice call continuity to a circuit switched bearer on 60 pages, again at the right level of detail for me. CS Fallback, although not really part of VoLTE is described as well. Other VoLTE topics discussed are emergency calls, messaging and radio performance.

In other words, a very good book the bring yourself up to speed on VoLTE if you have some prior experience in wireless and a good reference to refresh your memory later on. Very much recommended!