Hi all,
We're moving this discussion to the mailing list, as it seems it is
more generic and complex than we've thought initially.
The issue arose when I started doing load testing of the OsmoTRX
transceiver and disabled all gating in it. As a result, all incoming
noise was processed as valid Normal Bursts and Access Bursts and sent
up to OsmoBTS. This leads to a situation, similar to a RACH flood,
when there are more RACH requests coming, than a BTS could reasonably
process. And this leads to an unbounded increase of the AGCH queue in
the BTS - it consumes a few Mb per minute.
I think that this is the root cause of the issue we've seen at a
Netherlands festival installation, when 20K phones suddenly started
connecting to our station after official networks went down. When the
amount of RACH requests exceeded available CCCH capacity (took <5
seconds), mobile phones stopped answering out IMM.ASS messages.
Hypothesis is that the AGCH queue became so long, requests were sent
too late for a phone to receive it. And thus no phones answered to our
IMM.ASS messages. Unfortunately, I wasn't able to collect enough data
to check this hypothesis during that time and we don't have another
big festival on hands atm.
An attached is a quick fix for the unbounded queue growth. It uses a
hardcoded value for the maximum queue length, which is fine for our
load testing, but not flexible enough for the real life usage. We
should make the AGCH queue long enough to keep high performance. At
the same time, it must not exceed MS timeout or _all_ IMM.ASS messages
will miss their target MS's.
We could make this parameter user-configurable on a BTS side, but it
seems more reasonable to automatically calculate it, depending on the
channel combination and timeout values. But this should be done on the
BSC side. So the questions are:
1) what is a good way to calculate it?
2) should we configure this queue length over OML, or move the queue
from BTS to BSC?
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey there,
I have come across a nanoBTS 165AU but since is used and not tested from the previous owner, I guess it has set a static IP.
After turned on is booting (RED light) and then remains (ORANGE not flashing) even if the eth is connected to the router.
At the moment I am trying with ipaccess-find and BtsInstaller to find in on my LAN .
Unfortunately it is not answering and is not even getting an IP from the router by the DHCP daemon.
Two possibilities, I have thought:
- - an hw/sw issue;
- - a Static IP is set.
Supposing that is the 2nd possibility, I was thinking:
- - to change private class of my LAN, to see if it changes something;
- - to make an hard reset of the bts.
Do you know if it possible to reset in someway?
Ever happened this issue to you guys?
Suggestions or insults are welcome.
Thanks in advance.
Cheers,
Luca
P.S.: I don't recall exactly, but one time I heard that is possible to reset by short-circuiting some pins of the LAN/48VDC eth connector. Is it right?!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQIcBAEBAgAGBQJSE682AAoJEPLE1Qsi6ZiTuKkQAJaYGFTgMF5XlWuZuCI1eSvU
lVCvpdB+fDRY7o6iut3y0fGlS1ZOIS8X93c7/T0XKUvSJaZ2ARIGjqi81A4XlkAK
pdFvBNPKixYATYZYhP3nIggC1QGK9fuWQSUKVEGgnswsXt0VaJKdEwgn0CX7ttku
uoh6FM3vtp30drB4t9oe0bW9M9qzGz6yyw+8asaqQBs8bafOHm4+S4kJsN6lYmPU
wY/s8ctzqZerNI0MwBVASZCFldsyWe0NuduquYZlwg4god996srFNkVQL+o9nrmF
vmPb896DTsCdivwqs+UyaZOgp1mKxjtfco275pVATG4qSAgz/JYQBxWK6fWQr+Zv
PIzQvFLME1kh/29nUihxw93mzju5Rz1naTosx5+Fs7jPjCFocqD5Var3hkU4iu78
kNALJNx6UGOdfbqcInO30ltSm21HH1QBJnIoZf6MblELvHcvHbBNyPB8zM13suoS
y3/oD/wcXefQaMaSa5HFc30ydJHBWS+adNlVp3fdYYArZaVkFxaVjJx8fW1juPVx
54aco5j7/tZD5tfg9FCOTHqmAiOVDqjs7nZrOpsRdkdPJHq2uHbGmHGqyhZlVWNv
B+9/eiOdQyKZ5R+3vvRrmhBe9g2a28xtRI7N8KxwCov0wbA6R0h8l2UtGza6NTcn
EUdW3ptIWP216tSFdVTs
=9Ctc
-----END PGP SIGNATURE-----
In case of a headroom in a message, the 'head' pointer will not point to
the actual data.
---
src/osmo-bts-sysmo/l1_transp_fwd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/osmo-bts-sysmo/l1_transp_fwd.c b/src/osmo-bts-sysmo/l1_transp_fwd.c
index 5050705..87c230b 100644
--- a/src/osmo-bts-sysmo/l1_transp_fwd.c
+++ b/src/osmo-bts-sysmo/l1_transp_fwd.c
@@ -95,7 +95,7 @@ static int fwd_read_cb(struct osmo_fd *ofd)
static int prim_write_cb(struct osmo_fd *ofd, struct msgb *msg)
{
/* write to the fd */
- return write(ofd->fd, msg->head, msg->len);
+ return write(ofd->fd, msg->l1h, msgb_l1len(msg));
}
int l1if_transport_open(int q, struct femtol1_hdl *fl1h)
--
1.8.1.5
Hi list,
I managed to add interaction to the USSD implemented in the OpenBSC.
I attached a patch with the changes realized.The most important changes made are in the ussd.{c, h} files. I implemented the gsm0480_send_ussd_facility. Basically, I copied the gsm0480_send_response, change the GSM0480_OPERATION_CODE field value to GSM0480_OP_CODE_USS_REQUEST, removed the 2 bytes before this field and replaced the GSM0480_MTYPE_RELEASE_COMPLETE byte by GSM0480_MTYPE_FACILITY.
Now, I don't know how to proceed. More precisely, I don't know what function is called in the OpenBSC when the user send the response in the mobile phone.
Do you guys know the entry point function in this case ?
Best Regards
Hi all,
I'm working on OsmoNITB software and i am very interested in SMPP features.
I have read some posts about SMPP in OSMONITB and i have some question
about how to make it works.
I have compiled openbsc ( based on
http://openbsc.osmocom.org/trac/wiki/network_from_scratch ) with libsmpp34.
All is good.
When i start my OSMONITB, my netstat show listening port 2775.
But how to connect and send a SMS via SMPP?
I tried a little PHP script on github :
https://github.com/onlinecity/php-smpp
But i couldn't connect : INVALID SERVER ID Error 0xf
Do i need to put a USERNAME and PASSWORD ?
When i looked the code : in accept-all mode, all username and password are
corrects.
My BTS is in accept-all mode but i couldn't connect.
So I tried an another program in C. And same error.
Have you fixed this problem ? Is it working for you ?
Second, Is there a mechanism to pass SMS from OSMONITB to an another server
via SMPP ?
Thanks for your help.
--
*Ludovic RATEAU*
R&D Engineer
BJT PARTNERS
--
--
*Ludovic RATEAU
*Mobile : +33 6 04 10 5000
Hello everyone,
I just recently learn about openbsc, and still in the phase of
compiling and try to run the osmo-nitb app.
1st problem
The problem is one of my teammate said the osmo-nitb will also started/call
the osmo-sgsn program, but after examine the code, I still don't know how
the
osmo-sgsn is called from osmp-nitb, may be I was wrong, anyone can help me
with this, how can I activate osmo-sgsn from osmo-nitb, with extra
arguments?
2nd problem
Another question, when I try to compile osmo-sgsn, the gtp lib is missing,
as define in the makefile:
*if HAVE_LIBGTP*
*bin_PROGRAMS = osmo-gbproxy osmo-sgsn*
*else*
*bin_PROGRAMS = osmo-gbproxy*
*endif*
I don't know where to get this lib, so I modified by adding osmo-sgsn to
the *else clause* as-well to have osmo-sgsn compiled. I still can run
osmo-sgsn, but it show error about the gtp socket, i think the
configuration is not correct, but not because of missing gtp lib, should
this be a problem?
Best regards,
Dai
Hi Andreas,
We were testing TCH/H yesterday and stumbled upon an issue when a call
is made between TCH/F and TCH/H.
- When the call is from TCH/F to TCH/H, it doesn't connect.
- When the call is from TCH/H to TCH/F, it connects, but voice
quality is bad - sounds like 50% packet loss.
Logs and localhost Wireshark captures of calls in both directions are here:
http://ipse.chemeris.ru/osmo-captures/dumps.tar.xz
Do you see what's wrong with them?
Our configuration was
* Dual-TRX with 1 TCH/F and 14 TCH/H channels. We have to keep some
TCH/F channels, since there are old phones which doesn't support
TCH/H.
* Codecs enabled were FR, AFS and AHS.
* LCR was connected to the MNCC socket, but in the case of
TCH/F->TCH/H call I didn't see it coming to LCR at all.
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
Hi Harald (sorry for the typo).
I think that line 10 is a log of the USSD call I made.
My configuration is:
- Followed the tutorial. (
http://openbsc.osmocom.org/trac/wiki/network_from_scratch (using all
configurations shown in the tutoria, except the network name, that I
changed to DCG).
- Using a Ettus USRP N210
- All libraries installed in my notebook, with Ubuntu 13.04
kernel 3.8.0-29-generic.
- Starting osmo-nitb with the following command: osmo-nitb -c
~/.osmocom/open-bsc.cfg -l ~/.osmocom/hlr.sqlite3 -P -m -C
--debug=DRLL:DCC:DMM:DRR:DRSL:DNM
- I manually select the network in the Network Preferences. The phone is an
old Motorola Z6.
Hope it helps. If you need more information, just ask. If you need, I can
use other configurations or command options.
Best Regard,
On Sat, Aug 24, 2013 at 5:37 PM, Alexander Chemeris <
alexander.chemeris(a)gmail.com> wrote:
> Of-list: His name is "Harald", not "Herald" :)
>
> On Sun, Aug 25, 2013 at 12:36 AM, Alexander Chemeris
> <alexander.chemeris(a)gmail.com> wrote:
> > Maicon,
> >
> > Your log doesn't show any user activity, so you either (1) haven't
> > enabled enough logging or (2) your phone is not attached to the
> > OsmoNITB network.
> >
> > If you followed instructions from
> > http://openbsc.osmocom.org/trac/wiki/network_from_scratch, then you
> > should have enough logging enabled. In this case we have only option
> > (2) left and it would be great if you specify your software and
> > hardware setup and describe the procedure you're using to select the
> > network in your phone.
> >
> > On Sat, Aug 24, 2013 at 11:46 PM, Maicon Kist <maicon.kist(a)inf.ufrgs.br>
> wrote:
> >> Hi Herald,
> >>
> >> I'm trying to check the log messages. I'm trying to understand whats
> >> happening, but so far nothing came to my mind.
> >> I'm attaching the osmo-nitb log messages right before I call the *#100#
> >> number.
> >>
> >> Do you have any suggestion?
> >>
> >> PS: SMS and calls are working perfectly.
> >>
> >> Best Regards,
> >>
> >>
> >> On Sat, Aug 24, 2013 at 11:59 AM, Alexander Chemeris
> >> <alexander.chemeris(a)gmail.com> wrote:
> >>>
> >>> On Thu, Aug 22, 2013 at 9:40 PM, Maicon Kist <maicon.kist(a)inf.ufrgs.br
> >
> >>> wrote:
> >>> > Is there a tutorial in how to make a USSD application work in a
> OpenBSC
> >>> > network?
> >>> > Firstly I'm want to implement a simple "Hello World" application. eg.
> >>> > the
> >>> > client enter with a valid USSD number (*something) and the "Hello
> World"
> >>> > application executes.
> >>>
> >>> Look at the openbsc/src/libmsc/ussd.c file - it's very easy to extend
> >>> it to respond to various USSD requests. It would be great if we have a
> >>> kind of external API for implementing external USSD applications
> >>> without touching the OsmoNITB code. Patches for this are welcome.
> >>>
> >>> --
> >>> Regards,
> >>> Alexander Chemeris.
> >>> CEO, Fairwaves LLC / ООО УмРадио
> >>> http://fairwaves.ru
> >>
> >>
> >
> >
> >
> > --
> > Regards,
> > Alexander Chemeris.
> > CEO, Fairwaves LLC / ООО УмРадио
> > http://fairwaves.ru
>
>
>
> --
> Regards,
> Alexander Chemeris.
> CEO, Fairwaves LLC / ООО УмРадио
> http://fairwaves.ru
>
hi,
after upgrading to latest openbsc/master, i experienced the following
problem with sgsn:
<0013> gprs_llc.c:506 LLC SAPI=1 C FCS=0x7b8d5fCMD=UI DATA
<0013> gprs_llc.c:142 TLLI 0x990ea532 is foreign, converting to local
TLLI 0xd90ea532
<0013> gprs_llc.c:789 LLC RX: unknown TLLI 0x990ea532, creating LLME on
the fly
<0013> gprs_llc.c:142 TLLI 0x990ea532 is foreign, converting to local
TLLI 0xd90ea532
<0013> gprs_llc.c:372 LLC TX: unknown TLLI 0x990ea532, creating LLME on
the fly
<0012> gprs_bssgp.c:503 BSSGP BVCI=0 TLLI=990ea532 Rx LLC DISCARDED
<0012> gprs_bssgp.c:376 BSSGP TLLI=0x990ea532 Rx UPLINK-UNITDATA
<0013> gprs_llc.c:506 LLC SAPI=1 C FCS=0x30b960CMD=UI DATA
<0013> gprs_llc.c:142 TLLI 0x990ea532 is foreign, converting to local
TLLI 0xd90ea532
<0013> gprs_llc.c:789 LLC RX: unknown TLLI 0x990ea532, creating LLME on
the fly
<0013> gprs_llc.c:142 TLLI 0x990ea532 is foreign, converting to local
TLLI 0xd90ea532
<0013> gprs_llc.c:372 LLC TX: unknown TLLI 0x990ea532, creating LLME on
the fly
<0012> gprs_bssgp.c:503 BSSGP BVCI=0 TLLI=990ea532 Rx LLC DISCARDED
<0012> gprs_bssgp.c:376 BSSGP TLLI=0x990ea532 Rx UPLINK-UNITDATA
<0013> gprs_llc.c:506 LLC SAPI=1 C FCS=0x280569CMD=UI DATA
<0013> gprs_llc.c:142 TLLI 0x990ea532 is foreign, converting to local
TLLI 0xd90ea532
<0013> gprs_llc.c:789 LLC RX: unknown TLLI 0x990ea532, creating LLME on
the fly
<0013> gprs_llc.c:142 TLLI 0x990ea532 is foreign, converting to local
TLLI 0xd90ea532
<0013> gprs_llc.c:372 LLC TX: unknown TLLI 0x990ea532, creating LLME on
the fly
<0012> gprs_bssgp.c:503 BSSGP BVCI=0 TLLI=990ea532 Rx LLC DISCARDED
the auth-policy is configured to "accept-all". any idea how to do deeper
debugging?
regards,
andreass
Hi,
While I was playing around with openbsc project I noticed that the
libosmo-sccp libraries are built as a static libraries only and I decided that
it will be useful to build them as shared objects too.
I also enabled colored output of the test suite and ignore all tag files that
are generated by the Makefiles.
Cheers
Vasil Velichckov (3):
Build shared objects with libtool
Enable colored test results by default
Ignore the tag files that are generated by Makefile
.gitignore | 9 +++++++++
configure.ac | 2 +-
src/Makefile.am | 18 +++++++++++++-----
tests/m2ua/Makefile.am | 2 +-
tests/sccp/Makefile.am | 4 ++--
tests/testsuite.at | 1 +
6 files changed, 27 insertions(+), 9 deletions(-)
--
1.7.10.4
In this case the last_node variable may hold values that are not
in enum node_type, so int is used instead.
---
src/vty/command.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/vty/command.c b/src/vty/command.c
index df2ffea..7f76ced 100644
--- a/src/vty/command.c
+++ b/src/vty/command.c
@@ -2291,7 +2291,7 @@ gDEFUN(config_exit,
config_end_cmd, "end", "End current mode and change to enable mode.")
{
if (vty->node > ENABLE_NODE) {
- enum node_type last_node = CONFIG_NODE;
+ int last_node = CONFIG_NODE;
/* Repeatedly call go_parent until a top node is reached. */
while (vty->node > CONFIG_NODE) {
--
1.7.9.5
Hi list,
Peter, thank you for your reply.
I still have questions about media control:
1) when parsing MGCP CRCX, sdp is not expected. May I change it?
2) I still can't run media in BSC mode. Seems I'm missing something.
osmo-bsc and osmo-bsc_mgcp are running
BSSAP works perfectly
But it seems two interfaces are working completely independent:
-- MGCP between MSC and BSC
-- interface between BSC and BTS (ip.access):
at MGCP, connection is acknowledged, endpoint is allocated (at BSC
ip=192.168.1.11)
at ip.access interface between BSC and BTS, BTS replies to ip.accessCRCX
with proper acknowledgement with proper ip:port at BTS (192.168.1.9) , then
BSC issues ip.accessMDCX with endpoint ip zero:
7e:73:01:09:f8:00:2d:*f0:00:00:00:00*:f1:0f:be:f4:00:f2:03
My attempts to modify connection at MGCP interface has no impact on
ip.access interface
The key question, I'm not getting how osmo-bsc and osmo0bsc_mgcp are
interacting.
Thank you,
Dmitri
PS my configs are
mgcp
local ip 192.168.1.11
bts ip 192.168.1.9
bind ip 192.168.1.11
bind port 2427
rtp base 6000
sdp audio payload number 3
sdp audio payload name GSM/8000
number endpoints 31
and
e1_input
e1_line 0 driver ipa
network
network country code 250
mobile network code 07
short name OsmoBSC
long name OsmoBSC
auth policy closed
location updating reject cause 13
! encryption a5 1
neci 1
paging any use tch 0
rrlp mode none
mm info 1
handover 0
handover window rxlev averaging 10
handover window rxqual averaging 1
handover window rxlev neighbor averaging 10
handover power budget interval 6
handover power budget hysteresis 3
handover maximum distance 9999
timer t3101 10
timer t3103 0
timer t3105 0
timer t3107 0
timer t3109 0
timer t3111 0
timer t3113 60
timer t3115 0
timer t3117 0
timer t3119 0
timer t3122 0
timer t3141 0
dtx-used 0
subscriber-keep-in-ram 0
bts 0
type nanobts
band PCS1900
cell_identity 2611
location_area_code 51601
training_sequence_code 7
base_station_id_code 63
ms max power 15
cell reselection hysteresis 4
rxlev access min 0
channel allocator ascending
rach tx integer 9
rach max transmission 7
ip.access unit_id 1801 0
oml ip.access stream_id 255 line 0
neighbor-list mode manual-si5
gprs mode none
trx 0
rf_locked 0
arfcn 810
nominal power 0
max_power_red 20
rsl e1 tei 0
timeslot 0
phys_chan_config CCCH+SDCCH4
hopping enabled 0
timeslot 1
phys_chan_config TCH/F
hopping enabled 0
timeslot 2
phys_chan_config TCH/F
hopping enabled 0
timeslot 3
phys_chan_config TCH/F
hopping enabled 0
timeslot 4
phys_chan_config TCH/F
hopping enabled 0
timeslot 5
phys_chan_config TCH/F
hopping enabled 0
timeslot 6
phys_chan_config TCH/F
hopping enabled 0
timeslot 7
phys_chan_config TCH/F
hopping enabled 0
msc
! ip.access rtp-base 6000
timeout-ping 20
timeout-pong 5
dest 192.168.50.10 5000 0
in fact, BSSAP goes from a card over VPN, while MGCP comes from
self-written TRAU running locally, the same host as BSC
hi,
i reworked my l1sap patches for osmo-bts. (they are the base for adding
osmo-bts-trx model code, which allow support for OpenBTS transceivers,
like UmTRX or Calypso-BTS.) each single patch was tested, if
Sysmocom-BTS is still functioning after applying it, rather than testing
all patches together. i do not send the patches to mailing list, since
there are 21 patches, and i don't want to spam the list before i know
that these patches are small enough to be reviewed and understood. the
branch is jolly/l1sap_parts. please let me know, whether they require
better description or finer splitting.
regards,
andreas
from last path to first patch:
commit 0c0229886f6f6eba029c044e4cac8b420d86cd1c
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Sun Sep 1 12:30:52 2013 +0200
Remove obsolete gsmtap handling from osmo-bts-sysmo part.
commit dfc8a3635e527960fa615c4ce7342e9739230a79
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Sun Jun 16 15:09:56 2013 +0200
sysmobts: Forward CMR from L1 (Phone) to RTP payload
commit 8cfffc712914107fe8277c96ad3afb1891f25014
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Sun Sep 1 12:06:19 2013 +0200
Add gsmtap option to command line to main.c of osmo-bts-sysmo
commit 8ca47efb9cf9861a2766c41b96469263e1e13ed9
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Sun Sep 1 12:04:49 2013 +0200
Move gsmtap VTY commands from osmo-bts-sysmo to common part
commit 2653aee1604d1504d707c9ed264dcb5cdaf2b01d
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Mon Jul 29 09:45:22 2013 +0200
Send primitives at PH-/MPH-/TCH-SAP interface via GSMTAP
commit 66c08e87a2985ffd48e6d870ac6318c2b82a1476
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Sun Sep 1 11:57:07 2013 +0200
Move loopback control VTY commands from osmo-bts-sysmo to common part
commit 8015bfcb3014c707bfe16ed4b52612e6fe377e75
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Thu Feb 14 11:17:58 2013 +0100
Correctly fill system information messages from BSC
SI 5*/6 require L2 header of 0x03,0x03. All SI might be less than 23
octets, so they need to be filled with 0x2b.
commit ebc180d0270293195c830193234608629b50bc03
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Sun Jun 16 13:26:14 2013 +0200
sysmobts: Clean up transitions for lchan cipher state
There are three transitions:
1. LCHAN_CIPH_NONE -> LCHAN_CIPH_RX_REQ -> LCHAN_CIPH_RX_CONF
It is used to enable ciphering in RX (uplink) direction only.
2. LCHAN_CIPH_RX_CONF -> LCHAN_CIPH_RX_CONF_TX_REQ ->
LCHAN_CIPH_RXTX_CONF
It is used to additionally enable ciphering in TX (downlink) direction.
3. LCHAN_CIPH_NONE -> LCHAN_CIPH_RXTX_REQ -> LCHAN_CIPH_RX_CONF_TX_REQ
-> LCHAN_CIPH_RXTX_CONF
It is used to enable ciphering in both TX and RX directions. This is
used
when the channel is activated with encryption already enabled.
(assignment
or handover)
In order to follow the order of these transitions, the RX direction must
always be set before the TX direction.
If no cipher key is set (A5/0), ciphering is set to ALG 0, but lchan
cipher
state remains at LCHAN_CIPH_NONE.
commit c5f478d8d6702961dfb74642108187e653a05775
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Sat Aug 31 20:30:40 2013 +0200
Add MEAS (MPH_INFO) IND message to PH-/MPH-/TCH-SAP interface
This part moves processing of measurement infos from osmo-bts-sysmo to
common part.
commit ffc1cc39ea28b695b98eedd1d16bdd023e4a77ad
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Sun Sep 1 11:09:20 2013 +0200
Add SDCCH/SACCH/FACCH messages to PH-/MPH-/TCH-SAP interface
This part moves control channel message primitives from
osmo-bts-sysmo to
common part.
In order to control ciphering fo BTS model, CIPHER (MPH_INFO)
messages are
used.
commit adc84b8db3bff29b5c681e04e078ee6000e5f4bf
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Sun Sep 1 10:08:15 2013 +0200
Add TCH messages to PH-/MPH-/TCH-SAP interface
This part moves TCH handling from osmo-bts-sysmo to common part. The RTP
handling is done at the common part, so they can be used by other BTS
models.
commit 2510e3f23ed4fa0a469484703c6b86574f175cdc
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Sun Sep 1 09:19:45 2013 +0200
Move chan act/rel/modify from bts_model to PH-/MPH-/TCH-SAP interface
This part replaces channel activation/deactivation/modification routines
by MPH_INFO messages.
commit b1df874be87cf09290a3dd0d95790bc74f3d09fa
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Sun Sep 1 09:02:24 2013 +0200
Relace bts_model_get_time() by get_time() at common part
commit f5b8b0de3303cefb06838991441e24c6d58e7aae
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Sat Aug 31 19:49:12 2013 +0200
Add TIME (MPH_INFO) IND messages to PH-/MPH-/TCH-SAP interface
This part moves GSM time handling from osmo-bts-sysmo part to common
part.
commit a8d8eac3924517842c69a8d2b8ea4d8f17ce2c3a
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Fri Aug 30 08:48:38 2013 +0200
Add PDCH messages to PH-/MPH-/TCH-SAP interface
This part moves PDTCH, PACCH and PTCCH message primitives from
osmo-bts-sysmo to common part.
commit ebcbe2f73078200317d5b8a134753a069f9c3572
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Fri Aug 30 08:03:09 2013 +0200
Add PCH/AGCH message to PH-/MPH-/TCH-SAP interface
This part moves PCH and AGCH message primitives from osmo-bts-sysmo to
common part.
commit 0521a5b654251fcd9a2923c607c8dbad3bd44a30
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Fri Aug 30 07:46:30 2013 +0200
Add RACH message to PH-/MPH-/TCH-SAP interface
This part moves RACH message primitives from osmo-bts-sysmo to common
part.
commit 2ee4f41d6c5fe78bb0c347e673e2411486f2bc3f
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Mon Jul 29 09:42:23 2013 +0200
Add BCCH message to PH-/MPH-/TCH-SAP interface
This first part moves BCCH message primitives from osmo-bts-sysmo to
common
part. A new file "common/l1sap.c" is introduced to implement handling of
layer 1 messages from/to BTS model.
commit 4db570049f7ef6f7604e504083e8a3b751b09d6c
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Mon Jul 29 09:37:07 2013 +0200
Add header file of PH-/MPH-/TCH-SAP interface to common part of osmo-bts
Instead of handling primitives directly at layer 1 specific code,
osmo-bts handles primitives at common code.
When all primitive are moved, the l1sap interface will:
- receive PH-DATA indications and forward them to layer 2.
- check for RF link loss and notify BSC.
- receive TCH indications and forward them via RTP.
- receive PH-RTS indications and send PH-DATA requests with content
according to its logical channel.
- receive TCH-RTS indications and send TCH requests with content
received via RTP or loopback from TCH indications.
- send MPH-INFO requests to activate, deactivate and modify logical
channels and handle their confirms.
- receive MPH-INFO indications with measurements from tranceiver.
- forward received and transmitted PH-DATA to GSMTAP.
commit ebb73d8cc333584d440398a7bed41f3584693f40
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Sun Jul 28 11:48:40 2013 +0200
sysmo-bts: Use correct boundaries of L1 msg when forwarding to L1 proxy
In case of a headroom in a message, the 'head' pointer will not point to
the actual data.
commit 2ef39102fed2167014938221411055a43a1dd763
Author: Andreas Eversberg <jolly(a)eversberg.eu>
Date: Tue Feb 5 09:31:20 2013 +0100
Remove obsolete osmo-bts-bb code
Change '%s(bsc)#' to '%s(config-bsc)# '. The missing trailing blank
brakes osmopy's VTYInteract.command() because the blank is contained
in the end patterns which are checked to decide whether to leave the
select loop. Thus trying to execute the 'bsc' command there blocks
the test script forever.
---
openbsc/src/osmo-bsc/osmo_bsc_vty.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/openbsc/src/osmo-bsc/osmo_bsc_vty.c b/openbsc/src/osmo-bsc/osmo_bsc_vty.c
index 8eaa55b..f6cf1a0 100644
--- a/openbsc/src/osmo-bsc/osmo_bsc_vty.c
+++ b/openbsc/src/osmo-bsc/osmo_bsc_vty.c
@@ -43,7 +43,7 @@ static struct osmo_msc_data *osmo_msc_data(struct vty *vty)
static struct cmd_node bsc_node = {
BSC_NODE,
- "%s(bsc)#",
+ "%s(config-bsc)# ",
1,
};
--
1.7.9.5