Hello Eric, On Thu, 23 Jul 2009 11:35:33 +0200, "Eric Cathelinaud" <e.cathelinaud@googlemail.com> wrote:
I would like to ask another question. I can see on which time slot the burst is sent but i can't see the frame and the multiframe number. Is it available somewhere?
Not in the Abis communication, its the BTS which cares about frames but not the BSC. For the nanoBTS it is most certainly possible to get debug traces from the debug port (but probably not on Abis) which contain the frame number, but I am not aware that the same is possible for the BS-11. If you are interested in this low-level Layer 1 stuff, you might have a look at OpenBTS, you can adjust nearly everything or trace at a really low level. Best regards, Dieter -- Dieter Spaar, Germany spaar@mirider.augusta.de
Oh nice thanks for the information Best regards Eric Cathelinaud 2009/7/23 Dieter Spaar <spaar@mirider.augusta.de>
Hello Eric,
On Thu, 23 Jul 2009 11:35:33 +0200, "Eric Cathelinaud" < e.cathelinaud@googlemail.com> wrote:
I would like to ask another question. I can see on which time slot the
burst
is sent but i can't see the frame and the multiframe number. Is it available somewhere?
Not in the Abis communication, its the BTS which cares about frames but not the BSC. For the nanoBTS it is most certainly possible to get debug traces from the debug port (but probably not on Abis) which contain the frame number, but I am not aware that the same is possible for the BS-11.
If you are interested in this low-level Layer 1 stuff, you might have a look at OpenBTS, you can adjust nearly everything or trace at a really low level.
Best regards, Dieter -- Dieter Spaar, Germany spaar@mirider.augusta.de
Hi, I saw something wierd using misdn_log to see the Abis communication : even if i don't call or send SMS I can see a periodic paging and a periodic RACH answer. The period of the paging is 2.6 seconds. The RACH appears 16 or 17 ms after the paging. In attached file the capture (open with wireshark) : 1. a call Mobile1(Nokia6310i)-->2(Ericsson) 2. a SMS Mobile 1-->2 3. a call Mobile 2-->1 4. a SMS Mobile 2-->1 Between these 4 operations we can see lot of paging and RACH with no interruption. Does anyone understand this? Btw the SMS doesn't work for me. It is transmitted towards the BTS but not fowarded from the BTS to the 2nd mobile. Eric Cathelinaud 2009/7/23 Eric Cathelinaud <e.cathelinaud@googlemail.com>
Oh nice thanks for the information
Best regards Eric Cathelinaud
2009/7/23 Dieter Spaar <spaar@mirider.augusta.de>
Hello Eric,
On Thu, 23 Jul 2009 11:35:33 +0200, "Eric Cathelinaud" < e.cathelinaud@googlemail.com> wrote:
I would like to ask another question. I can see on which time slot the
burst
is sent but i can't see the frame and the multiframe number. Is it available somewhere?
Not in the Abis communication, its the BTS which cares about frames but not the BSC. For the nanoBTS it is most certainly possible to get debug traces from the debug port (but probably not on Abis) which contain the frame number, but I am not aware that the same is possible for the BS-11.
If you are interested in this low-level Layer 1 stuff, you might have a look at OpenBTS, you can adjust nearly everything or trace at a really low level.
Best regards, Dieter -- Dieter Spaar, Germany spaar@mirider.augusta.de
On Fri, Jul 24, 2009 at 05:26:31PM +0200, Eric Cathelinaud wrote:
I saw something wierd using misdn_log to see the Abis communication : even if i don't call or send SMS I can see a periodic paging and a periodic RACH answer.
Does anyone understand this?
you are seeing those paging commands only on the A-bis interface but not on the log output of OpenBSC?
Btw the SMS doesn't work for me. It is transmitted towards the BTS but not fowarded from the BTS to the 2nd mobile.
No surprise here. the latter code is not implemented yet ;) Working on it. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
I saw something wierd using misdn_log to see the Abis communication : even if i don't call or send SMS I can see a periodic paging and a periodic RACH answer.
Does anyone understand this?
you are seeing those paging commands only on the A-bis interface but not on the log output of OpenBSC?
Well I didn't use the log of OpenBSC in the same time but normally there is no periodic paging like this with the log of OpenBSC. I will try it again tomorrow and compare with the log of OpenBSC.
Btw the SMS doesn't work for me. It is transmitted towards the BTS but not fowarded from the BTS to the 2nd mobile.
No surprise here. the latter code is not implemented yet ;) Working on it.
oh ok ;)
Eric Cathelinaud
well I didn't pay attention to this for the log of OpenBSC but it's the same yes. I still don't understand what are these 2 packets. Could it be the information for paging loaded each 2,5 seconds in only one packet? I mean : even if we have no paging request these packets should be sent? And every RACH information regrouped in one packet is also transmitted towards the BSC periodically? Thanks Eric Cathelinaud 2009/7/26 Eric Cathelinaud <e.cathelinaud@googlemail.com>
I saw something wierd using misdn_log to see the Abis communication : even
if i don't call or send SMS I can see a periodic paging and a periodic RACH answer.
Does anyone understand this?
you are seeing those paging commands only on the A-bis interface but not on the log output of OpenBSC?
Well I didn't use the log of OpenBSC in the same time but normally there is no periodic paging like this with the log of OpenBSC. I will try it again tomorrow and compare with the log of OpenBSC.
Btw the SMS doesn't work for me. It is transmitted towards the BTS but not fowarded from the BTS to the 2nd mobile.
No surprise here. the latter code is not implemented yet ;) Working on it.
oh ok ;)
Eric Cathelinaud
Hi, I still have one question about the log. We can see only messages going from BTS to BSC but not the ones in the other way. Why? This is the case with the log from mISDN tool and I think it's almost the same with bsc_hack option but I need to check (I think with bsc_hack option there are some messages in the other way too but a lot of them are missing like during a call procedure for example). Eric Cathelinaud
On Tue, Jul 28, 2009 at 12:34:59AM +0200, Eric Cathelinaud wrote:
Hi,
I still have one question about the log. We can see only messages going from BTS to BSC but not the ones in the other way. Why?
I would give you answers if I had them. As I indicated before on this list, I'm almost constantly travelling and rarely have access to a BS-11, so I cannot test/verify any of your findings. I did some casual checking of misdn_log last time, and it _seemed_ to work fine. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hello, I give you a screenshot in attached file. May be Andreas know why. This screenshot shows a terminated call procedure. We should have : BTS --> BSC : CHANNEL REQUIRED BSC --> BTS : CHANNEL ACTIVATION BTS --> BSC : CHANNEL ACTIVATION ACK BSC --> BTS : IMMEDIATE ASSIGNMENT COMMAND and so on And on the misdn log we only have : BTS --> BSC : CHANNEL REQUIRED BTS --> BSC : CHANNEL ACTIVATION ACK and so on I can't see any message from BSC to BTS. But I can see : "S, func=RR, N(R)=23" from LAPD format I didn't find what it is exactly. Thanks Eric Cathelinaud 2009/7/28 Harald Welte <laforge@gnumonks.org>
On Tue, Jul 28, 2009 at 12:34:59AM +0200, Eric Cathelinaud wrote:
Hi,
I still have one question about the log. We can see only messages going from BTS to BSC but not the ones in the other way. Why?
I would give you answers if I had them. As I indicated before on this list, I'm almost constantly travelling and rarely have access to a BS-11, so I cannot test/verify any of your findings. I did some casual checking of misdn_log last time, and it _seemed_ to work fine. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
participants (3)
-
Dieter Spaar -
Eric Cathelinaud -
Harald Welte