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

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@gmail.com] Sent: Thursday, January 02, 2014 4:56 PM To: Harald Welte Cc: openbsc@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.githttp://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.namehttp://user.name "Jason" git config --global user.email jason.anoop@gmail.commailto: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.commailto: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

Hello Harald, Thanks for your inputs.

On Fri, Jan 17, 2014 at 10:20 PM, Harald Welte laforge@gnumonks.org wrote:

...

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.

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?

...

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 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.

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