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,
On Thu, Jul 23, 2009 at 12:26:14AM +0200, Harald Welte wrote:
Hi again,
I'm currently in the train, so forgive me posting the initial TODO list to the mailing list rather than the wiki.
this is now at http://bs11-abis.gnumonks.org/trac/wiki/HAR2009
Hi,
On Thu, 23 Jul 2009 00:26:14 +0200 Harald Welte laforge@gnumonks.org wrote:
=== absolutely required ===
- 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
yeah, I can test that. What do you want me to do exactly? See if I can register to OpenBSC via both TRX?
Regards, Daniel Willmann
On Thu, Jul 23, 2009 at 12:26:14AM +0200, Harald Welte wrote:
- test dual-TRX operation of BS-11 on OpenBSC [Stefan/Daniel, can you do that?]
Since I didn't proceed much on the Multidrop issue yesterday, I spent a bit of time investigating this. I have fixed two minor bugs in bsc_hack regarding the setup of TRX1, but now both TRX become live.
I've also twisted the channel allocator to first use+exhaust TRX1 before going to TRX0 timeslots. What's weird is that the first allocated channel (TRX1/TS0) is not useable, with the following behaviour:
* we see a channel request on the RACH * we assign TRX1/TS0 on the AGCH * we activate the channel on the BTS * we see the CM Service request from the MS on the TRX1/TS0 * we send the CM Service Ack from the BTS to the MS on TRX1/TS0 * after some time, T200 of the Um interface expires and the phone gives up.
So it seems the CM Service ACK is never received by the phone.
I have verified the TRX1/TS0 channel configuration is TCH/Full in LMT I have verified the CM Service ACK is transmitted to the correct GSM channel by usign the MA-10 protocol analyzer.
This is really weird.
For Timeslot 1 and higher, everything is working fine.
I've reviewed the relevant code sections, and there is no special treetment of TS0 on any TRX that is != C0. (trx0).
Any ideas?
Hi, some more status updates:
On Thu, Jul 23, 2009 at 12:26:14AM +0200, Harald Welte wrote:
- 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 ;)
Status update: I have now hard-coded a MS power limit of 20dBm (100mW) for all activated channels. The BS-11 still doesn't use dynamic MS power control yet, but that is optional anyway. At least we're sure the MS now get told to use no more than 100mW to talk to the BTS.
- stable OCXO reference to calibrate BS-11 internal clock
** this could be done before the event, but Harald has no precision clock source
Dexter was here yesterday, and with his help (and his HFC-S card) we successfully re-calibrated two BS-11.
Using the nanoBTS frequency offset test, we can see the relative frequency offset (in parts-per-billion!) of all BCCH in the vicinity. With this test it was easy to observe how the carrier frequency delta of the BS-11 became smaller and smaller and finally was in the same range than the commercial GSM network BTS's.
-
Daniel Willmann -
Harald Welte