About sniff multi bursts in a frame, CCCH_CONF

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

About sniff multi bursts in a frame, CCCH_CONF

Aegean Chou
Dear all,

        the bts arround me uses MultiCCCH, it's CCCH_CONF = 110 (6), so it uses TS0, TS2, TS4 and TS6 in a frame for PCH/AGCH.
        but the burst_ind only CCCH-CONF 0 & 1 are supported, it can sniff TS0 only, so only catch 1/4 IMM ASS for me.
        my OWN phone, it's just not in TS0 (i use nokia netmonitor to check it), so i can't catch it at all (phones use IMSI to decide page group).

        i read the source briefly, and modify prim_rx_nb.c line "l1s_rx_win_ctrl(arfcn, L1_RXWIN_NB, 0);" for TS2, TS4, TS6 temporarily,
        but this way i'll need 4 phones to catch ONE station. it's very strange, and not beauty.

        i think the bottleneck is the DSP, as the DSP task (ALLC_DSP_TASK) can only process one TS of a frame (it's enough for phone),
        i think maybe backup/restore the DSP task variable patch needed, i'm new to the DSP disassemble and patch, anyone can help? thanks

Best Regards
Steve

Reply | Threaded
Open this post in threaded view
|

Re: About sniff multi bursts in a frame, CCCH_CONF

Sylvain Munaut
>        the bts arround me uses MultiCCCH, it's CCCH_CONF = 110 (6), so it uses TS0, TS2, TS4 and TS6 in a frame for PCH/AGCH.

Mmm ,interesting, I had never seen that option being used before. What
network is this.

>        but the burst_ind only CCCH-CONF 0 & 1 are supported, it can sniff TS0 only, so only catch 1/4 IMM ASS for me.
>        my OWN phone, it's just not in TS0 (i use nokia netmonitor to check it), so i can't catch it at all (phones use IMSI to decide page group).

Well, it's your own phone (or any known target phone), you know the
IMSI, hence the paging group ...


>        i think the bottleneck is the DSP, as the DSP task (ALLC_DSP_TASK) can only process one TS of a frame (it's enough for phone),
>        i think maybe backup/restore the DSP task variable patch needed, i'm new to the DSP disassemble and patch, anyone can help? thanks

That's gonna be _very_ hard, the DSP uses _plenty_ of global variables ...

But OTOH, instead of using the normal 'RX task', you can use the sniff
task to listen to the CCCH. The sniff task will _not_ do the channel
decoding (i.e. you'll have to call xcch_decode to get the actual 23
bytes L2 frame), but it can sniff up to 4 bursts in a frame. just look
at how sdcch sniffing is done, it currently sniff 2 timeslot 0 & 3 (to
get DL & UL).

This way you won't need any hard DSP patching, just a minor patch on
the firmware to convert CCCH listening to burst_ind (leave the BCCH
task as-it is, just mod the CCCH). And then a patch in the host app to
call xcch_decode appropriately and feed the results 'as if' it cames
from the phone directly.

Cheers,

    Sylvain

Reply | Threaded
Open this post in threaded view
|

Re: Re: About sniff multi bursts in a frame, CCCH_CONF

Aegean Chou
In reply to this post by Aegean Chou
Hi, Sylvain Munaut

        It's china mobile, i can provide more information if you need.
        Thanks for pointing out the right way, i'll try to modify codes according to BCCH'.

        BTW, i modify TS (line l1s_rx_win_ctrl _ONLY_) from 0 to 2, 4 and 6, the TS2 and TS4 work well, but the TS6 crash very soon because FCCH error,
        for example, what's wrong? (high TS -> low TS)?

THIS FIRMWARE WAS COMPILED WITHOUT TX SUPPORT!!!
Assert DSP into Reset
Releasing DSP from Reset
Installing DSP sniff patch
Setting some dsp_api.ndb values
Setting API NDB parameters
DSP Download Status: 0x0001
DSP API Version: 0x0000 0x0000
Finishing download phase
DSP Download Status: 0x0002
DSP API Version: 0x3606 0x0000
LOST 1831!
L1CTL_FBSB_REQ (arfcn=70, flags=0x7)
Starting FCCH RecognitionFB0 (11:6): TOA= 7200, Power= -69dBm, Angle= 3691Hz
FB1 (21:8): TOA= 9651, Power= -69dBm, Angle=  103Hz
  fn_offset=20 (fn=21 + attempt=8 + ntdma = 7)
  delay=9 (fn_offset=20 + 11 - fn=21 - 1
  scheduling next FB/SB detection task with delay 9
=>FB @ FNR 20 fn_offset=20 qbits=3420
Synchronize_TDMA
LOST 3186!
SB1 (46:1): TOA=   29, Power= -69dBm, Angle=  217Hz
=> SB 0x00c12184: BSIC=33 fn=89118(67/16/21) qbits=24
Synchronize_TDMA
=>FB @ FNR 45 fn_offset=89118 qbits=4932
LOST 1912!
TOA AVG is not 16 qbits, correcting (got 20)
L1CTL_DM_EST_REQ (arfcn=4866, chan_nr=0x41, tsc=1)
LOST 2110!
L1CTL_DM_REL_REQL1CTL_FBSB_REQ (arfcn=70, flags=0x7)
Starting FCCH RecognitionLOST 3515!
FB0 (91861:3): TOA= 2544, Power= -67dBm, Angle= 3754Hz
FB1 (91871:8): TOA= 8751, Power= -67dBm, Angle=   40Hz
  fn_offset=91869 (fn=91871 + attempt=8 + ntdma = 6)
  delay=8 (fn_offset=91869 + 11 - fn=91871 - 1
  scheduling next FB/SB detection task with delay 8
=>FB @ FNR 91869 fn_offset=91869 qbits=4820
Synchronize_TDMA
LOST 3711!
SB1 (183745:1): TOA=   29, Power= -67dBm, Angle=  160Hz
=> SB 0x01e12284: BSIC=33 fn=91882(69/24/31) qbits=24
Synchronize_TDMA
=>FB @ FNR 183744 fn_offset=91882 qbits=4932
LOST 1912!
L1CTL_DM_EST_REQ (arfcn=4866, chan_nr=0x69, tsc=1)
LOST 2109!
L1CTL_DM_REL_REQL1CTL_FBSB_REQ (arfcn=70, flags=0x7)
Starting FCCH RecognitionLOST 3516!
FB0 (92514:8): TOA= 8784, Power= -67dBm, Angle= 3696Hz
FB1 (92524:8): TOA= 8755, Power= -67dBm, Angle=   69Hz
  fn_offset=92522 (fn=92524 + attempt=8 + ntdma = 6)
  delay=8 (fn_offset=92522 + 11 - fn=92524 - 1
  scheduling next FB/SB detection task with delay 8
=>FB @ FNR 92522 fn_offset=92522 qbits=4836
Synchronize_TDMA
LOST 3717!
SB1 (185051:1): TOA=   27, Power= -66dBm, Angle=   47Hz
=> SB 0x00852284: BSIC=33 fn=92535(69/ 1/21) qbits=16
Synchronize_TDMA
=>FB @ FNR 185050 fn_offset=92535 qbits=4924
LOST 1909!
TOA AVG is not 16 qbits, correcting (got 19)
L1CTL_DM_EST_REQ (arfcn=4866, chan_nr=0x73, tsc=1)
LOST 2578!
L1CTL_DM_REL_REQL1CTL_FBSB_REQ (arfcn=70, flags=0x7)
Starting FCCH RecognitionLOST 3047!
FB0 (93574:9): TOA=10032, Power= -72dBm, Angle= 3770Hz
FB1 (93585:9): TOA=10003, Power= -72dBm, Angle=  -11Hz
  fn_offset=93583 (fn=93585 + attempt=9 + ntdma = 7)
  delay=8 (fn_offset=93583 + 11 - fn=93585 - 1
  scheduling next FB/SB detection task with delay 8
=>FB @ FNR 93583 fn_offset=93583 qbits=4828
Synchronize_TDMA
LOST 3713!
SB1 (187172:1): TOA=   27, Power= -72dBm, Angle=  132Hz
=> SB 0x01582384: BSIC=33 fn=93596(70/22/11) qbits=16
Synchronize_TDMA
=>FB @ FNR 187171 fn_offset=93596 qbits=4924
LOST 1910!
L1CTL_DM_EST_REQ (arfcn=4866, chan_nr=0x43, tsc=1)
LOST 2578!
L1CTL_DM_REL_REQL1CTL_FBSB_REQ (arfcn=70, flags=0x7)
Starting FCCH RecognitionLOST 3047!
FB0 (94186:1): TOA=   48, Power= -68dBm, Angle= 3743Hz
FB1 (94197:9): TOA=10007, Power= -68dBm, Angle= 3738Hz
  fn_offset=94195 (fn=94197 + attempt=9 + ntdma = 7)
  delay=8 (fn_offset=94195 + 11 - fn=94197 - 1
  scheduling next FB/SB detection task with delay 8
FB1 (94217:11): TOA=12507, Power= -68dBm, Angle= 3783Hz
  fn_offset=94215 (fn=94217 + attempt=11 + ntdma = 9)
  delay=8 (fn_offset=94215 + 11 - fn=94217 - 1
  scheduling next FB/SB detection task with delay 8
FB1 (94237:11): TOA=12507, Power= -69dBm, Angle= 3743Hz
  fn_offset=94235 (fn=94237 + attempt=11 + ntdma = 9)
  delay=8 (fn_offset=94235 + 11 - fn=94237 - 1
  scheduling next FB/SB detection task with delay 8
FB1 (94248:2): TOA= 1259, Power= -69dBm, Angle= 3689Hz
  fn_offset=94246 (fn=94248 + attempt=2 + ntdma = 0)
  delay=8 (fn_offset=94246 + 11 - fn=94248 - 1
  scheduling next FB/SB detection task with delay 8
... ...

======= 2011-09-26 14:10:17 =======

>>        the bts arround me uses MultiCCCH, it's CCCH_CONF = 110 (6), so it uses TS0, TS2, TS4 and TS6 in a frame for PCH/AGCH.
>
>Mmm ,interesting, I had never seen that option being used before. What
>network is this.
>
>>        but the burst_ind only CCCH-CONF 0 & 1 are supported, it can sniff TS0 only, so only catch 1/4 IMM ASS for me.
>>        my OWN phone, it's just not in TS0 (i use nokia netmonitor to check it), so i can't catch it at all (phones use IMSI to decide page group).
>
>Well, it's your own phone (or any known target phone), you know the
>IMSI, hence the paging group ...
>
>
>>        i think the bottleneck is the DSP, as the DSP task (ALLC_DSP_TASK) can only process one TS of a frame (it's enough for phone),
>>        i think maybe backup/restore the DSP task variable patch needed, i'm new to the DSP disassemble and patch, anyone can help? thanks
>
>That's gonna be _very_ hard, the DSP uses _plenty_ of global variables ...
>
>But OTOH, instead of using the normal 'RX task', you can use the sniff
>task to listen to the CCCH. The sniff task will _not_ do the channel
>decoding (i.e. you'll have to call xcch_decode to get the actual 23
>bytes L2 frame), but it can sniff up to 4 bursts in a frame. just look
>at how sdcch sniffing is done, it currently sniff 2 timeslot 0 & 3 (to
>get DL & UL).
>
>This way you won't need any hard DSP patching, just a minor patch on
>the firmware to convert CCCH listening to burst_ind (leave the BCCH
>task as-it is, just mod the CCCH). And then a patch in the host app to
>call xcch_decode appropriately and feed the results 'as if' it cames
>from the phone directly.
>
>Cheers,
>
>    Sylvain

= = = = = = = = = = = = = = = = = = = =
                       

Best regards
Steve

Reply | Threaded
Open this post in threaded view
|

Re: Re: About sniff multi bursts in a frame, CCCH_CONF

Sylvain Munaut
>        BTW, i modify TS (line l1s_rx_win_ctrl _ONLY_) from 0 to 2, 4 and 6, the TS2 and TS4 work well, but the TS6 crash very soon because FCCH error,

Because the DSP doesn't have enough time to process the data between
the end of timeslot 6 and the next interrupt. Which causes a desync
between the TPU and DSP and then hell breaks loose and nothing will
work until a reset.

In theory when the phone is in another timeslot, we don't change the
RX window, we change the alignement of the interrupt. (but then that
means you can only listen to 1 timeslot).

When you use the burst sniff mode, it *should* still work for TS=6
this way (it's tight, but it fits). Because the phone doesn't need to
do all the channel decoding stuff, it's left to the PC.

Cheers,

    Sylvain