Dear All,
as you will know, we have applied for an experimental GSM license for the 26C3 (http://events.ccc.de/congress/2009/).
Last week, the license was granted. However, only two ARFCN's have been granted (I applied for 8). As it turns out, this was a communication problem.
Today they have acknowledged a third ARFCN. So we can have at least one single-TRX BTS on each floor. On wednesday they will determine whether we can have more than three, or if we'll have to live with three ARFCN only.
If we get 6, it will be one dual-TRX BTS for each floor. If we get even more, the surplus ones can be used for random experiments.
TODO items before 26C3 (for the next couple of days): * finish handover implementation (critical) * do some more testing with LCR integration (Andreas did it, but I also want to have more hands-on experience with it) * introduce log levels and/or per-subscriber tracing functionality to "see the signal among all the noise" while debugging problems in an otherwise busy network * ensure SMS implementation is more robust than at HAR * log all measurement reports to database for later analysis of handover performance. We could also get them from pcap files, so not strictly neccessary.
Optional: * finish AMR-halfrate implementation, as this will increase our capacity. This includes dynamically selecting the codec that is used for each call. I don't think we'll manage finishing this, especially with the LCR integration. Standalone might be possible - but that is useless for 26C3
Hi,
TODO items before 26C3 (for the next couple of days):
- finish handover implementation (critical)
- do some more testing with LCR integration (Andreas did it, but I also
want to have more hands-on experience with it)
- introduce log levels and/or per-subscriber tracing functionality to
"see the signal among all the noise" while debugging problems in an otherwise busy network
- ensure SMS implementation is more robust than at HAR
- log all measurement reports to database for later analysis of handover
performance. We could also get them from pcap files, so not strictly neccessary.
Optional:
- finish AMR-halfrate implementation, as this will increase our capacity.
This includes dynamically selecting the codec that is used for each call. I don't think we'll manage finishing this, especially with the LCR integration. Standalone might be possible - but that is useless for 26C3
Are you planning on finishing up all those points by yourself or could you use some help on some of theses ? (It wouldn't be very efficient to have several people working on the very same feature independently).
I'll be in vacation in a few days till 26c3 and I was planning on working more seriously on GSM projects.
I can definitely do some handhover testing once it's implemented. I was also planning on finishing my chan_openbsc for asterisk, the RRLP work I started and have a look at encryption but if some other things would be more useful, I can take a crack at them.
Cheers,
Sylvain
On Mon, Dec 14, 2009 at 11:18:16PM +0100, Sylvain Munaut wrote:
Hi,
TODO items before 26C3 (for the next couple of days):
- finish handover implementation (critical)
- do some more testing with LCR integration (Andreas did it, but I also
want to have more hands-on experience with it)
- introduce log levels and/or per-subscriber tracing functionality to
"see the signal among all the noise" while debugging problems in an otherwise busy network
- ensure SMS implementation is more robust than at HAR
- log all measurement reports to database for later analysis of handover
performance. We could also get them from pcap files, so not strictly neccessary.
Optional:
- finish AMR-halfrate implementation, as this will increase our capacity.
This includes dynamically selecting the codec that is used for each call. I don't think we'll manage finishing this, especially with the LCR integration. Standalone might be possible - but that is useless for 26C3
Are you planning on finishing up all those points by yourself or could you use some help on some of theses ? (It wouldn't be very efficient to have several people working on the very same feature independently).
well, as it seems zecke is already doing a lot of work with regard to logging/tracing. Not sure if he can finish that all by himself. If yes, it would be great to simply use his work.
If you are interested, you could work on the SMS implementation. Somehow we have a number of known bugs: * inconsistent/incompatible/incorrect handling of transaction ID's * interleaved 04.11 CP-DATA transfers if a phone sends a multi-part message or multiple SMS at the same time. If you do this right now, we will use one full cycle of channel request -> immediate assignment -> establish indication -> cm service request -> cm service ack and then the full CP and RP transfers for each part of the message. However, the phones use the MMS (more messages to send) and overlapped / interleaved CP-DATA transfers in order to do all of this in one go, in one RR connection. We need to support this.
I think the handover I'll have to do by myself, and theoretically it should all be finished in my codebase, will spend the full day today testing and finishing it.
Regards, Harald
Hi,
If you are interested, you could work on the SMS implementation. Somehow
we have a number of known bugs:
- inconsistent/incompatible/incorrect handling of transaction ID's
- interleaved 04.11 CP-DATA transfers if a phone sends a multi-part
message or multiple SMS at the same time. If you do this right now, we will use one full cycle of channel request -> immediate assignment -> establish indication -> cm service request -> cm service ack and then the full CP and RP transfers for each part of the message. However, the phones use the MMS (more messages to send) and overlapped / interleaved CP-DATA transfers in order to do all of this in one go, in one RR connection. We need to support this.
Ok, after sending a couple of big messages I see what you mean. I don't get multiple RR connections but I get multiple CM service requests one after another in a single RR connection.
Looking into it ...
Sylvain
On Monday 14 December 2009 17:39:04 Harald Welte wrote:
- introduce log levels and/or per-subscriber tracing functionality to "see the signal among all the noise" while debugging problems in an
otherwise busy network
please see the debug branch. it has the capability of logging everything to a vty. I could easily implement a hardcode filter for subscriber imsi/tmsi and will ping you once I did it (I try to do it today).
z.
On Tuesday 15 December 2009 04:40:29 Holger Freyther wrote:
On Monday 14 December 2009 17:39:04 Harald Welte wrote:
- introduce log levels and/or per-subscriber tracing functionality to "see the signal among all the noise" while debugging problems in an
otherwise busy network
please see the debug branch. it has the capability of logging everything to a vty. I could easily implement a hardcode filter for subscriber imsi/tmsi and will ping you once I did it (I try to do it today).
I have pushed two more changes to the holger/new-debug-arch branch. Now in vty it is possible to do:
tamarin> logging enable tamarin> logging filter imsi IMSI tamarin> logging filter all 1 (to output every message via VTY)
I will have to test with my GSM network once I have setup everything again.. I'm plagued by a cold or such... slowing me a bit down.
z.
Hi Harald,
On Mon, Dec 14, 2009 at 19:39, Harald Welte laforge@gnumonks.org wrote:
as you will know, we have applied for an experimental GSM license for the 26C3 (http://events.ccc.de/congress/2009/).
Last week, the license was granted. However, only two ARFCN's have been granted (I applied for 8). As it turns out, this was a communication problem.
Today they have acknowledged a third ARFCN. So we can have at least one single-TRX BTS on each floor. On wednesday they will determine whether we can have more than three, or if we'll have to live with three ARFCN only.
If we get 6, it will be one dual-TRX BTS for each floor. If we get even more, the surplus ones can be used for random experiments.
Does it means that we won't be able to do OpenBTS experiments there? We planned to test new USSD code in OpenBTS and it will be a shame to cancel this plans.
On Tue, Dec 15, 2009 at 11:53:38PM +0300, Alexander Chemeris wrote:
Hi Harald,
On Mon, Dec 14, 2009 at 19:39, Harald Welte laforge@gnumonks.org wrote:
as you will know, we have applied for an experimental GSM license for the 26C3 (http://events.ccc.de/congress/2009/).
Last week, the license was granted. However, only two ARFCN's have been granted (I applied for 8). As it turns out, this was a communication problem.
Today they have acknowledged a third ARFCN. So we can have at least one single-TRX BTS on each floor. On wednesday they will determine whether we can have more than three, or if we'll have to live with three ARFCN only.
If we get 6, it will be one dual-TRX BTS for each floor. If we get even more, the surplus ones can be used for random experiments.
Does it means that we won't be able to do OpenBTS experiments there? We planned to test new USSD code in OpenBTS and it will be a shame to cancel this plans.
Dear Alexander,
I do not remember having seen any specific request from you applying for an ARFCN for OpenBTS experiments. Like in any country of the world, you need a test license in Germany to operate equipment in the GSM band. If you did and I missed that, I apologize.
As you can see from my e-mail, we likely don't even have enough ARFCNs for operating the actual GSM network at 26C3 - not to talk about runing any more experimental stuff for doing actual development.
The priorities for me have been very clear: First the actual GSM network, then any experiments.
Hi Harald,
On Wed, Dec 16, 2009 at 02:14, Harald Welte laforge@gnumonks.org wrote:
I do not remember having seen any specific request from you applying for an ARFCN for OpenBTS experiments. Like in any country of the world, you need a test license in Germany to operate equipment in the GSM band. If you did and I missed that, I apologize.
Sorry, I was not clear enough. I wrote that we want to have OpenBTS working and assumed that you include that in your ARFCN request.That's my bad, I should have been more clear.
I wouldn't tell for the whole world. ;) Someone wrote, that in Holland (IIRC) you can run low-power GSM in low part of 1800 without any restrictions. And in many countries no one just care if you run something low-power in clear ARFCN.
As you can see from my e-mail, we likely don't even have enough ARFCNs for operating the actual GSM network at 26C3 - not to talk about runing any more experimental stuff for doing actual development.
The priorities for me have been very clear: First the actual GSM network, then any experiments.
That's clear.
Hi all,
one more update:
On Mon, Dec 14, 2009 at 05:39:04PM +0100, Harald Welte wrote:
as you will know, we have applied for an experimental GSM license for the 26C3 (http://events.ccc.de/congress/2009/).
Last week, the license was granted. However, only two ARFCN's have been granted (I applied for 8). As it turns out, this was a communication problem.
Today they have acknowledged a third ARFCN. So we can have at least one single-TRX BTS on each floor. On wednesday they will determine whether we can have more than three, or if we'll have to live with three ARFCN only.
Today they have acknowledged a total of 5 ARFCN's in GSM1800 for the 26C3. All of them are for indoor use only, with 200mW maximum transmit power.
Regards, Harald
-
Alexander Chemeris -
Harald Welte -
Holger Freyther -
Sylvain Munaut