An opportunity to learn> OpenBTS GPRS Troubleshooting ... #34
Comments
|
You can try giving the mobile more time to answer the block assignment by increasing the +8 at MAC.cpp:1365 if you get stuck there. The BSN is the base station internal sequence number and directly mapped to the frame number. |
|
Thanks for answering Daniel,
I will follow your suggestion, If I am not wrong it is just to change to +8
by another like +9 or +10 or so ... save, and re-compile again, correct?
And also, is my setup (VM Ubuntu 16.04 --- USB 3.0 ----- USRPB210) a
proper one for this experiment? I am worried that some how the VM introduces
delays so the cellphone never receiving or sending data at proper time....
Does GPRS work OK for you??? how many cellphones were you able to attach to
OpenBTS-GPRS at same time??? Is it normal that it losses GPRS connection
after having transmitted data packets for some time???
Thanks
2018-03-13 4:59 GMT-05:00 daniel-starke <[email protected]>:
… You can try giving the mobile more time to answer the block assignment by
increasing the +8 at MAC.cpp:1365
<https://github.com/RangeNetworks/openbts/blob/c438a5a689b32539d1c4ce8dd607d0231451faa9/GPRS/MAC.cpp#L1365>
if you get stuck there. The BSN is the base station internal sequence
number and directly mapped
<https://github.com/RangeNetworks/openbts/blob/c438a5a689b32539d1c4ce8dd607d0231451faa9/GPRS/RLC.cpp#L69>
to the frame number.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#34 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AF6sVAcusipcofjNGRS3poDSXflpPtT6ks5td5iMgaJpZM4SoVVv>
.
|
|
Correct. |
|
hello everyone. Well using the OpenBTS master version, I changed the "+8" on MAC.cpp:1365 for a "+9" and also for a "+10" and it just got worst ... if with +8 the cellphone attached to OpenBTS, with values =+9 or +10 it just attach and detach constantly ... so I decided to rollback to "+8". After install the hole thin again, and re-set some configuration, now the cellphone sees the network and it presents as if it is attached to a GPRS network but no data packet flow is noticed. The LOG: Mar 13 17:41:36 researcher openbts: DEBUG 32732:674 2018-03-13T17:41:36.7 MSInfo.cpp:227:msCleanUSFs: GPRS1,42807:CleanUSFs MS#1,TLLI=90560ac0 anyactiveuplinks=0 chcnt=1 freedusf=1 Mar 13 17:41:52 researcher openbts: DEBUG 32732:574 2018-03-13T17:41:52.9 MAC.cpp:1020:makeReservationInt: GPRS1,43621:makeReservation restype=ForRACH afterBSN=43623,fn=189033 mttype=0 rd->mRSSI=-10 rd->mTimingError=0 Mar 13 17:41:53 researcher openbts: DEBUG 32732:674 2018-03-13T17:41:53.1 MAC.cpp:1124:recvReservation: GPRS1,43627:recvReservationForRACH tbf=null bsn=43623 PDCH#512:2 A message that describes an ERROR on the below log is: SGSN:Premature end of GPRS GMM message type 1 AttachRequest I am about to quit ... somehow GPRS is not working for me ... any suggestions please? |
|
Ok. I can conclude this: For some reason, GPRS feature from OpenBTS does not work well on some cellphones. I was able to test a Lonet SIM808 module with OpenBTS GPRS. This module can connect to a GPRS network by the means of AT commands. These AT Commands you can send to the SIM808 through a serial monitor interface provided, for example, by an Arduino Mega 2560. More details here and here. I can say that all TCP connection establishment attempt against the OpenBTS GPRS network was successful and pings to an external IP address were successful too, of course there are some lost packets but nothing of that much of importance to think that there is something wrong with the radio link. My next target is to build a script on the Arduino IDE to program the SIM808 to send pings for 24 hours to the OpenBTS GPRS network so we can determine some reliability of the solution. Any suggestion or comment on this will be greatly appreciated. |
Can I use a € 5 gsm antenna to operate openbts? |
|
Yes, u can, and make sure VSWR parameter is below 2 and measure it, not just see the technical spec, measure it. Bad antennas can damage the PA on your SDR device. |
Hello people!
Please little bit of your help here. The following enumerated log corresponds to the attempt of a smartphone working only on 2G attempting to connect to the GPRS network established by OpenBTS, I think it corresponds to a TWO-PHASE ACCESS PROCEDURE on CCCH (described here) :
MAC.cpp:1020:makeReservationInt: GPRS1,401111:makeReservation restype=ForRACH afterBSN=401113,fn=1738156 mttype=0 rd->mRSSI=-21 rd->mTimingError=0
MAC.cpp:1056:makeReservationInt: GPRS1,401111: reservation result: bsn=401113 bsn.FN()=1738156 rrbp=0
MAC.cpp:1386:makeSingleBlockImmediateAssign: GPRS1,401111:serviceRACH at gBSNNext=401111 with reservation at RBN=401113=1738156 frames.
MAC.cpp:1407:makeSingleBlockImmediateAssign: GPRS1,401111:GPRS serviceRACH sending L3ImmediateAssignment:RR Immediate Assignment PageMode=(0) DedicatedModeOrTBF=(TMA=0 Downlink=0 DMOrTBF=1) ChannelDescription=(typeAndOffset=TCH/F TN=2 TSC=2 ARFCN=512) RequestReference=(RA=0x79 T=40833 T1'=30 T2=13 T3=33) TimingAdvance=0 Single Block Packet Uplink Assignment mAlpha=10 mGamma=31 TBFStartFrame=1738156=(T=40876 T1p=30 T3=25 T2=4)
MAC.cpp:2089:advanceBSNNext: GPRS1,401119:Reservation unanswered ForRACH ttype=0 TBF(null ptr) bsn=401113 fn=1738156res=( bsn=401113 ForRACH)
I think these GPRS Debug messages corresponds to this procedure:
MS ---------------------------------- BTS
----------- RACH --------------------->
<----------- IMM ASS ------------------
---- PCKT CONTROL ACK ------> <<<< FAIL TO ARRIVE AT OPENBTS !!!!
........................................................
What I ask from you here is to correct me on the assumptions that I am doing so I can get a guide to understand this no connection problem. My cellphone rarely connects to GPRS from OpenBTS and when it does it losses the GPRS connection after some time ... I think if I get to understand this and also with the support of GPRS Fundamentals (for example: here) it would be a good source for people that is hopping to get into how things work in GSM/GPRS. So my assumptions are as follows:
**BEFORE 1) and 2): **
At some previous point (maybe at BSN = 400945 or less), OpenBTS received a RACH message (RACH Procedure) from some cellphone. Now, the network has to answer with an Immediate Assignment to deliver Radio Resources to that cellphone, then ...
At 1) and 2):
The function called makeReservationInt from layer MAC (process taking place at BSN = 400946) performs a RRBP (Relative Reserved Block Period) reservation on a future BSN>=400949 (what is exactly BSN??) to expect and receive the Packet Control Acknowledgement (PCA) message from cellphone. I think it indicates at 1) that RACH message was received at frame number 1737445 and that establishment cause was LUR (Location Update Request, mttype=0) and that RSSI = -21dBm and zero timing error. At 2) it indicates that successfully reserved the BSN = 400949 to receive cellphone's PCA.
At 3) and 4)
It denotes the answer itself to the RACH message. The answer is called Immediate Assignment from OpenBTS to cellphone. The message is issued on Block Sequence Number = 400946 at Frame Number (FN) 1737445 (Here, which is the relationship between FN and BSN???). The Radio Resource Immediate Assignment message contains information of the Temporary Block Flow (TBF) that OpenBTS is reserving to "talk" with cellphone:
If the phone successfully receives this message then it will send a Packet Control ACK on BSN=400949 fn=1737445.
But at 5),
OpenBTS says that no answer from cellphone was received at BSN = 400949 fn = 1737445 and hence the TBF establishment was aborted. So, with no TBF, the cellphone does not continues with the following GPRS Attach Procedure, then no GMM protocol is activated, then no PDP Context is created and finally no GPRS data transfer is possible...
Questions:
Thanks so much for your patience and help.
The text was updated successfully, but these errors were encountered: