From: Kurtis H. <khe...@cs...> - 2012-03-28 17:41:17
|
My understanding is that if you don't have open registration turned on, OpenBTS will reject the handset during camping. The handset will remember this and reject any further attempts to camp on that tower explicitly. This seems to be the behavior you are seeing. On Wed, Mar 28, 2012 at 8:14 AM, Orkhan Badirkhanli <orx...@gm...> wrote: > Well, even when the handset was sending channel request message and then > connecting, it was first displaying "Network is no longer available" > message. Thus I think the problem is in something else. > > Right now I am testing with external clock(signal generator) connected as > opposed to past. > > As I turned the system on for the first time during the day and testing I > experienced the following. I ran the the openbts, sipauthserve(is there a > need to run the asterisk explicitly?) and wireshark. I chose the test > network in the list of operators and before I got "Network no longer > available" message, I fixed a channel request message in wireshark. > > The response message in the wireshark as displayed was "IMSI not found". Yes > I did not register my IMSI in the asterisk and in the log file I saw that > the system denied registration. So I am guessing that is the reason for > "Network no longer available". Is this right? > > After trying this for several time and seeing the wireshark packets sent > from phone and from the system, I decided to restart my system and try > everything again. > > But this time I saw saw no activity in the wireshark and along with getting > network not available messages, I was getting this continuously in the log > file: > > Mar 28 17:52:43 openbts: INFO 3045002096 > RadioResource.cpp:148:AccessGrantResponder: RA=0x2 when=0:1376661 age=5 > delay=0.683594 RSSI=-23 > > Mar 28 17:52:43 openbts: INFO 3045002096 > RadioResource.cpp:228:AccessGrantResponder: sending PageMode=(0) > DedicatedModeOrTBF=(TMA=0 Downlink=0 DMOrTBF=0) > ChannelDescription=(typeAndOffset=SDCCH/4-0 TN=0 TSC=2 ARFCN=613) > RequestReference=(RA=2 T1'=14 T2=13 T3=18) TimingAdvance=1 > > Mar 28 17:53:00 transceiver: ERR 3043343216 > UHDDevice.cpp:574:check_rx_md_err: An internal receive buffer has filled at > 125.99 sec. > > I was not getting the last message(ERR) everytime, but at some times. > > Do you have any suggestions? > > I think adjusting power levels is one step further, so thought I should be > all set with being able to successfully connecting > > Thanks everyone for consideration > > On Tue, Mar 27, 2012 at 5:25 AM, Thomas Tsou <tt...@vt...> wrote: >> >> On Mon, Mar 26, 2012 at 6:29 PM, Orkhan Badirkhanli <orx...@gm...> >> wrote: >> > Thomas >> > >> > In the setting where I only decreased the rxgain to 10dBm, the cell >> > phone >> > was sending a channel request message to OpenBTS as I was detecting the >> > packages through wireshark. >> >> Ok. >> >> > I noticed that even though the handset was showing OpenBTS in the list >> > of >> > operators from up to 20m with rooms in between, it was not sending a >> > request >> > channel message and was showing "No signal" sign. >> >> Note that the handset does not need to send a channel request every >> time it camps if it was connected to the BTS in a previous instance. >> >> > And yes, also in the room is LOS the handset was not sending request >> > channel >> > signal from longer than 2m. >> >> Is the handset still camping in these instances? or are getting "No >> signal" at just a few meters? >> >> Thomas > > > > > -- > Orkhan > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > |