OpenBSC February 2014

openbsc@lists.osmocom.org

20 participants
31 discussions

[libosmocore PATCH v3] src/serial.c: Add serial helper read and write function
by Alvaro Neira 13 Feb '14

13 Feb '14

From: Álvaro Neira Ayuso <anayuso(a)sysmocom.de> This patch provide two new functions for reading and writing from the serial interface. I think this two functions makes it easy reading and writing from the serial interface. Signed-off-by: Alvaro Neira Ayuso <anayuso(a)sysmocom.de> --- v3: Fixed the bug that i send errno when in this case errno don't return anything. Fixed some format error for having consistency with the others function and now, I control when read function return the value 0 for saying the end of the file. v2: Fixed the write function for don't supposing that i will write all the msg in one time. I have studied the limit in the read function and i have used the -errno like the other functions inside serial.c for having consistency. The previous version, i have supposed that we need to liberate the info in case of error, now if we have a error we can check the info that we have received or we must to send again. include/osmocom/core/serial.h | 4 +++ src/serial.c | 53 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 57 insertions(+) diff --git a/include/osmocom/core/serial.h b/include/osmocom/core/serial.h index 1640a6d..056010b 100644 --- a/include/osmocom/core/serial.h +++ b/include/osmocom/core/serial.h @@ -33,10 +33,14 @@ #include <termios.h> +struct msgb; + int osmo_serial_init(const char *dev, speed_t baudrate); int osmo_serial_set_baudrate(int fd, speed_t baudrate); int osmo_serial_set_custom_baudrate(int fd, int baudrate); int osmo_serial_clear_custom_baudrate(int fd); +int osmo_serial_write(int fd, struct msgb *msg); +int osmo_serial_read(int fd, struct msgb *msg, int numbytes); /*! @} */ diff --git a/src/serial.c b/src/serial.c index 66ee756..8c28e7a 100644 --- a/src/serial.c +++ b/src/serial.c @@ -43,6 +43,7 @@ #endif #include <osmocom/core/serial.h> +#include <osmocom/core/msgb.h> #if 0 @@ -226,4 +227,56 @@ osmo_serial_clear_custom_baudrate(int fd) return 0; } +/*! \brief Read data from Serial interface + * \param[in] fd File descriptor of the open device + * \param[in] msg Struct where we save the info + * \param[in] numbytes Number of bytes that we want read + * \returns 0 for success or negative errno. + */ +int +osmo_serial_read(int fd, struct msgb *msg, int numbytes) +{ + int rc, bread = 0; + + if (numbytes > msg->data_len) + return -ENOSPC; + + while (bread < numbytes) { + rc = read(fd, msg->tail, numbytes - bread); + if (rc < 0) + return -errno; + if (rc == 0) + break; + + bread += rc; + msgb_put(msg, rc); + } + + return bread; +} + +/*! \brief Write data to Serial interface + * \param[in] fd File descriptor of the open device + * \param[in] msg Struct where we have the info for writing + * \returns 0 for success or negative errno. + * + * The msgb->data pointer is updated when consuming this message + */ +int +osmo_serial_write(int fd, struct msgb *msg) +{ + int rc, bwritten = 0; + + while (msg->len > 0) { + rc = write(fd, msg->data, msg->len); + if (rc < 0) + return -errno; + + msgb_pull(msg, rc); + bwritten += rc; + } + + return bwritten; +} + /*! @} */

1 0

[libosmocore PATCH v2] src/serial.c: Add serial helper read and write function
by Alvaro Neira 13 Feb '14

13 Feb '14

From: Álvaro Neira Ayuso <anayuso(a)sysmocom.de> This patch provide two new functions for reading and writing from the serial interface. I think this two functions makes it easy reading and writing from the serial interface. Signed-off-by: Alvaro Neira Ayuso <anayuso(a)sysmocom.de> --- v2: Fixed the write function for don't supposing that i will write all the msg in one time. I have studied the limit in the read function and i have used the -errno like the other functions inside serial.c for having consistency. The previous version, i have supposed that we need to liberate the info in case of error, now if we have a error we can check the info that we have received or we must to send again. include/osmocom/core/serial.h | 4 +++ src/serial.c | 51 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 55 insertions(+) diff --git a/include/osmocom/core/serial.h b/include/osmocom/core/serial.h index 1640a6d..056010b 100644 --- a/include/osmocom/core/serial.h +++ b/include/osmocom/core/serial.h @@ -33,10 +33,14 @@ #include <termios.h> +struct msgb; + int osmo_serial_init(const char *dev, speed_t baudrate); int osmo_serial_set_baudrate(int fd, speed_t baudrate); int osmo_serial_set_custom_baudrate(int fd, int baudrate); int osmo_serial_clear_custom_baudrate(int fd); +int osmo_serial_write(int fd, struct msgb *msg); +int osmo_serial_read(int fd, struct msgb *msg, int numbytes); /*! @} */ diff --git a/src/serial.c b/src/serial.c index 66ee756..c71ee6a 100644 --- a/src/serial.c +++ b/src/serial.c @@ -43,6 +43,7 @@ #endif #include <osmocom/core/serial.h> +#include <osmocom/core/msgb.h> #if 0 @@ -226,4 +227,54 @@ osmo_serial_clear_custom_baudrate(int fd) return 0; } +/*! \brief Read datas from Serial interface + * \param[in] fd File descriptor of the open device + * \param[in] msg Struct where we save the info + * \param[in] numbytes Number of bytes that we want read + * \returns 0 for success or negative errno. + */ +int +osmo_serial_read(int fd, struct msgb *msg, int numbytes) +{ + int rc, bread = 0; + + if (numbytes > msg->data_len) + return -errno; + + while (bread < numbytes) { + rc = read(fd, msg->tail, numbytes - bread); + if (rc < 0) + return -errno; + + bread += rc; + msgb_put(msg, rc); + } + + return bread; +} + +/*! \brief Write datas to Serial interface + * \param[in] fd File descriptor of the open device + * \param[in] msg Struct where we have the info for writing + * \returns 0 for success or negative errno. + * + * The msgb->data pointer is updated when consuming this message + */ +int +osmo_serial_write(int fd, struct msgb *msg) +{ + int rc, bwritten = 0; + + while (msg->len > 0) { + rc = write(fd, msg->data, msg->len); + if (rc == -1) + return -errno; + + msgb_pull(msg, rc); + bwritten += rc; + } + + return bwritten; +} + /*! @} */

3 2

Force Channel Release after abrupt call end (aka battery pull of mobile device)
by j h 13 Feb '14

13 Feb '14

I've come across an issue where any channel that are active do not release in the case of an abrupt end from the mobile (such as battery being pulled). I attempting to go in programmatically and send a CC Disconnect and a CC Release to the BSC however this doesn't solve my issue. Any thoughts of how to remedy this programatically?

2 1

osmoSGSN
by Michal Grznár 12 Feb '14

12 Feb '14

Hi, I am trying to use osmoSGSN in topology with openGGSN and sim-bss, which is simulator of BSS made by company Alcatel-Lucent. I have a problem that my osmoSGSN can not communicate with sim-BSS and it can not connect correctly. It is caused by non function bssgp. I would like to ask you, how can I configure bssgp on osmoSGSN? I can configure ns states also from vty on osmoSGSN but I can not bssgp states such as bvci etc...Please could you help me? I hope you will reply me soon. Thank you very much Best regards, Michal Grznár

2 3

[PATCH] src/serial.c: Add serial helper read and write function
by Alvaro Neira 11 Feb '14

11 Feb '14

4 3

SMS RP-Data spec violation. Somebody wants to fix it?
by Holger Hans Peter Freyther 09 Feb '14

09 Feb '14

Hi, I just looked at a trace and saw that the RP-MessageReference we assign is hardcoded to 42. It should be a sequence number going from 0 to 255. It is somehow idiotic as there can only be one SMS per direction and there is the transaction identifier as well. I would propose a patch that does: Change gsm411_send_sms to ask the subscriber connection/transaction code for a message reference. For added bonus also "put" the number so we could verify to not re-use the number too early. anyones wants to come up with a fix? holger

2 5

possible bug in OpenBSC
by Ciaby 07 Feb '14

07 Feb '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all, we are currently experiencing some issues with OpenBSC paired with a sysmobts-2050. SDCCH channels are getting stick into BROKEN/UNUSABLE state, and they don't get released. This accumulates over time and reaches a point where we have to manually restart osmo-nitb because there are no channels availables and the whole network breaks down. Is it a know issue or only us? :) This is the "show lchan" output: BTS 0, TRX 0, Timeslot 0, Lchan 0: Type SDCCH Connection: 0, State: BROKEN UNUSABLE BS Power: 37 dBm, MS Power: 39 dBm No Subscriber Bound IP: 0.0.0.0 Port 0 RTP_TYPE2=0 CONN_ID=0 Measurement Report: Flags: DLinval RXL-FULL-ul: -87 dBm, RXL-SUB-ul: -47 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0 BTS 1, TRX 0, Timeslot 0, Lchan 2: Type NONE Connection: 0, State: BROKEN UNUSABLE BS Power: 37 dBm, MS Power: 39 dBm No Subscriber Bound IP: 0.0.0.0 Port 0 RTP_TYPE2=0 CONN_ID=0 Measurement Report: Flags: DLinval RXL-FULL-ul: -110 dBm, RXL-SUB-ul: -110 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0 BTS 1, TRX 0, Timeslot 0, Lchan 3: Type NONE Connection: 0, State: BROKEN UNUSABLE BS Power: 37 dBm, MS Power: 39 dBm No Subscriber Bound IP: 0.0.0.0 Port 0 RTP_TYPE2=0 CONN_ID=0 Measurement Report: Flags: DLinval RXL-FULL-ul: -110 dBm, RXL-SUB-ul: -110 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0 Timeslot 0 is configured as CCCH+SDCCH4. Cheers Ciaby -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREKAAYFAlL0A7MACgkQC30ZhxNccpEr7QD/WugVMQo5LW1u2RVNeK6TL6Rx hNl/h7f2UB/3lhedCTIBALcMXoglpdx/CLIo5nrZVQqoVVRCTD8Jd6UzQFtbejx+ =l7KL -----END PGP SIGNATURE-----

2 1

Fwd: [dispatch] SIP and GSM/UMTS with OpenBTS
by Jim Forster 05 Feb '14

05 Feb '14

Dear list members, I posted the following message to the IETF DISPATCH mailing list earlier today. It's got a bit of a lengthy intro, as that community is not familiar with OpenBTS (and probably not OpenBSC either), and in preliminary discussions with them it was clear that it needed a good explanation. I invite you all to join the IETF DISPATCH list, and participate in the discussion. Tim Panton has already raised some good points. See http://trac.tools.ietf.org/wg/dispatch/trac/wiki for info about the DISPATCH group and https://www.ietf.org/mailman/listinfo/dispatch to join the list. -- Jim Range Networks Begin forwarded message: > From: Jim Forster <jim.forster(a)rangenetworks.com> > Subject: [dispatch] SIP and GSM/UMTS with OpenBTS > Date: February 5, 2014 at 12:09:45 PM GMT+5:30 > To: "dispatch(a)ietf.org" <dispatch(a)ietf.org> > > Dear DISPATCH group, > > OpenBTS and OpenBSC are projects are combining GSM phones and SIP in new and interesting ways. I think there is some value to the community in discussing these in the DISPATCH mailing list and having an related meeting at the London IETF. There is both some short-term, relatively straightforward work to be done to agree on the usage of SIP in these existing implementations. There may also be some very interesting work to be done on more advanced approaches. > > First, some background: OpenBTS is an open source project started by the founders of Range Networks to make a 'GSM system in a box', by implementing a system which supports the air interface for GSM phones (Um) using a Software Defined Radio (SDR) for the RF. While the GSM & 3GPP defined air interface to the phones is supported, OpenBTS diverges from these standards by immediately gatewaying the call to SIP. Each GSM or UMTS phone can then appear on the Internet as a SIP endpoint. A local SIP switching decision is made to route the call; Asterix, Freeswitch, Yate have been. The call is then sent to another local connected phone or to some other SIP service point on the Internet. > > With this in place, because the air interface to the phones is supported with no changes, standard GSM/UMTS phones can make calls to other phones on the same OpenBTS system or to any SIP endpoint on the Internet, and thence to the PSTN via any of the many SIP-PSTN gateways in operation. > > A fair question would be "Why do all this? What's wrong with GSM & 3GPP systems?". One reason is that the OpenBTS approach allows very small, stand alone systems, which efficiently connect GSM and UMTS phones to the Internet based SIP systems with a minimum of other systems. Certainly GSM/3GPP based micro cells exist, but are tied to the 3GPP 'Core' which is usually beyond the means of smaller users. OpenBTS aspires to be the simplest way for a GSM/UMTS phone to make phone calls to the SIP & PSTN world. > > At least several hundred, and likely several thousand of these systems are deployed already. Many are in labs, but others are production usage on all continents. Universities find these systems very attractive for teaching and researching: all the code from RF to Signaling is visible and may be changed as desired. > > Furthermore, additional SDRs are popping up all the time. There are 3-4 separate SDR based systems that run OpenBTS and more are coming. Right now they range from $2000 up, but it's easy to see them dropping to $500 or so this year; even Kickstarter campaigns are funding some of them. There's no natural floor below that; adding GSM/UMTS to a home router and making it a micro-cell running SIP to the Internet could conceivably be a $10 HW delta and some more SW. Secondly, there are several countries that have unlicensed GSM band (Sweden, Netherlands, UK?) so some efforts are underway to do exactly that. > > When facing the Internet, OpenBTS is simply a SIP client. However, to assure interoperability, there may be value in standardized behavior, including these issues: > > * Which elements of SIP are needed for this operation? > * Should these be documented in a profile of SIP usage to be OpenBTS Ready? > * Should ICE be recommended or possibly be required for operation behind NATs? > * What about BTS-BTS neighbor discovery > * Use of SIP Re-invite for hand-over when a mobile phone moves from one BTS to a neighbor > * For somewhat different use cases: one could separate signaling from media transport and thus might support WebRTC or other such systems. E.164 addresses are used in phones, but temporary numbers can be assigned as needed (as done in Roaming) and not surfaced to the WebRTC level. > * What Changes required for IPv6? > * Required and recommended security provisions > * Is IETF an appropriate forum for this, or should it be in 3GPP, or Sipforum.org, or a separate industry group formed? > > I look forward to discussion on the mailing list, and hopefully meeting and discussing in London. > > Yours, > > Jim Forster > Range Networks > _______________________________________________ > dispatch mailing list > dispatch(a)ietf.org > https://www.ietf.org/mailman/listinfo/dispatch

1 0

OsmoDevCon 2014: CFP
by Sylvain Munaut 05 Feb '14

05 Feb '14

Dear all, Time has come to fill out the "Talks/Discussions/Workshop / Hacking" section of the wiki page. If you have something you'd like to present, talk about or hack on, add it there. A simple descriptive title along with an estimated duration is enough. I guess we'll collect those for 2/3 weeks and then start making the schedule. Cheers, Sylvain

1 0

GPRS vs. voice with openbsc
by Ralph A. Schmid, dk5ras 03 Feb '14

03 Feb '14

Hi out there, I am using OpenBTS with an USRP1, so not absolutely on-topic here, but I have here some effects with GPRS that are a bit annoying, and I would like to ask if something similar is known with the openbsc familiy when using GPRS. GPRS works, but with a reduced operating distance. While voice and SMS work over 200m (USRP1, WBX, small omni antennae) GPRS stops after 20-25 m, when downlink level is around -70dBm. Digging a bit deeper showed me that GPRS uses a somehow strange power control model, not a closed loop but a kind of dedicated guess, derived from the downlink RSSI at the ME. Setting the corresponding gamma value has a strong influence, but even with its lowest value I do not reach more than those 25m, and I can reduce the operating range to 2m with it. Playing with rxgain and other parameters did not really improve things. Is similar behavior known with the openbsc familiy GSM systems? I even know similar effects from commercial operators (O2 Germany with EDGE), not knowing if it is the same issue or something completely different. A first glance at some documents showed me that this power level calculation seems to be normal - is there really no closed loop for GPRS available? With best regards Ralph.

3 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC February 2014