Hi!
Some other 'bug' that I discovered while looking at traces recently is in RSL, where we
* Send RSL ACTIVATE CHANNEL to open a channel on the BTS side * Send RR IMMEDIATE ASSIGN through the AGCH to the MS and only later receive RSL ACT CHAN ACK.
This seems to work fine, since we queue the messages in-order and dequeue them in-order and simply assume the BTS will ACK. but what if it cannot activate the channel due to a hardware problem? Or what if we have a bug and try to assign the same channel twice?
However, on the E1 protocol analyzer the ordering of events was reversed, i.e. the IMMEDIATE ASSIGN happened before the RSL CHAN ACT. I couldn't understand why, since we always enqueue at the end of the queue and dequeue from the front. But what I was missing: In a multi-TRX setup, the IMMEDIATE ASSIGN gets sent over the TRX0 (AGCH, part of BCCH) while the RSL CHAN ACTIVATE gets sent over TRX1. Each TRX has its own RSL link, and the TRX0 link might be ready to receive our message a bit sooner than the TRX1 link...
So in this case, we send the messages in wrong order, and risk a channel assignment error.
What needs to be done is to actually send the RSL CHAN ACT, save the state, wait for the CHAN ACT ACK, then transmit the IMMEDIATE ASSIGN.
Similar issues might exist in other cases of channel activation, such as handover.
On 06/22/2010 12:08 AM, Harald Welte wrote:
What needs to be done is to actually send the RSL CHAN ACT, save the state, wait for the CHAN ACT ACK, then transmit the IMMEDIATE ASSIGN.
I am going to do this for the assignment and immediate assignment commands.. today/now.
On 06/22/2010 09:27 AM, Holger Hans Peter Freyther wrote:
On 06/22/2010 12:08 AM, Harald Welte wrote:
What needs to be done is to actually send the RSL CHAN ACT, save the state, wait for the CHAN ACT ACK, then transmit the IMMEDIATE ASSIGN.
I am going to do this for the assignment and immediate assignment commands.. today/now.
I have implemented that, for the handover case and in the On-Waves branch for early assignment, we already waited for the signal ack.
My understanding of GSM 08.58 so far is that it is taken for granted that the BTS will always have a ACK/NACK for requests. With this in mind I have not added an extra timer waiting for the CHANnel ACTivate ACK/NACK. I am also storing the RACH req information inside the lchan (as a pointer) and use the pointerz inside the CHAN ACT ACK handling to decide if an immediate assignment should be send.
This appears to work for the two handsets I have tested it with, I took the liberty to push the change.
Hi Zecke,
On Tue, Jun 22, 2010 at 05:43:05PM +0800, Holger Freyther wrote:
On 06/22/2010 09:27 AM, Holger Hans Peter Freyther wrote:
On 06/22/2010 12:08 AM, Harald Welte wrote:
What needs to be done is to actually send the RSL CHAN ACT, save the state, wait for the CHAN ACT ACK, then transmit the IMMEDIATE ASSIGN.
I am going to do this for the assignment and immediate assignment commands.. today/now.
I have implemented that, for the handover case and in the On-Waves branch for early assignment, we already waited for the signal ack.
ok, great news.
My understanding of GSM 08.58 so far is that it is taken for granted that the BTS will always have a ACK/NACK for requests. With this in mind I have not added an extra timer waiting for the CHANnel ACTivate ACK/NACK.
makes sense to me.
I am also storing the RACH req information inside the lchan (as a pointer) and use the pointerz inside the CHAN ACT ACK handling to decide if an immediate assignment should be send.
sounds fine, too. Thanks!
-
Harald Welte -
Holger Freyther -
Holger Hans Peter Freyther