Hey OpenBSC, Tom,
I've been working on getting OsmoBTS running on the recently open-sourced Range Networks RAD1 radio. The code is available here: https://github.com/kheimerl/vbts-openbts/tree/osmotrx. I am stuck now and I was hoping the mailing list might be able to provide some perspective.
With the RAD1, the system is beaconing correctly. However, phones are unable to camp. I logged a phone trying to camp on both the RAD1 and a B100 to compare the output and see if anything jumps out. The osmoBTS/osmo-nitb logs are seemingly identical, but the transceiver outputs are different. Both of the transceiver outputs are attached. The only big difference I see is in the "underflows" on the RAD1, which in my experience is a deal-breaker; that's not usually an easy fix.
Does anyone have a different perspective on what might be going on in here?
Thanks!
On Jan 9, 2014 3:26 PM, "Kurtis Heimerl" kheimerl@cs.berkeley.edu wrote:
With the RAD1, the system is beaconing correctly. However, phones are
unable to camp. I logged a phone trying to camp on both the RAD1 and a B100 to compare the output and see if anything jumps out. The osmoBTS/osmo-nitb logs are seemingly identical, but the transceiver outputs are different.
By beaconing correctly, you mean the handset recognize the network? Based on these logs, you're not receiving RACH bursts.
Both of the transceiver outputs are attached. The only big difference I see is in the "underflows" on the RAD1, which in my experience is a deal-breaker; that's not usually an easy fix.
This is unrelated to osmo-bts. The effect on performance will depend on the frequency of occurrence.
-TT
Thanks for the response! This level is a bit beyond where I normally work. Followup comments in line:
On Fri, Jan 10, 2014 at 3:39 AM, Tom Tsou tom@tsou.cc wrote:
On Jan 9, 2014 3:26 PM, "Kurtis Heimerl" kheimerl@cs.berkeley.edu wrote:
With the RAD1, the system is beaconing correctly. However, phones are
unable to camp. I logged a phone trying to camp on both the RAD1 and a B100 to compare the output and see if anything jumps out. The osmoBTS/osmo-nitb logs are seemingly identical, but the transceiver outputs are different.
By beaconing correctly, you mean the handset recognize the network?
Yep. When doing a scan it correctly identifies the new network.
Based on these logs, you're not receiving RACH bursts.
What makes you say that? I don't see RACHs in either log, but the phone camps in the 52M trace so it must have received a RACH. I do see attempts to decode a RACH in the RAD1 trace though...
Both of the transceiver outputs are attached. The only big difference I see is in the "underflows" on the RAD1, which in my experience is a deal-breaker; that's not usually an easy fix.
This is unrelated to osmo-bts. The effect on performance will depend on the frequency of occurrence.
My thought was that osmo-bts may not be producing enough packets (or something) causing it to underflow. Am I off base there?
-TT
On Fri, Jan 10, 2014 at 10:27 PM, Kurtis Heimerl kheimerl@cs.berkeley.edu wrote:
Yep. When doing a scan it correctly identifies the new network.
Based on these logs, you're not receiving RACH bursts.
What makes you say that? I don't see RACHs in either log, but the phone camps in the 52M trace so it must have received a RACH. I do see attempts to decode a RACH in the RAD1 trace though...
The logged RACH burst are below the detection threshold and subsequently dropped - most likely just noise. I assume you're lab testing, so signal strength should not be an issue. If you have logged SDCCH traffic (e.g. L3 registration), then the RACH got through at some point. You may be receiving RACH bursts, but there are no such transactions in the particular posted logs.
Both of the transceiver outputs are attached. The only big difference I see is in the "underflows" on the RAD1, which in my experience is a deal-breaker; that's not usually an easy fix.
This is unrelated to osmo-bts. The effect on performance will depend on the frequency of occurrence.
My thought was that osmo-bts may not be producing enough packets (or something) causing it to underflow. Am I off base there?
The sample stream going to the device is continuous in all transceiver cases regardless of what comes down from the upper layers. If osmo-bts or openbts submits less bursts than the other, filler bursts will be added. In other words, from the device I/O standpoint, there should be no difference between osmo-bts and openbts.
What happens if you start the transceiver and then shut down core while leaving the transceiver running? Underruns still present?
-TT
-
Kurtis Heimerl -
Tom Tsou