Structure of traffic data in burst_ind messages

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

Structure of traffic data in burst_ind messages

Bhaskar11
I'm experimenting with burst-ind branch and am able to track control messages in ccch_scan.

I then send an Assignment Command to change to a traffic channel. I can see the bursts come in, but cannot make out the format of the data.

If I understand right, the burst_ind structure holds 15 bytes of data, but the traffic data should be 33 bytes. I assume the traffic data is spread across several burst-ind messages.

Can you please clarify how to re-assemble the full 33-byte traffic data structure from the burst_ind messages?

Thanks.

B.

Reply | Threaded
Open this post in threaded view
|

Re: Structure of traffic data in burst_ind messages

Sylvain Munaut
> Can you please clarify how to re-assemble the full 33-byte traffic data
> structure from the burst_ind messages?

GSM 05.03

Reply | Threaded
Open this post in threaded view
|

Re: Structure of traffic data in burst_ind messages

Bhaskar11

> Can you please clarify how to re-assemble the full 33-byte traffic data
> structure from the burst_ind messages?

GSM 05.03

Thanks!

I'd like to believe that we already have code that does the work somewhere in the Osmocom project, even if it does it partially. I see some interesting code in rx_l1_traffic_ind() in l1ctl.c. But that already assumes 33 bytes received. If possible I'd rather build on existing code that build from scratch!

Can you please point me in the right direction?

Thanks for your prompt replies.

B.

Reply | Threaded
Open this post in threaded view
|

Re: Structure of traffic data in burst_ind messages

Sylvain Munaut
Hi,


> I see some interesting
> code in rx_l1_traffic_ind() in l1ctl.c. But that already assumes 33 bytes
> received. If possible I'd rather build on existing code that build from
> scratch!

There is no code that does what's needed for traffic channels in
osmocom-bb. During normal operation, this is entirely dealt with
inside the DSP, and traffic_ind deals with some TI specific stuff that
has no relevance whatsoever in this case.


> Can you please point me in the right direction?

again ... GSM 05.03

I will not repeat myself, a third time ...


Cheers,

     Sylvain

Reply | Threaded
Open this post in threaded view
|

Re: Structure of traffic data in burst_ind messages

Bhaskar11
I'm able to track the channel and extract the data. But to detect end of traffic I follow the similar code as in ccch_scan by checking the signal to noise ratio of the bursts on the downlink but during SACCH bursts only.

In most cases app_state.dch_badcnt quickly climbs beyond 6, and the channel is dropped within barely a second. Much of the traffic data bursts also have a very low snr. Very occasionally, the channel stays on for 3 to 5 seconds, then drops. During these rare occasions the traffic data remains with high snr for longer time also.

What am I doing wrong? Is this the right way to detect end of traffic data? Is it normal for this channel to have low snr?

B



On Fri, Jan 25, 2013 at 1:13 AM, Sylvain Munaut <[hidden email]> wrote:
Hi,


> I see some interesting
> code in rx_l1_traffic_ind() in l1ctl.c. But that already assumes 33 bytes
> received. If possible I'd rather build on existing code that build from
> scratch!

There is no code that does what's needed for traffic channels in
osmocom-bb. During normal operation, this is entirely dealt with
inside the DSP, and traffic_ind deals with some TI specific stuff that
has no relevance whatsoever in this case.


> Can you please point me in the right direction?

again ... GSM 05.03

I will not repeat myself, a third time ...


Cheers,

     Sylvain

Reply | Threaded
Open this post in threaded view
|

Re: Structure of traffic data in burst_ind messages

Bhaskar11
I'm trying to decode TCH data using burst_ind. Below is info from the frames as they come.

The SACCHs are correctly separated by 26 frames in the frame number so I know the data is valid. I detect upload/download of frame by checking (bi->flags & BI_FLG_SACCH).

But I see two problems:
1. Almost every alternate frame is missing.
2. I should not be seeing any upload frames, as I am not using filter-rework.

Can you please guide me on what could be wrong?


Data received:

  TCH/H (hl=1, hu=1) in FN=379183 DL SACCH
  TCH/H (hl=0, hu=1) in FN=379183 UL SACCH
  TCH/H (hl=1, hu=1) in FN=379185 DL 
  TCH/H (hl=1, hu=1) in FN=379185 UL 
  TCH/H (hl=1, hu=1) in FN=379187 DL 
  TCH/H (hl=0, hu=0) in FN=379187 UL 
  TCH/H (hl=1, hu=0) in FN=379189 DL 
  TCH/H (hl=0, hu=1) in FN=379189 UL 
  TCH/H (hl=1, hu=1) in FN=379191 DL 
  TCH/H (hl=0, hu=1) in FN=379191 UL 
  TCH/H (hl=1, hu=1) in FN=379193 DL 
  TCH/H (hl=0, hu=0) in FN=379193 UL 
  TCH/H (hl=1, hu=1) in FN=379195 DL 
  TCH/H (hl=0, hu=1) in FN=379195 UL 
  TCH/H (hl=1, hu=1) in FN=379198 DL 
  TCH/H (hl=1, hu=0) in FN=379198 UL 
  TCH/H (hl=1, hu=1) in FN=379200 DL 
  TCH/H (hl=0, hu=1) in FN=379200 UL 
  TCH/H (hl=1, hu=1) in FN=379202 DL 
  TCH/H (hl=1, hu=0) in FN=379202 UL 
  TCH/H (hl=0, hu=0) in FN=379204 DL 
  TCH/H (hl=1, hu=0) in FN=379204 UL 
  TCH/H (hl=0, hu=0) in FN=379206 DL 
  TCH/H (hl=1, hu=0) in FN=379206 UL 
  TCH/H (hl=1, hu=1) in FN=379208 DL 
  TCH/H (hl=0, hu=1) in FN=379208 UL 
  TCH/H (hl=0, hu=0) in FN=379209 DL SACCH
  TCH/H (hl=1, hu=1) in FN=379209 UL SACCH
  TCH/H (hl=0, hu=0) in FN=379211 DL 
  TCH/H (hl=1, hu=1) in FN=379211 UL 
  TCH/H (hl=1, hu=1) in FN=379213 DL 
  TCH/H (hl=0, hu=0) in FN=379213 UL 
  TCH/H (hl=1, hu=1) in FN=379215 DL 
  TCH/H (hl=0, hu=0) in FN=379215 UL 
  TCH/H (hl=1, hu=1) in FN=379217 DL 
  TCH/H (hl=1, hu=1) in FN=379217 UL 
  TCH/H (hl=1, hu=1) in FN=379219 DL 
  TCH/H (hl=0, hu=0) in FN=379219 UL 
  TCH/H (hl=1, hu=1) in FN=379221 DL 
  TCH/H (hl=0, hu=1) in FN=379221 UL 
  TCH/H (hl=1, hu=1) in FN=379224 DL 
  TCH/H (hl=1, hu=0) in FN=379224 UL 
  TCH/H (hl=1, hu=1) in FN=379226 DL 
  TCH/H (hl=1, hu=1) in FN=379226 UL 
  TCH/H (hl=1, hu=1) in FN=379228 DL 
  TCH/H (hl=1, hu=1) in FN=379228 UL 
  TCH/H (hl=1, hu=1) in FN=379230 DL 
  TCH/H (hl=1, hu=1) in FN=379230 UL 
  TCH/H (hl=1, hu=1) in FN=379232 DL 
  TCH/H (hl=1, hu=1) in FN=379232 UL 
  TCH/H (hl=1, hu=1) in FN=379234 DL 
  TCH/H (hl=0, hu=0) in FN=379234 UL 
  TCH/H (hl=1, hu=1) in FN=379235 DL SACCH
  TCH/H (hl=0, hu=1) in FN=379235 UL SACCH
  TCH/H (hl=1, hu=1) in FN=379237 DL 
  TCH/H (hl=1, hu=1) in FN=379237 UL 
  TCH/H (hl=0, hu=0) in FN=379239 DL 
  TCH/H (hl=1, hu=0) in FN=379239 UL 
  TCH/H (hl=0, hu=0) in FN=379241 DL 
  TCH/H (hl=1, hu=0) in FN=379241 UL 
  TCH/H (hl=0, hu=0) in FN=379243 DL 
  TCH/H (hl=0, hu=1) in FN=379243 UL 
  TCH/H (hl=0, hu=0) in FN=379245 DL 
  TCH/H (hl=0, hu=0) in FN=379245 UL 
  TCH/H (hl=1, hu=1) in FN=379247 DL 
  TCH/H (hl=0, hu=1) in FN=379247 UL 
  TCH/H (hl=1, hu=1) in FN=379250 DL 
  TCH/H (hl=0, hu=0) in FN=379250 UL 
  TCH/H (hl=1, hu=1) in FN=379252 DL 
  TCH/H (hl=1, hu=1) in FN=379252 UL 
  TCH/H (hl=1, hu=1) in FN=379254 DL 
  TCH/H (hl=1, hu=0) in FN=379254 UL 
  TCH/H (hl=1, hu=1) in FN=379256 DL 
  TCH/H (hl=1, hu=1) in FN=379256 UL 
  TCH/H (hl=1, hu=1) in FN=379258 DL 
  TCH/H (hl=1, hu=0) in FN=379258 UL 
  TCH/H (hl=1, hu=1) in FN=379260 DL 
  TCH/H (hl=0, hu=0) in FN=379260 UL 
  TCH/H (hl=1, hu=1) in FN=379261 DL SACCH
  TCH/H (hl=1, hu=0) in FN=379261 UL SACCH
  TCH/H (hl=1, hu=1) in FN=379263 DL 
  TCH/H (hl=0, hu=0) in FN=379263 UL 
  TCH/H (hl=1, hu=1) in FN=379265 DL 

Reply | Threaded
Open this post in threaded view
|

Re: Structure of traffic data in burst_ind messages

Sylvain Munaut
> But I see two problems:
> 1. Almost every alternate frame is missing.

... TCH/H ...

> 2. I should not be seeing any upload frames, as I am not using
> filter-rework.

The filters only attenuate the signal ... if the victim phone is close
enough, they will go through anyway.
Also, AFAIR the phone will transmit a burst_ind packet in anycase ...
which might be complete gibberish, that up to you to try to interpret
it.

Cheers,

    Sylvain

Reply | Threaded
Open this post in threaded view
|

Re: Structure of traffic data in burst_ind messages

Bhaskar11
Sylvain, thanks for the prompt replies.  But...

> But I see two problems:
> 1. Almost every alternate frame is missing.

... TCH/H ...

I re-read the specs: 05.03 / 3.2.4. If the data is spread across 4 blocks, should that not mean some of the data will be on each successive burst?

The specs don't mention skipping alternate bursts. So, I still don't understand why the entire burst would be missing alternately.

I seem to have missed something important here.

 
> 2. I should not be seeing any upload frames, as I am not using
> filter-rework.

The filters only attenuate the signal ... if the victim phone is close
enough, they will go through anyway.
Also, AFAIR the phone will transmit a burst_ind packet in anycase ...
which might be complete gibberish, that up to you to try to interpret
it.

In your experience, up to what distance does this kind of interference come in a typical scenario? Is it in the range of  dozens of metres or hundreds?

B.

Reply | Threaded
Open this post in threaded view
|

Re: Structure of traffic data in burst_ind messages

Sylvain Munaut
Hi,

> I re-read the specs: 05.03 / 3.2.4. If the data is spread across 4 blocks,
> should that not mean some of the data will be on each successive burst?

sucessive burst ... on the logical channel, not the physical channel.

You need to read 05.02 now.


> The specs don't mention skipping alternate bursts.

Sure they do. You just haven't read them all yet.


> I seem to have missed something important here.

Yes, it would seem so.


> In your experience, up to what distance does this kind of interference come
> in a typical scenario? Is it in the range of  dozens of metres or hundreds?

No idea, never did any testing beyond a single room.

Cheers,

    Sylvain

Pe
Reply | Threaded
Open this post in threaded view
|

Re: Structure of traffic data in burst_ind messages

Pe
In reply to this post by Bhaskar11
Hi, Bhaskar11
Did you resolve problem with low snr?
Do you make synchronization on SCH before going to TCH, after Assignment Command?
Reply | Threaded
Open this post in threaded view
|

Re: Structure of traffic data in burst_ind messages

Bhaskar11
Yes, I send the command
l1ctl_tx_fbsb_req(ms, ms->test_arfcn,
L1CTL_FBSB_F_FB0 | L1CTL_FBSB_F_SB, 100, 0,
app_state.ccch_mode, dbm2rxlev(-85));
before switching channels.

Now most of the channels stick on for much longer, but a few drop within seconds.

But I cannot know for sure if this has "worked" until I can decode and recognise some FACCH commands.

On AMR HR I get data like:

  TCH/H (hl=0, hu=0) in FN=1864368 DL SACCH
  Detected FACCH (hl=1, hu=0) in FN=1864369 DL
  Detected FACCH (hl=1, hu=0) in FN=1864371 DL
  Detected FACCH (hl=1, hu=1) in FN=1864373 DL
  Detected FACCH (hl=1, hu=1) in FN=1864375 DL
  Detected FACCH (hl=1, hu=1) in FN=1864386 DL
  Detected FACCH (hl=1, hu=1) in FN=1864388 DL
  Detected FACCH (hl=1, hu=1) in FN=1864390 DL
  Detected FACCH (hl=1, hu=1) in FN=1864392 DL
  TCH/H (hl=0, hu=0) in FN=1864394 DL SACCH
  Detected FACCH (hl=1, hu=1) in FN=1864395 DL
  Detected FACCH (hl=1, hu=1) in FN=1864397 DL
  Detected FACCH (hl=1, hu=1) in FN=1864399 DL
  Detected FACCH (hl=1, hu=0) in FN=1864401 DL
  Detected FACCH (hl=1, hu=1) in FN=1864403 DL
  Detected FACCH (hl=1, hu=0) in FN=1864405 DL
  Detected FACCH (hl=1, hu=1) in FN=1864408 DL
  Detected FACCH (hl=1, hu=0) in FN=1864410 DL
  TCH/H (hl=0, hu=0) in FN=1864420 DL SACCH

which does not look correct because I think the FACCH should be in groups of 4.

Any explanations? Suggestions?

B.


On Thu, Jan 31, 2013 at 8:38 PM, Pe <[hidden email]> wrote:
Hi, Bhaskar11
Did you resolve problem with low snr?
Do you make synchronization on SCH before going to TCH, after Assignment
Command?



--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Structure-of-traffic-data-in-burst-ind-messages-tp4025762p4025787.html
Sent from the baseband-devel mailing list archive at Nabble.com.


Reply | Threaded
Open this post in threaded view
|

Re: Structure of traffic data in burst_ind messages

Bhaskar11
Looks like the problem is because of DTX because the FACCH bursts vanish during speech and return during pause.

Anyone has experience with DTX?

B.



On Fri, Feb 1, 2013 at 10:42 AM, Bhaskar11 <[hidden email]> wrote:
Yes, I send the command
l1ctl_tx_fbsb_req(ms, ms->test_arfcn,
L1CTL_FBSB_F_FB0 | L1CTL_FBSB_F_SB, 100, 0,
app_state.ccch_mode, dbm2rxlev(-85));
before switching channels.

Now most of the channels stick on for much longer, but a few drop within seconds.

But I cannot know for sure if this has "worked" until I can decode and recognise some FACCH commands.

On AMR HR I get data like:

  TCH/H (hl=0, hu=0) in FN=1864368 DL SACCH
  Detected FACCH (hl=1, hu=0) in FN=1864369 DL
  Detected FACCH (hl=1, hu=0) in FN=1864371 DL
  Detected FACCH (hl=1, hu=1) in FN=1864373 DL
  Detected FACCH (hl=1, hu=1) in FN=1864375 DL
  Detected FACCH (hl=1, hu=1) in FN=1864386 DL
  Detected FACCH (hl=1, hu=1) in FN=1864388 DL
  Detected FACCH (hl=1, hu=1) in FN=1864390 DL
  Detected FACCH (hl=1, hu=1) in FN=1864392 DL
  TCH/H (hl=0, hu=0) in FN=1864394 DL SACCH
  Detected FACCH (hl=1, hu=1) in FN=1864395 DL
  Detected FACCH (hl=1, hu=1) in FN=1864397 DL
  Detected FACCH (hl=1, hu=1) in FN=1864399 DL
  Detected FACCH (hl=1, hu=0) in FN=1864401 DL
  Detected FACCH (hl=1, hu=1) in FN=1864403 DL
  Detected FACCH (hl=1, hu=0) in FN=1864405 DL
  Detected FACCH (hl=1, hu=1) in FN=1864408 DL
  Detected FACCH (hl=1, hu=0) in FN=1864410 DL
  TCH/H (hl=0, hu=0) in FN=1864420 DL SACCH

which does not look correct because I think the FACCH should be in groups of 4.

Any explanations? Suggestions?

B.


On Thu, Jan 31, 2013 at 8:38 PM, Pe <[hidden email]> wrote:
Hi, Bhaskar11
Did you resolve problem with low snr?
Do you make synchronization on SCH before going to TCH, after Assignment
Command?



--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Structure-of-traffic-data-in-burst-ind-messages-tp4025762p4025787.html
Sent from the baseband-devel mailing list archive at Nabble.com.



Pe
Reply | Threaded
Open this post in threaded view
|

Re: Structure of traffic data in burst_ind messages

Pe
Hi, Bhaskar
I have the same problem with periodical channel dropping from snr 255 to snr less then 10. It is not because of DTX, as i think. May be it is because of handovers, but dropping is too often.
I did not use FACCH information yet.
Can you get a reference to document with facch decoding scheme? google didnt help.
Reply | Threaded
Open this post in threaded view
|

Re: Structure of traffic data in burst_ind messages

Bhaskar11
You can know if it is DTX by checking for SID messages before it drops and before it resumes. A simple way to check if it is DTX  is to watch SNR level during speech/pause.

If you are not using AMR, then you can check signal strength only for the mandatory frames which are listed in TS 05.08 / 8.3.

FACCH specs will be in TS 05.03. But AFAIK it will not help for this purpose.

You cannot Google these things. You will have to read the specs from the 3GPP website http://www.3gpp.org/specification-numbering

B


On Tue, Feb 12, 2013 at 5:46 PM, Pe <[hidden email]> wrote:
Hi, Bhaskar
I have the same problem with periodical channel dropping from snr 255 to snr
less then 10. It is not because of DTX, as i think. May be it is because of
handovers, but dropping is too often.
I did not use FACCH information yet.
Can you get a reference to document with facch decoding scheme? google didnt
help.



--
View this message in context: http://baseband-devel.722152.n3.nabble.com/Structure-of-traffic-data-in-burst-ind-messages-tp4025762p4025826.html
Sent from the baseband-devel mailing list archive at Nabble.com.