Update on the GSM network at the CCC Camp 2011
During the past weeks, I've been trying very hard to get to a technical
solution for the setup regarding the private GSM network that we intend
to operate at the CCC Camp
2011. Unfortunately, despite puting in way too much time that I
don't have, no really good solution appeared. There were times when I
was wondering if it would happen at all - mainly due to the lack of
properly integrated / tested RF related issues like PA, LNA, duplexer,
But it seems just in time Dieter came to the rescue. So now we have
pretty much figured out the equipment and settled on a configuration.
We'll have 2 Nokia Metrosite BTS with a total of 5 TRX, each running at
5W using borrowed equipment.
During the next 10 days, all the parts like antennas, cabling, plugs,
adapters and the BTS units themselves should arrive at my place. Let's
hope there are no serious fuck-ups that cause something to not arrive
So all in all, there's a 99% chance we will have a functional GSM
network. The Nokia A-bis support in OpenBSC will be brand new, so there
might be some glitches here and there. But then, that's part of the
fun. I'm already very curious to see what kind of coverage we get. I
guess if we do things right, it should reach well into Finowfurt itself,
and not just barely cover the camp grounds like we had at HAR 2009.
US government closing data centers and give up their independence
Sometimes I really think I must be dreaming. Who in their right mind
would propose something like closing
something like 800 government-owned data centers and outsourcing all the
data to the cloud?
As a government, you
- make yourself dependent from a private company to supply essential
- introduce single points of failure (technically, administratively)
previously, you had 800 data centers, maybe each of them not as reliable
as the advertisements of the cloud provider - but it is unlikely that
all of them go down at the same time
- give up control over who physically owns and has access to the data
In fact, you will have a hard time even finding anyone at all who can
tell you where your data is physically located. Maybe even out of the
Now you can argue that all those things can be put down in contracts as
service level agreements (SLAs). That's true, but as we say around
here: Paper is patient, meaning no paper is going to help you
after data has been copied or was lost, and if you suddenly fail to
provide basic services of the public administration.
The distributed nature of self-hosting your data and applications has
key advantages in terms of security and reliability. Why would somebody
give that up without a broad discussion? And we're not talking about
some private company where nobody but their shareholders care if they
loose data or go out of business. We're talking about the public
People seem to have lost perspective on the overall advantages of a
heterogeneous, distributed setup.
On the recent THC release on the Vodafone femtocell
I am mainly posting this to prevent any more people mailing me about
this release. There's nothing really spectacular here.
Starting from 2009 on, the usual suspects (aka OpenBSC developers) have
been looking at various 3G femtocells, including the Vodafone one (I
have 10 of them here). Aside from that Alcatel-Lucent design that
Vodafone uses, we've also looked at the Cisco/AT+T/ip.access design, as
well as the Ubiquisys/SFR one. With some effort you can root all of
them, and you can then make sure they don't connect to the respective
operator but to an IP address of your choosing.
The protocols are vendor-dependent. The Vodafone femtocell uses a
version of RANAP (the protocol between RNC and MSC in UMTS) behind an 8
byte proprietary header. As RANAP is specified in the 3GPP, it was
pretty easy to build a small piece of code that interacts with the unit.
Ubiquisys (used by SFR) uses the UMA protocols, and the
Cisco/ip.access/AT+T design uses a proprietary ip.access protocol called
URSL (sort-of a "progression" of the 2G RSL to UMTS).
Supporting them from OpenBSC is not easy. While the call control and
SMS transfer protocols of 3G are identical to GSM, everything below
doesn't really bear much resemblance. I would guess it would take at
least a man-month to get basic signalling, call + SMS support working,
if not more.
Given the fact that the femtocells all speak their vendor-proprietary
dialects, and given that they often come with license terms that
only permit the use of their firmware in combination with their gateway
located at the operator network, we never thought it is a high priority
item for us to work on.
What you also have to consider, is that their output power of 20dBm is
even less than the 200mW of typical small-scale GSM BTS, and that they
typically only support the operation of 4 concurrent phones. Nothing
that you would be able to run e.g. a conference telephony network on.
Furthermore, due to the wide channels (5MHz), it is very likely that all
available sprectrum has been auctioned off/licensed to commercial
operators, so it's almost impossible to get something like a test
license. In GSM with 200kHz channels, there's often still a guard band
or some unallocated channel that can be used.
If you really want to have some free software + femtocell based 3G
network, go ahead and do it. The option existed for years now, ever
since femtocells started shipping to the market. All of them are some
form of embedded Linux systems. Rooting them isn't really different
from rooting a Linux based WiFi router / DSL modem. So what's that
new about the THC release? That a vendor of Linux embedded devices
chose a trivial password? If you're surprised by that, I guess you
haven't taken apart many embedded devices then.
SIM-unlocking the Openmoko phones?
I think it's quite funny that SIM-unlicking vendors like RebelSIM
actually advertise that their products are compatible with Openmoko,
as you can see
in this PDF file.
What's funny about this? Well, Openmoko phones have never been sold
with any form of SIM or Operator locking. The entire idea was to have a
phone that is under the control of the user, not the operator...
SIMtrace v1.0 prototypes are working out of the box
After the debacle with various wrong footprints in the v0.9,
I'm very happy to announce that the SIMtrace v1.0 hardware is working
fine. All footprints correct, schematics correct, layout/Gerber
correct. All we had to do is solder the components, attach it to USB,
flash the firmware and use it.
Here's a picture of the board (sorry, my soldering is not very clean):
Early next week we will be ordering a batch of 100 units from the SMT
house we have chosen.