Hi again, I'm currently in the train, so forgive me posting the initial TODO list to the mailing list rather than the wiki. I'll put it in the wiki soon. If you want to take on of the items, just let me know! What I think we have to do before HAR is as follows: == Actual code == === absolutely required === * finish and test the SMS implementation [Harald] * make sure we enable MS power control and impose a global limit of 100mW for the uplink (MS->BSC) direction by means of the MS POWER IE's and the BCCH information. That sounds like something for Dieter to figure out, especially since he has measurement equipment ;) * test dual-BTS-on-single-E1-card config [Harald] ** up to now, we have only tested with two nanoBTS, not BS-11 ! * test dual-TRX operation of BS-11 on OpenBSC [Stefan/Daniel, can you do that?] ** channel allocator can be tweaked to give 2nd TRX a preference for debugging [I'll add those to trac, since they are really important] === optional === * implement a 'provisioning mode' to OpenBSC that ** acccepts every new IMSI the first time we see it ** sends a SMS with a auth token to that mobile ** disconnects that mobile immediately * implement a web site / cgi script ** once user enters correct tuple of ISMI + auth code, we *** assign him a number (user cannot choose, we assign) *** set authorized=1 in the sql table * implement a web site bug tracker for user bug reports ** the should include detailed information about the phone model, his phone number and the exact timestamp, so we can match it in the pcap's * add more introspection code for the VTY interface to explore the run-time data structures in OpenBSC * implement different TCH assignment schemes (early / very early / OCASU) * do we really want a SDCCH/8 or is SDCCH/4 for each BTS sufficient? * some more testing with two BTS * in case we call a user who is currently offline/busy, generate SMS about missed call and store it in the SMS table * web interface ideas ** SMS gateway where people can send SMS from the web site *** SMS spam function for us in case we want to inform users about something ** simplistic phone book * enhance vty interface with administrative functions such as ** ability to close arbitrary channels (i.e. terminate a call) ** ability to kick-ban a user out of the network *** set authorized=0 *** perform authentication procedure with reject at its end * make sure we store all the 'this phone was registerd before to MCC/MNC/LAC' from the LOC UPD REQ data * make sure we really store the classmark1/2/3 together with IMEI in SQL table == Things to bring to the event == * spectrum analyzer [from CCCB] * stable OCXO reference to calibrate BS-11 internal clock ** this could be done before the event, but Harald has no precision clock source * trace mobiles / monitor mode mobiles (if anyone has some) * some poles to which we can mount the BS-11 ? == Misc == * draft 'usage terms & conditions' to be put on the registration web site and the HAR2009 wiki, indicating ** all signalling and traffic data will be stored for R&D purpose ** we do not employ authentication and/or encryption ** we do not provide any service guarantee ** this is for evaluation+testing only ** no handover/roaming and/or external calls ** no warranty for any damage to MS, SIM, ... ** IMSI/IMEI information will not be disclosed by us, but people can sniff it Regards, -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)