10 Oct
2012
10 Oct
'12
5:38 p.m.
Similar problem with DL_PACKET_UPLINK_ACK_NACK..., now logs are
synchronized:
BTS:
1349870962.242903 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543233 FN52 17
DATA raw=(0401018aae8c0f01c0050816083a853907018754033d89)
1349870962.261436 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543237 FN52 21
DATA raw=(000102058aae8c0f1b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)
1349870962.262173 3042884464: [ PCU -> BTS ] PCH: L2Length 11
primitive=UNIT_DATA raw=(063f300f40027d6ba40000d8aae8c0f81a022b2b2b2b)
1349870962.262261 3042884464: [ BTS -> PCU ] PhPchCnf:
2d063f300f40027d6ba40000d8aae8c0f81a022b2b2b2b
1349870962.263013 3042884464: [ PCU -> BTS ] PACCH FN 2543250 FN52 34
CNTRL1 raw=(4f2400208000000000000000f155d181e02b2b2b2b2b2b)
DL_PACKET_UPLINK_ACK_NACK
1349870962.283385 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543242 FN52 26
DATA raw=(0401018aae8c0f01c0050816083a853907018754033d89)
1349870962.302008 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543246 FN52 30
DATA raw=(000102058aae8c0f1b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)
1349870962.320769 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543250 FN52 34
DATA raw=(0401018aae8c0f01c0050816083a853907018754033d89)
1349870962.362534 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543259 FN52 43
CNTRL1 raw=(40062aba303f2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)
UL_PACKET_CONTROL_ACKNOWLEDGEMENT
1349870962.480042 3042884464: [ PCU -> BTS ] PDTCH: FN 2543298 FN52 30 DATA
raw=(0f01002541c001081501ff6cba2b2b2b2b2b2b2b2b2b2b)
PCU:
<0005> gprs_rlcmac_data.cpp:880 Decoded premier TLLI=0x8aae8c0f of UL DATA
TBF=0.
<0005> gprs_rlcmac_data.cpp:743 Complete UL frame for TBF=0: len=17
<0008> gprs_rlcmac.cpp:1760 LLC [PCU -> SGSN] TFI: 0 TLLI: 0x8aae8c0f len=17
<0008> gprs_bssgp_pcu.cpp:145 LLC [SGSN -> PCU] = TLLI: 0x8aae8c0f IMSI:
000 len: 9
<0002> gprs_rlcmac.cpp:354 Allocating DL TBF: TFI=0 TRX=0 MS_CLASS=10
<0002> gprs_rlcmac.cpp:948 - Setting Control TS 7
<0002> gprs_rlcmac_data.cpp:1804 TX: START TFI: 0 TLLI: 0x8aae8c0f
Immediate Assignment Downlink (PCH)
<0002> gprs_rlcmac_data.cpp:281 PACKET CONTROL ACK with unknown FN=2543259
TLL=0x8aae8c0f (TRX 0 TS 7)
<0002> gprs_rlcmac.cpp:895 Free UL TBF=0 with TLLI=0x8aae8c0f.
<0004> gprs_rlcmac_data.cpp:1456 Complete DL frame for TBF=0: len=9
<0002> gprs_rlcmac.cpp:895 Free DL TBF=0 with TLLI=0x8aae8c0f.
<0008> gprs_bssgp_pcu.cpp:145 LLC [SGSN -> PCU] = TLLI: 0x8aae8c0f IMSI:
000 len: 9
<0002> gprs_rlcmac.cpp:354 Allocating DL TBF: TFI=0 TRX=0 MS_CLASS=10
<0002> gprs_rlcmac.cpp:948 - Setting Control TS 7
<0002> gprs_rlcmac_data.cpp:1804 TX: START TFI: 0 TLLI: 0x8aae8c0f
Immediate Assignment Downlink (PCH)
<0004> gprs_rlcmac_data.cpp:1456 Complete DL frame for TBF=0: len=9
<0002> gprs_rlcmac.cpp:895 Free DL TBF=0 with TLLI=0x8aae8c0f.
...
*From:* Vladimir Rolbin [mailto:vrolbin@gmail.com]
*Sent:* Tuesday, October 09, 2012 5:17 PM
*To:* osmocom-pcu(a)lists.osmocom.org; openbts-discuss(a)lists.sourceforge.net
*Subject:* [Openbts-discuss] gprs PACCH downlink assignment problem
Hi,
My set is openbts-p2.8-gprs-exp/osmo-pcu-jolly. I encounter the problem
with PACCH downlink assignment:
If the difference between FNs of DL_PACKET_DOWNLINK_ASSIGNMENT and
corresponding UL_PACKET_CONTROL_ACKNOWLEDGEMENT
is expected (RRBP = 0) 13 everything is OK (OpenBTS log):
1347379490.099008 3031505776: [ PCU -> BTS ] PACCH FN 2536893 FN52 21
CNTRL1 raw=(4f0800000c03400a0800802b2b2b2b2b2b2b2b2b2b2b2b)
DL_PACKET_DOWNLINK_ASSIGNMENT
1347379490.118500 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536885 FN52 13
DATA raw=(100101cc741f3203c005650000014500003c00010000ff)
1347379490.136108 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536889 FN52 17
DATA raw=(080105cc741f3228e2a8c8aa0100000100000000000003)
1347379490.154624 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536893 FN52 21
DATA raw=(040107cc741f32777777066b616e6e656c036f72670000)
1347379490.215582 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536906 FN52 34
CNTRL1
raw=(400731d07ccb2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)UL_PACKET_CONTROL_ACKNOWLEDGEMENT
But it's not always the case
1349788219.582282 3043367792: [ PCU -> BTS ] PACCH FN 2189728 FN52 8 CNTRL1
raw=(4f0800000c02800a0d00802b2b2b2b2b2b2b2b2b2b2b2b)
DL_PACKET_DOWNLINK_ASSIGNMENT
1349788219.601978 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189720 FN52 0
DATA raw=(040103ae3558373751f40103e800101773022a85464200)
1349788219.620378 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189724 FN52 4
DATA raw=(0001042dae355837026a4e0432100000258ccc2b2b2b2b)
1349788219.638881 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189728 FN52 8
DATA raw=(040103ae3558373751f40103e800101773022a85464200)
1349788219.680973 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189737 FN52 17
CNTRL1 raw=(4006b8d560df2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)
UL_PACKET_CONTROL_ACKNOWLEDGEMENT
diff FN = 9, that causes the following behaviour in pcu:
<0002> gprs_rlcmac_data.cpp:1753 TBF: START TFI: 0 TLLI: 0xae355837 Packet
Downlink Assignment (PACCH)
<0004> gprs_rlcmac_data.cpp:1442 Complete DL frame for TBF=0: len=9
<0002> gprs_rlcmac_data.cpp:281 PACKET CONTROL ACK with unknown FN=2163607
TLL=0xae355837 (TRX 0 TS 7)
<0002> gprs_rlcmac_data.cpp:100 Poll timeout for UL TBF=0
<0002> gprs_rlcmac_data.cpp:107 - Timeout for polling PACKET CONTROL ACK
for PACKET UPLINK ACK
Any ideas? Is it the known issue?
Regards,
Vladimir Rolbin
10 Oct
10 Oct
6:13 p.m.
Hi, Vladimir!
Hi, Vladimir!
I haven't any problems with downlink assignment and
PACKET_UPLINK_ACK_NACK now, but I will check it.
Please, check, have you applied this patch?
https://github.com/chemeris/openbts-p2.8/commit/bfa47ccfa26ab30b0232584ac67…
2012/10/10 Vladimir Rolbin <vrolbin(a)gmail.com>om>:
Similar problem with DL_PACKET_UPLINK_ACK_NACK..., now
logs are
synchronized:
BTS:
1349870962.242903 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543233 FN52 17
DATA raw=(0401018aae8c0f01c0050816083a853907018754033d89)
1349870962.261436 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543237 FN52 21
DATA raw=(000102058aae8c0f1b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)
1349870962.262173 3042884464: [ PCU -> BTS ] PCH: L2Length 11
primitive=UNIT_DATA raw=(063f300f40027d6ba40000d8aae8c0f81a022b2b2b2b)
1349870962.262261 3042884464: [ BTS -> PCU ] PhPchCnf:
2d063f300f40027d6ba40000d8aae8c0f81a022b2b2b2b
1349870962.263013 3042884464: [ PCU -> BTS ] PACCH FN 2543250 FN52 34 CNTRL1
raw=(4f2400208000000000000000f155d181e02b2b2b2b2b2b)
DL_PACKET_UPLINK_ACK_NACK
1349870962.283385 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543242 FN52 26
DATA raw=(0401018aae8c0f01c0050816083a853907018754033d89)
1349870962.302008 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543246 FN52 30
DATA raw=(000102058aae8c0f1b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)
1349870962.320769 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543250 FN52 34
DATA raw=(0401018aae8c0f01c0050816083a853907018754033d89)
1349870962.362534 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543259 FN52 43
CNTRL1 raw=(40062aba303f2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)
UL_PACKET_CONTROL_ACKNOWLEDGEMENT
1349870962.480042 3042884464: [ PCU -> BTS ] PDTCH: FN 2543298 FN52 30 DATA
raw=(0f01002541c001081501ff6cba2b2b2b2b2b2b2b2b2b2b)
PCU:
<0005> gprs_rlcmac_data.cpp:880 Decoded premier TLLI=0x8aae8c0f of UL DATA
TBF=0.
<0005> gprs_rlcmac_data.cpp:743 Complete UL frame for TBF=0: len=17
<0008> gprs_rlcmac.cpp:1760 LLC [PCU -> SGSN] TFI: 0 TLLI: 0x8aae8c0f len=17
<0008> gprs_bssgp_pcu.cpp:145 LLC [SGSN -> PCU] = TLLI: 0x8aae8c0f IMSI: 000
len: 9
<0002> gprs_rlcmac.cpp:354 Allocating DL TBF: TFI=0 TRX=0 MS_CLASS=10
<0002> gprs_rlcmac.cpp:948 - Setting Control TS 7
<0002> gprs_rlcmac_data.cpp:1804 TX: START TFI: 0 TLLI: 0x8aae8c0f Immediate
Assignment Downlink (PCH)
<0002> gprs_rlcmac_data.cpp:281 PACKET CONTROL ACK with unknown FN=2543259
TLL=0x8aae8c0f (TRX 0 TS 7)
<0002> gprs_rlcmac.cpp:895 Free UL TBF=0 with TLLI=0x8aae8c0f.
<0004> gprs_rlcmac_data.cpp:1456 Complete DL frame for TBF=0: len=9
<0002> gprs_rlcmac.cpp:895 Free DL TBF=0 with TLLI=0x8aae8c0f.
<0008> gprs_bssgp_pcu.cpp:145 LLC [SGSN -> PCU] = TLLI: 0x8aae8c0f IMSI: 000
len: 9
<0002> gprs_rlcmac.cpp:354 Allocating DL TBF: TFI=0 TRX=0 MS_CLASS=10
<0002> gprs_rlcmac.cpp:948 - Setting Control TS 7
<0002> gprs_rlcmac_data.cpp:1804 TX: START TFI: 0 TLLI: 0x8aae8c0f Immediate
Assignment Downlink (PCH)
<0004> gprs_rlcmac_data.cpp:1456 Complete DL frame for TBF=0: len=9
<0002> gprs_rlcmac.cpp:895 Free DL TBF=0 with TLLI=0x8aae8c0f.
...
From: Vladimir Rolbin [mailto:vrolbin@gmail.com]
Sent: Tuesday, October 09, 2012 5:17 PM
To: osmocom-pcu(a)lists.osmocom.org; openbts-discuss(a)lists.sourceforge.net
Subject: [Openbts-discuss] gprs PACCH downlink assignment problem
Hi,
My set is openbts-p2.8-gprs-exp/osmo-pcu-jolly. I encounter the problem with
PACCH downlink assignment:
If the difference between FNs of DL_PACKET_DOWNLINK_ASSIGNMENT and
corresponding UL_PACKET_CONTROL_ACKNOWLEDGEMENT
is expected (RRBP = 0) 13 everything is OK (OpenBTS log):
1347379490.099008 3031505776: [ PCU -> BTS ] PACCH FN 2536893 FN52 21 CNTRL1
raw=(4f0800000c03400a0800802b2b2b2b2b2b2b2b2b2b2b2b)
DL_PACKET_DOWNLINK_ASSIGNMENT
1347379490.118500 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536885 FN52 13
DATA raw=(100101cc741f3203c005650000014500003c00010000ff)
1347379490.136108 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536889 FN52 17
DATA raw=(080105cc741f3228e2a8c8aa0100000100000000000003)
1347379490.154624 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536893 FN52 21
DATA raw=(040107cc741f32777777066b616e6e656c036f72670000)
1347379490.215582 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536906 FN52 34
CNTRL1
raw=(400731d07ccb2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)UL_PACKET_CONTROL_ACKNOWLEDGEMENT
But it's not always the case
1349788219.582282 3043367792: [ PCU -> BTS ] PACCH FN 2189728 FN52 8 CNTRL1
raw=(4f0800000c02800a0d00802b2b2b2b2b2b2b2b2b2b2b2b)
DL_PACKET_DOWNLINK_ASSIGNMENT
1349788219.601978 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189720 FN52 0
DATA raw=(040103ae3558373751f40103e800101773022a85464200)
1349788219.620378 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189724 FN52 4
DATA raw=(0001042dae355837026a4e0432100000258ccc2b2b2b2b)
1349788219.638881 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189728 FN52 8
DATA raw=(040103ae3558373751f40103e800101773022a85464200)
1349788219.680973 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189737 FN52 17
CNTRL1 raw=(4006b8d560df2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)
UL_PACKET_CONTROL_ACKNOWLEDGEMENT
diff FN = 9, that causes the following behaviour in pcu:
<0002> gprs_rlcmac_data.cpp:1753 TBF: START TFI: 0 TLLI: 0xae355837 Packet
Downlink Assignment (PACCH)
<0004> gprs_rlcmac_data.cpp:1442 Complete DL frame for TBF=0: len=9
<0002> gprs_rlcmac_data.cpp:281 PACKET CONTROL ACK with unknown FN=2163607
TLL=0xae355837 (TRX 0 TS 7)
<0002> gprs_rlcmac_data.cpp:100 Poll timeout for UL TBF=0
<0002> gprs_rlcmac_data.cpp:107 - Timeout for polling PACKET CONTROL ACK for
PACKET UPLINK ACK
Any ideas? Is it the known issue?
Regards,
Vladimir Rolbin
--
Regards,
Ivan Kluchnikov.
http://fairwaves.ru
11 Oct
11 Oct
12:39 p.m.
Hi, Ivan
Yes, the patch is applied..
It's not so clear the role of the timers mT3101, mT3111 and mT3109 for
PDTCH channel.
If I see well when "AccessGrantResponder -> LCH = gBTS.getPDTCH();" the
same channel
is opened every time (it's never closed explicitly):
LogicalChannel::open(); -> L1FEC::open() -> mDecoder->open(); -> void
L1Decoder::open() ->
{
ScopedLock lock(mLock);
if (!mRunning) start();
mFER=0.0F;
mT3111.reset();
mT3109.reset();
mT3101.set();
mActive = true;
}
handleGoodFrame function is overridden, so the channel stops to be active
here after mT3101 is elapsed:
void XCCHL1Decoder::writeLowSide(const RxBurst& inBurst)
{
OBJLOG(DEBUG) <<"XCCHL1Decoder " << inBurst;
// If the channel is closed, ignore the burst.
if (!active()) {
OBJLOG(DEBUG) <<"XCCHL1Decoder not active, ignoring input";
return;
}
...
}
Pls advice..
Regards,
Vladimir
On Wed, Oct 10, 2012 at 6:13 PM, Ivan Kluchnikov <
Ivan.Kluchnikov(a)fairwaves.ru> wrote:
Hi, Vladimir!
Hi, Vladimir!
I haven't any problems with downlink assignment and
PACKET_UPLINK_ACK_NACK now, but I will check it.
Please, check, have you applied this patch?
https://github.com/chemeris/openbts-p2.8/commit/bfa47ccfa26ab30b0232584ac67…
2012/10/10 Vladimir Rolbin <vrolbin(a)gmail.com>om>:
Similar problem with
DL_PACKET_UPLINK_ACK_NACK..., now logs are
synchronized:
BTS:
1349870962.242903 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543233 FN52
17
DATA
raw=(0401018aae8c0f01c0050816083a853907018754033d89)
1349870962.261436 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543237 FN52
21
DATA
raw=(000102058aae8c0f1b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)
1349870962.262173 3042884464: [ PCU -> BTS ] PCH: L2Length 11
primitive=UNIT_DATA raw=(063f300f40027d6ba40000d8aae8c0f81a022b2b2b2b)
1349870962.262261 3042884464: [ BTS -> PCU ] PhPchCnf:
2d063f300f40027d6ba40000d8aae8c0f81a022b2b2b2b
1349870962.263013 3042884464: [ PCU -> BTS ] PACCH FN 2543250 FN52 34
CNTRL1
raw=(4f2400208000000000000000f155d181e02b2b2b2b2b2b)
DL_PACKET_UPLINK_ACK_NACK
1349870962.283385 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543242 FN52
26
DATA
raw=(0401018aae8c0f01c0050816083a853907018754033d89)
1349870962.302008 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543246 FN52
30
DATA
raw=(000102058aae8c0f1b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)
1349870962.320769 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543250 FN52
34
DATA
raw=(0401018aae8c0f01c0050816083a853907018754033d89)
1349870962.362534 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543259 FN52
43
CNTRL1
raw=(40062aba303f2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)
UL_PACKET_CONTROL_ACKNOWLEDGEMENT
1349870962.480042 3042884464: [ PCU -> BTS ] PDTCH: FN 2543298 FN52 30
DATA
raw=(0f01002541c001081501ff6cba2b2b2b2b2b2b2b2b2b2b)
PCU:
<0005> gprs_rlcmac_data.cpp:880 Decoded premier TLLI=0x8aae8c0f of UL
DATA
TBF=0.
<0005> gprs_rlcmac_data.cpp:743 Complete UL frame for TBF=0: len=17
<0008> gprs_rlcmac.cpp:1760 LLC [PCU -> SGSN] TFI: 0 TLLI: 0x8aae8c0f
len=17
<0008> gprs_bssgp_pcu.cpp:145 LLC [SGSN
-> PCU] = TLLI: 0x8aae8c0f IMSI:
000
len: 9
<0002> gprs_rlcmac.cpp:354 Allocating DL TBF: TFI=0 TRX=0 MS_CLASS=10
<0002> gprs_rlcmac.cpp:948 - Setting Control TS 7
<0002> gprs_rlcmac_data.cpp:1804 TX: START TFI: 0 TLLI: 0x8aae8c0f
Immediate
Assignment Downlink (PCH)
<0002> gprs_rlcmac_data.cpp:281 PACKET CONTROL ACK with unknown
FN=2543259
> TLL=0x8aae8c0f (TRX 0 TS 7)
> <0002> gprs_rlcmac.cpp:895 Free UL TBF=0 with TLLI=0x8aae8c0f.
> <0004> gprs_rlcmac_data.cpp:1456 Complete DL frame for TBF=0: len=9
> <0002> gprs_rlcmac.cpp:895 Free DL TBF=0 with TLLI=0x8aae8c0f.
<0008> gprs_bssgp_pcu.cpp:145 LLC [SGSN
-> PCU] = TLLI: 0x8aae8c0f IMSI:
000
len: 9
<0002> gprs_rlcmac.cpp:354 Allocating DL TBF: TFI=0 TRX=0 MS_CLASS=10
<0002> gprs_rlcmac.cpp:948 - Setting Control TS 7
<0002> gprs_rlcmac_data.cpp:1804 TX: START TFI: 0 TLLI: 0x8aae8c0f
Immediate
Assignment Downlink (PCH)
<0004> gprs_rlcmac_data.cpp:1456 Complete DL frame for TBF=0: len=9
<0002> gprs_rlcmac.cpp:895 Free DL TBF=0 with TLLI=0x8aae8c0f.
...
From: Vladimir Rolbin [mailto:vrolbin@gmail.com]
Sent: Tuesday, October 09, 2012 5:17 PM
To: osmocom-pcu(a)lists.osmocom.org; openbts-discuss(a)lists.sourceforge.net
Subject: [Openbts-discuss] gprs PACCH downlink assignment problem
Hi,
My set is openbts-p2.8-gprs-exp/osmo-pcu-jolly. I encounter the problem
with
PACCH downlink assignment:
If the difference between FNs of DL_PACKET_DOWNLINK_ASSIGNMENT and
corresponding UL_PACKET_CONTROL_ACKNOWLEDGEMENT
is expected (RRBP = 0) 13 everything is OK (OpenBTS log):
1347379490.099008 3031505776: [ PCU -> BTS ] PACCH FN 2536893 FN52 21
CNTRL1
raw=(4f0800000c03400a0800802b2b2b2b2b2b2b2b2b2b2b2b)
DL_PACKET_DOWNLINK_ASSIGNMENT
1347379490.118500 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536885 FN52
13
DATA
raw=(100101cc741f3203c005650000014500003c00010000ff)
1347379490.136108 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536889 FN52
17
DATA
raw=(080105cc741f3228e2a8c8aa0100000100000000000003)
1347379490.154624 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536893 FN52
21
DATA
raw=(040107cc741f32777777066b616e6e656c036f72670000)
1347379490.215582 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536906 FN52
34
CNTRL1
raw=(400731d07ccb2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)UL_PACKET_CONTROL_ACKNOWLEDGEMENT
But it's not always the case
1349788219.582282 3043367792: [ PCU -> BTS ] PACCH FN 2189728 FN52 8
CNTRL1
raw=(4f0800000c02800a0d00802b2b2b2b2b2b2b2b2b2b2b2b)
DL_PACKET_DOWNLINK_ASSIGNMENT
1349788219.601978 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189720 FN52 0
DATA raw=(040103ae3558373751f40103e800101773022a85464200)
1349788219.620378 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189724 FN52 4
DATA raw=(0001042dae355837026a4e0432100000258ccc2b2b2b2b)
1349788219.638881 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189728 FN52 8
DATA raw=(040103ae3558373751f40103e800101773022a85464200)
1349788219.680973 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189737 FN52
17
CNTRL1
raw=(4006b8d560df2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)
UL_PACKET_CONTROL_ACKNOWLEDGEMENT
diff FN = 9, that causes the following behaviour in pcu:
<0002> gprs_rlcmac_data.cpp:1753 TBF: START TFI: 0 TLLI: 0xae355837
Packet
Downlink Assignment (PACCH)
<0004> gprs_rlcmac_data.cpp:1442 Complete DL frame for TBF=0: len=9
<0002> gprs_rlcmac_data.cpp:281 PACKET CONTROL ACK with unknown
FN=2163607
TLL=0xae355837 (TRX 0 TS 7)
<0002> gprs_rlcmac_data.cpp:100 Poll timeout for UL TBF=0
<0002> gprs_rlcmac_data.cpp:107 - Timeout for polling PACKET CONTROL ACK
for
PACKET UPLINK ACK
Any ideas? Is it the known issue?
Regards,
Vladimir Rolbin
--
Regards,
Ivan Kluchnikov.
http://fairwaves.ru
12 Oct
12 Oct
12:32 p.m.
Hi, Vladimir!
I fixed this problem with PDTCH channel and got rid of T3111, T3109
and T3101 timers.
Just update your repository.
I have two recommendations for tests:
1. Run osmo-pcu with parameters of your SIM card, for that use options:
-m --mcc MCC use given MCC instead of value provided by BTS
-n --mnc MNC use given MNC instead of value provided by BTS
Example:
./osmo-pcu -n 02 -m 250
2. Add config file to osmo-pcu/src directory, which you can find in attachment.
2012/10/11 Vladimir Rolbin <vrolbin(a)gmail.com>om>:
Hi, Ivan
Yes, the patch is applied..
It's not so clear the role of the timers mT3101, mT3111 and mT3109 for PDTCH
channel.
If I see well when "AccessGrantResponder -> LCH = gBTS.getPDTCH();" the
same
channel
is opened every time (it's never closed explicitly):
LogicalChannel::open(); -> L1FEC::open() -> mDecoder->open(); -> void
L1Decoder::open() ->
{
ScopedLock lock(mLock);
if (!mRunning) start();
mFER=0.0F;
mT3111.reset();
mT3109.reset();
mT3101.set();
mActive = true;
}
handleGoodFrame function is overridden, so the channel stops to be active
here after mT3101 is elapsed:
void XCCHL1Decoder::writeLowSide(const RxBurst& inBurst)
{
OBJLOG(DEBUG) <<"XCCHL1Decoder " << inBurst;
// If the channel is closed, ignore the burst.
if (!active()) {
OBJLOG(DEBUG) <<"XCCHL1Decoder not active, ignoring input";
return;
}
...
}
Pls advice..
Regards,
Vladimir
On Wed, Oct 10, 2012 at 6:13 PM, Ivan Kluchnikov
<Ivan.Kluchnikov(a)fairwaves.ru> wrote:
--
Regards,
Ivan Kluchnikov.
http://fairwaves.ru
Hi, Vladimir!
Hi, Vladimir!
I haven't any problems with downlink assignment and
PACKET_UPLINK_ACK_NACK now, but I will check it.
Please, check, have you applied this patch?
https://github.com/chemeris/openbts-p2.8/commit/bfa47ccfa26ab30b0232584ac67…
2012/10/10 Vladimir Rolbin <vrolbin(a)gmail.com>om>:
Similar problem with
DL_PACKET_UPLINK_ACK_NACK..., now logs are
synchronized:
BTS:
1349870962.242903 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543233 FN52
17
DATA raw=(0401018aae8c0f01c0050816083a853907018754033d89)
1349870962.261436 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543237 FN52
21
DATA raw=(000102058aae8c0f1b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)
1349870962.262173 3042884464: [ PCU -> BTS ] PCH: L2Length 11
primitive=UNIT_DATA raw=(063f300f40027d6ba40000d8aae8c0f81a022b2b2b2b)
1349870962.262261 3042884464: [ BTS -> PCU ] PhPchCnf:
2d063f300f40027d6ba40000d8aae8c0f81a022b2b2b2b
1349870962.263013 3042884464: [ PCU -> BTS ] PACCH FN 2543250 FN52 34
CNTRL1
raw=(4f2400208000000000000000f155d181e02b2b2b2b2b2b)
DL_PACKET_UPLINK_ACK_NACK
1349870962.283385 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543242 FN52
26
DATA raw=(0401018aae8c0f01c0050816083a853907018754033d89)
1349870962.302008 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543246 FN52
30
DATA raw=(000102058aae8c0f1b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)
1349870962.320769 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543250 FN52
34
DATA raw=(0401018aae8c0f01c0050816083a853907018754033d89)
1349870962.362534 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543259 FN52
43
CNTRL1 raw=(40062aba303f2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)
UL_PACKET_CONTROL_ACKNOWLEDGEMENT
1349870962.480042 3042884464: [ PCU -> BTS ] PDTCH: FN 2543298 FN52 30
DATA
raw=(0f01002541c001081501ff6cba2b2b2b2b2b2b2b2b2b2b)
PCU:
<0005> gprs_rlcmac_data.cpp:880 Decoded premier TLLI=0x8aae8c0f of UL
DATA
TBF=0.
<0005> gprs_rlcmac_data.cpp:743 Complete UL frame for TBF=0: len=17
<0008> gprs_rlcmac.cpp:1760 LLC [PCU -> SGSN] TFI: 0 TLLI: 0x8aae8c0f
len=17
<0008> gprs_bssgp_pcu.cpp:145 LLC [SGSN -> PCU] = TLLI: 0x8aae8c0f IMSI:
000
len: 9
<0002> gprs_rlcmac.cpp:354 Allocating DL TBF: TFI=0 TRX=0 MS_CLASS=10
<0002> gprs_rlcmac.cpp:948 - Setting Control TS 7
<0002> gprs_rlcmac_data.cpp:1804 TX: START TFI: 0 TLLI: 0x8aae8c0f
Immediate
Assignment Downlink (PCH)
<0002> gprs_rlcmac_data.cpp:281 PACKET CONTROL ACK with unknown
FN=2543259
TLL=0x8aae8c0f (TRX 0 TS 7)
<0002> gprs_rlcmac.cpp:895 Free UL TBF=0 with TLLI=0x8aae8c0f.
<0004> gprs_rlcmac_data.cpp:1456 Complete DL frame for TBF=0: len=9
<0002> gprs_rlcmac.cpp:895 Free DL TBF=0 with TLLI=0x8aae8c0f.
<0008> gprs_bssgp_pcu.cpp:145 LLC [SGSN -> PCU] = TLLI: 0x8aae8c0f IMSI:
000
len: 9
<0002> gprs_rlcmac.cpp:354 Allocating DL TBF: TFI=0 TRX=0 MS_CLASS=10
<0002> gprs_rlcmac.cpp:948 - Setting Control TS 7
<0002> gprs_rlcmac_data.cpp:1804 TX: START TFI: 0 TLLI: 0x8aae8c0f
Immediate
Assignment Downlink (PCH)
<0004> gprs_rlcmac_data.cpp:1456 Complete DL frame for TBF=0: len=9
<0002> gprs_rlcmac.cpp:895 Free DL TBF=0 with TLLI=0x8aae8c0f.
...
From: Vladimir Rolbin [mailto:vrolbin@gmail.com]
Sent: Tuesday, October 09, 2012 5:17 PM
To: osmocom-pcu(a)lists.osmocom.org; openbts-discuss(a)lists.sourceforge.net
Subject: [Openbts-discuss] gprs PACCH downlink assignment problem
Hi,
My set is openbts-p2.8-gprs-exp/osmo-pcu-jolly. I encounter the problem
with
PACCH downlink assignment:
If the difference between FNs of DL_PACKET_DOWNLINK_ASSIGNMENT and
corresponding UL_PACKET_CONTROL_ACKNOWLEDGEMENT
is expected (RRBP = 0) 13 everything is OK (OpenBTS log):
1347379490.099008 3031505776: [ PCU -> BTS ] PACCH FN 2536893 FN52 21
CNTRL1
raw=(4f0800000c03400a0800802b2b2b2b2b2b2b2b2b2b2b2b)
DL_PACKET_DOWNLINK_ASSIGNMENT
1347379490.118500 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536885 FN52
13
DATA raw=(100101cc741f3203c005650000014500003c00010000ff)
1347379490.136108 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536889 FN52
17
DATA raw=(080105cc741f3228e2a8c8aa0100000100000000000003)
1347379490.154624 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536893 FN52
21
DATA raw=(040107cc741f32777777066b616e6e656c036f72670000)
1347379490.215582 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536906 FN52
34
CNTRL1
raw=(400731d07ccb2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)UL_PACKET_CONTROL_ACKNOWLEDGEMENT
But it's not always the case
1349788219.582282 3043367792: [ PCU -> BTS ] PACCH FN 2189728 FN52 8
CNTRL1
raw=(4f0800000c02800a0d00802b2b2b2b2b2b2b2b2b2b2b2b)
DL_PACKET_DOWNLINK_ASSIGNMENT
1349788219.601978 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189720 FN52
0
DATA raw=(040103ae3558373751f40103e800101773022a85464200)
1349788219.620378 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189724 FN52
4
DATA raw=(0001042dae355837026a4e0432100000258ccc2b2b2b2b)
1349788219.638881 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189728 FN52
8
DATA raw=(040103ae3558373751f40103e800101773022a85464200)
1349788219.680973 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189737 FN52
17
CNTRL1 raw=(4006b8d560df2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)
UL_PACKET_CONTROL_ACKNOWLEDGEMENT
diff FN = 9, that causes the following behaviour in pcu:
<0002> gprs_rlcmac_data.cpp:1753 TBF: START TFI: 0 TLLI: 0xae355837
Packet
Downlink Assignment (PACCH)
<0004> gprs_rlcmac_data.cpp:1442 Complete DL frame for TBF=0: len=9
<0002> gprs_rlcmac_data.cpp:281 PACKET CONTROL ACK with unknown
FN=2163607
TLL=0xae355837 (TRX 0 TS 7)
<0002> gprs_rlcmac_data.cpp:100 Poll timeout for UL TBF=0
<0002> gprs_rlcmac_data.cpp:107 - Timeout for polling PACKET CONTROL ACK
for
PACKET UPLINK ACK
Any ideas? Is it the known issue?
Regards,
Vladimir Rolbin
--
Regards,
Ivan Kluchnikov.
http://fairwaves.ru
14 Oct
14 Oct
6:27 p.m.
Hi, Ivan
I've added the config file (thanks), but the parameter alloc-algorithm a I
have already set in pcu source before.
The only problem with MCC, MNC I've encountered is that osmo-sgsn rejects
SIMs not belonging
to configured MCC, MNC.. so will you explain the first recommendation?
Till today I used gnuradio 3.3.0/libusb 0.12. Today I tried unsuccessfully
to update the gnuradio to 4.3.2 version.
What versions of gnuradio and libusb are you currently using in your test
env?
I have different results for different UEs. I'am able to open
facebook.com(one of my tests) with about 80% success when testing
Samsung Z500, but
Sony Ericsson Z750i failes on attach request (it responses on imsi identity
request and
does not on imei identity request sending attach request many times till
cell reselection). What are your best results?
Regards,
Vladimir
On Fri, Oct 12, 2012 at 12:32 PM, Ivan Kluchnikov <
Ivan.Kluchnikov(a)fairwaves.ru> wrote:
Hi, Vladimir!
I fixed this problem with PDTCH channel and got rid of T3111, T3109
and T3101 timers.
Just update your repository.
I have two recommendations for tests:
1. Run osmo-pcu with parameters of your SIM card, for that use options:
-m --mcc MCC use given MCC instead of value provided by BTS
-n --mnc MNC use given MNC instead of value provided by BTS
Example:
./osmo-pcu -n 02 -m 250
2. Add config file to osmo-pcu/src directory, which you can find in
attachment.
2012/10/11 Vladimir Rolbin <vrolbin(a)gmail.com>om>:
--
Regards,
Ivan Kluchnikov.
http://fairwaves.ru
Hi, Ivan
Yes, the patch is applied..
It's not so clear the role of the timers mT3101, mT3111 and mT3109 for
PDTCH
channel.
If I see well when "AccessGrantResponder -> LCH = gBTS.getPDTCH();" the
same
channel
is opened every time (it's never closed explicitly):
LogicalChannel::open(); -> L1FEC::open() -> mDecoder->open(); -> void
L1Decoder::open() ->
{
ScopedLock lock(mLock);
if (!mRunning) start();
mFER=0.0F;
mT3111.reset();
mT3109.reset();
mT3101.set();
mActive = true;
}
handleGoodFrame function is overridden, so the channel stops to be active
here after mT3101 is elapsed:
void XCCHL1Decoder::writeLowSide(const RxBurst& inBurst)
{
OBJLOG(DEBUG) <<"XCCHL1Decoder " << inBurst;
// If the channel is closed, ignore the burst.
if (!active()) {
OBJLOG(DEBUG) <<"XCCHL1Decoder not active, ignoring input";
return;
}
...
}
Pls advice..
Regards,
Vladimir
On Wed, Oct 10, 2012 at 6:13 PM, Ivan Kluchnikov
<Ivan.Kluchnikov(a)fairwaves.ru> wrote:
>
> Hi, Vladimir!
>
>
> Hi, Vladimir!
>
> I haven't any problems with downlink assignment and
> PACKET_UPLINK_ACK_NACK now, but I will check it.
> Please, check, have you applied this patch?
>
>
https://github.com/chemeris/openbts-p2.8/commit/bfa47ccfa26ab30b0232584ac67…
>
>
> 2012/10/10 Vladimir Rolbin <vrolbin(a)gmail.com>om>:
> > Similar problem with DL_PACKET_UPLINK_ACK_NACK..., now logs are
> > synchronized:
> >
> > BTS:
> >
> > 1349870962.242903 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543233
FN52
> > 17
> > DATA raw=(0401018aae8c0f01c0050816083a853907018754033d89)
> > 1349870962.261436 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543237
FN52
> > 21
> > DATA raw=(000102058aae8c0f1b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)
> > 1349870962.262173 3042884464: [ PCU -> BTS ] PCH: L2Length 11
> > primitive=UNIT_DATA raw=(063f300f40027d6ba40000d8aae8c0f81a022b2b2b2b)
> > 1349870962.262261 3042884464: [ BTS -> PCU ] PhPchCnf:
> > 2d063f300f40027d6ba40000d8aae8c0f81a022b2b2b2b
> > 1349870962.263013 3042884464: [ PCU -> BTS ] PACCH FN 2543250 FN52 34
> > CNTRL1
> > raw=(4f2400208000000000000000f155d181e02b2b2b2b2b2b)
> > DL_PACKET_UPLINK_ACK_NACK
> > 1349870962.283385 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543242
FN52
> > 26
> > DATA raw=(0401018aae8c0f01c0050816083a853907018754033d89)
> > 1349870962.302008 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543246
FN52
> > 30
> > DATA raw=(000102058aae8c0f1b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)
> > 1349870962.320769 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543250
FN52
> > 34
> > DATA raw=(0401018aae8c0f01c0050816083a853907018754033d89)
> > 1349870962.362534 3064806256: [ BTS -> PCU ] PhDataInd: FN 2543259
FN52
> > 43
> > CNTRL1 raw=(40062aba303f2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)
> > UL_PACKET_CONTROL_ACKNOWLEDGEMENT
> > 1349870962.480042 3042884464: [ PCU -> BTS ] PDTCH: FN 2543298 FN52 30
> > DATA
> > raw=(0f01002541c001081501ff6cba2b2b2b2b2b2b2b2b2b2b)
> >
> > PCU:
> >
> > <0005> gprs_rlcmac_data.cpp:880 Decoded premier TLLI=0x8aae8c0f of UL
> > DATA
> > TBF=0.
> > <0005> gprs_rlcmac_data.cpp:743 Complete UL frame for TBF=0: len=17
> > <0008> gprs_rlcmac.cpp:1760 LLC [PCU -> SGSN] TFI: 0 TLLI: 0x8aae8c0f
> > len=17
> > <0008> gprs_bssgp_pcu.cpp:145 LLC [SGSN -> PCU] = TLLI: 0x8aae8c0f
IMSI:
> > 000
> > len: 9
> > <0002> gprs_rlcmac.cpp:354 Allocating DL TBF: TFI=0 TRX=0 MS_CLASS=10
> > <0002> gprs_rlcmac.cpp:948 - Setting Control TS 7
> > <0002> gprs_rlcmac_data.cpp:1804 TX: START TFI: 0 TLLI: 0x8aae8c0f
> > Immediate
> > Assignment Downlink (PCH)
> > <0002> gprs_rlcmac_data.cpp:281 PACKET CONTROL ACK with unknown
> > FN=2543259
> > TLL=0x8aae8c0f (TRX 0 TS 7)
> > <0002> gprs_rlcmac.cpp:895 Free UL TBF=0 with TLLI=0x8aae8c0f.
> > <0004> gprs_rlcmac_data.cpp:1456 Complete DL frame for TBF=0: len=9
> > <0002> gprs_rlcmac.cpp:895 Free DL TBF=0 with TLLI=0x8aae8c0f.
> > <0008> gprs_bssgp_pcu.cpp:145 LLC [SGSN -> PCU] = TLLI: 0x8aae8c0f
IMSI:
> > 000
> > len: 9
> > <0002> gprs_rlcmac.cpp:354 Allocating DL TBF: TFI=0 TRX=0 MS_CLASS=10
> > <0002> gprs_rlcmac.cpp:948 - Setting Control TS 7
> > <0002> gprs_rlcmac_data.cpp:1804 TX: START TFI: 0 TLLI: 0x8aae8c0f
> > Immediate
> > Assignment Downlink (PCH)
> > <0004> gprs_rlcmac_data.cpp:1456 Complete DL frame for TBF=0: len=9
> > <0002> gprs_rlcmac.cpp:895 Free DL TBF=0 with TLLI=0x8aae8c0f.
> >
> > ...
> >
> >
> >
> > From: Vladimir Rolbin [mailto:vrolbin@gmail.com]
> > Sent: Tuesday, October 09, 2012 5:17 PM
> > To: osmocom-pcu(a)lists.osmocom.org;
openbts-discuss(a)lists.sourceforge.net
> > Subject: [Openbts-discuss] gprs PACCH
downlink assignment problem
> >
> >
> >
> > Hi,
> >
> >
> >
> > My set is openbts-p2.8-gprs-exp/osmo-pcu-jolly. I encounter the
problem
> > with
> > PACCH downlink assignment:
> >
> >
> >
> > If the difference between FNs of DL_PACKET_DOWNLINK_ASSIGNMENT and
> > corresponding UL_PACKET_CONTROL_ACKNOWLEDGEMENT
> > is expected (RRBP = 0) 13 everything is OK (OpenBTS log):
> >
> >
> >
> > 1347379490.099008 3031505776: [ PCU -> BTS ] PACCH FN 2536893 FN52 21
> > CNTRL1
> > raw=(4f0800000c03400a0800802b2b2b2b2b2b2b2b2b2b2b2b)
> > DL_PACKET_DOWNLINK_ASSIGNMENT
> > 1347379490.118500 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536885
FN52
> > 13
> > DATA raw=(100101cc741f3203c005650000014500003c00010000ff)
> > 1347379490.136108 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536889
FN52
> > 17
> > DATA raw=(080105cc741f3228e2a8c8aa0100000100000000000003)
> > 1347379490.154624 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536893
FN52
> > 21
> > DATA raw=(040107cc741f32777777066b616e6e656c036f72670000)
> > 1347379490.215582 3063704432: [ BTS -> PCU ] PhDataInd: FN 2536906
FN52
> > 34
> > CNTRL1
> >
> >
raw=(400731d07ccb2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)UL_PACKET_CONTROL_ACKNOWLEDGEMENT
> >
> >
> >
> >
> >
> > But it's not always the case
> >
> >
> >
> > 1349788219.582282 3043367792: [ PCU -> BTS ] PACCH FN 2189728 FN52 8
> > CNTRL1
> > raw=(4f0800000c02800a0d00802b2b2b2b2b2b2b2b2b2b2b2b)
> > DL_PACKET_DOWNLINK_ASSIGNMENT
> > 1349788219.601978 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189720
FN52
> > 0
> > DATA raw=(040103ae3558373751f40103e800101773022a85464200)
> > 1349788219.620378 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189724
FN52
> > 4
> > DATA raw=(0001042dae355837026a4e0432100000258ccc2b2b2b2b)
> > 1349788219.638881 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189728
FN52
> > 8
> > DATA raw=(040103ae3558373751f40103e800101773022a85464200)
> > 1349788219.680973 3064179568: [ BTS -> PCU ] PhDataInd: FN 2189737
FN52
> > 17
> > CNTRL1 raw=(4006b8d560df2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b2b)
> > UL_PACKET_CONTROL_ACKNOWLEDGEMENT
> >
> >
> >
> > diff FN = 9, that causes the following behaviour in pcu:
> >
> >
> >
> > <0002> gprs_rlcmac_data.cpp:1753 TBF: START TFI: 0 TLLI: 0xae355837
> > Packet
> > Downlink Assignment (PACCH)
> > <0004> gprs_rlcmac_data.cpp:1442 Complete DL frame for TBF=0: len=9
> > <0002> gprs_rlcmac_data.cpp:281 PACKET CONTROL ACK with unknown
> > FN=2163607
> > TLL=0xae355837 (TRX 0 TS 7)
> > <0002> gprs_rlcmac_data.cpp:100 Poll timeout for UL TBF=0
> > <0002> gprs_rlcmac_data.cpp:107 - Timeout for polling PACKET CONTROL
ACK
for
PACKET UPLINK ACK
Any ideas? Is it the known issue?
Regards,
Vladimir Rolbin
--
Regards,
Ivan Kluchnikov.
http://fairwaves.ru
4234
days inactive
4238
days old
osmocom-net-gprs@lists.osmocom.org
4 comments
2 participants
participants (2)
-
Ivan Kluchnikov -
Vladimir Rolbin