8 Nov
2013
8 Nov
'13
5:17 p.m.
Hi Jason,
On Fri, Nov 08, 2013 at 01:21:46PM +0000, Jason DSouza wrote:
But I'm waiting at Opstart for Obj Class -
RADIO_CARRIER to trigger
trx-init() which is never received from BSC. That is where I'm struck
now. All this so far is similar to sysmobts interface, something
similar to bts_model_opstart() function in osmo-bts-sysmo.
Please see the following code from bts_ipaccess_nanobts.c:
==============
/* Callback function to be called whenever we get a GSM 12.21 state change event */
static int nm_statechg_event(int evt, struct nm_statechg_signal_data *nsd)
{
[...]
case NM_OC_RADIO_CARRIER:
trx = obj;
if (new_state->operational == NM_OPSTATE_DISABLED &&
new_state->availability == NM_AVSTATE_OK)
abis_nm_opstart(trx->bts, obj_class, trx->bts->bts_nr,
trx->nr, 0xff);
break;
==============
So the opstrart for the RADIO_CARRIER is sent in response to an incoming
NM_MT_STATECHG_EVENT_REP withe the operational state set to DISABLED and
the availability set to OK.
My guess is that you are not sending such a state event from the BTS to
the BSC. I can also not see that in the pcap file you have sent. All
OML messages in there relate to the Site MAnager or the BTS object
class, but there are no messages related to any other MOs.
As indicated, it is best to start from a known-working setup with a
supported BTS model, or at least from a protocol trace of an existing
supported configuration.
Please also make sure to set your 'bts model' to nanobts, I _think_ the
'bts model sysmobts' is still broken.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
8 Nov
8 Nov
6:33 p.m.
New subject: Openbsc support for new BTS
On Fri, Nov 08, 2013 at 05:17:46PM +0100, Harald Welte wrote:
Please also make sure to set your 'bts model'
to nanobts, I _think_ the
'bts model sysmobts' is still broken.
nope. I fixed it, even in mixed nanobts/sysmobts operation.
2 Dec
2 Dec
2:37 p.m.
New subject: Openbsc support for new BTS
Dear Harald,
Sorry for the delay in response. I was busy with the interface design and
coding.
On Fri, Nov 8, 2013 at 9:47 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
So the opstrart for the RADIO_CARRIER is sent in
response to an incoming
NM_MT_STATECHG_EVENT_REP withe the operational state set to DISABLED and
the availability set to OK.
My guess is that you are not sending such a state event from the BTS to
the BSC.
You were just spot on Harald. That's working now. Many thanks.
To update you further,
My development has gone ahead for quite some time now. Now I'm able to
configure TRX, configure TS and logical channels.
RTS indications(for SDCCH), Time indications and DATA requests are being
exchanged between osmobts - Octasic PHY.
And finally now I'm able to see the network. So far so good.
That said, I'm not able to latch to the network yet as I've not yet done
with my coding. Also I'm yet to get my GSM sim cards for testing.
Only then I will be able to test the rest (latching to the network and
voice calls).
Meantime I have some questions:
(1)
I'm not very clear on the usage of msgb data structure of libosmocore yet.
Ex: what's the significance of l1h, l2h ptrs in msgb.
l1p_msg->l2h = l1p_msg->data;
l1p_msg->l1h = msgb_push(l1p_msg, sizeof(*l1sap));
I also see that l1h points to the msgb->data itself. And there are lots of
typecasts happening as the L1 indications are being processed.
As of now I just allocate memory for msgb, (1032 bytes) and then memcopy
the L1 message to the msgb->data and set the msgb->data_len to the size of
L1 msg & msgb->len to 1032 for mainly RTS ind & RACH ind and it works. I
guess that's because maybe the msgb contents are not directly used as we
extract important fields into l1sap datastructure.
But I'm not too sure of that for DATA ind, for the voice traffic. I think I
only need to send the MS data content from the data indications as I'm L1
header decoding is not possible at openbsc side as it is PHY dependent.
Some pointers around here to make my understanding clear on what should be
the message content for msgb or l1sap when it is sent up in the uplink
direction in l1sap_up(), would be of great help.
(2)
In handle_ph_ra_ind() in l1_if.c od sysmobts, l1sap->u.rach_ind.chan_nr has
not been filled up with 0x88, that means it should always
call l1sap_handover_rach() in l1sap.c for every RACH for SDCCH. Is there
any other way of distinguishing if it is HO ACCESS or normal ACCESS? (This
was from code I downloaded, I don't know if this was fixed later??)
(3)
In the BSC config, encryption takes value of a5 0/1/2
Does 0 mean no encryption? If not how do I switch off encryption from
openbsc? Just skip that line in config?
(4)
Regarding the sharing of code on my new interface:
I'm yet to clean up my code and I think 1st release would be at least when
I'm able to latch to the MS.
I'm new to git repo, I will have to go through tutorials before I can
create new repo for sharing this new interface with openbsc.
Is there any central server where we can create such repo for openbsc?
I prefer to create a new repo as adding it to existing branch may break
other stuff of osmobts-trx and osmobts-sysmo.
May be once I have stable release we can merge it up with main branch.
Jason
11 Dec
11 Dec
1:17 a.m.
New subject: Openbsc support for new BTS
Hi Jason,
On Mon, Dec 02, 2013 at 07:07:02PM +0530, Jason Anoop wrote:
Sorry for the delay in response. I was busy with the
interface design and
coding.
I'm the one who took lots of time for the response this time :/
My development has gone ahead for quite some time now.
Now I'm able to
configure TRX, configure TS and logical channels.
great.
I'm not very clear on the usage of msgb data
structure of libosmocore yet.
Ex: what's the significance of l1h, l2h ptrs in msgb.
they should be pointing to the layer1 / layer2 header of a message.
What exactly is considered l1/l2/l3/... is dependent on the specific use
case / interface. We use msgb's for all types of GSM and non-gesm
interfaces, and their use is not always very consistent, sorry ;)
'msgb's are inspired by 'skb's (struct sk_buff) of the linux kernel, so
if you read up on linux skbs, it will help you will understand the idea
of msgbs.
l1p_msg->l2h = l1p_msg->data;
this sents the layer2 pointer (lapdm) to the data pointer.
l1p_msg->l1h = msgb_push(l1p_msg, sizeof(*l1sap));
msgb_push is pushing (prepending) data to the buffer. Basically
pre-pending the
I also see that l1h points to the msgb->data
itself. And there are lots of
typecasts happening as the L1 indications are being processed.
Those typecasts are likely hacks and should be revisited. Not every
developer (myself included) is showing the required discipline to do
things as they should be done. And the 'trx' branch you're working on
is a particularly recent part of code (and not yet merged to master), so
that might even show more of that.
As of now I just allocate memory for msgb, (1032
bytes) and then memcopy
the L1 message to the msgb->data and set the msgb->data_len to the size of
L1 msg & msgb->len to 1032 for mainly RTS ind & RACH ind and it works. I
guess that's because maybe the msgb contents are not directly used as we
extract important fields into l1sap datastructure.
Normally we would attempt to avoid such extra copies by allocating a
msgb and already reading the received l1 message (from a socket in your
case?) into the msgb. We would then process and possibly strip the
primitive header of your PHY and replace it with the primitive header
the trx branch uses, push that further up into the generic part of
osmo-bts, which then processes the layer2 payload in the LAPDm code. If
it is not a a fragment that needs defragmentation, we would then push
the RSL header in front and send the data out on the Abis interface
without ever copying any of the data. The only copies that happen are
from kernel->userspace (hidden in the read/recv system call from the PHY
interface), and the second copy when writing to the TCP socket sending
the RSL message.
This is particularly important when looking at traffic channel data,
of which there is much more than signalling frames. There's absolutely
no need to copy that data again and again.
header decoding is not possible at openbsc side as it
is PHY dependent.
Some pointers around here to make my understanding clear on what should be
the message content for msgb or l1sap when it is sent up in the uplink
direction in l1sap_up(), would be of great help.
I hope the explanation above gives you a general idea. For any more
detailed help, I would suggest publishing your patches / branch in a way
that it can be reviewed.
In handle_ph_ra_ind() in l1_if.c od sysmobts,
l1sap->u.rach_ind.chan_nr has not been filled up with 0x88, that means
it should always call l1sap_handover_rach() in l1sap.c for every RACH
for SDCCH. Is there any other way of distinguishing if it is HO ACCESS
or normal ACCESS?
the channel number will indicate if the RACH was received on an uplink
CCCH (RACH channel), or on a SDCCH or TCH. In the former case it is
normal access, in the latter case it must be handover access.
In the BSC config, encryption takes value of a5 0/1/2
Does 0 mean no encryption? If not how do I switch off encryption from
openbsc? Just skip that line in config?
A5/0 is specified as no encryption in the GSM specification, yes.
That's not OpenBSC specific.
Regarding the sharing of code on my new interface:
I'm yet to clean up my code and I think 1st release would be at least when
I'm able to latch to the MS.
Don't think in terms of releases. Have you seen any OsmoBTS releases
anywhere? There are none. Whatever any of our develoeprs works on, is
pushed to a branch in the repository. Even if its not finished yet,
sometimes even before it compiles. This is one way to get more people
to look at the code, before it gets too large/complex for anyone to
review ;) You're not delivering code to a customer, but you are
sharing it with other developers.
I'm new to git repo, I will have to go through
tutorials before I can
create new repo for sharing this new interface with openbsc.
Is there any central server where we can create such repo for openbsc?
OpenBSC should not really need any modifications, at least from what I
can tell. Assuming you meant OsmoBTS, then yes, we have git.osmocom.org
on which we can create new repositories - or of course branches to
existing repositories.
I prefer to create a new repo as adding it to existing
branch may break
other stuff of osmobts-trx and osmobts-sysmo.
The normal way we handle this is by having an additional branch on top
of the branch you forked from. A completely new repository isn't really
needed, just one more (or N more) new branches. The only part where you
have to be careful is to never push to master or somebody elses branch,
but only push to your personal branches.
May be once I have stable release we can merge it up
with main branch.
We'll see, code normally receives some review, and if you're unfamiliar
with the coding style and customs of the project, then typically
experience shows that the code will have to go through a few revisisons
before it can be merged.
What's also important is to have self-contained commits with proper
commit messages. Each logical change (like addition of an new feature,
fixing one bug) should be a separate commit.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
2 Jan
2 Jan
12:26 p.m.
New subject: Openbsc support for new BTS
Hello Harald,
Season's greetings! I was on Christmas vacation and just back in office
today.
Thank you for your time and patience to respond with the details of
standard message structure of osmocom coding style.
I'm sorry, at this point I'm not compliant with that and surely require
some effort on that front. Right now my priority was to make this piece of
software work with Octasic Phy and I'm very close to that and will update
you after the testing.
Right now the code is not very clean as I might not have followed osmocom
coding rules and needs to be cleaned up. But I'm trying to share the
OSMOBTS modifications with you. As I said I'm new to git, I'm just trying
by going through some tutorials.
I have local folder osmo-bts which was cloned from osmocom repo
git clone git://git.osmocom.org/osmo-bts.git
I then changed the branch to jolly/trx from master:
git checkout -b jolly/trx origin/jolly/trx
I then created my private branch:
git checkout -b jason-oct-phy
Then I have added all my changes into it.
I then added the modified files into git.
git add .
Then I commited the changes:
git commit -m "jason-oct-phy new branch - Initial commit"
Changed the author & email:
git config --global user.name "Jason"
git config --global user.email jason.anoop(a)gmail.com
updated the commit to reflect the above:
git commit --amend --reset-author
git log shows:
root@gsm-bss:/home/osmo-bts# git log
commit 9bd1926c1e105844ce3e8d39234c6aec9259cc27
Author: Jason <jason.anoop(a)gmail.com>
Date: Thu Jan 2 16:07:13 2014 +0530
jason-oct-phy new branch - Initial commit
I can see my branch active:
root@gsm-bss:/home/osmo-bts# git branch
* jason-oct-phy
jolly/trx
master
I see all my changes are commited:
root@gsm-bss:/home/osmo-bts# git status
# On branch jason-oct-phy
nothing to commit (working directory clean)
I can also see the diff between jolly/trx branch and my jason-oct-phy
branch.
git diff jolly/trx jason-oct-phy
However, when I try to push my branch changes to the repo, I fail.
root@gsm-bss:/home/osmo-bts# git push -u origin jason-oct-phy
fatal: remote error: access denied or repository not exported: /osmo-bts.git
Could you please help me if I'm missing something? Why am I not able to
push the changes? Thanks for your help in this regard.
Cheers!
Jason
17 Jan
17 Jan
5:11 p.m.
New subject: Openbsc support for new BTS
Hello Harald,
I wanted to discuss with you about two problems we are currently facing with openbsc and
octasic Phy.
(1)
During the configuration, openbsc takes quite a long time to configure all the physical
timeslots. Octasic phy configures those physical channels instantly and sends ack to
openbsc but openbsc state transition takes quite a long time to send the next physical
timeslot config. Is there anything we could do to make this faster?
(2)
In Openbsc all the physical timeslot configurations are done at one time at the beginning
and during calls only logical channels are configured and released but physical timeslots
are always configured.
We see a lot of unexpected channels are configured because of emergency calls and intruder
calls (may be surrounding disturbances).
Those unwanted calls are not going through though, they create unnecessary problems. I
have kept the auth policy as closed in the openbsc config.
Is there any way we can avoid those unwanted logical channel configurations happening for
emergency and other intruder calls ?
How about the possibility of configuring physical channel configurations along with
logical channel configurations on the go whenever ts is required? I understand Openbsc
behavior should be modified in that case.
Thanks in advance for your inputs on those.
Regarding sharing of the code, as I pointed out in my last email that I'm not able to
push the changes onto the branch (as in below email),
I'm also fine to share the tar file containing the changes if someone can help me
create a branch on git repo.
Thanks,
Jason
________________________________
From: Jason Anoop [jason.anoop(a)gmail.com]
Sent: Thursday, January 02, 2014 4:56 PM
To: Harald Welte
Cc: openbsc(a)lists.osmocom.org; Jason DSouza; Amit Singh
Subject: Re: Openbsc support for new BTS
Hello Harald,
Season's greetings! I was on Christmas vacation and just back in office today.
Thank you for your time and patience to respond with the details of standard message
structure of osmocom coding style.
I'm sorry, at this point I'm not compliant with that and surely require some
effort on that front. Right now my priority was to make this piece of software work with
Octasic Phy and I'm very close to that and will update you after the testing.
Right now the code is not very clean as I might not have followed osmocom coding rules and
needs to be cleaned up. But I'm trying to share the OSMOBTS modifications with you. As
I said I'm new to git, I'm just trying by going through some tutorials.
I have local folder osmo-bts which was cloned from osmocom repo
git clone git://git.osmocom.org/osmo-bts.git<http://git.osmocom.org/osmo-bts.git&g…
I then changed the branch to jolly/trx from master:
git checkout -b jolly/trx origin/jolly/trx
I then created my private branch:
git checkout -b jason-oct-phy
Then I have added all my changes into it.
I then added the modified files into git.
git add .
Then I commited the changes:
git commit -m "jason-oct-phy new branch - Initial commit"
Changed the author & email:
git config --global user.name<http://user.name> "Jason"
git config --global user.email jason.anoop@gmail.com<mailto:jason.anoop@gmail.com>
updated the commit to reflect the above:
git commit --amend --reset-author
git log shows:
root@gsm-bss:/home/osmo-bts# git log
commit 9bd1926c1e105844ce3e8d39234c6aec9259cc27
Author: Jason <jason.anoop@gmail.com<mailto:jason.anoop@gmail.com>>
Date: Thu Jan 2 16:07:13 2014 +0530
jason-oct-phy new branch - Initial commit
I can see my branch active:
root@gsm-bss:/home/osmo-bts# git branch
* jason-oct-phy
jolly/trx
master
I see all my changes are commited:
root@gsm-bss:/home/osmo-bts# git status
# On branch jason-oct-phy
nothing to commit (working directory clean)
I can also see the diff between jolly/trx branch and my jason-oct-phy branch.
git diff jolly/trx jason-oct-phy
However, when I try to push my branch changes to the repo, I fail.
root@gsm-bss:/home/osmo-bts# git push -u origin jason-oct-phy
fatal: remote error: access denied or repository not exported: /osmo-bts.git
Could you please help me if I'm missing something? Why am I not able to push the
changes? Thanks for your help in this regard.
Cheers!
Jason
5:50 p.m.
New subject: Openbsc support for new BTS
Hi Jason,
On Fri, Jan 17, 2014 at 04:11:46PM +0000, Jason DSouza wrote:
During the configuration, openbsc takes quite a long
time to configure
all the physical timeslots. Octasic phy configures those physical
channels instantly and sends ack to openbsc but openbsc state
transition takes quite a long time to send the next physical timeslot
config. Is there anything we could do to make this faster?
I don't think there are any delays in the OpenBSC codes, at least not
that I remember. The OML configuration on the sysmoBTS or nanoBTS takes
only seconds for a single TRX.
I would appreciate if you could send a pcap file of the complete Abis
dialogue betewen osmo-bts and openbsc so I can see what might be causing
the delay.
In Openbsc all the physical timeslot configurations
are done at one
time at the beginning and during calls only logical channels are
configured and released but physical timeslots are always configured.
correct.
We see a lot of unexpected channels are configured
because of
emergency calls and intruder calls (may be surrounding disturbances).
I suspect this is related to the fact that the RACH detection only has a
very weak CRC, which means that you get lots of false positives from
the PHY. Is that the case?
Those unwanted calls are not going through though,
they create
unnecessary problems. I have kept the auth policy as closed in the
openbsc config.
I would strongly argue against running any 'open' network outside a
faraday cage. So I believe you are doing it the 'right' way.
Is there any way we can avoid those unwanted logical
channel
configurations happening for emergency and other intruder calls ?
You can tune a lot of the parameters. In osmo-bts code itself, you can
set a threshold in terms of RxLevel or C/I (is that available for RACH
detection?) and drop all requests below a certain level or C/I
In the system information, you can play with paramters such as
Rx-Access-Level-Min.
If you have mobile phones with engineering modes, then you can set the
cell to barred in the SI and instruct your engineering mode phone to
ignore barred cells. This way no real other phones would actually
communicate with your cell.
Finally, you can of course always use a duplexer + attenuator + coaxial
cable between phone and BTS to avoid any interference from the real
networks surrounding you. We have some customers who use this with
cascaded splitters for up to 100 (!) mobile stations during device
testing. You need phones with an antenna connector, though.
How about the possibility of configuring physical
channel
configurations along with logical channel configurations on the go
whenever ts is required? I understand Openbsc behavior should be
modified in that case.
This is not supported by OpenBSC so far. It is a classic BSC with
static timeslot configurations. Our customers (or other production
users who are not our customers) so far didn't indicate a strong need for
dynamic allocation, so it is not implemented yet.
And yes, it would mean some architectural changes. If there is
[commercial] demand, or somebody seriously wants to contribute some time
and effort in implementing it, we would apprecaite that. Otherwise it's
just one of many potential wishlist items on a long list, sorry ;)
Regarding sharing of the code, as I pointed out in my
last email that
I'm not able to push the changes onto the branch (as in below email),
Sorry for not getting back on that. Like all Free Software projects I
know of, the git repositories only provide public read access. Write
access is permitted only via git-over-ssh, and we would need your ssh
public key. If you send that public key by private mail to me, I can
autorize you to commit to the repository.
Meanwhile, and independent of that, I suggest the use of 'git
send-email' on your series of commit, to generate a series of
automatically generated e-mail messages to the openbsc(a)lists.osmocom.org
mailing list for public review of the code. If you feel hesitant due to
not having done this with git before: feel free to do a test run to my
personal e-mail address and I'll let you know if everything has worked.
I'm also fine to share the tar file containing the
changes if someone
can help me create a branch on git repo.
Let's work on your git commit access and send the patch series by e-mail
meanwhile. Thanks!
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
21 Jan
21 Jan
1:51 p.m.
New subject: Openbsc support for new BTS
Hello Harald,
Thanks for your inputs.
On Fri, Jan 17, 2014 at 10:20 PM, Harald Welte <laforge(a)gnumonks.org> wrote:
I investigated this in osmobts. The delay was exactly 20 seconds per physical ts, thus
amounting around 160 seconds approx. The reason seems to be OML_PING_TIMER of 20 sec set
after LINK_STATE_CONNECT in abis_timeout() function. I guess that's the polling time
for the abis messages?
I do not think they are false positives from the phy, neither I think our CRC is weak.
Those are mainly the rach from real commercial phones around.
During the
configuration, openbsc takes quite a long time to configure all the physical timeslots.
I don't think there are any delays in the OpenBSC codes, at least not that I
remember.
The OML configuration on the sysmoBTS or nanoBTS takes only seconds for a single TRX.
We see a lot
of unexpected channels are configured
I suspect this is related to the fact that
the RACH detection only has a very weak CRC,
which means that you get lots of false positives from the PHY. Is that the case? I would strongly argue against running any
'open' network outside a faraday cage.
So I believe you are doing it the 'right' way.
Of course yes! Auth policy
in the config is always closed :)
You can tune a lot of the parameters.
In osmo-bts code itself, you can set a threshold in terms of RxLevel or C/I
and drop all requests below a certain level or C/I
I need to check the support for those messages in our L1.
In the system information, you can play with paramters
such as Rx-Access-Level-Min.
The parameter rxlev access min <0-63> in the openbsc config takes care of this?
But again, this is measurement information I guess and need to be supported by the phy.
Write access is permitted only via git-over-ssh, and
we would need your ssh public key.
If you send that public key by private mail to me, I can autorize you to commit to the
repository.
Ok I will do that in the separate email.
Thanks,
Jason
3:04 p.m.
New subject: Openbsc support for new BTS
Hi Jason,
On Tue, Jan 21, 2014 at 12:51:41PM +0000, Jason DSouza wrote:
I am not referring to your implementation, but to the general effects /
short-comings / implications of the GSM specification. As far as I
understand, you typically have lots of false positives as the CRC
_inside_ the RACH burst is so weak, that applying it to random noies
will still give you considerable number of hits.
But yes, if you actually operate with an antenna during R&D, then you
will likely see real RACH bursts of commercial phones.
The L1 just has to report RxLevel and C/I to osmo-bts, the rest is done
in osmo-bts.
This is a standard GSM radio parameter that will change behavior of the
MS. No support required in your PHY.
Regards,
Harald
--
- Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
which means
that you get lots of false positives from the PHY. Is
that the case?
I do not think they are false positives from the phy, neither I think
our CRC is weak. Those are mainly the rach from real commercial phones
around. In osmo-bts
code itself, you can set a threshold in terms of RxLevel
or C/I and drop all requests below a certain level or C/I
I need to check the support for those messages in our L1. In the system
information, you can play with paramters such as
Rx-Access-Level-Min.
The parameter rxlev access min <0-63> in the openbsc config takes care
of this? But again, this is measurement information I guess and need
to be supported by the phy.
3755
days inactive
3829
days old
8 comments
4 participants
participants (4)
-
Harald Welte -
Holger Hans Peter Freyther -
Jason Anoop -
Jason DSouza