Openbsc support for new BTS

historical

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 at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)