laforge.gnumonks.org/

Hi David,

On Wed, Jul 22, 2009 at 09:22:57AM -0700, David A. Burgess wrote:

One thing we plan do at Burning Man is run an auto-provisioning system via SMS, using the BTS itself as a SIM reader. When a handset first tries to register, we will accept the location updating attempt and then send a text message saying "If you want experimental service, please reply with your telephone number." The reply to the text message then goes into a function that creates a new entry in the provisioning database based on the originating IMSI and the content of the message. Then we will respond with something like "Thanks for joining our test. This is an experimental network. WE DO NOT SUPPORT EMERGENCY CALLS. To quit the test, reply to this message." In the US, at least, the part about emergency calls is really important.

I realize you don't have a lot of time left to get ready for HAR, though. This may or may not be a simple hack, depending on the state of your SMS software. But if it works, it will be a lot faster than provisioning phone by hand.

Yes, I was thinking about something similar, but more restrictive:

* let an unknown imsi perform location update * send a SMS that this is a test network, include IMSI plus some authentication token in the SMS * send a authentication request to the phone * reject the authentication irrespective of the response

This way the phone cannot stay on our network until somebody has gone to a web browser and entered imsi + auth code from that SMS. Still it's not foolproof, since anyone with airprobe could just get that imsi + auth code off the air and authenticate for somebody else :(

Oh, and of course, only do that entire procedure onec for every given IMSI, so next time the location update request is rejected without any SMS, unless the auth code has been entered on the web site.

I'm not sure if I can manage to implement this, but it would be the solution I would hope for. On the other hand, having to manually enter people keeps the number of users smaller and more controllable. If there's one volunteer who can take care of that, it should be fine.

Regards,

Hi Stefan,

On Wed, Jul 22, 2009 at 07:11:12PM +0200, Stefan Schmidt wrote:

On Wed, 2009-07-22 at 18:38, Harald Welte wrote:

...

I'm not sure if I can manage to implement this, but it would be the solution I would hope for. On the other hand, having to manually enter people keeps the number of users smaller and more controllable. If there's one volunteer who can take care of that, it should be fine.

Hmm, judging from the rush at the POC on other conferences/camps at the first day I would think we would need at least 3-4 people at the first day. Especially if you have in mind that it is a new "feature" of such an event and people may carry a GSM handset with them but no extra DECT. For the later days 1 or 2 people at the desk should be ok.

I think we should advertise/communicate the GSM network as a more experimental feature.

Even with two BTS at two TRX (exercising all our four ARFCN), the total call capacity is not more than 13 simultanesous MS-to-MS calls (since each call requires two timeslots). Yes we could do half-rate, but we have no software support for that so far.

Sure, we can take a different approach and just let everyone in and see how many segfaults of OpenBSC we can fix under that kind of load :)

But I think a 'slow start' would definitely help, where we don't allow too many people onto the network.

Of course we could also allow people to register their IMSI themselves on a web-based interface, but then have something like a global counter of currently attached MS in OpenBSC and then simply refuse further people on the network.

So a manual registration process has the following pro's: * the number of authorized ms on the network is limited * the number of authorized ms is growing at a slow speed * we have some personal interaction with the respective people and maybe can actually ask them to do a MO and MT call during registration, marking this handset model (IMEI) as 'known working' or file a bug report.

An automatic registration process obviously has the following pro's: * we can get virtually everyone onto the network * we do not need to spend time with registering people.

I'm a bit undecided, but think for HAR2009 we should probably go for a manual process first. Only after things have proven reliable in that scale, we can plan for something bigger next time (26C3). If everything works fine on the first day of HAR2009, then we could also switch from manual to the automatic process, at least if the software already exists.

If the process is still manual but the web-based UI already exists, we can also see if we can find some random HAR volunteers to do the actual registration procedure.

Regards.

Hi Stefan!

On Wed, Jul 22, 2009 at 06:32:28PM +0200, Stefan Schmidt wrote:

...

It would be great to know which other OpenBSC users/hackers will be present at the event. As there are multiple things that I'm planning to do at HAR2009, I would be happy about any help that I might get from you guys.

Daniel, Jan and me will also be there. We already have our cards so the problem with sold out cards did not catch us. I can only speak for myself, but I would bet Jan and Daniel are thinking along the same lines, we would be happy to help out.

Ok, great!

...

Basically there will be

• A 'stable' GSM network with BS-11 and OpenBSC for people to test their phone interoperability with OpenBSC by making/receiving calls and SMS.

Great. Covering the whole event with an official GSM network should give us a lot of fun. :)

well, I basically want to avoid the impression that this is a phone network for reliable use for everyone. The software will not run stable enough, and I suspect many interoperability reasons. Also, our capacity is too small for the number of people at the event.

"stable" means that this is not where we should test each and every of our committ's, but rather run something that we expect to behave as sane/stable as possible.

...

Especially for the 'stable' network, there is a lot of help required, among others:

• physical setup of the BS-11

When do you plan to do this? We haven't settled for final dates yet, but planned to be around from 12. - 17. Daniel and I should be able to be there earlier. I would think it would make sense to get the physical infrastructure in place before most of the people arrive. 10. - 11. for physical software setup sounds like a good idea to me. That should give us enough time to have it running stable from 12. to 16.

I don't really know yet. I'll ask the HAR guys how early we can start to put up our equipment.

What about tents, tables, chairs, etc? Is this something we get from the orga or should organise ourself? I may be able to arrange a big tent plus some tables and banks. Taking into account that I would need to ask and we have the transportation proplem I would prefer equipment already at the destination.

Don't count on any equipment being there for us. I'll bring my own personal tent (well, it is a tent intended for 5 people AFAIR), but that's it.

If we start to ask for support from HAR, I think this will in turn raise the expectations that we actually provide a stable operational service for them - something that I think we simply cannot provide yet.

...

• registration of mobile phones into the network. It would probably be good to have a setup where people can plug their SIM into a SIM card reader (or phone that can read the IMSI). We can then create the SQL entry with their IMSI and extension.

Maybe some pre-registration over a website which feeds the IMSI into the db and assigns a number? It would help to spread the load of register 3000 IMSIs during the event. :) On the other hand it would drain time now. Anyway, I volunteer to help out dealing with people at the event.

Hmm, another idea pops up into my mind right now. Any chance we can get a big bunch of pre paid SIMs without money on the account? If we would get some 100s of them we could prepare them in advance and just hand out to the people.

well, those SIM's would have to be sold, and that would mean dealing with cash, dealing with change, etc. - not very practical IMHO. Also, if we sell something, that again leads to the conclusion that people should get something in return.

It might also raise the wrong impression to the regulatory authority if we actually charge money for anything.

...

• making sure the network runs and OpenBSC / hfcmulti gets restarted in case something hangs.

Should be the job for the same people running the GOC (GSM Operating Center) ;)

heh. well, we can have a simple script that respawns the two (in the right order) if bsc_hack dies. We should have 'ulimit -c unlimited' and store all the core files for later debugging. Also, the pcap files have to be rotated away at every bsc_hack restart.

We also need to ensure that we save the bsc_hack binary that corresponds to the respective core versions. Maybe actually the entire corresponding source tree for gdb.

That would be a task for our pre-HAR TODO list (I'll start one soon).

I've seen on the wiki side that you will bring two BS-11 for the stable network. Do you think that are enough, or should Daniel bring his one as well. (Not that I could stop him putting _everything_ into the car for the event.)

Well, I think it is always good to have another unit, and if only as spare part in case one breaks or magicall disappears. Apart from that, it might also help for testing BS-11 specific code on something that is not the production network.

Regards.

Hello.

On Thu, 2009-07-23 at 18:47, Stefan Schmidt wrote:

Hmm, ok. Do you remember the tent we had at the last CCC camp? I may be able to get that one again. Also some tables and banks.

I reserved the tent plus 3 tables and banks from 11.8 - to 18.8 now. The tent is an SG30, means to cover an area of 30 square meter. Should we inform the HAR orga about the size and a preferred place?

regards Stefan Schmidt