Plans for GSM / OpenBSC field test at 27C3

[Harald Welte]

Hi all!

As some of you know, we will again have an OpenBSC field test at the
Chaos Communication Congress from December 27-30 in Berlin / Germany.

I have already applied for the license from the regulatory authority. No
feedback yet, but I expect no problems, as it is more or less what we
had last year.  The only difference is that I've asked for 6 ARFCN (5 last
year).

It will again be a nanoBTS / GSM 1800 setup.

Regarding the overall setup, I want to deviate from what we had last year
in the following way:

1) Issue our own SIM cards to permit Authentication + Encryption.  This is
   the perfect way how we can have a A5/1 based network that people can use
   to play with airprobe + Kraken - without violating any laws.

   In practise, this will mean we use 16in1 SIM cards, I have already bought
   1000 of them.  It also means that the GSM helpdesk will have to issue those
   SIMC cards.  I would suggest we simply sell them (as opposed to providing
   them for a deposit, as we then would have to take back a lot of cards and
   return money, which is a lot of overhead).

   We will keep a database of all the IMSI + Ki tuples that we have issued,
   which we will use as HLR + AuC.   This database will be persistent, i.e.
   at other events like the CCC camp 2011 or 28C3 we expect those SIM cards
   to be used again without any registration.

2) Provide GPRS + EDGE services using OsmoSGSN and OpenGGSN.  I am not sure
   how stable this will run - but we have a good chacne of catching bugs in
   our code by running at the event.  We will be able to provide real-world
   IP addresses to every mobile phone, without filter and without NAT !

   I am not yet sure how we will deal with dividing the timeslots between
   GSM and GPRS.  The dynamic TCH / PDCH code in OpenBSC hasn't ever been
   tested, so we might use a static configuration - potentially changing
   that static config depending on the usage pattern / load we see.

3) Make dual-TRX setups standard (3 BTS with 2TRX each)

   This is simply to enhance the capacity, particularly of SDCCH/8 resources

4) Consider putting all BTS in the same location area

   This will significantly reduce our need for signalling channels, but at
   the expense we no longer know where a particular phone is located in the
   building.  Thus, we might make this optional and see if it is needed for
   load reasons.

5) Improve the SMS situation

   The current SMS code still sucks really bad.  We don't want this inside
   OpenBSC, and we still don't do timer-based / automatic delivery.  Using
   the manual 'sms send pending' command causes severe blockage if the queue
   is getting too large.  I will try to squeeze in some time to rewrite this
   code and make it run as external process.

6) User registration

   So we sell SIM cards with a pre-programmed IMSI + Ki, but how do we
   enable users to assign a phone number to them?  Ideally I would want
   them to simply register a phone number at the eventphone.de GURU
   web interface ahead of the event.  But how do we match the IMSI and
   the phone number?  Ask users to simply state the phone number they
   registered?  How do we get some kind of authentication?

Comments and additions are most welcome,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20101026/d28e50e7/attachment.bin>