OpenBSC

openbsc@lists.osmocom.org

16 participants
4280 discussions

GPRS, EDGE support
by Sipos Csaba 27 Jan '14

27 Jan '14

Hi Guys, I just wanted to ask a few questions about packet data availability/support, because I did not find the specifics on the site. 1. Is there a working GPRS/EDGE implementation in the moment? If not, what is the plan or the state of the development process? 2. Which hardware should I buy, if I want to play with GPRS/EDGE? I am thinking about USRP or BladeRF, but maybe there is a better alternative. I am willing to spend more in order to get a more future proof unit (for example: to have a unit which is capable of doing EDGE if and when it is going to be supported). 3. This is not related to packet data. I wonder if I buy a USRP unit , it is possible to configure and use one USRP device with more than one TRX? In general, I think a lot of people are interested in packet data and OpenBSC/OpenBTS, it would be nice to clarify these informations on the site. BR, Csaba

10 32

Control interface and counters
by Holger Hans Peter Freyther 26 Jan '14

26 Jan '14

Dear Ivan, I noticed that you added a lot of commands to query counters. When we are designing the interface we made sure to add wildcard commands. So most counters can be already read without adding a special command for that. holger

2 2

Re: RF power problems with current master of osmo-trx
by Alexander Chemeris 25 Jan '14

25 Jan '14

Hi Thomas, I'm moving this discussion to the OpenBSC mailing list, as it has nothing to do with UmTRX, but rather with OsmoTRX. On Sat, Jan 25, 2014 at 11:36 AM, Tom Tsou <tom(a)tsou.cc> wrote: > On Sat, Jan 25, 2014 at 1:22 AM, Andreas Eversberg <andreas(a)eversberg.eu> wrote: >> once a channel was activeated, >> there will be RF power on the specific TS, even when osmo-bts does not send >> bursts anymore. i guess that some filler table of osmo-trx causes it. i >> think it would be nice if osmo-trx would stop transmitting, when there are >> no more bursts comming from osmo-bts. (at least after a while.) > > Yes, this is the behaviour of the filler table, which will resend the > previous frame until a new frame arrives. Sending an idle frame will > disable output, which is how the filler table is managed in OpenBTS. > You can disable the filler table with this patch. Could you make this configurable from the command line or from the socket control interface? I believe we should leave filler table as the default option, but allow one to disable it when OsmoTRX is used with OsmoBTS. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru

3 3

OsmoBTS branch for network_from_scratch.
by Andrew Back 25 Jan '14

25 Jan '14

Hello, When following the network_from_scratch instructions with a Linaro Ubuntu 12.11 host, I encountered a build error when it came to OsmoBTS: linaro-ubuntu-desktop:~/osmocom/osmo-bts> make Making all in include make[1]: Entering directory `/home/linaro/osmocom/osmo-bts/include' Making all in osmo-bts make[2]: Entering directory `/home/linaro/osmocom/osmo-bts/include/osmo-bts' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/home/linaro/osmocom/osmo-bts/include/osmo-bts' make[2]: Entering directory `/home/linaro/osmocom/osmo-bts/include' make[2]: Nothing to be done for `all-am'. make[2]: Leaving directory `/home/linaro/osmocom/osmo-bts/include' make[1]: Leaving directory `/home/linaro/osmocom/osmo-bts/include' Making all in src make[1]: Entering directory `/home/linaro/osmocom/osmo-bts/src' Making all in common make[2]: Entering directory `/home/linaro/osmocom/osmo-bts/src/common' CC gsm_data_shared.o CC sysinfo.o CC logging.o CC abis.o abis.c: In function ‘abis_sock_cb’: abis.c:360:2: warning: #warning HACK [-Wcpp] CC oml.o oml.c: In function ‘rx_oml_ipa_rsl_connect’: oml.c:1049:17: warning: assignment from incompatible pointer type [enabled by default] oml.c:1053:2: warning: passing argument 1 of ‘abis_open’ from incompatible pointer type [enabled by default] ../../include/osmo-bts/abis.h:35:5: note: expected ‘struct ipabis_link *’ but argument is of type ‘struct e1inp_sign_link *’ CC bts.o CC rsl.o rsl.c:140:2: warning: #warning merge lchan_lookup with OpenBSC [-Wcpp] rsl.c: In function ‘get_rsl_local_ip’: rsl.c:1265:32: error: ‘struct e1inp_sign_link’ has no member named ‘bfd’ rsl.c: In function ‘rsl_rx_ipac_XXcx’: rsl.c:1398:5: warning: initialization from incompatible pointer type [enabled by default] make[2]: *** [rsl.o] Error 1 make[2]: Leaving directory `/home/linaro/osmocom/osmo-bts/src/common' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/linaro/osmocom/osmo-bts/src' make: *** [all-recursive] Error 1 linaro-ubuntu-desktop:~/osmocom/osmo-bts> This was resolved by building from branch jolly/trx_rebased instead of jolly/trx. Should we now be using the rebased branch? If so I will update the wiki. Regards, Andrew -- Andrew Back http://carrierdetect.com

2 1

Re: Re[2]: GPRS, EDGE support
by Don Fanning 25 Jan '14

25 Jan '14

Again, I can't speak to the USRP or BladeRF. OpenBTS is a completely different project with a completely different scope. The projects share very little of a common code base therefore I would consider it incompatible as architecturally they are night and day. OpenBTS is a hack of GSM protocol while OpenBSC is a emulation of the GSM/GPRS mobile network infrastructure. If I had to recommend available compatible hardware, I would suggest community based hardware like Harald's own sysmoBTS or Alexander's UmTRX. On Thu, Jan 23, 2014 at 9:37 AM, Sipos Csaba <dchardware(a)gmail.com> wrote: > Hi Don, > > > Thanks for the answer. > > > THe problem with nanobts that it is unaccessible, and even when it turns > up on ebay, it costs a fortune. > > > I'd rather pay that fortune for an USRP or half that fortune for a > bladerf, and I will have an SDR which I can use not only as a BTS. > > > So, at the moment GPRS/EDGE is only possible with nanoBTS? What about USRP > or BladeRF running OpenBTS? > > > BR, > > Csaba > > > > There has been a working GPRS stack for a while now: > > http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS > > > As for USRP or OpenBTS, I cannot comment upon having never used either > platform. >

1 0

[PATCH] lapd/test: Add test case for RSL EST REQ -> LAPD
by Jacob Erlbeck 24 Jan '14

24 Jan '14

This test case processes RSL establish requests for SMS (SAPI 3) on the SDCCH and the SACCH channels. The TX queues are checked after processing each message. Ticket: #225 Sponsored-by: On-Waves ehf --- tests/lapd/lapd_test.c | 120 +++++++++++++++++++++++++++++++++++++++++------ tests/lapd/lapd_test.ok | 7 +++ 2 files changed, 112 insertions(+), 15 deletions(-) diff --git a/tests/lapd/lapd_test.c b/tests/lapd/lapd_test.c index 37c0db8..b4594de 100644 --- a/tests/lapd/lapd_test.c +++ b/tests/lapd/lapd_test.c @@ -80,6 +80,14 @@ static const uint8_t rel_req[] = { 0x02, 0x07, 0x01, 0x0a, 0x02, 0x40, 0x14, 0x01 }; +static const uint8_t est_req_sdcch_sapi3[] = { + 0x02, 0x04, 0x01, 0x20, 0x02, 0x03 +}; + +static const uint8_t est_req_sacch_sapi3[] = { + 0x02, 0x04, 0x01, 0x0b, 0x02, 0x43 +}; + static struct msgb *create_cm_serv_req(void) { struct msgb *msg; @@ -131,6 +139,16 @@ static struct msgb *create_rel_req(void) return msg; } +static struct msgb *create_est_req(const uint8_t *est_req, size_t est_req_size) +{ + struct msgb *msg; + + msg = msgb_from_array(est_req, est_req_size); + msg->l2h = msg->data; + msg->l3h = msg->l2h + sizeof(struct abis_rsl_rll_hdr); + return msg; +} + static int send(struct msgb *in_msg, struct lapdm_channel *chan) { struct osmo_phsap_prim pp; @@ -350,6 +368,52 @@ static void test_lapdm_polling() lapdm_channel_exit(&ms_to_bts_channel); } +static void test_lapdm_contention_resolution() +{ + printf("I test contention resultion by having two mobiles collide and " + "first mobile repeating SABM.\n"); + + int rc; + struct lapdm_polling_state test_state; + struct osmo_phsap_prim pp; + + /* Configure LAPDm on both sides */ + struct lapdm_channel bts_to_ms_channel; + memset(&bts_to_ms_channel, 0, sizeof(bts_to_ms_channel)); + + memset(&test_state, 0, sizeof(test_state)); + test_state.bts = &bts_to_ms_channel; + + /* BTS to MS in polling mode */ + lapdm_channel_init(&bts_to_ms_channel, LAPDM_MODE_BTS); + lapdm_channel_set_flags(&bts_to_ms_channel, LAPDM_ENT_F_POLLING_ONLY); + lapdm_channel_set_l1(&bts_to_ms_channel, NULL, &test_state); + lapdm_channel_set_l3(&bts_to_ms_channel, bts_to_ms_tx_cb, &test_state); + + /* Send SABM MS 1, we must get UA */ + send_sabm(&bts_to_ms_channel, 0); + rc = lapdm_phsap_dequeue_prim(&bts_to_ms_channel.lapdm_dcch, &pp); + CHECK_RC(rc); + OSMO_ASSERT(memcmp(pp.oph.msg->l2h, ua, ARRAY_SIZE(ua)) == 0); + + /* Send SABM MS 2, we must get nothing, due to collision */ + send_sabm(&bts_to_ms_channel, 1); + rc = lapdm_phsap_dequeue_prim(&bts_to_ms_channel.lapdm_dcch, &pp); + OSMO_ASSERT(rc == -ENODEV); + + /* Send SABM MS 1 again, we must get UA gain */ + send_sabm(&bts_to_ms_channel, 0); + rc = lapdm_phsap_dequeue_prim(&bts_to_ms_channel.lapdm_dcch, &pp); + CHECK_RC(rc); + OSMO_ASSERT(memcmp(pp.oph.msg->l2h, ua, ARRAY_SIZE(ua)) == 0); + + /* clean up */ + lapdm_channel_exit(&bts_to_ms_channel); + + /* idempotent */ + lapdm_channel_exit(&bts_to_ms_channel); +} + static void test_lapdm_early_release() { printf("I test RF channel release of an unestablished channel.\n"); @@ -381,14 +445,13 @@ static void test_lapdm_early_release() lapdm_channel_exit(&bts_to_ms_channel); } -static void test_lapdm_contention_resolution() +static void lapdm_establish(const uint8_t *est_req, size_t est_req_size) { - printf("I test contention resultion by having two mobiles collide and " - "first mobile repeating SABM.\n"); - int rc; struct lapdm_polling_state test_state; struct osmo_phsap_prim pp; + struct msgb *msg; + const char *queue_name; /* Configure LAPDm on both sides */ struct lapdm_channel bts_to_ms_channel; @@ -403,22 +466,39 @@ static void test_lapdm_contention_resolution() lapdm_channel_set_l1(&bts_to_ms_channel, NULL, &test_state); lapdm_channel_set_l3(&bts_to_ms_channel, bts_to_ms_tx_cb, &test_state); - /* Send SABM MS 1, we must get UA */ - send_sabm(&bts_to_ms_channel, 0); + /* Send the release request */ + msg = create_est_req(est_req, est_req_size); + rc = lapdm_rslms_recvmsg(msg, &bts_to_ms_channel); + fprintf(stderr, "recvmsg: got rc %d: %s\n", rc, rc <= 0 ? strerror(-rc) : "???"); + OSMO_ASSERT(rc == 0); + + /* Take message from queue */ rc = lapdm_phsap_dequeue_prim(&bts_to_ms_channel.lapdm_dcch, &pp); + if (rc >= 0) + queue_name = "DCCH"; + else { + rc = lapdm_phsap_dequeue_prim(&bts_to_ms_channel.lapdm_acch, &pp); + if (rc >= 0) + queue_name = "ACCH"; + } + + fprintf(stderr, "dequeue: got rc %d: %s\n", rc, + rc <= 0 ? strerror(-rc) : "-"); CHECK_RC(rc); - OSMO_ASSERT(memcmp(pp.oph.msg->l2h, ua, ARRAY_SIZE(ua)) == 0); - /* Send SABM MS 2, we must get nothing, due to collision */ - send_sabm(&bts_to_ms_channel, 1); - rc = lapdm_phsap_dequeue_prim(&bts_to_ms_channel.lapdm_dcch, &pp); - OSMO_ASSERT(rc == -ENODEV); + printf("Took message from %s queue: L2 header size %d, " + "SAP %#x, %d/%d, Link 0x%02x\n", + queue_name, msgb_l2len(pp.oph.msg) - msgb_l3len(pp.oph.msg), + pp.oph.sap, pp.oph.primitive, pp.oph.operation, + pp.u.data.link_id); + printf("Message: %s\n", osmo_hexdump(pp.oph.msg->data, pp.oph.msg->len)); + + OSMO_ASSERT(pp.oph.msg->data == msgb_l2(pp.oph.msg)); - /* Send SABM MS 1 again, we must get UA gain */ - send_sabm(&bts_to_ms_channel, 0); rc = lapdm_phsap_dequeue_prim(&bts_to_ms_channel.lapdm_dcch, &pp); - CHECK_RC(rc); - OSMO_ASSERT(memcmp(pp.oph.msg->l2h, ua, ARRAY_SIZE(ua)) == 0); + OSMO_ASSERT(rc < 0); + rc = lapdm_phsap_dequeue_prim(&bts_to_ms_channel.lapdm_acch, &pp); + OSMO_ASSERT(rc < 0); /* clean up */ lapdm_channel_exit(&bts_to_ms_channel); @@ -427,6 +507,15 @@ static void test_lapdm_contention_resolution() lapdm_channel_exit(&bts_to_ms_channel); } +static void test_lapdm_establishment() +{ + printf("I test RF channel establishment.\n"); + printf("Testing SAPI3/SDCCH\n"); + lapdm_establish(est_req_sdcch_sapi3, sizeof(est_req_sdcch_sapi3)); + printf("Testing SAPI3/SACCH\n"); + lapdm_establish(est_req_sacch_sapi3, sizeof(est_req_sacch_sapi3)); +} + int main(int argc, char **argv) { osmo_init_logging(&info); @@ -434,6 +523,7 @@ int main(int argc, char **argv) test_lapdm_polling(); test_lapdm_early_release(); test_lapdm_contention_resolution(); + test_lapdm_establishment(); printf("Success.\n"); return 0; diff --git a/tests/lapd/lapd_test.ok b/tests/lapd/lapd_test.ok index 27389bf..e4b1359 100644 --- a/tests/lapd/lapd_test.ok +++ b/tests/lapd/lapd_test.ok @@ -21,4 +21,11 @@ I test RF channel release of an unestablished channel. I test contention resultion by having two mobiles collide and first mobile repeating SABM. bts_to_ms_tx_cb: MS->BTS(us) message 25 BTS: Verifying CM request. +I test RF channel establishment. +Testing SAPI3/SDCCH +Took message from DCCH queue: L2 header size 3, SAP 0x1000000, 0/0, Link 0x03 +Message: 0f 3f 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b +Testing SAPI3/SACCH +Took message from ACCH queue: L2 header size 5, SAP 0x1000000, 0/0, Link 0x43 +Message: 00 00 0f 3f 01 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b Success. -- 1.7.9.5

1 0

RE: Re[2]: GPRS, EDGE support
by Ralph A. Schmid, dk5ras 24 Jan '14

24 Jan '14

OpenBTS supports GPRS, but at least for me it does not work very reliably, I consider this only a proof of concept. While voice/SMS range is up to 200m, GPRS breaks down after 5m (!) distance, and the connection stalls after a while, requiring a restart of OpenBTS. I am using an USRP1 with WBX board. Ralph. From: openbsc-bounces(a)lists.osmocom.org [mailto:openbsc-bounces@lists.osmocom.org] On Behalf Of Sipos Csaba Sent: Thursday, 23 January, 2014 18:37 To: Don Fanning Cc: openbsc(a)lists.osmocom.org Subject: Re[2]: GPRS, EDGE support Hi Don, Thanks for the answer. THe problem with nanobts that it is unaccessible, and even when it turns up on ebay, it costs a fortune. I'd rather pay that fortune for an USRP or half that fortune for a bladerf, and I will have an SDR which I can use not only as a BTS. So, at the moment GPRS/EDGE is only possible with nanoBTS? What about USRP or BladeRF running OpenBTS? BR, Csaba There has been a working GPRS stack for a while now: http://openbsc.osmocom.org/trac/wiki/OpenBSC_GPRS As for USRP or OpenBTS, I cannot comment upon having never used either platform.

2 2

RE: Re[4]: GPRS, EDGE support
by Ralph A. Schmid, dk5ras 24 Jan '14

24 Jan '14

Well, at least voice and SMS is not affected and works just great. GPRS uses only an open power control, no closed loop, maybe it has to do with this? At the moment I do not have other hardware for comparison, so digging deeper into this may be not so useful. The issue is discussed on the OpenBTS mailing list, with no clear results at the moment. Ralph. From: Sipos Csaba [mailto:dchardware@gmail.com] Sent: Thursday, 23 January, 2014 22:01 To: Ralph A. Schmid, dk5ras Cc: 'Don Fanning'; openbsc(a)lists.osmocom.org Subject: Re[4]: GPRS, EDGE support Thanks for the info! At least now I know, that the GPRS/EDGE is part of the OpenBTS code, so any hardware is OK for packet data which can run OpenBTS. That is good news. Anyway, it is just an educated guess, but don't you think your problem with GPRS is related to timing? My experience with real life networks clearly shows that even a slight timing related problem or inaccuracy can led to something like that. My other experience is with R&S CMW500, which I used with a little external antenna and encountered the same problem. After a few meters even the voice calls started to drop with -60 RSSI. The reason was obvious: the device lacks any filters on the input chain (it is designed for production mode), and when all the received RF energy hits the receiver from all the bands, it causes problems like that. And the packet data was way more sensitive to this than voice calls. After installing proper filters, the problem is gone. BR, Csaba OpenBTS supports GPRS, but at least for me it does not work very reliably, I consider this only a proof of concept. While voice/SMS range is up to 200m, GPRS breaks down after 5m (!) distance, and the connection stalls after a while, requiring a restart of OpenBTS. I am using an USRP1 with WBX board. Ralph.

1 0

Re: Re[4]: GPRS, EDGE support
by Alexander Chemeris 24 Jan '14

24 Jan '14

Csaba, We use UmTRX routinely to develop GPRS code for OpenBSC and it works well. I can't say much about other SDR equipment, but we have some timing related bugs with USRP1 based devices of one of our customers. Regarding the official OpenBTS GPRS code - we've never tried to run it, but looking into the code, it lacks quite a few features the OpenBSC implementation has. On Fri, Jan 24, 2014 at 1:01 AM, Sipos Csaba <dchardware(a)gmail.com> wrote: > Thanks for the info! > > > At least now I know, that the GPRS/EDGE is part of the OpenBTS code, so > any hardware is OK for packet data which can run OpenBTS. That is good news. > > > Anyway, it is just an educated guess, but don't you think your problem > with GPRS is related to timing? My experience with real life networks > clearly shows that even a slight timing related problem or inaccuracy can > led to something like that. > > > My other experience is with R&S CMW500, which I used with a little > external antenna and encountered the same problem. After a few meters even > the voice calls started to drop with -60 RSSI. The reason was obvious: the > device lacks any filters on the input chain (it is designed for production > mode), and when all the received RF energy hits the receiver from all the > bands, it causes problems like that. And the packet data was way more > sensitive to this than voice calls. After installing proper filters, the > problem is gone. > > > BR, > > Csaba > > > > OpenBTS supports GPRS, but at least for me it does not work very > reliably, I consider this only a proof of concept. While voice/SMS range is > up to 200m, GPRS breaks down after 5m (!) distance, and the connection > stalls after a while, requiring a restart of OpenBTS. I am using an USRP1 > with WBX board. > > > > Ralph. > -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / ООО УмРадио http://fairwaves.ru

1 0

[PATCH] Support of multiple RSL connections for ABIS/ipaccess (BTS side)
by Andreas Eversberg 22 Jan '14

22 Jan '14

hi, while re-basing the osmo-bts-trx code with master, i saw that the ABIS code has been replaced by libosmo-abis. libosmo-abis is not capable of handling multiple RSL connections, so the multi-TRX support is broke now. the attached patch will add multiple RSL connection support to libosmo-abis. regards, andreas

2 10

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC