OpenBSC

openbsc@lists.osmocom.org

4 participants
4157 discussions

Force Channel Release after abrupt call end (aka battery pull of mobile device)

by j h

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?

11 years, 5 months

osmoSGSN

by Michal Grznár

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

11 years, 5 months

[PATCH] src/serial.c: Add serial helper read and write function

by Alvaro Neira

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> --- include/osmocom/core/serial.h | 4 ++++ src/serial.c | 33 +++++++++++++++++++++++++++++++++ 2 files changed, 37 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..818426a 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,36 @@ osmo_serial_clear_custom_baudrate(int fd) return 0; } +int +osmo_serial_read(int fd, struct msgb *msg, int numbytes) +{ + int rc, bread = 0; + + while (bread < numbytes) { + rc = read(fd, msg->tail, numbytes - bread); + if (rc < 0) { + msgb_free(msg); + return -1; + } + bread += rc; + msgb_put(msg, rc); + } + + return bread; +} + +int +osmo_serial_write(int fd, struct msgb *msg) +{ + int bwritten = 0, ret = 0; + + bwritten = write(fd, msg->data, msg->len); + if (bwritten < 0 || bwritten < msg->len) { + msgb_free(msg); + ret = -1; + } + + return ret; +} + /*! @} */

11 years, 5 months

SMS RP-Data spec violation. Somebody wants to fix it?

by Holger Hans Peter Freyther

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

11 years, 5 months

possible bug in OpenBSC

by Ciaby

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

11 years, 5 months

Fwd: [dispatch] SIP and GSM/UMTS with OpenBTS

by Jim Forster

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

11 years, 5 months

OsmoDevCon 2014: CFP

by Sylvain Munaut

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

11 years, 5 months

GPRS vs. voice with openbsc

by Ralph A. Schmid, dk5ras

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.

11 years, 5 months

Calls from BTS to PTSN planification doubts

by Diego Fernandez Alonso

Hello, my name is Diego. I've a configurated sysmoBTS in OpenBSC network-in-the-box (NITB) mode, and the osmo-nitb is working fine, doing and receiving calls and messages between the phones connected to the sysmoBTS network. At this point I would need to call outside the OpenBSC, and I would be very gratefull if someone could help me with some doubts I have. I'm new in this. For the isdn card capable of NT-mode, I've seen the "OpenVox B200P 2-port ISDN BRI PCI" card for buying, but: 1-An "OpenVox B100P ISDN BRI PCI" card, with only one RJ45 female connector, could be used correctly, working together with an already installed PCI Ethernet Controller card? Or, is it better an isdn card with two RJ45 connectors in the same card? One for connecting the BTS to the computer, and the another for connecting the computer to a LAN through a router or switch? I would like to avoid to cut cables as the LCR guide says, http://isdn.eversberg.eu/download/doc-1.4/linux-call-router-1.4_1.pdf, and the problems with the cross over and not crossed cables. 2-The "Howto OpenBSC with Asterisk and LCR" guide, http://openbsc.osmocom.org/trac/wiki/OpenBSC_LCR, indicates that it's necessary compile and install LibOsmocore and OpenBSC, but the OpenBSC/OsmoNITB inside the sysmoBTS is working, so I'm not sure about this step. If the solution is to build, configure and run OpenBSC/OsmoNITB + OsmoSGSN + OpenGGSN on a PC and configure the sysmoBTS to connect to this, should I change the image of the BTS and its whole configuration? 3-Although I don't have the isdn card yet, for testing some configurations in the PC I followed the "Building and Running OpenBSC with Asterisk" Pierre Kim guide, that I believe is newer than the "How to OpenBSC with Asterisk and LCR", and I haven't problems with the installations. So if I run the lcr: # lcr start ** LCR Version 1.14 LCR 1.14 started, waiting for calls... and running the osmo-nitb: # ./osmo-nitb -m -P DB: Database initialized. DB: Database prepared. My question in this point, is it only necessary to connect the BTS to the isdn card with the right OpenBSC to finish the system configuration? Many thanks for your time and for your work. Kindest regards, Diego.

11 years, 5 months

[PATCH 1/5] mgcp/test: Only include conn_mode into test output

by Jacob Erlbeck

Currently the conn_mode and the output_enabled flags are printed to stdout. This patch modifies this to print the output_enabled flags to stderr instead. The bits in conn_mode are shown as RECV, SEND, and LOOP. This does not reduce the significance of the test, since there is an assertion already that verifies the values of the output_enabled flags with respect to the conn_mode. Sponsored-by: On-Waves ehf --- openbsc/tests/mgcp/mgcp_test.c | 21 +++++++++++++++------ openbsc/tests/mgcp/mgcp_test.ok | 18 +++++++++--------- 2 files changed, 24 insertions(+), 15 deletions(-) diff --git a/openbsc/tests/mgcp/mgcp_test.c b/openbsc/tests/mgcp/mgcp_test.c index fa68867..5f69072 100644 --- a/openbsc/tests/mgcp/mgcp_test.c +++ b/openbsc/tests/mgcp/mgcp_test.c @@ -399,13 +399,22 @@ static void test_messages(void) else printf("Requested packetization period not set\n"); - if ((endp->conn_mode & CONN_UNMODIFIED) == 0) - printf("Connection mode: %d, " - "BTS output %sabled, NET output %sabled\n", + if ((endp->conn_mode & CONN_UNMODIFIED) == 0) { + printf("Connection mode: %d:%s%s%s%s\n", endp->conn_mode, - endp->bts_end.output_enabled ? "en" : "dis", - endp->net_end.output_enabled ? "en" : "dis"); - else + !endp->conn_mode ? " NONE" : "", + endp->conn_mode & MGCP_CONN_SEND_ONLY ? + " SEND" : "", + endp->conn_mode & MGCP_CONN_RECV_ONLY ? + " RECV" : "", + endp->conn_mode & MGCP_CONN_LOOPBACK & + ~MGCP_CONN_RECV_SEND ? + " LOOP" : ""); + fprintf(stderr, + "BTS output %sabled, NET output %sabled\n", + endp->bts_end.output_enabled ? "en" : "dis", + endp->net_end.output_enabled ? "en" : "dis"); + } else printf("Connection mode not set\n"); OSMO_ASSERT(endp->net_end.output_enabled == diff --git a/openbsc/tests/mgcp/mgcp_test.ok b/openbsc/tests/mgcp/mgcp_test.ok index fbe2566..76806f9 100644 --- a/openbsc/tests/mgcp/mgcp_test.ok +++ b/openbsc/tests/mgcp/mgcp_test.ok @@ -19,7 +19,7 @@ Testing CRCX Dummy packets: 1 Detected packet duration: 40 Requested packetetization period: 20-20 -Connection mode: 1, BTS output enabled, NET output disabled +Connection mode: 1: RECV Testing MDCX3 Dummy packets: 1 Packet duration not set @@ -29,35 +29,35 @@ Testing MDCX4 Dummy packets: 1 Detected packet duration: 40 Requested packetetization period: 20-20 -Connection mode: 3, BTS output enabled, NET output enabled +Connection mode: 3: SEND RECV Testing MDCX4_PT1 Dummy packets: 1 Detected packet duration: 40 Requested packetetization period: 20-40 -Connection mode: 3, BTS output enabled, NET output enabled +Connection mode: 3: SEND RECV Testing MDCX4_PT2 Dummy packets: 1 Detected packet duration: 40 Requested packetetization period: 20-20 -Connection mode: 3, BTS output enabled, NET output enabled +Connection mode: 3: SEND RECV Testing MDCX4_PT3 Dummy packets: 1 Detected packet duration: 40 Requested packetization period not set -Connection mode: 3, BTS output enabled, NET output enabled +Connection mode: 3: SEND RECV Testing MDCX4_SO Detected packet duration: 40 Requested packetetization period: 20-20 -Connection mode: 2, BTS output disabled, NET output enabled +Connection mode: 2: SEND Testing DLCX Detected packet duration: 20 Requested packetization period not set -Connection mode: 0, BTS output disabled, NET output disabled +Connection mode: 0: NONE Testing CRCX_ZYN Dummy packets: 1 Packet duration not set Requested packetization period not set -Connection mode: 1, BTS output enabled, NET output disabled +Connection mode: 1: RECV Testing EMPTY Testing SHORT1 Testing SHORT2 @@ -68,7 +68,7 @@ Testing RQNT2 Testing DLCX Detected packet duration: 20 Requested packetization period not set -Connection mode: 0, BTS output disabled, NET output disabled +Connection mode: 0: NONE Testing CRCX Re-transmitting CRCX Testing RQNT1 -- 1.7.9.5

11 years, 5 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC