Project

General

Profile

Bug #1747

ip.access nanobts: phone cannot be called while actively downloading

Added by neels over 3 years ago. Updated about 3 years ago.

Status:
Rejected
Priority:
Low
Assignee:
Category:
-
Target version:
-
Start date:
06/10/2016
Due date:
% Done:

0%

Spec Reference:

Description

During testing with another BTS (sysmoBTS), I found that GPRS service is
typically interrupted when an actively downloading phone is called.

Today, while testing dyn pdch on the ip.access nanobts, I found that while phone A
is actively downloading, phone B cannot call phone A.

At first I thought it was related to dyn pdch changes, but indeed the problem still exists
on the master branch, without dyn pdch being in use (5x TCH/F, 1x PDCH),
verified with openbsc.git 9329e6fb490960359d9b93d08585441d86f44b81 :

nitb log:

<0005> bsc_init.c:498 VTY at 127.0.0.1 4242
<001a> input/ipaccess.c:838 enabling ipaccess BSC mode
<0016> smpp_smsc.c:978 SMPP at 0.0.0.0 2775
<0005> bsc_hack.c:305 CTRL at 127.0.0.1 4249
DB: Database initialized.
DB: Database prepared.
<001a> input/ipa.c:265 accept()ed new link from 10.9.1.170 to port 3002
<001a> input/ipa.c:265 accept()ed new link from 10.9.1.170 to port 3003
<0004> bsc_init.c:287 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 868 using MCC=1 MNC=868 LAC=1 CID=0 BSIC=63
<0004> abis_rsl.c:1466 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(868) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x03 ta=0
<0004> abis_rsl.c:1202 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK
<0002> gsm_04_08.c:1166 LOCATION UPDATING REQUEST: MI(TMSI)=3486192556 type=IMSI ATTACH 
<0003> bsc_api.c:647 BSC: Passing unknown 04.08 RR message type 0x60 to MSC
<0003> gsm_04_08.c:1282 MSC: Unimplemented GSM 04.08 RR msg type 0x60
<0002> gsm_04_08.c:555 IDENTITY RESPONSE: MI(IMEI)=357737059672710
<0002> gsm_04_08.c:507 -> LOCATION UPDATE ACCEPT
<0002> gsm_04_08.c:880 -> MM INFO
<0002> gsm_subscriber.c:305 Subscriber 274018000000012 ATTACHED LAC=1
<0002> gsm_04_08.c:1180 TMSI Reallocation Completed. Subscriber: 274018000000012
<0004> abis_rsl.c:619 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD
<0004> abis_rsl.c:1106 (bts=0,trx=0,ts=0,ss=0): MEAS RES for inactive channel
<0004> abis_rsl.c:1106 (bts=0,trx=0,ts=0,ss=0): MEAS RES for inactive channel
<0004> abis_rsl.c:665 (bts=0,trx=0,ts=0,ss=0) RF Channel Release CMD due error 0
<0004> abis_rsl.c:721 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK
<0004> abis_rsl.c:1466 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(868) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x0c ta=0
<0004> abis_rsl.c:1202 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK
<0002> gsm_04_08.c:1166 LOCATION UPDATING REQUEST: MI(TMSI)=3454751355 type=IMSI ATTACH 
<0003> bsc_api.c:647 BSC: Passing unknown 04.08 RR message type 0x60 to MSC
<0003> gsm_04_08.c:1282 MSC: Unimplemented GSM 04.08 RR msg type 0x60
<0002> gsm_04_08.c:555 IDENTITY RESPONSE: MI(IMEI)=354716013859490
<0002> gsm_04_08.c:507 -> LOCATION UPDATE ACCEPT
<0002> gsm_04_08.c:880 -> MM INFO
<0002> gsm_subscriber.c:305 Subscriber 901990000000038 ATTACHED LAC=1
<0002> gsm_04_08.c:1180 TMSI Reallocation Completed. Subscriber: 901990000000038
<0004> abis_rsl.c:619 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD
<0004> abis_rsl.c:1106 (bts=0,trx=0,ts=0,ss=0): MEAS RES for inactive channel
<0004> abis_rsl.c:1106 (bts=0,trx=0,ts=0,ss=0): MEAS RES for inactive channel
<0004> abis_rsl.c:665 (bts=0,trx=0,ts=0,ss=0) RF Channel Release CMD due error 0
<0004> abis_rsl.c:721 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK

[ phone A starts downloading, phone B tries to call but can't get through ]

<0004> abis_rsl.c:1466 (bts=0,trx=0,ts=2,ss=0) Activating ARFCN(868) SS(0) lctype TCH/F r=CALL ra=0x48 ta=0
<0004> abis_rsl.c:1202 (bts=0,trx=0,ts=2,ss=0) CHANNEL ACTIVATE ACK
<0002> gsm_04_08.c:988 <- CM SERVICE REQUEST serv_type=0x01 MI(TMSI)=3505312560
<0002> gsm_04_08_utils.c:681 -> CM SERVICE ACK
<0003> bsc_api.c:647 BSC: Passing unknown 04.08 RR message type 0x60 to MSC
<0003> gsm_04_08.c:1282 MSC: Unimplemented GSM 04.08 RR msg type 0x60
<000a> bsc_api.c:402 Sending ChanModify for speech: SPEECH_V1 on channel TCH_F
<0002> gsm_subscriber.c:175 Subscriber 274018000000012 not paged yet.
<0004> abis_rsl.c:1868 (bts=0,trx=0,ts=2,ss=0) IPAC_BIND speech_mode=0x10 RTP_PAYLOAD=3
<0004> abis_rsl.c:1221 (bts=0,trx=0,ts=2,ss=0) CHANNEL MODE MODIFY ACK
<0004> abis_rsl.c:2032 (bts=0,trx=0,ts=2,ss=0) IPAC_CRCX_ACK LOCAL_IP=10.9.1.170 LOCAL_PORT=4026 CON_ID=29 
<0007> paging.c:111 No slots available on bts nr 0
<0004> abis_rsl.c:619 (bts=0,trx=0,ts=2,ss=0) DEACTivate SACCH CMD
<0004> abis_rsl.c:2051 (bts=0,trx=0,ts=2,ss=0) IPAC_DLCX_IND 
<0004> abis_rsl.c:665 (bts=0,trx=0,ts=2,ss=0) RF Channel Release CMD due error 0
<0004> abis_rsl.c:721 (bts=0,trx=0,ts=2,ss=0) RF CHANNEL RELEASE ACK
<0007> paging.c:111 No slots available on bts nr 0

[ phone A stops downloading, phone B can now call it: ]

<0004> abis_rsl.c:1466 (bts=0,trx=0,ts=2,ss=0) Activating ARFCN(868) SS(0) lctype TCH/F r=CALL ra=0x44 ta=0
<0004> abis_rsl.c:1202 (bts=0,trx=0,ts=2,ss=0) CHANNEL ACTIVATE ACK
<0002> gsm_04_08.c:988 <- CM SERVICE REQUEST serv_type=0x01 MI(TMSI)=3505312560
<0002> gsm_04_08_utils.c:681 -> CM SERVICE ACK
<0003> bsc_api.c:647 BSC: Passing unknown 04.08 RR message type 0x60 to MSC
<0003> gsm_04_08.c:1282 MSC: Unimplemented GSM 04.08 RR msg type 0x60
<000a> bsc_api.c:402 Sending ChanModify for speech: SPEECH_V1 on channel TCH_F
<0002> gsm_subscriber.c:175 Subscriber 274018000000012 not paged yet.
<0004> abis_rsl.c:1868 (bts=0,trx=0,ts=2,ss=0) IPAC_BIND speech_mode=0x10 RTP_PAYLOAD=3
<0004> abis_rsl.c:1221 (bts=0,trx=0,ts=2,ss=0) CHANNEL MODE MODIFY ACK
<0004> abis_rsl.c:2032 (bts=0,trx=0,ts=2,ss=0) IPAC_CRCX_ACK LOCAL_IP=10.9.1.170 LOCAL_PORT=4000 CON_ID=32 
<0004> abis_rsl.c:1466 (bts=0,trx=0,ts=3,ss=0) Activating ARFCN(868) SS(0) lctype TCH/F r=PAGING ra=0x26 ta=0
<0004> abis_rsl.c:1202 (bts=0,trx=0,ts=3,ss=0) CHANNEL ACTIVATE ACK
<0003> bsc_api.c:647 BSC: Passing unknown 04.08 RR message type 0x60 to MSC
<0003> gsm_04_08.c:1282 MSC: Unimplemented GSM 04.08 RR msg type 0x60
<000a> bsc_api.c:402 Sending ChanModify for speech: SPEECH_V1 on channel TCH_F
<0004> abis_rsl.c:1868 (bts=0,trx=0,ts=3,ss=0) IPAC_BIND speech_mode=0x10 RTP_PAYLOAD=3
<0004> abis_rsl.c:1221 (bts=0,trx=0,ts=3,ss=0) CHANNEL MODE MODIFY ACK
<0004> abis_rsl.c:2032 (bts=0,trx=0,ts=3,ss=0) IPAC_CRCX_ACK LOCAL_IP=10.9.1.170 LOCAL_PORT=4002 CON_ID=33 
<0004> abis_rsl.c:1907 (bts=0,trx=0,ts=3,ss=0) IPAC_MDCX IP=10.9.1.170 PORT=4000 RTP_PAYLOAD=3 RTP_PAYLOAD2=0 CONN_ID=33 speech_mode=0x00
<0004> abis_rsl.c:1907 (bts=0,trx=0,ts=2,ss=0) IPAC_MDCX IP=10.9.1.170 PORT=4002 RTP_PAYLOAD=3 RTP_PAYLOAD2=0 CONN_ID=32 speech_mode=0x00
<0004> abis_rsl.c:2042 (bts=0,trx=0,ts=3,ss=0) IPAC_MDCX_ACK CON_ID=33 
<0004> abis_rsl.c:2042 (bts=0,trx=0,ts=2,ss=0) IPAC_MDCX_ACK CON_ID=32 
<0004> abis_rsl.c:619 (bts=0,trx=0,ts=3,ss=0) DEACTivate SACCH CMD
<0004> abis_rsl.c:619 (bts=0,trx=0,ts=2,ss=0) DEACTivate SACCH CMD
<0004> abis_rsl.c:1106 (bts=0,trx=0,ts=2,ss=0): MEAS RES for inactive channel
<0004> abis_rsl.c:1106 (bts=0,trx=0,ts=3,ss=0): MEAS RES for inactive channel
<0004> abis_rsl.c:2051 (bts=0,trx=0,ts=3,ss=0) IPAC_DLCX_IND 
<0004> abis_rsl.c:665 (bts=0,trx=0,ts=3,ss=0) RF Channel Release CMD due error 0
<0004> abis_rsl.c:721 (bts=0,trx=0,ts=3,ss=0) RF CHANNEL RELEASE ACK
<0004> abis_rsl.c:2051 (bts=0,trx=0,ts=2,ss=0) IPAC_DLCX_IND 
<0004> abis_rsl.c:665 (bts=0,trx=0,ts=2,ss=0) RF Channel Release CMD due error 0
<0004> abis_rsl.c:721 (bts=0,trx=0,ts=2,ss=0) RF CHANNEL RELEASE ACK


Related issues

Related to OsmoMSC - Feature #1599: Gs interface (BSSMAP+) between SGSN and MSC/VLRNew02/23/2016

History

#1 Updated by laforge over 3 years ago

  • Assignee set to neels

This is the expected behavior unless/until there is some paging coordination between the CS and PS plane.

  • MSC sends paging request to BSC
  • BSC sends it to all BTSs in LAC
  • BTSs broadcast it on CCCH

However, as long as a TBF is active, the MS will not go back to the CCCH where it will receive the PCH. Rather, it stays on the TCH.

So what's required is some way for the circuit-switched paging message to be delivered to the MS via GPRS on the PDCH.

I'm actually surprised you observe different behavior with other BTSs like OsmoBTS. This probably just means that OsmoBTS is more frequently/rapidly releasing the MS to camp back on the CCCH where it will receive the paging on PCH, while the nanoBTS PCU keeps the TBF open at all times?

#2 Updated by laforge over 3 years ago

  • Related to Feature #1599: Gs interface (BSSMAP+) between SGSN and MSC/VLR added

#3 Updated by neels over 3 years ago

laforge wrote:

I'm actually surprised you observe different behavior with other BTSs like OsmoBTS.

With SysmoBTS, when A calls B, B very reliably stops GPRS ("the GPRS icon disappears",
downloads cease). So far it made the impression to be intentional and immediate...

#4 Updated by neels about 3 years ago

  • Priority changed from Normal to Low

#5 Updated by laforge about 3 years ago

  • Status changed from New to Rejected

actually, OsmoBTS is passing the CS-paging via the pcu_socket into osmo-pcu which then delivers it via the active TBF to the MS, so the MS can suspend GPRS services and answer the CS paging.

It simply seems that the nanoBTS doesn't support this feature, or that it might require some extra signalling related work from our side to support it.

Let's reject this until somebody with a strong interest in nanoBTS actually considers it useful to investigate this further.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)