-- cgit v1.2.3 From 75c0e08acc898fbf534004b5f08d6c43e4252f55 Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Sat, 20 Feb 2016 10:56:10 +0100 Subject: initial checkin of manuals to public repo The manuals existed in different form for several years in an internal sysmocom repository. However, since they had just recently been converted from docboox-xml to asciidoc and all files have been re-shuffled for enabling the public release, there's not much point in keeping the history with git-filter-branch. --- doc/manuals/Makefile | 42 + doc/manuals/chapters/alink.adoc | 15 + doc/manuals/chapters/overview.adoc | 69 + doc/manuals/chapters/running.adoc | 42 + doc/manuals/osmobsc-usermanual-docinfo.xml | 52 + doc/manuals/osmobsc-usermanual.adoc | 35 + doc/manuals/osmobsc-vty-reference.xml | 44 + doc/manuals/vty/bsc_vty_additions.xml | 14 + doc/manuals/vty/bsc_vty_reference.xml | 3059 ++++++++++++++++++++++++++++ 9 files changed, 3372 insertions(+) create mode 100644 doc/manuals/Makefile create mode 100644 doc/manuals/chapters/alink.adoc create mode 100644 doc/manuals/chapters/overview.adoc create mode 100644 doc/manuals/chapters/running.adoc create mode 100644 doc/manuals/osmobsc-usermanual-docinfo.xml create mode 100644 doc/manuals/osmobsc-usermanual.adoc create mode 100644 doc/manuals/osmobsc-vty-reference.xml create mode 100644 doc/manuals/vty/bsc_vty_additions.xml create mode 100644 doc/manuals/vty/bsc_vty_reference.xml diff --git a/doc/manuals/Makefile b/doc/manuals/Makefile new file mode 100644 index 000000000..e2c464cf2 --- /dev/null +++ b/doc/manuals/Makefile @@ -0,0 +1,42 @@ +# XSL stylesheets downloaded from http://docbook.sourceforge.net/release/xsl/current/html/ +# Makefile from BitBake/OpenEmbedded manuals + + +EXTRA_DEPS = gen-bsc-vty-docbook + +topdir = . +bsc_reference = $(topdir)/osmobsc-vty-reference.xml +manuals = $(bsc_reference) +# types = pdf txt rtf ps xhtml html man tex texi dvi +# types = pdf txt +types = $(docbooktotypes) +docbooktotypes = pdf +# htmlcssfile = +# htmlcss = + +TOPDIR := .. +ASCIIDOCS := osmobsc-usermanual + +include $(TOPDIR)/build/Makefile.asciidoc.inc +include $(TOPDIR)/build/Makefile.inc + +osmobsc-usermanual.pdf: chapters/*.adoc + +clean: + rm -rf $(cleanfiles) + +gen-bsc-vty-docbook: FORCE + $(call command,xsltproc -o generated/combined1.xml \ + --stringparam with $(PWD)/../common/vty_additions.xml \ + $(MERGE_DOC) vty/bsc_vty_reference.xml, \ + XSLTPROC,Merging Common VTY) + $(call command,xsltproc -o generated/combined2.xml \ + --stringparam with $(PWD)/../common/bsc_vty_additions.xml \ + $(MERGE_DOC) generated/combined1.xml, \ + XSLTPROC,Merging Common BSC VTY) + $(call command,xsltproc -o generated/combined3.xml \ + --stringparam with $(PWD)/vty/bsc_vty_additions.xml \ + $(MERGE_DOC) generated/combined2.xml, \ + XSLTPROC,Merging BSC VTY) + $(call command,xsltproc ../vty_reference.xsl generated/combined3.xml > generated/docbook_vty.xml, \ + XSLTPROC,Converting BSC VTY to DocBook) diff --git a/doc/manuals/chapters/alink.adoc b/doc/manuals/chapters/alink.adoc new file mode 100644 index 000000000..37e64c06b --- /dev/null +++ b/doc/manuals/chapters/alink.adoc @@ -0,0 +1,15 @@ +== A-link including SCCP/BSSAP/DTAP + +OsmoBSC implements a minimal sub-set of the GSM A interface as specified +in TS 08.08. + +Unlike classic A interface implementations for E1 interfacs, OsmoBSC +implements a variant of encapsulating the A interface over IP. To do +so, the SCCP messages are wrapped in an IPA multiplex and then +communicated over TCP. The audio channels are mapped to RTP streams. + +This protcol stacking is sometimes called "SCCPlite". + +=== + +FIXME diff --git a/doc/manuals/chapters/overview.adoc b/doc/manuals/chapters/overview.adoc new file mode 100644 index 000000000..b6cc2e888 --- /dev/null +++ b/doc/manuals/chapters/overview.adoc @@ -0,0 +1,69 @@ +[[overview]] +== Overview + +This manual should help you getting started with OsmoBSC. It will cover +aspects of configuring and running the OsmoBSC. + +[[intro_overview]] +=== About OsmoBSC + +OsmoBSC is one particular version of the OpenBSC software suite. + +Unlike the highly integrated OmsoNITB, OsmoBSC impleents a more classic +GSM Base Station Controller with A-bis interface towards BTSs and A +interface towards a MSC. + + +=== Software Components + +OsmoBSC contains a variety of different software components, which +we'll quickly describe in this section. + +==== A-bis Implementation + +OsmoBSC implements the ETSI/3GPP specified A-bis interface, including +TS 08.56 (LAPD), TS 08.58 (RSL) and TS 12.21 (OML). In addition, it +supports a variety of vendor-specific extensions and dialects in order +to communicate with BTSs from Siemens, Nokia, Ericsson, ip.access and +sysmocom. + +For more information, see <> and <>. + +==== A Implementation + +OsmoBSC implements a minimal sub-set of the GSM A interface as specified +in TS 08.08. + +Unlike classic A interface implementations for E1 interfacs, OsmoBSC +implements a variant of encapsulating the A interface over IP. To do +so, the SCCP messages are wrapped in an IPA multiplex and then +communicated over TCP. The audio channels are mapped to RTP streams. + +This protcol stacking is sometimes called "SCCPlite". + +For more information, see <>. + + +==== BSC Implementation + +The BSC implementation covers the classic functionality of a GSM Base +Station Controller, i.e. + +* configuring and bringing up BTSs with their TRXs and TSs +* implementing the A-bis interface / protocols for signalling and actual + voice data (TRAU frames). +* processing measurement results from the mobile stations in dedicated + mode, performing hand-over decision and execution. +* Terminating the TS 04.08 RR (Radio Resource) sub-layer from the MS. + +For more information, see <>, <> and <>. + + +==== TRAU mapper / E1 sub-channel muxer + +Unlike classic GSM networks, OsmoBSC does not perform any transcoding. +Rather, a compatible codec is selected for both legs of a call, and +codec frames are passed through transparently. In order to achieve this +with E1 based BTS, OsmoBSC contains a E1 sub-channel de- and +re-multiplexer as well as a TRAU mapper that can map uplink to downlink +frames and vice versa. diff --git a/doc/manuals/chapters/running.adoc b/doc/manuals/chapters/running.adoc new file mode 100644 index 000000000..4be680986 --- /dev/null +++ b/doc/manuals/chapters/running.adoc @@ -0,0 +1,42 @@ +== Running OsmoBSC + +The OsmoBSC executable (`osmo-bsc`) offers the following command-line +arguments: + +==== SYNOPSIS + +*osmo-bsc* [-h|-V] [-d 'DBGMASK'] [-D] [-c 'CONFIGFILE'] [-s] [-T] [-e 'LOGLEVEL'] [-l 'IP'] [-r 'RFCTL'] + +==== OPTIONS + +*-h, --help*:: + Print a short help message about the supported options +*-V, --version*:: + Print the compile-time version number of the OsmoBTS program +*-d, --debug 'DBGMASK','DBGLEVELS'*:: + Set the log subsystems and levels for logging to stderr. This + has mostly been superseded by VTY-based logging configuration, + see <> for further information. +*-D, --daemonize*:: + Fork the process as a daemon into background. +*-c, --config-file 'CONFIGFILE'*:: + Specify the file and path name of the configuration file to be + used. If none is specified, use `openbsc.cfg` in the current + working directory. +*-s, --disable-color*:: + Disable colors for logging to stderr. This has mostly been + deprecated by VTY based logging configuration, see <> + for more information. +*-T, --timestamp*:: + Enable time-stamping of log messages to stderr. This has mostly + been deprecated by VTY based logging configu- ration, see + <> for more information. +*-e, --log-level 'LOGLEVEL'*:: + Set the global log level for logging to stderr. This has mostly + been deprecated by VTY based logging configuration, see + <> for more information. +*-l, --local='IP'*:: + Specify the local IP address of the OsmoBSC-MGCP +*-r, --rf-ctl 'RFCTL'*:: + Offer a Unix domain socket for RF control at the path/filename + 'RFCTL' in the file system. diff --git a/doc/manuals/osmobsc-usermanual-docinfo.xml b/doc/manuals/osmobsc-usermanual-docinfo.xml new file mode 100644 index 000000000..42307ceab --- /dev/null +++ b/doc/manuals/osmobsc-usermanual-docinfo.xml @@ -0,0 +1,52 @@ + + + 1 + February 2016 + HW + + Initial OsmoBSC manual, recycling OsmoNITB sections + + + + + + + Holger + Freyther + hfreyther@sysmocom.de + HF + + sysmocom + sysmocom - s.f.m.c. GmbH + Managing Director + + + + Harald + Welte + hwelte@sysmocom.de + HW + + sysmocom + sysmocom - s.f.m.c. GmbH + Managing Director + + + + + + 2012-2016 + sysmocom - s.f.m.c. GmbH + + + + + Permission is granted to copy, distribute and/or modify this + document under the terms of the GNU Free Documentation License, + Version 1.3 or any later version published by the Free Software + Foundation; with the Invariant Sections being just 'Foreword', + 'Acknowledgements' and 'Preface', with no Front-Cover Texts, + and no Back-Cover Texts. A copy of the license is included in + the section entitled "GNU Free Documentation License". + + diff --git a/doc/manuals/osmobsc-usermanual.adoc b/doc/manuals/osmobsc-usermanual.adoc new file mode 100644 index 000000000..dcb475a63 --- /dev/null +++ b/doc/manuals/osmobsc-usermanual.adoc @@ -0,0 +1,35 @@ +OsmoBSC User Manual +=================== +Harald Welte + + +include::../common/chapters/preface.adoc[] + +include::chapters/overview.adoc[] + +include::chapters/running.adoc[] + +include::../common/chapters/vty.adoc[] + +include::../common/chapters/logging.adoc[] + +include::../common/chapters/bts.adoc[] + +include::chapters/bts-examples.adoc[] + +include::../common/chapters/bsc.adoc[] + +include::../common/chapters/abis.adoc[] + +#include::../common/chapters/alink.adoc[] + +include::../common/chapters/control_if.adoc[] + +include::../common/chapters/port_numbers.adoc[] + +include::../common/chapters/bibliography.adoc[] + +include::../common/chapters/glossary.adoc[] + +include::../common/chapters/gfdl.adoc[] + diff --git a/doc/manuals/osmobsc-vty-reference.xml b/doc/manuals/osmobsc-vty-reference.xml new file mode 100644 index 000000000..6e60357c7 --- /dev/null +++ b/doc/manuals/osmobsc-vty-reference.xml @@ -0,0 +1,44 @@ + + + + +]> + + + + + + v1 + 13th August 2012 + hf + Initial + + + v2 + 5th March 2014 + hf + Update to match osmo-bsc version 0.13.0-305 + + + + OsmoBSC VTY Reference + + + 2012-2014 + + + + This work is copyright by sysmocom - s.f.m.c. GmbH. All rights reserved. + + + + + + &chapter-vty; + + diff --git a/doc/manuals/vty/bsc_vty_additions.xml b/doc/manuals/vty/bsc_vty_additions.xml new file mode 100644 index 000000000..2764eb8f9 --- /dev/null +++ b/doc/manuals/vty/bsc_vty_additions.xml @@ -0,0 +1,14 @@ + + + + MSC Connection Commands + This node allows to configure the MSC connection related + settings. + + + + BSC Commands + This node allows to configure the BSC connection related + settings. + + diff --git a/doc/manuals/vty/bsc_vty_reference.xml b/doc/manuals/vty/bsc_vty_reference.xml new file mode 100644 index 000000000..3b61b4235 --- /dev/null +++ b/doc/manuals/vty/bsc_vty_reference.xml @@ -0,0 +1,3059 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + \ No newline at end of file -- cgit v1.2.3 From a412d9041fe6819e3344037662dcf44e6dbb4229 Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Sat, 20 Feb 2016 18:12:53 +0100 Subject: Add link to Asciidoc source code of manual --- doc/manuals/osmobsc-usermanual-docinfo.xml | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/doc/manuals/osmobsc-usermanual-docinfo.xml b/doc/manuals/osmobsc-usermanual-docinfo.xml index 42307ceab..5ac374201 100644 --- a/doc/manuals/osmobsc-usermanual-docinfo.xml +++ b/doc/manuals/osmobsc-usermanual-docinfo.xml @@ -49,4 +49,10 @@ and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License". + + The Asciidoc source code of this manual can be found at + + http://git.osmocom.org/osmo-gsm-manuals/ + + -- cgit v1.2.3 From 2e904b13854480733d37790dadb8a1fc01c17398 Mon Sep 17 00:00:00 2001 From: Max Date: Wed, 4 May 2016 14:30:49 +0200 Subject: Add OsmoBSC control interface description --- doc/manuals/chapters/overview.adoc | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/doc/manuals/chapters/overview.adoc b/doc/manuals/chapters/overview.adoc index b6cc2e888..6577df823 100644 --- a/doc/manuals/chapters/overview.adoc +++ b/doc/manuals/chapters/overview.adoc @@ -67,3 +67,25 @@ codec frames are passed through transparently. In order to achieve this with E1 based BTS, OsmoBSC contains a E1 sub-channel de- and re-multiplexer as well as a TRAU mapper that can map uplink to downlink frames and vice versa. + +=== Control interface + +The actual protocol is described in <> section. Here we +describe variables specific to OsmoBSC. + +.Variables available over control interface +[options="header",width="100%",cols="20%,5%,5%,50%,20%"] +|=== +|Name|Access|Trap|Value|Comment +|msc_connection_status|RO|Yes|"connected", "disconnected"|Indicate the status of connection to MSC. +|bts_connection_status|RO|Yes|"connected", "disconnected"|Indicate the status of connection to BTS. +|location|RW|Yes|",(invalid\|fix2d\|fix3d),,,"|Set/Get location data. +|timezone|RW|No|",,", "off"|-19 <= hours <= 19, mins in {0, 15, 30, 45}, and 0 <= dst <= 2 +|notification|WO|Yes|| +|inform-msc-v1|WO|Yes|| +|ussd-notify-v1|WO|Yes|| +|=== + +Some comments. +FIXME: commands defined in src/ctrl/control_if.c? Nodes? Traps? + -- cgit v1.2.3 From 1389bd17567b54729993f9abef8f54212bb09b41 Mon Sep 17 00:00:00 2001 From: Jonathan Brielmaier Date: Wed, 25 May 2016 15:01:11 +0200 Subject: fix various typos across all manuals --- doc/manuals/chapters/alink.adoc | 4 ++-- doc/manuals/chapters/overview.adoc | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/manuals/chapters/alink.adoc b/doc/manuals/chapters/alink.adoc index 37e64c06b..081e03ff9 100644 --- a/doc/manuals/chapters/alink.adoc +++ b/doc/manuals/chapters/alink.adoc @@ -3,12 +3,12 @@ OsmoBSC implements a minimal sub-set of the GSM A interface as specified in TS 08.08. -Unlike classic A interface implementations for E1 interfacs, OsmoBSC +Unlike classic A interface implementations for E1 interface, OsmoBSC implements a variant of encapsulating the A interface over IP. To do so, the SCCP messages are wrapped in an IPA multiplex and then communicated over TCP. The audio channels are mapped to RTP streams. -This protcol stacking is sometimes called "SCCPlite". +This protocol stacking is sometimes called "SCCPlite". === diff --git a/doc/manuals/chapters/overview.adoc b/doc/manuals/chapters/overview.adoc index 6577df823..580a42eb8 100644 --- a/doc/manuals/chapters/overview.adoc +++ b/doc/manuals/chapters/overview.adoc @@ -9,7 +9,7 @@ aspects of configuring and running the OsmoBSC. OsmoBSC is one particular version of the OpenBSC software suite. -Unlike the highly integrated OmsoNITB, OsmoBSC impleents a more classic +Unlike the highly integrated OmsoNITB, OsmoBSC implements a more classic GSM Base Station Controller with A-bis interface towards BTSs and A interface towards a MSC. @@ -39,7 +39,7 @@ implements a variant of encapsulating the A interface over IP. To do so, the SCCP messages are wrapped in an IPA multiplex and then communicated over TCP. The audio channels are mapped to RTP streams. -This protcol stacking is sometimes called "SCCPlite". +This protocol stacking is sometimes called "SCCPlite". For more information, see <>. -- cgit v1.2.3 From 1d772228e41db0127752c1ce66ccf01d7461f6b8 Mon Sep 17 00:00:00 2001 From: Neels Hofmeyr Date: Wed, 25 May 2016 15:12:33 +0200 Subject: minor tweak --- doc/manuals/chapters/alink.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/manuals/chapters/alink.adoc b/doc/manuals/chapters/alink.adoc index 081e03ff9..0321c0e02 100644 --- a/doc/manuals/chapters/alink.adoc +++ b/doc/manuals/chapters/alink.adoc @@ -3,7 +3,7 @@ OsmoBSC implements a minimal sub-set of the GSM A interface as specified in TS 08.08. -Unlike classic A interface implementations for E1 interface, OsmoBSC +Unlike classic A interface implementations for E1 interfaces, OsmoBSC implements a variant of encapsulating the A interface over IP. To do so, the SCCP messages are wrapped in an IPA multiplex and then communicated over TCP. The audio channels are mapped to RTP streams. -- cgit v1.2.3 From 7f3d8ea4d371b7ff4a90c7a7fba11d167d8ab537 Mon Sep 17 00:00:00 2001 From: Max Date: Wed, 4 May 2016 14:52:15 +0200 Subject: Add OsmoBSC control interface description --- doc/manuals/chapters/control.adoc | 99 +++++++++++++++++++++++++++++++++++++ doc/manuals/osmobsc-usermanual.adoc | 2 + 2 files changed, 101 insertions(+) create mode 100644 doc/manuals/chapters/control.adoc diff --git a/doc/manuals/chapters/control.adoc b/doc/manuals/chapters/control.adoc new file mode 100644 index 000000000..a1d6b435b --- /dev/null +++ b/doc/manuals/chapters/control.adoc @@ -0,0 +1,99 @@ +[[control]] +== Control interface + +The actual protocol is described in <>, the variables +common to all programs using it are described in <>. Here we +describe variables specific to OsmoBSC. The commands starting with prefix +"net.btsN." are specific to a certain BTS so N have to be replaced with BTS +number when issuing command e. g. "net.bts1.channel-load". Similarly the +TRX-specific commands are additionally prefixed with TRX number e. g. +"net.bts1.trx2.arfcn". + +.Variables available over control interface +[options="header",width="100%",cols="20%,5%,5%,50%,20%"] +|=== +|Name|Access|Trap|Value|Comment +|msc_connection_status|RO|Yes|"connected", "disconnected"|Indicate the status of connection to MSC. +|bts_connection_status|RO|Yes|"connected", "disconnected"|Indicate the status of connection to BTS. +|location|RW|Yes|",(invalid\|fix2d\|fix3d),,,"|Set/Get location data. +|timezone|RW|No|",,", "off"|-19 \<= hours \<= 19, mins in {0, 15, 30, 45}, and 0 \<= dst \<= 2 +|apply-configuration|WO|No|"restart"|Restart all BTSes. +|mnc|RW|No|""|Set/Get MNC (value between (0, 999)). +|mcc|RW|No|""|Set/Get MCC (value between (1, 999)). +|short-name|RW|No|""|Set/Get network's short name. +|long-name|RW|No|""|Set/Get network's long name. +|mcc-mnc-apply|WO|No|","|Apply new MCC/MNC values if different from currently used one. +|notification|WO|Yes|Arbitrary value| See <> for details. +|inform-msc-v1|WO|Yes|Arbitrary value| See <> for details. +|ussd-notify-v1|WO|No|",,"| See <> for details. +|rf_locked|RW|No|"0","1"|See <> for details. +|number-of-bts|RO|No|""|Get number of configured BTS. +|net.btsN.location-area-code|RW|No|""|Set/Get LAC (value between (0, 65535)). +|net.btsN.cell-identity|RW|No|""|Set/Get Cell Identity (value between (0, 65535)). +|net.btsN.apply-configuration|WO|No|Ignored|Restart BTS via OML. +|net.btsN.send-new-system-informations|WO|No|Ignored|Regenerate System Information messages for given BTS. +|net.btsN.channel-load|RO|No|",,"|See <> for details. +|net.btsN.oml-connection-state|RO|No|"connected", "disconnected"|Indicate the status of OML connection of BTS. +|net.btsN.gprs-mode|RW|No|""|See <> for details. +|net.btsN.rf_state|RO|No|",,"|See <> for details. +|net.btsN.trxM.arfcn|RW|No|""|Set/Get ARFCN (value between (0, 1023)). +|net.btsN.trxM.max-power-reduction|RW|No|""|See <> for details. +|=== + +[[notif]] +=== notification + +Setting this variable initiate TRAP "notification" to all the clients connected +to control interface with the value supplied in SET operation. This is not +intended to be used outside of local systems. + +[[infomsc]] +=== inform-msc-v1 + +Setting this variable initiate TRAP "inform-msc-v1" to all connected MSCs +control interfaces with the value supplied in SET operation. + +[[ussdnot]] +=== ussd-notify-v1 + +Setting this variable will send USSD Notify message to subscriber specified in +command parameters with the text specified in command parameters. + +[[chanlo]] +=== channel-load + +Obtain channel load for given BTS. Returns concatenated set of triplets +(",,") for all channel types configured on the BTS. The +"" is the channel type. The "" is the number of channels of that +type currently in use. The "" is the number of channels of that type +configured on the BTS. + +[[gprsm]] +=== gprs-mode + +Set/Get the GPRS mode of the BTS. One of the following is +accepted/returned: "none", "gprs", "egprs". + +[[rfs]] +=== rf_state + +Following triplet is returned: ",,". The "" might be +"operational" or "inoperational" representing different operational states. The +"" might be "locked" or "unlocked" representing administrative status. +The "" might be "off", "on", "grace" or "unknown" representing different +RF policies. + +[[rfl]] +=== rf_locked + +Set/Get RF locked status. The GET operation will return either "0" or "1" +depending on the RF lock status. The SET operation will set RF lock status if +RF Ctrl is enabled in the BSC Configuration. + +[[mpr]] +=== max-power-reduction + +Set/Get the value of maximum power reduction. Even values between 0 and 22 are +accepted. + +FIXME: add variables defined in src/ctrl/control_if.c? diff --git a/doc/manuals/osmobsc-usermanual.adoc b/doc/manuals/osmobsc-usermanual.adoc index dcb475a63..bf1f9241a 100644 --- a/doc/manuals/osmobsc-usermanual.adoc +++ b/doc/manuals/osmobsc-usermanual.adoc @@ -9,6 +9,8 @@ include::chapters/overview.adoc[] include::chapters/running.adoc[] +include::chapters/control.adoc[] + include::../common/chapters/vty.adoc[] include::../common/chapters/logging.adoc[] -- cgit v1.2.3 From d588a95904d9fc4d65052f9dda356331b16fcc36 Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Mon, 4 Jul 2016 22:50:17 +0200 Subject: add Ericsson OM2000 message sequence charts (one for each MO) --- doc/manuals/om2000/README | 2 ++ doc/manuals/om2000/om2k-bts.msc | 24 ++++++++++++++++++++++++ doc/manuals/om2000/om2k-mo-cf.msc | 19 +++++++++++++++++++ doc/manuals/om2000/om2k-mo-is.msc | 29 +++++++++++++++++++++++++++++ doc/manuals/om2000/om2k-mo-rx.msc | 31 +++++++++++++++++++++++++++++++ doc/manuals/om2000/om2k-mo-tf.msc | 29 +++++++++++++++++++++++++++++ doc/manuals/om2000/om2k-mo-trxc.msc | 16 ++++++++++++++++ doc/manuals/om2000/om2k-mo-ts.msc | 28 ++++++++++++++++++++++++++++ doc/manuals/om2000/om2k-mo-tx.msc | 26 ++++++++++++++++++++++++++ doc/manuals/om2000/om2k-trx.msc | 33 +++++++++++++++++++++++++++++++++ 10 files changed, 237 insertions(+) create mode 100644 doc/manuals/om2000/README create mode 100644 doc/manuals/om2000/om2k-bts.msc create mode 100644 doc/manuals/om2000/om2k-mo-cf.msc create mode 100644 doc/manuals/om2000/om2k-mo-is.msc create mode 100644 doc/manuals/om2000/om2k-mo-rx.msc create mode 100644 doc/manuals/om2000/om2k-mo-tf.msc create mode 100644 doc/manuals/om2000/om2k-mo-trxc.msc create mode 100644 doc/manuals/om2000/om2k-mo-ts.msc create mode 100644 doc/manuals/om2000/om2k-mo-tx.msc create mode 100644 doc/manuals/om2000/om2k-trx.msc diff --git a/doc/manuals/om2000/README b/doc/manuals/om2000/README new file mode 100644 index 000000000..08f8cc138 --- /dev/null +++ b/doc/manuals/om2000/README @@ -0,0 +1,2 @@ +This is a set of message sequence charts documneting our understanding +of Ericsson OM2000 at BTS start-up, by looking at protocol traces. diff --git a/doc/manuals/om2000/om2k-bts.msc b/doc/manuals/om2000/om2k-bts.msc new file mode 100644 index 000000000..0c6439859 --- /dev/null +++ b/doc/manuals/om2000/om2k-bts.msc @@ -0,0 +1,24 @@ +msc { + trxc [label="TRXC"], tf [label="TF"], is [label="IS"], cf [label="CF"], bsc [label="BSC"]; + cf => bsc [label="Fault Report"]; + cf <=> bsc [label="Start incl. Negotiation"]; + cf <=> bsc [label="Operational Info"]; + + is <=> bsc [label="Connect"]; + is <=> bsc [label="Reset"]; + is <=> bsc [label="Start"]; + is <=> bsc [label="Config"]; + is <=> bsc [label="Enable"]; + is <=> bsc [label="Operational Info"]; + + trxc <=> bsc [label="TRXC + dependent objects"]; + + cf <=> bsc [label="Calendar Time"]; + + tf <=> bsc [label="Conncet"]; + tf <=> bsc [label="Reset"]; + tf <=> bsc [label="Start"]; + tf <=> bsc [label="Config"]; + tf <=> bsc [label="Enable"]; + tf <=> bsc [label="Operational Info"]; +} diff --git a/doc/manuals/om2000/om2k-mo-cf.msc b/doc/manuals/om2000/om2k-mo-cf.msc new file mode 100644 index 000000000..f10e5196d --- /dev/null +++ b/doc/manuals/om2000/om2k-mo-cf.msc @@ -0,0 +1,19 @@ +msc { + bts [label="BTS"], bsc [label="BSC"]; + # this is for the Central Function Object + --- [label="Initial state after initializing OML TEI"]; + + bts <= bsc [label="Start Request"]; + bts => bsc [label="Reset Request Accept"]; + + bts => bsc [label="Negotiation Request"]; + bts <= bsc [label="Negotiation Request ACK"]; + + bts => bsc [label="Start Result (Started)"]; + bts <= bsc [label="Start Result ACK"]; + + bts <= bsc [label="Operational Info (Operational)"]; + bts => bsc [label="Operational Info Accept"]; + + # continue with IS, TRXC, TF +} diff --git a/doc/manuals/om2000/om2k-mo-is.msc b/doc/manuals/om2000/om2k-mo-is.msc new file mode 100644 index 000000000..20acdd859 --- /dev/null +++ b/doc/manuals/om2000/om2k-mo-is.msc @@ -0,0 +1,29 @@ +msc { + bts [label="BTS"], bsc [label="BSC"]; + # this is for the Interface Switch Object + --- [label="Initial state after initializing CF"]; + + bts <= bsc [label="Connect Command"]; + bts => bsc [label="Connect Complete"]; + + bts <= bsc [label="Reset Command"]; + bts => bsc [label="Reset Complete"]; + + bts <= bsc [label="Start Request"]; + bts => bsc [label="Start Request Accept"]; + bts => bsc [label="Start Result (Disabled)"]; + bts <= bsc [label="Start Result ACK"]; + + bts <= bsc [label="IS Configuration Request"]; + bts => bsc [label="IS Configuration Request Accept"]; + bts => bsc [label="IS Configuration Result (According to Req)"]; + bts <= bsc [label="IS Configuration Result ACK"]; + + bts <= bsc [label="Enable Request"]; + bts => bsc [label="Enable Request Accept"]; + bts => bsc [label="Enable Result (Enabled)"]; + bts <= bsc [label="Enable Result ACK"]; + + bts <= bsc [label="Operational Info (Operational)"]; + bts => bsc [label="Operational Info Accept"]; +} diff --git a/doc/manuals/om2000/om2k-mo-rx.msc b/doc/manuals/om2000/om2k-mo-rx.msc new file mode 100644 index 000000000..4fe1365d2 --- /dev/null +++ b/doc/manuals/om2000/om2k-mo-rx.msc @@ -0,0 +1,31 @@ +msc { + bts [label="BTS"], bsc [label="BSC"]; + # this is for the TRX Receiver Object + --- [label="Initial state after initializing TRXC"]; + + bts <= bsc [label="Connect Command"]; + bts => bsc [label="Connect Complete"]; + + bts <= bsc [label="Reset Command"]; + bts => bsc [label="Reset Complete"]; + + bts <= bsc [label="Start Request"]; + bts => bsc [label="Start Request Accept"]; + bts => bsc [label="Start Result (Disabled)"]; + bts <= bsc [label="Start Result ACK"]; + + bts <= bsc [label="Start Request"]; + bts => bsc [label="Reset Request Accept"]; + bts => bsc [label="Start Result (Disabled)"]; + bts <= bsc [label="Start Result ACK"]; + + bts <= bsc [label="RX Configuration Request"]; + bts => bsc [label="RX Configuration Request Accept"]; + bts => bsc [label="RX Configuration Result"]; + bts <= bsc [label="RX Configuration Result ACK"]; + + bts <= bsc [label="Enable Request"]; + bts => bsc [label="Enable Request Accept"]; + bts => bsc [label="Enable Result (Enabled)"]; + bts <= bsc [label="Enable Result ACK"]; +} diff --git a/doc/manuals/om2000/om2k-mo-tf.msc b/doc/manuals/om2000/om2k-mo-tf.msc new file mode 100644 index 000000000..ae1cdfda7 --- /dev/null +++ b/doc/manuals/om2000/om2k-mo-tf.msc @@ -0,0 +1,29 @@ +msc { + bts [label="BTS"], bsc [label="BSC"]; + # this is for the Timing Funcition Object + --- [label="Initial state after initializing CF"]; + + bts <= bsc [label="Connect Command"]; + bts => bsc [label="Connect Complete"]; + + bts <= bsc [label="Reset Command"]; + bts => bsc [label="Reset Complete"]; + + bts <= bsc [label="Start Request"]; + bts => bsc [label="Reset Request Accept"]; + bts => bsc [label="Start Result (Disabled)"]; + bts <= bsc [label="Start Result ACK"]; + + bts <= bsc [label="TF Configuration Request"]; + bts => bsc [label="TF Configuration Request Accept"]; + bts => bsc [label="TF Configuration Result (According to Req)"]; + bts <= bsc [label="TF Configuration Result ACK"]; + + bts <= bsc [label="Enable Request"]; + bts => bsc [label="Enable Request Accept"]; + bts => bsc [label="Enable Result (Enabled)"]; + bts <= bsc [label="Enable Result ACK"]; + + bts <= bsc [label="Operational Info (Operational)"]; + bts => bsc [label="Operational Info Accept"]; +} diff --git a/doc/manuals/om2000/om2k-mo-trxc.msc b/doc/manuals/om2000/om2k-mo-trxc.msc new file mode 100644 index 000000000..56fb63962 --- /dev/null +++ b/doc/manuals/om2000/om2k-mo-trxc.msc @@ -0,0 +1,16 @@ +msc { + bts [label="BTS"], bsc [label="BSC"]; + # this is for the TRX Controller Object + --- [label="Initial state after initializing IS"]; + + bts <= bsc [label="Reset Command"]; + bts => bsc [label="Reset Complete"]; + + bts <= bsc [label="Start Request"]; + bts => bsc [label="Reset Request Accept"]; + bts => bsc [label="Start Result (Started)"]; + bts <= bsc [label="Start Result ACK"]; + + bts <= bsc [label="Operational Info (Operational)"]; + bts => bsc [label="Operational Info Accept"]; +} diff --git a/doc/manuals/om2000/om2k-mo-ts.msc b/doc/manuals/om2000/om2k-mo-ts.msc new file mode 100644 index 000000000..6557de00e --- /dev/null +++ b/doc/manuals/om2000/om2k-mo-ts.msc @@ -0,0 +1,28 @@ +msc { + bts [label="BTS"], bsc [label="BSC"]; + # this is for the Timeslot Object + --- [label="Initial state after initializing RX"]; + + bts <= bsc [label="Connect Command"]; + bts => bsc [label="Connect Complete"]; + + bts <= bsc [label="Reset Command"]; + bts => bsc [label="Reset Complete"]; + + bts <= bsc [label="Start Request"]; + bts => bsc [label="Reset Request Accept"]; + bts => bsc [label="Start Result (Disabled)"]; + bts <= bsc [label="Start Result ACK"]; + + bts <= bsc [label="TS Configuration Request"]; + bts => bsc [label="TS Configuration Request Accept"]; + bts => bsc [label="TS Configuration Result"]; + bts <= bsc [label="TS Configuration Result ACK"]; + + bts <= bsc [label="Enable Request"]; + bts => bsc [label="Enable Request Accept"]; + bts => bsc [label="Enable Result (Enabled)"]; + bts <= bsc [label="Enable Result ACK"]; + + # continue with BCCH filling after all TS +} diff --git a/doc/manuals/om2000/om2k-mo-tx.msc b/doc/manuals/om2000/om2k-mo-tx.msc new file mode 100644 index 000000000..f822951ad --- /dev/null +++ b/doc/manuals/om2000/om2k-mo-tx.msc @@ -0,0 +1,26 @@ +msc { + bts [label="BTS"], bsc [label="BSC"]; + # this is for the TRX Transmitter Object + --- [label="Initial state after initializing TRXC"]; + + bts <= bsc [label="Connect Command"]; + bts => bsc [label="Connect Complete"]; + + bts <= bsc [label="Reset Command"]; + bts => bsc [label="Reset Complete"]; + + bts <= bsc [label="Start Request"]; + bts => bsc [label="Reset Request Accept"]; + bts => bsc [label="Start Result (Disabled)"]; + bts <= bsc [label="Start Result ACK"]; + + bts <= bsc [label="TX Configuration Request"]; + bts => bsc [label="TX Configuration Request Accept"]; + bts => bsc [label="TX Configuration Result"]; + bts <= bsc [label="TX Configuration Result ACK"]; + + bts <= bsc [label="Enable Request"]; + bts => bsc [label="Enable Request Accept"]; + bts => bsc [label="Enable Result (Enabled)"]; + bts <= bsc [label="Enable Result ACK"]; +} diff --git a/doc/manuals/om2000/om2k-trx.msc b/doc/manuals/om2000/om2k-trx.msc new file mode 100644 index 000000000..21e61d8b1 --- /dev/null +++ b/doc/manuals/om2000/om2k-trx.msc @@ -0,0 +1,33 @@ +msc { + hscale=2; + ts [label="TS"], rx [label="RX"], tx [label="TX"], trxc [label="TRXC"], bsc [label="BSC"]; + + trxc => bsc [label="Fault Report"]; + + trxc <=> bsc [label="Reset"]; + trxc <=> bsc [label="Start"]; + trxc <=> bsc [label="Operational Info"]; + + --- [label="Do we wait for TF here?"]; + + tx <=> bsc [label="Connect"]; + tx <=> bsc [label="Reset"]; + tx <=> bsc [label="Start"]; + tx <=> bsc [label="Config"]; + tx <=> bsc [label="Enable"]; + + rx <=> bsc [label="Connect"]; + rx <=> bsc [label="Reset"]; + rx <=> bsc [label="Start"]; + rx <=> bsc [label="Config"]; + rx <=> bsc [label="Enable"]; + + ts <=> bsc [label="Connect"]; + ts <=> bsc [label="Reset"]; + ts <=> bsc [label="Start"]; + ts <=> bsc [label="Config"]; + ts <=> bsc [label="Enable"]; + + trxc <=> bsc [label="BCCH INFO"]; + trxc <=> bsc [label="Other RSL procedures"]; +} -- cgit v1.2.3 From 132e0861b82451ba3755f83211cc8de33b8aded1 Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Mon, 3 Oct 2016 14:33:44 +0200 Subject: OM2000 message sequence charts: specify MO in node name --- doc/manuals/om2000/om2k-mo-cf.msc | 2 +- doc/manuals/om2000/om2k-mo-is.msc | 2 +- doc/manuals/om2000/om2k-mo-rx.msc | 2 +- doc/manuals/om2000/om2k-mo-tf.msc | 2 +- doc/manuals/om2000/om2k-mo-trxc.msc | 2 +- doc/manuals/om2000/om2k-mo-ts.msc | 2 +- doc/manuals/om2000/om2k-mo-tx.msc | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/doc/manuals/om2000/om2k-mo-cf.msc b/doc/manuals/om2000/om2k-mo-cf.msc index f10e5196d..4f647bb29 100644 --- a/doc/manuals/om2000/om2k-mo-cf.msc +++ b/doc/manuals/om2000/om2k-mo-cf.msc @@ -1,5 +1,5 @@ msc { - bts [label="BTS"], bsc [label="BSC"]; + bts [label="BTS (CF)"], bsc [label="BSC"]; # this is for the Central Function Object --- [label="Initial state after initializing OML TEI"]; diff --git a/doc/manuals/om2000/om2k-mo-is.msc b/doc/manuals/om2000/om2k-mo-is.msc index 20acdd859..99ec7b765 100644 --- a/doc/manuals/om2000/om2k-mo-is.msc +++ b/doc/manuals/om2000/om2k-mo-is.msc @@ -1,5 +1,5 @@ msc { - bts [label="BTS"], bsc [label="BSC"]; + bts [label="BTS (IS)"], bsc [label="BSC"]; # this is for the Interface Switch Object --- [label="Initial state after initializing CF"]; diff --git a/doc/manuals/om2000/om2k-mo-rx.msc b/doc/manuals/om2000/om2k-mo-rx.msc index 4fe1365d2..438578769 100644 --- a/doc/manuals/om2000/om2k-mo-rx.msc +++ b/doc/manuals/om2000/om2k-mo-rx.msc @@ -1,5 +1,5 @@ msc { - bts [label="BTS"], bsc [label="BSC"]; + bts [label="TRX (RX)"], bsc [label="BSC"]; # this is for the TRX Receiver Object --- [label="Initial state after initializing TRXC"]; diff --git a/doc/manuals/om2000/om2k-mo-tf.msc b/doc/manuals/om2000/om2k-mo-tf.msc index ae1cdfda7..8df363800 100644 --- a/doc/manuals/om2000/om2k-mo-tf.msc +++ b/doc/manuals/om2000/om2k-mo-tf.msc @@ -1,5 +1,5 @@ msc { - bts [label="BTS"], bsc [label="BSC"]; + bts [label="BTS (TF)"], bsc [label="BSC"]; # this is for the Timing Funcition Object --- [label="Initial state after initializing CF"]; diff --git a/doc/manuals/om2000/om2k-mo-trxc.msc b/doc/manuals/om2000/om2k-mo-trxc.msc index 56fb63962..c3bcbb39f 100644 --- a/doc/manuals/om2000/om2k-mo-trxc.msc +++ b/doc/manuals/om2000/om2k-mo-trxc.msc @@ -1,5 +1,5 @@ msc { - bts [label="BTS"], bsc [label="BSC"]; + bts [label="TRX (TRXC)"], bsc [label="BSC"]; # this is for the TRX Controller Object --- [label="Initial state after initializing IS"]; diff --git a/doc/manuals/om2000/om2k-mo-ts.msc b/doc/manuals/om2000/om2k-mo-ts.msc index 6557de00e..9f9bbf80e 100644 --- a/doc/manuals/om2000/om2k-mo-ts.msc +++ b/doc/manuals/om2000/om2k-mo-ts.msc @@ -1,5 +1,5 @@ msc { - bts [label="BTS"], bsc [label="BSC"]; + bts [label="TRX (TS)"], bsc [label="BSC"]; # this is for the Timeslot Object --- [label="Initial state after initializing RX"]; diff --git a/doc/manuals/om2000/om2k-mo-tx.msc b/doc/manuals/om2000/om2k-mo-tx.msc index f822951ad..88a12a4bb 100644 --- a/doc/manuals/om2000/om2k-mo-tx.msc +++ b/doc/manuals/om2000/om2k-mo-tx.msc @@ -1,5 +1,5 @@ msc { - bts [label="BTS"], bsc [label="BSC"]; + bts [label="TRX (TX)"], bsc [label="BSC"]; # this is for the TRX Transmitter Object --- [label="Initial state after initializing TRXC"]; -- cgit v1.2.3 From 92c845eca572962e917d307237c045864effbc3c Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Mon, 3 Oct 2016 14:35:54 +0200 Subject: OM2000 MSC: Fix spelling --- doc/manuals/om2000/om2k-bts.msc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/manuals/om2000/om2k-bts.msc b/doc/manuals/om2000/om2k-bts.msc index 0c6439859..a26065793 100644 --- a/doc/manuals/om2000/om2k-bts.msc +++ b/doc/manuals/om2000/om2k-bts.msc @@ -15,7 +15,7 @@ msc { cf <=> bsc [label="Calendar Time"]; - tf <=> bsc [label="Conncet"]; + tf <=> bsc [label="Connect"]; tf <=> bsc [label="Reset"]; tf <=> bsc [label="Start"]; tf <=> bsc [label="Config"]; -- cgit v1.2.3 From b667aefb66d30024ba15c7eb3f92e72e5b2e8ce1 Mon Sep 17 00:00:00 2001 From: Neels Hofmeyr Date: Mon, 17 Oct 2016 04:42:34 +0200 Subject: make clean: also remove generated image files Change-Id: I80798e79b4ccee64f26f58f9754de02b2958e33e --- doc/manuals/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/doc/manuals/Makefile b/doc/manuals/Makefile index e2c464cf2..fb5e269d7 100644 --- a/doc/manuals/Makefile +++ b/doc/manuals/Makefile @@ -24,6 +24,7 @@ osmobsc-usermanual.pdf: chapters/*.adoc clean: rm -rf $(cleanfiles) + rm -rf osmobsc-usermanual__*.{svg,png} gen-bsc-vty-docbook: FORCE $(call command,xsltproc -o generated/combined1.xml \ -- cgit v1.2.3 From 4d8fc869bffa2d379e9080d937832c87e4ee6b7e Mon Sep 17 00:00:00 2001 From: Neels Hofmeyr Date: Mon, 17 Oct 2016 06:15:34 +0200 Subject: add 'make check' target Generate *.check files from asciidoc output and grep for WARNINGs. Add *.check files to gitignore and to 'make clean'. Change-Id: Ibccc83a3415930a528f2e8e4e4dda3b81c6d0b64 --- doc/manuals/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/manuals/Makefile b/doc/manuals/Makefile index fb5e269d7..9fc6f266c 100644 --- a/doc/manuals/Makefile +++ b/doc/manuals/Makefile @@ -24,7 +24,7 @@ osmobsc-usermanual.pdf: chapters/*.adoc clean: rm -rf $(cleanfiles) - rm -rf osmobsc-usermanual__*.{svg,png} + rm -rf osmobsc-usermanual__*.{svg,png,check} gen-bsc-vty-docbook: FORCE $(call command,xsltproc -o generated/combined1.xml \ -- cgit v1.2.3 From 4c297e7b93af692147d09ca2ceb68aba06193723 Mon Sep 17 00:00:00 2001 From: Neels Hofmeyr Date: Mon, 17 Oct 2016 06:12:13 +0200 Subject: OsmoBSC+NITB/running: fix title levels, one too deep Change-Id: If81e44c9a0774e5de39cc536989cef5cb214a224 --- doc/manuals/chapters/running.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/manuals/chapters/running.adoc b/doc/manuals/chapters/running.adoc index 4be680986..6747a2919 100644 --- a/doc/manuals/chapters/running.adoc +++ b/doc/manuals/chapters/running.adoc @@ -3,11 +3,11 @@ The OsmoBSC executable (`osmo-bsc`) offers the following command-line arguments: -==== SYNOPSIS +=== SYNOPSIS *osmo-bsc* [-h|-V] [-d 'DBGMASK'] [-D] [-c 'CONFIGFILE'] [-s] [-T] [-e 'LOGLEVEL'] [-l 'IP'] [-r 'RFCTL'] -==== OPTIONS +=== OPTIONS *-h, --help*:: Print a short help message about the supported options -- cgit v1.2.3 From d0f60df769ed3c2ca8220e07c693d2e7f7891e6c Mon Sep 17 00:00:00 2001 From: Neels Hofmeyr Date: Mon, 17 Oct 2016 06:12:36 +0200 Subject: OsmoBSC: include bts-examples.adoc from OsmoNITB Change-Id: I6b6d8c413762c710453b228f846216961b578597 --- doc/manuals/osmobsc-usermanual.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/manuals/osmobsc-usermanual.adoc b/doc/manuals/osmobsc-usermanual.adoc index bf1f9241a..25bd35b59 100644 --- a/doc/manuals/osmobsc-usermanual.adoc +++ b/doc/manuals/osmobsc-usermanual.adoc @@ -17,7 +17,7 @@ include::../common/chapters/logging.adoc[] include::../common/chapters/bts.adoc[] -include::chapters/bts-examples.adoc[] +include::../OsmoNITB/chapters/bts-examples.adoc[] include::../common/chapters/bsc.adoc[] -- cgit v1.2.3 From 7f7ca91a0489277ddff259a3370a3d9bb5e1b27f Mon Sep 17 00:00:00 2001 From: Neels Hofmeyr Date: Mon, 17 Oct 2016 06:47:22 +0200 Subject: fix 'make clean': shell glob, ignore failure Unfortunately a glob like osmo-x__*.{svg,png} doesn't work, so have the suffixes in separate globs. Add dashes to indicate that failure should be ignored. Change-Id: I6bc4d9ea72b43a573acbc860c23397f748de2c7b --- doc/manuals/Makefile | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/doc/manuals/Makefile b/doc/manuals/Makefile index 9fc6f266c..284ac3bba 100644 --- a/doc/manuals/Makefile +++ b/doc/manuals/Makefile @@ -23,8 +23,10 @@ include $(TOPDIR)/build/Makefile.inc osmobsc-usermanual.pdf: chapters/*.adoc clean: - rm -rf $(cleanfiles) - rm -rf osmobsc-usermanual__*.{svg,png,check} + -rm -rf $(cleanfiles) + -rm osmobsc-usermanual__*.png + -rm osmobsc-usermanual__*.svg + -rm osmobsc-usermanual*.check gen-bsc-vty-docbook: FORCE $(call command,xsltproc -o generated/combined1.xml \ -- cgit v1.2.3 From 931ec5a5b6095117c2ef1193279db82118704b77 Mon Sep 17 00:00:00 2001 From: Ivaylo Kostov Date: Thu, 29 Dec 2016 15:26:59 +0100 Subject: BSC,BTS: add diagrams of PCU-BTS-NITB-SGSN relationships Change-Id: I0eb09706efb768fa4f6810872fb6568cbc9838cb --- doc/manuals/chapters/overview.adoc | 69 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+) diff --git a/doc/manuals/chapters/overview.adoc b/doc/manuals/chapters/overview.adoc index 580a42eb8..3bb22ccc0 100644 --- a/doc/manuals/chapters/overview.adoc +++ b/doc/manuals/chapters/overview.adoc @@ -13,6 +13,75 @@ Unlike the highly integrated OmsoNITB, OsmoBSC implements a more classic GSM Base Station Controller with A-bis interface towards BTSs and A interface towards a MSC. +The difference between classic GSM network architecture and +the OsmoNITB based GSM network architecture is illustrated in +<> and <>. + +[[fig-gsm-classic]] +.Classic GSM network architecture (simplified) +[graphviz] +---- +digraph G { + rankdir=LR; + MS0 [label="MS"]; + MS1 [label="MS"]; + MS2 [label="MS"]; + MS3 [label="MS"]; + BTS0 [label="BTS"]; + BTS1 [label="BTS"]; + BSC; + MSC [label="MSC/VLR"]; + HLR [label="HLR/AUC"]; + EIR; + SMSC; + MS0->BTS0 [label="Um"]; + MS1->BTS0 [label="Um"]; + MS2->BTS1 [label="Um"]; + MS3->BTS1 [label="Um"]; + BTS0->BSC [label="Abis"]; + BTS1->BSC [label="Abis"]; + BSC->MSC [label="A"]; + MSC->HLR [label="C"]; + MSC->EIR [label="F"]; + MSC->SMSC; +} +---- + +[[fig-gsm-nitb]] +.GSM system architecture using OsmoNITB +[graphviz] +---- +digraph G { + rankdir=LR; + MS0 [label="MS"]; + MS1 [label="MS"]; + MS2 [label="MS"]; + MS3 [label="MS"]; + BTS0 [label="BTS"]; + BTS1 [label="BTS"]; + EXTMNCC [label="Linux Call Router / SoftSwitch / PBX\n(optional)"]; + MS0->BTS0 [label="Um"]; + MS1->BTS0 [label="Um"]; + MS2->BTS1 [label="Um"]; + MS3->BTS1 [label="Um"]; + BTS0->BSC [label="Abis"]; + BTS1->BSC [label="Abis"]; + subgraph cluster_nitb { + label = "OsmoNITB"; + BSC; + MSC [label="MSC/VLR"]; + SMSC; + EIR; + HLR [label="HLR/AUC"]; + BSC->MSC; + MSC->HLR; + MSC->EIR; + MSC->SMSC; + } + MSC -> EXTMNCC [label="external MNCC"]; +} +---- + === Software Components -- cgit v1.2.3 From b120272f86773d3c6d0b39e78cd6eae7b3a9b655 Mon Sep 17 00:00:00 2001 From: Pau Espin Pedrol Date: Wed, 3 May 2017 12:38:05 +0200 Subject: Add osmux-reference document Change-Id: I4d19df98af84560c147a637bc42ebe570bb280aa --- doc/manuals/Makefile | 4 +- doc/manuals/osmux-reference-docinfo.xml | 89 +++++++ doc/manuals/osmux-reference.adoc | 396 ++++++++++++++++++++++++++++++++ 3 files changed, 488 insertions(+), 1 deletion(-) create mode 100644 doc/manuals/osmux-reference-docinfo.xml create mode 100644 doc/manuals/osmux-reference.adoc diff --git a/doc/manuals/Makefile b/doc/manuals/Makefile index 284ac3bba..e12d3e283 100644 --- a/doc/manuals/Makefile +++ b/doc/manuals/Makefile @@ -15,18 +15,20 @@ docbooktotypes = pdf # htmlcss = TOPDIR := .. -ASCIIDOCS := osmobsc-usermanual +ASCIIDOCS := osmobsc-usermanual osmux-reference include $(TOPDIR)/build/Makefile.asciidoc.inc include $(TOPDIR)/build/Makefile.inc osmobsc-usermanual.pdf: chapters/*.adoc +osmux-reference.pdf: osmux-reference.adoc clean: -rm -rf $(cleanfiles) -rm osmobsc-usermanual__*.png -rm osmobsc-usermanual__*.svg -rm osmobsc-usermanual*.check + -rm osmux-reference*.check gen-bsc-vty-docbook: FORCE $(call command,xsltproc -o generated/combined1.xml \ diff --git a/doc/manuals/osmux-reference-docinfo.xml b/doc/manuals/osmux-reference-docinfo.xml new file mode 100644 index 000000000..06b2d7edd --- /dev/null +++ b/doc/manuals/osmux-reference-docinfo.xml @@ -0,0 +1,89 @@ + + + 0.1 + 11 June 2012 + Pablo Neira Ayuso + + Initial version of the proposal for internal discussion. + + + + 0.2 + 11 June 2012 + Pablo Neira Ayuso + + Second version after comments from Holger and Harald: + Include figures that provide expect traffic savings (in %). + Change licensing terms (owned by OnWaves and consultants). + Adjust work from 200 to 150 hours, remove details on how the implementation + + + + 0.3 + 20 June 2017 + Pau Espin Pedrol + + Improve and extenend for osmo-gsm-manuals inclusion from Pau Espin: + Convert to asciidoc. + Update frame bits according to implementation. + + + + + + + Holger + Freyther + hfreyther@sysmocom.de + HF + + sysmocom + sysmocom - s.f.m.c. GmbH + Managing Director + + + + Harald + Welte + hwelte@sysmocom.de + HW + + sysmocom + sysmocom - s.f.m.c. GmbH + Managing Director + + + + Pablo + Neira Ayuso + pneira@sysmocom.de + PN + + sysmocom + sysmocom - s.f.m.c. GmbH + + + + + + 2012-2017 + sysmocom - s.f.m.c. GmbH + + + + + Permission is granted to copy, distribute and/or modify this + document under the terms of the GNU Free Documentation License, + Version 1.3 or any later version published by the Free Software + Foundation; with the Invariant Sections being just 'Foreword', + 'Acknowledgements' and 'Preface', with no Front-Cover Texts, + and no Back-Cover Texts. A copy of the license is included in + the section entitled "GNU Free Documentation License". + + + The Asciidoc source code of this manual can be found at + + http://git.osmocom.org/osmo-gsm-manuals/ + + + diff --git a/doc/manuals/osmux-reference.adoc b/doc/manuals/osmux-reference.adoc new file mode 100644 index 000000000..068bc19e0 --- /dev/null +++ b/doc/manuals/osmux-reference.adoc @@ -0,0 +1,396 @@ +[[osmux]] += OSmux: reduce of SAT uplink costs by protocol optimizations + +== Problem + +In case of satellite based GSM systems, the transmission cost on the back-haul +is relatively expensive. The billing for such SAT uplink is usually done in a +pay-per-byte basis. Thus, reducing the amount of bytes transfered would +significantly reduce the cost of such uplinks. In such environment, even +seemingly small protocol optimizations, eg. message batching and trunking, can +result in significant cost reduction. + +This is true not only for speech codec frames, but also for the constant +background load caused by the signalling link (A protocol). Optimizations in +this protocol are applicable to both VSAT back-haul (best-effort background IP) +as well as Inmarsat based links (QoS with guaranteed bandwidth). + +== Proposed solution + +In order to reduce the bandwidth consumption, this document proposes to develop +a multiplex protocol that will be used to proxy voice and signalling traffic +through the SAT links. + +=== Voice + +For the voice case, we propose a protocol that provides: + +* Batching: that consists of putting multiple codec frames on the sender side + into one single packet to reduce the protocol header overhead. This batch + is then sent as one RTP/UDP/IP packet at the same time. Currently, AMR 5.9 + codec frames are transported in a RTP/UDP/IP protocol stacking. This means + there are 15 bytes of speech codec frame, plus a 2 byte RTP payload header, + plus the RTP (12 bytes), UDP (8 bytes) and IP (20 bytes) overhead. This means + we have 40 byte overhead for 17 byte payload. + +* Trunking: in case of multiple concurrent voice calls, each of them will + generate one speech codec frame every 20ms. Instead of sending only codec + frames of one voice call in a given IP packet, we can 'interleave' or trunk + the codec frames of multiple calls into one IP. This further increases the + IP packet size and thus improves the payload/overhead ratio. + +Both techniques should be applied without noticeable impact in terms of user +experience. As the satellite back-haul has very high round trip time (several +hundred milliseconds), adding some more delay is not going to make things +significantly worse. + +For the batching, the idea consists of batching multiple codec frames on the +sender side, A batching factor (B) of '4' means that we will send 4 codec +frames in one underlying protocol packet. The additional delay of the batching +can be computed as (B-1)*20ms as 20ms is the duration of one codec frame. +Existing experimentation has shown that a batching factor of 4 to 8 (causing a +delay of 60ms to 140ms) is acceptable and does not cause significant quality +degradation. + +The main requirements for such voice RTP proxy are: + +* Always batch codec frames of multiple simultaneous calls into single UDP + message. + +* Batch configurable number codec frames of the same call into one UDP + message. + +* Make sure to properly reconstruct timing at receiver (non-bursty but + one codec frame every 20ms). + +* Implementation in libosmo-netif to make sure it can be used + in osmo-bts (towards osmo-bsc), osmo-bsc (towards osmo-bts and + osmo-bsc_nat) and osmo-bsc_nat (towards osmo-bsc) + +* Primary application will be with osmo-bsc connected via satellite link to + osmo-bsc_nat. + +* Make sure to properly deal with SID (silence detection) frames in case + of DTX. + +* Make sure to transmit and properly re-construct the M (marker) bit of + the RTP header, as it is used in AMR. + +* Primary use case for AMR codec, probably not worth to waste extra + payload byte on indicating codec type (amr/hr/fr/efr). If we can add + the codec type somewhere without growing the packet, we'll do it. + Otherwise, we'll skip this. + +=== Signalling + +Signalling uses SCCP/IPA/TCP/IP stacking. Considering SCCP as payload, this +adds 3 (IPA) + 20 (TCP) + 20 (IP) = 43 bytes overhead for every signalling +message, plus of course the 40-byte-sized TCP ACK sent in the opposite +direction. + +While trying to look for alternatives, we consider that none of the standard IP +layer 4 protocols are suitable for this application. We detail the reasons +why: + +* TCP is a streaming protocol aimed at maximizing the throughput of a stream + withing the constraints of the underlying transport layer. This feature is + not really required for the low-bandwidth and low-pps GSM signalling. + Moreover, TCP is stream oriented and does not conserve message boundaries. + As such, the IPA header has to serve as a boundary between messages in the + stream. Moreover, assuming a generally quite idle signalling link, the + assumption of a pure TCP ACK (without any data segment) is very likely to + happen. + +* Raw IP or UDP as alternative is not a real option, as it does not recover + lost packets. + +* SCTP preserves message boundaries and allows for multiple streams + (multiplexing) within one connection, but it has too much overhead. + +For that reason, we propose the use of LAPD for this task. This protocol was +originally specified to be used on top of E1 links for the A interface, who +do not expose any kind of noticeable latency. LAPD resolves (albeit not as +good as TCP does) packet loss and copes with packet re-ordering. + +LAPD has a very small header (3-5 octets) compared to TCPs 20 bytes. Even if +LAPD is put inside UDP, the combination of 11 to 13 octets still saves a +noticable number of bytes per packet. Moreover, LAPD has been modified for less +reliable interfaces such as the GSM Um interface (LAPDm), as well as for the +use in satellite systems (LAPsat in ETSI GMR). + +== OSmux protocol + +The OSmux protocol is the core of our proposed solution. This protocol operates +over UDP or, alternatively, over raw IP. The designated default UDP port number +and IP protocol type have not been yet decided. + +Every OSmux message starts with a control octet. The control octet contains a +2-bit Field Type (FT) and its location starts on the 2nd bit for backward +compatibility with older versions (used to be 3 bits). The FT defines the +structure of the remaining header as well as the payload. + +The following FT values are assigned: + +* FT == 0: LAPD Signalling +* FT == 1: AMR Codec +* FT == 2: Dummy +* FT == 3: Reserved for Fture Use + +There can be any number of OSmux messages batched up in one underlaying packet. +In this case, the multiple OSmux messages are simply concatenated, i.e. the +OSmux header control octet directly follows the last octet of the payload of the +previous OSmux message. + + +=== LAPD Signalling (0) + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +|X|FT |X X X X X| PL-LENGTH | LAPD header + payload | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +Field Type (FT): 2 bits:: +The Field Type allocated for AMR codec is "0". + +This frame type is not yet supported inside OsmoCom and may be subject to +change in future versions of the protocol. + + +=== AMR Codec (1) + +This OSmux packet header is used to transport one or more RTP-AMR packets for a +specific RTP stream identified by the Circuit ID field. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +|M|FT | CTR |F|Q| Red. TS/SeqNR | Circuit ID |AMR FT |AMR CMR| ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +Marker (M): 1 bit:: +This is a 1:1 mapping from the RTP Marker (M) bit as specified in RFC3550 +Section 5.1 (RTP) as well as RFC3267 Section 4.1 (RTP-AMR). In AMR, the Marker +is used to indicate the beginning of a talk-spurt, i.e. the end of a silence +period. In case more than one AMR frame from the specific stream is batched into +this OSmux header, it is guaranteed that the first AMR frame is the first in the +talkspurt. + +Field Type (FT): 2 bits:: +The Field Type allocated for AMR codec is "1". + +Frame Counter (CTR): 2 bits:: +Provides the number of batched AMR payloads (starting 0) after the header. For +instance, if there are 2 AMR payloads batched, CTR will be "1". + +AMR-F (F): 1 bit:: +This is a 1:1 mapping from the AMR F field in RFC3267 Section 4.3.2. In case +there are multiple AMR codec frames with different F bit batched together, we +only use the last F and ignore any previous F. + +AMR-Q (Q): 1 bit:: +This is a 1:1 mapping from the AMR Q field (Frame quality indicator) in RFC3267 +Section 4.3.2. In case there are multiple AMR codec frames with different Q bit +batched together, we only use the last Q and ignore any previous Q. + +Circuit ID Code (CIC): 8 bits:: +Identifies the Circuit (Voice call), which in RTP is identified by {srcip, +srcport, dstip, dstport, ssrc}. + +Reduced/Combined Timestamp and Sequence Number (RCTS): 8 bits:: +Resembles a combination of the RTP timestamp and sequence number. In the GSM +system, speech codec frames are generated at a rate of 20ms. Thus, there is no +need to have independent timestamp and sequence numbers (related to a 8kHz +clock) as specified in AMR-RTP. + +AMR Codec Mode Request (AMR-FT): 4 bits:: +This is a mapping from te AMR FT field (Frame type index) in RFC3267 Section +4.3.2. The length of each codec frame needs to be determined from this field. It +is thus guaranteed that all frames for a specific stream in an OSmux batch are +of the same AMR type. + +AMR Codec Mode Request (AMR-CMR): 4 bits:: +The RTP AMR payload header as specified in RFC3267 contains a 4-bit CMR field. +Rather than transporting it in a separate octet, we squeeze it in the lower four +bits of the clast octet. In case there are multiple AMR codec frames with +different CMR, we only use the last CMR and ignore any previous CMR. + +==== Additional considerations + +* It can be assumed that all OSmux frames of type AMR Codec contain at least 1 + AMR frame. +* Given a batch factor of N frames (N>1), it can not be assumed that the amount + of AMR frames in any OSmux frame will always be N, due to some restrictions + mentioned above. For instance, a sender can decide to send before queueing the + expected N frames due to timing issues, or to conform with the restriction + that the first AMR frame in the batch must be the first in the talkspurt + (Marker M bit). + + +=== Dummy (2) + +This kind of frame is used for NAT traversal. If a peer is behind a NAT, its +source port specified in SDP will be a private port not accessible from the +outside. Before other peers are able to send any packet to it, they require the +mapping between the private and the public port to be set by the firewall, +otherwise the firewall will most probably drop the incoming messages or send it +to a wrong destination. The firewall in most cases won't create a mapping until +the peer behind the NAT sends a packet to the peer residing outside. + +In this scenario, if the peer behind the nat is expecting to receive but never +transmit audio, no packets will ever reach him. To solve this, the peer sends +dummy packets to let the firewall create the port mapping. When the other peers +receive this dummy packet, they can infer the relation between the original +private port and the public port and start sending packets to it. + +When opening a connection, the peer is expected to send dummy packets until it +starts sending real audio, at which point dummy packets are not needed anymore. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +|X|FT | CTR |X X|X X X X X X X X X| Circuit ID |AMR FT |X X X X| ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +Field Type (FT): 2 bits:: +The Field Type allocated for AMR codec is "2". + +Frame Counter (CTR): 2 bits:: +Provides the number of dummy batched AMR payloads (starting 0) after the header. +For instance, if there are 2 AMR payloads batched, CTR will be "1". + +Circuit ID Code (CIC): 8 bits:: +Identifies the Circuit (Voice call), which in RTP is identified by {srcip, +srcport, dstip, dstport, ssrc}. + +AMR Codec Mode Request (AMR-FT): 4 bits:: +This field must contain any valid value described in the AMR FT field (Frame +type index) in RFC3267 Section 4.3.2. + +==== Additional considerations + +* After the header, additional padding needs to be allocated to conform with CTR +and AMR FT fields. For instance, if CTR is 0 and AMR FT is AMR 6.9, a padding +of 17 bytes is to be allocated after the header. + +* On receival of this kind of OSmux frame, it's usually enough for the reader to + discard the header plus the calculated padding and keep operating. + + +== Evaluation: Expected traffic savings + +The following figure shows the traffic saving (in %) depending on the number +of concurrent numbers of callings (asumming trunking but no batching at all): +---- + Traffic savings (%) + 100 ++-------+-------+--------+--------+-------+--------+-------+-------++ + + + + + + + batch factor 1 **E*** + + | | + 80 ++ ++ + | | + | | + | ****E********E + 60 ++ ****E*******E********E*** ++ + | **E**** | + | **** | + 40 ++ *E** ++ + | ** | + | ** | + | ** | + 20 ++ E ++ + | | + + + + + + + + + + + 0 ++-------+-------+--------+--------+-------+--------+-------+-------++ + 0 1 2 3 4 5 6 7 8 + Concurrent calls +---- + +The results shows a saving of 15.79% with only one concurrent call, that +quickly improves with more concurrent calls (due to trunking). + +We also provide the expected results by batching 4 messages for a single call: +---- + Traffic savings (%) + 100 ++-------+-------+--------+--------+-------+--------+-------+-------++ + + + + + + + batch factor 4 **E*** + + | | + 80 ++ ++ + | | + | | + | ****E********E*******E********E*******E********E + 60 ++ ****E**** ++ + | E*** | + | | + 40 ++ ++ + | | + | | + | | + 20 ++ ++ + | | + + + + + + + + + + + 0 ++-------+-------+--------+--------+-------+--------+-------+-------++ + 0 1 2 3 4 5 6 7 8 + Concurrent calls +---- + +The results show a saving of 56.68% with only one concurrent call. Trunking +slightly improves the situation with more concurrent calls. + +We also provide the figure with batching factor of 8: +---- + Traffic savings (%) + 100 ++-------+-------+--------+--------+-------+--------+-------+-------++ + + + + + + + batch factor 8 **E*** + + | | + 80 ++ ++ + | | + | ****E*******E********E + | ****E********E********E*******E**** | + 60 ++ E*** ++ + | | + | | + 40 ++ ++ + | | + | | + | | + 20 ++ ++ + | | + + + + + + + + + + + 0 ++-------+-------+--------+--------+-------+--------+-------+-------++ + 0 1 2 3 4 5 6 7 8 + Concurrent calls +---- + +That shows very little improvement with regards to batching 4 messages. +Still, we risk to degrade user experience. Thus, we consider a batching factor +of 3 and 4 is adecuate. + +== Other proposed follow-up works + +The following sections describe features that can be considered in the mid-run +to be included in the OSmux infrastructure. They will be considered for future +proposals as extensions to this work. Therefore, they are NOT included in +this proposal. + +=== Encryption + +Voice streams within OSmux can be encrypted in a similar manner to SRTP +(RFC3711). The only potential problem is the use of a reduced sequence number, +as it wraps in (20ms * 2^256 * B), i.e. 5.12s to 40.96s. However, as the +receiver knows at which rate the codec frames are generated at the sender, he +should be able to compute how much time has passed using his own timebase. + +Another alternative can be the use of DTLS (RFC 6347) that can be used to +secure datagram traffic using TLS facilities (libraries like openssl and +gnutls already support this). + +=== Multiple OSmux messages in one packet + +In case there is already at least one active voice call, there will be +regular transmissions of voice codec frames. Depending on the batching +factor, they will be sent every 70ms to 140ms. The size even of a +batched (and/or trunked) codec message is still much lower than the MTU. + +Thus, any signalling (related or unrelated to the call causing the codec +stream) can just be piggy-backed to the packets containing the voice +codec frames. -- cgit v1.2.3 From b75422f9d4aad858b4f3503463d8d60c7863f60c Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Mon, 29 May 2017 20:51:30 +0200 Subject: Add chapter on Cell Broadcast Support in Osmocom (to BSC+NITB manual) Change-Id: I2c621def499dc0564d31eb9440e22e79948a5466 --- doc/manuals/osmobsc-usermanual.adoc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/manuals/osmobsc-usermanual.adoc b/doc/manuals/osmobsc-usermanual.adoc index 25bd35b59..9323373b3 100644 --- a/doc/manuals/osmobsc-usermanual.adoc +++ b/doc/manuals/osmobsc-usermanual.adoc @@ -27,6 +27,8 @@ include::../common/chapters/abis.adoc[] include::../common/chapters/control_if.adoc[] +include::../common/chapters/cell-broadcast.adoc[] + include::../common/chapters/port_numbers.adoc[] include::../common/chapters/bibliography.adoc[] -- cgit v1.2.3 From f1d4251461640f4cb44f44d1a6c9afdd6c64abe4 Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Wed, 31 May 2017 21:22:42 +0200 Subject: BSC: Add series of message sequence charts about MGCP handling Change-Id: Id5948677d23a58ce112b57f91bea953a93baab4c --- doc/manuals/Makefile | 6 ++- doc/manuals/aoip-mgw-options-docinfo.xml | 47 +++++++++++++++++++ doc/manuals/aoip-mgw-options.adoc | 77 +++++++++++++++++++++++++++++++ doc/manuals/mgw/classic-bsc.msc | 39 ++++++++++++++++ doc/manuals/mgw/osmo-bsc-new-mgw-e1.msc | 50 ++++++++++++++++++++ doc/manuals/mgw/osmo-bsc-new-mgw.msc | 71 ++++++++++++++++++++++++++++ doc/manuals/mgw/osmo-bsc-old-sccplite.msc | 64 +++++++++++++++++++++++++ 7 files changed, 353 insertions(+), 1 deletion(-) create mode 100644 doc/manuals/aoip-mgw-options-docinfo.xml create mode 100644 doc/manuals/aoip-mgw-options.adoc create mode 100644 doc/manuals/mgw/classic-bsc.msc create mode 100644 doc/manuals/mgw/osmo-bsc-new-mgw-e1.msc create mode 100644 doc/manuals/mgw/osmo-bsc-new-mgw.msc create mode 100644 doc/manuals/mgw/osmo-bsc-old-sccplite.msc diff --git a/doc/manuals/Makefile b/doc/manuals/Makefile index e12d3e283..93c7b81c5 100644 --- a/doc/manuals/Makefile +++ b/doc/manuals/Makefile @@ -15,13 +15,14 @@ docbooktotypes = pdf # htmlcss = TOPDIR := .. -ASCIIDOCS := osmobsc-usermanual osmux-reference +ASCIIDOCS := osmobsc-usermanual osmux-reference aoip-mgw-options include $(TOPDIR)/build/Makefile.asciidoc.inc include $(TOPDIR)/build/Makefile.inc osmobsc-usermanual.pdf: chapters/*.adoc osmux-reference.pdf: osmux-reference.adoc +aoip-mgw-options.pdf: aoip-mgw-options.adoc clean: -rm -rf $(cleanfiles) @@ -29,6 +30,9 @@ clean: -rm osmobsc-usermanual__*.svg -rm osmobsc-usermanual*.check -rm osmux-reference*.check + -rm aoip-mgw-options*.png + -rm aoip-mgw-options*.svg + -rm aoip-mgw-options*.check gen-bsc-vty-docbook: FORCE $(call command,xsltproc -o generated/combined1.xml \ diff --git a/doc/manuals/aoip-mgw-options-docinfo.xml b/doc/manuals/aoip-mgw-options-docinfo.xml new file mode 100644 index 000000000..080959443 --- /dev/null +++ b/doc/manuals/aoip-mgw-options-docinfo.xml @@ -0,0 +1,47 @@ + + + 0.1 + 31 May 2017 + Harald Welte + + Initial version of the proposal for internal discussion. + + + + + + + Harald + Welte + hwelte@sysmocom.de + HW + + sysmocom + sysmocom - s.f.m.c. GmbH + Managing Director + + + + + + 2017 + sysmocom - s.f.m.c. GmbH + + + + + Permission is granted to copy, distribute and/or modify this + document under the terms of the GNU Free Documentation License, + Version 1.3 or any later version published by the Free Software + Foundation; with the Invariant Sections being just 'Foreword', + 'Acknowledgements' and 'Preface', with no Front-Cover Texts, + and no Back-Cover Texts. A copy of the license is included in + the section entitled "GNU Free Documentation License". + + + The Asciidoc source code of this manual can be found at + + http://git.osmocom.org/osmo-gsm-manuals/ + + + diff --git a/doc/manuals/aoip-mgw-options.adoc b/doc/manuals/aoip-mgw-options.adoc new file mode 100644 index 000000000..8ce3b91a5 --- /dev/null +++ b/doc/manuals/aoip-mgw-options.adoc @@ -0,0 +1,77 @@ += OsmoBSC A / SCCPlite / 3GPP AoIP Options + +== Introduction + +This document serves as a paper to illustrate the different +configurations of OsmoBSC in terms of integration with BTSs and MSCs. + +The document should accompany us in the 2017 development cycle which +includes the _death of the NITB_, i.e. the move away from OsmoNITB to +having OsmoBSC in all configurations, whether with a +proprietary/external MSC or with OsmoMSC. + +Particular attention is spent on the user plane, including aspects +such as + +* user plane transport address handling +* use of MGCP (Media Gateway Control Protocol) +* the (required) evolution of `osmo-bsc_mgcp` +* not loosing classic TDM (E1/T1) BTS support when moving from + OsmoNITB to split OsmoBSC + OsmoMSC setup + + +== Overview + +=== Classic GSM RAN with E1 based Abis and E1 A + +This configuration was actually never supported by OpenBSC, as E1 BTS +support was so far for NITB only, but not for OsmoBSC. + +[mscgen] +---- +include::mgw/classic-bsc.msc[] +---- + +=== OsmoBSC 2010-2017: IPA-style A over SCCPlite + +This configuration was introduced as early as 2010 in OpenBSC. It +allowed the use of IP based BTSs (ip.access nanoBTS as well as all the +OsmoBTS supported BTS models) in combination with third-party MSCs +implementing a pre-standard, proprietary way of transporting the A +interface over IP at a time where the 3GPP specifications only allowed +classic TDM transport. + +[mscgen] +---- +include::mgw/osmo-bsc-old-sccplite.msc[] +---- + + +=== OsmoBSC 2017+: 3GPP AoIP + Abis/IP + +Release 7 of 3GPP included an official specification on how an +interoperable A-over-IP (AoIP) interface shall look like. + +As more modern MSCs at operators tend to favor implementing 3GPP AoIP +rather than the proprietary SCCPlite based A interface, it becomes +neccessary for OsmoBSC to support this. + +At the same time, for compatibility reasons, the classic SCCPlite +support shall be kept, if possible with reasonable effort. + +[mscgen] +---- +include::mgw/osmo-bsc-new-mgw.msc[] +---- + + +=== OsmoBSC 2017+: 3GPP AoIP + Abis/E1 + +Since OsmoNITB will soon be deprecated, we will use OsmoBSC in all +Osmocom GSM ntework setups, requiring the support for classic E1/T1 +based BTSs from OsmoBSC. + +[mscgen] +---- +include::mgw/osmo-bsc-new-mgw-e1.msc[] +---- diff --git a/doc/manuals/mgw/classic-bsc.msc b/doc/manuals/mgw/classic-bsc.msc new file mode 100644 index 000000000..56d288997 --- /dev/null +++ b/doc/manuals/mgw/classic-bsc.msc @@ -0,0 +1,39 @@ +# MO Call on a classic E1 Abis BTS with classic E1 A BSC +# not actually supported by OsmoBSC (nor planned), for refrence only +msc { + hscale=2; + ms [label="MS"], bts [label="E1 BTS"], bsc[label="OsmoBSC"], trau[label="TRAU"], m_sc[label="MSC"]; + + ms box m_sc [label="We assume a SDCCH is already established"]; + ...; + + ms -> m_sc [label="DTAP CC SETUP"]; + ms <- m_sc [label="DTAP CC CALL PROCEEDING"]; + + bsc <- m_sc [label="BSSAP ASSGN REQ"]; + bsc box m_sc [label="E1 TS for PCM specified by CIC"]; + bts <- bsc [label="RSL CHAN ACT"]; + bts -> bsc [label="RSL CHAN ACT ACK"]; + bts box bsc [label="E1 TS + 16k sub-slot configured for given lchan"]; + ms <-> bsc [label="Assignment"]; + bsc -> m_sc [label="BSSAP ASSGN CMPL"]; + + ...; + trau <- m_sc [label="PCM Audio in full E1 slot"]; + bts <- trau [label="A-bis TRAU frames on 16k sub-slot"]; + + ...; + ms <- m_sc [label="DTAP CC CONNECT"]; + ms -> m_sc [label="DTAP CC CONNECT ACK"]; + trau <-> m_sc [label="PCM Audio in full E1 slot"]; + bts <-> trau [label="A-bis TRAU frames on 16k sub-slot"]; + --- [label="Voice Call in Progress"]; + ms <- m_sc [label="DTAP CC DISCONNET"]; + ms <- m_sc [label="DTAP CC RELEASE"]; + ms <- m_sc [label="DTAP CC RELEASE COMPL"]; + ...; + bsc <- m_sc [label="BSSMAP CLEAR CMD"]; + bsc -> m_sc [label="BSSMAP CLEAR COMPL"]; + bsc <- m_sc [label="SCCP RLSD"]; + bsc -> m_sc [label="SCCP RLC"]; +} diff --git a/doc/manuals/mgw/osmo-bsc-new-mgw-e1.msc b/doc/manuals/mgw/osmo-bsc-new-mgw-e1.msc new file mode 100644 index 000000000..7912a73f5 --- /dev/null +++ b/doc/manuals/mgw/osmo-bsc-new-mgw-e1.msc @@ -0,0 +1,50 @@ +# MO-Call with E1 BTS + OsmoBSC with true 3GPP AoIP (planned +# osmo-bsc_mgcp has to be extended to true MGW functionality! +msc { + hscale=2; + ms [label="MS"], bts [label="E1 BTS"], bsc[label="OsmoBSC"], mgcp[label="osmo-bsc_mgcp"], m_sc[label="MSC"]; + + ms box m_sc [label="We assume a SDCCH is already established"]; + ...; + + ms -> m_sc [label="DTAP CC SETUP"]; + ms <- m_sc [label="DTAP CC CALL PROCEEDING"]; + + m_sc box m_sc [label="Bind arbitrary local port (4000)"]; + bsc <- m_sc [label="BSSAP ASSGN REQ (3GPP AoIP MSC:4000)"]; + bts <- bsc [label="RSL CHAN ACT"]; + bts -> bsc [label="RSL CHAN ACT ACK"]; + ms <-> bsc [label="Assignment"]; + ...; + + mgcp <- bsc [label="MGCP CRCX ts1/ss2@abis (MSC:4000)"]; + mgcp box mgcp [label="Bind to MGW-local RTP Port (3000)\nConnect to MSC:4000"]; + mgcp -> bsc [label="MGCP CRCX ts1/ss2@a OK (MGW:3000)"]; + ...; + + bsc -> m_sc [label="BSSAP ASSGN CMPL (3GPP AoIP MGW:3000)"]; + m_sc box m_sc [label="Connect remote RTP to MGW addr from ASSGN CMPL"]; + ...; + + mgcp <=> m_sc [label="RTP Audio MGW:3000 MSC:4000"]; + bts <=> mgcp [label="TRAU Frame Audio (E1 TS1 SS2)"]; + ms <=> bts [label="Um Audio (bidirectional)"]; + ms <-> m_sc [label="DTAP CC ALERTING"]; + ...; + + ms <- m_sc [label="DTAP CC CONNECT"]; + ms -> m_sc [label="DTAP CC CONNECT ACK"]; + --- [label="Voice Call in Progress"]; + ms <- m_sc [label="DTAP CC DISCONNET"]; + ms <- m_sc [label="DTAP CC RELEASE"]; + ms <- m_sc [label="DTAP CC RELEASE COMPL"]; + ...; + bsc <- m_sc [label="BSSMAP CLEAR CMD"]; + bsc -> m_sc [label="BSSMAP CLEAR COMPL"]; + bsc <- m_sc [label="SCCP RLSD"]; + bsc -> m_sc [label="SCCP RLC"]; + ...; + mgcp <- bsc [label="MGCP DLCX ts1/ss2@a"]; + mgcp box mgcp [label="Release MSC-facing local RTP port (3000)"]; + mgcp -> bsc [label="MGCP DLCX ts1/ss2@a OK"]; +} diff --git a/doc/manuals/mgw/osmo-bsc-new-mgw.msc b/doc/manuals/mgw/osmo-bsc-new-mgw.msc new file mode 100644 index 000000000..2bab84dec --- /dev/null +++ b/doc/manuals/mgw/osmo-bsc-new-mgw.msc @@ -0,0 +1,71 @@ +# MO-Call with OsmoBTS + OsmoBSC with true 3GPP AoIP (planned) +msc { + hscale=2; + ms [label="MS"], bts [label="OsmoBTS"], bsc[label="OsmoBSC"], mgcp[label="osmo-bsc_mgcp"], m_sc[label="MSC"]; + + ms box m_sc [label="We assume a SDCCH is already established"]; + ...; + + ms -> m_sc [label="DTAP CC SETUP"]; + ms <- m_sc [label="DTAP CC CALL PROCEEDING"]; + + m_sc box m_sc [label="Bind arbitrary local port (4000)"]; + bsc <- m_sc [label="BSSAP ASSGN REQ (3GPP AoIP MSC:4000)"]; + bts <- bsc [label="RSL CHAN ACT"]; + bts -> bsc [label="RSL CHAN ACT ACK"]; + ms <-> bsc [label="Assignment"]; + ...; + + # connect BTS RTP with BSC-MGW RTP + bts <- bsc [label="IPA CRCX"]; + bts box bts [label="Bind to BTS-local RTP Port (1000)"]; + bts -> bsc [label="IPA CRCX ACK (BTS:1000)"]; + bsc -> mgcp [label="MGCP CRCX 2@abis (BTS:1000)"]; + mgcp box mgcp [label="Bind to MGW-local RTP Port (2000)\nConnect to BTS:1000"]; + bsc <- mgcp [label="MGCP CRCX 2@abis OK (MGW:2000)"]; + bts <- bsc [label="IPA MDCX 2@abis (MGW:2000)"]; + bts box bts [label="Connect RTP socket to remote (MGW) RTP Port"]; + bts -> bsc [label="IPA MDCX 2@abis ACK"]; + #bsc -> mgcp [label="MGCP MDCX 2@abis (optional)"]; + #bsc <- mgcp [label="MGCP MDCX 2@abis OK (optional)"]; + ...; + + mgcp <- bsc [label="MGCP CRCX 1@a (MSC:4000)"]; + mgcp box mgcp [label="Bind to MGW-local RTP Port (3000)\nConnect to MSC:4000"]; + mgcp -> bsc [label="MGCP CRCX 1@a OK (MGW:3000)"]; + ...; + + bsc -> m_sc [label="BSSAP ASSGN CMPL (3GPP AoIP MGW:3000)"]; + m_sc box m_sc [label="Connect remote RTP to MGW addr from ASSGN CMPL"]; + ...; + + mgcp <=> m_sc [label="RTP Audio MGW:3000 MSC:4000"]; + bts <=> mgcp [label="RTP Audio BTS:1000 MGW:2000"]; + ms <=> bts [label="Um Audio (bidirectional)"]; + ms <-> m_sc [label="DTAP CC ALERTING"]; + ...; + + ms <- m_sc [label="DTAP CC CONNECT"]; + ms -> m_sc [label="DTAP CC CONNECT ACK"]; + --- [label="Voice Call in Progress"]; + ms <- m_sc [label="DTAP CC DISCONNET"]; + ms <- m_sc [label="DTAP CC RELEASE"]; + ms <- m_sc [label="DTAP CC RELEASE COMPL"]; + ...; + bsc <- m_sc [label="BSSMAP CLEAR CMD"]; + bsc -> m_sc [label="BSSMAP CLEAR COMPL"]; + bsc <- m_sc [label="SCCP RLSD"]; + bsc -> m_sc [label="SCCP RLC"]; + ...; + mgcp <- bsc [label="MGCP DLCX 1@a"]; + mgcp box mgcp [label="Release MSC-facing local RTP port (3000)"]; + mgcp -> bsc [label="MGCP DLCX 1@a OK"]; + + bsc -> mgcp [label="MGCP DLCX 2@abis"]; + mgcp box mgcp [label="Release BTS-facing local RTP port (2000)"]; + bsc <- mgcp [label="MGCP DLCX 2@abis OK"]; + + bts <- bsc [label="IPA DLCX"]; + bts box bts [label="Release BTS-local RTP port (1000)"]; + bts -> bsc [label="IPA DLCX OK"]; +} diff --git a/doc/manuals/mgw/osmo-bsc-old-sccplite.msc b/doc/manuals/mgw/osmo-bsc-old-sccplite.msc new file mode 100644 index 000000000..f7298bfac --- /dev/null +++ b/doc/manuals/mgw/osmo-bsc-old-sccplite.msc @@ -0,0 +1,64 @@ +# MO-Call with OsmoBTS + OsmoBSC using A/IP with IPA/SCCPlite +# Supported since 2010 using osmo-bsc + osmo-bsc_nat +msc { + hscale=2; + ms [label="MS"], bts [label="OsmoBTS"], bsc[label="OsmoBSC"], mgcp[label="osmo-bsc_mgcp"], m_sc[label="MSC"]; + + ms box m_sc [label="We assume a SDCCH is already established"]; + ...; + + ms -> m_sc [label="DTAP CC SETUP"]; + ms <- m_sc [label="DTAP CC CALL PROCEEDING"]; + + bsc <- m_sc [label="BSSAP ASSGN REQ"]; + bts <- bsc [label="RSL CHAN ACT"]; + bts -> bsc [label="RSL CHAN ACT ACK"]; + ms <-> bsc [label="Assignment"]; + bsc -> m_sc [label="BSSAP ASSGN CMPL"]; + + ...; + bts <- bsc [label="IPA CRCX"]; + bts box bts [label="Bind to BSC-local RTP Port"]; + bts -> bsc [label="IPA CRCX ACK"]; + bts <- bsc [label="IPA MDCX"]; + bts box bts [label="Connect RTP socket to remote (bsc_mgcp) RTP Port"]; + bts -> bsc [label="IPA MDCX ACK"]; + + mgcp <- m_sc [label="MGCP CRCX"]; + mgcp box mgcp [label="Bind to BTS-local RTP Port"]; + mgcp -> m_sc [label="MGCP CRCX OK"]; + mgcp <- m_sc [label="MGCP MDCX (recvonly) "]; + mgcp box mgcp [label="Connect RTP socket to remote (MSC) RTP Port"]; + mgcp -> m_sc [label="MGCP MDCX OK"]; + mgcp <= m_sc [label="RTP Audio"]; + bts <= mgcp [label="RTP Audio"]; + ms <= bts [label="Um Audio (unidirectional)"]; + ms <- m_sc [label="DTAP CC ALERTING"]; + + ...; + mgcp <- m_sc [label="MGCP MDCX (sndrecv) "]; + mgcp box mgcp [label="Switch to bi-directional audio"]; + mgcp -> m_sc [label="MGCP MDCX OK"]; + mgcp <=> m_sc [label="RTP Audio"]; + bts <=> mgcp [label="RTP Audio"]; + ms <=> bts [label="Um Audio (bidirectional)"]; + ...; + ms <- m_sc [label="DTAP CC CONNECT"]; + ms -> m_sc [label="DTAP CC CONNECT ACK"]; + mgcp <- m_sc [label="MGCP MDCX (sndrecv) "]; + mgcp box mgcp [label="Why?"]; + mgcp -> m_sc [label="MGCP MDCX OK"]; + --- [label="Voice Call in Progress"]; + ms <- m_sc [label="DTAP CC DISCONNET"]; + ms <- m_sc [label="DTAP CC RELEASE"]; + ms <- m_sc [label="DTAP CC RELEASE COMPL"]; + ...; + bsc <- m_sc [label="BSSMAP CLEAR CMD"]; + bsc -> m_sc [label="BSSMAP CLEAR COMPL"]; + bsc <- m_sc [label="SCCP RLSD"]; + bsc -> m_sc [label="SCCP RLC"]; + ...; + mgcp <- m_sc [label="MGCP DLCX"]; + mgcp box mgcp [label="Release local RTP port"]; + mgcp -> m_sc [label="MGCP DLCX OK"]; +} -- cgit v1.2.3 From ac70cf9658df3f55f41340529794897792675128 Mon Sep 17 00:00:00 2001 From: Pau Espin Pedrol Date: Tue, 18 Jul 2017 18:56:22 +0200 Subject: osmux-reference: Use packetdiag to draw packet header structures Change-Id: Id75152278f41d56b7bd2e652b9947e33d6523c64 --- doc/manuals/Makefile | 3 ++ doc/manuals/osmux-reference.adoc | 63 ++++++++++++++++++++++++++++++---------- 2 files changed, 50 insertions(+), 16 deletions(-) diff --git a/doc/manuals/Makefile b/doc/manuals/Makefile index 93c7b81c5..35f50da00 100644 --- a/doc/manuals/Makefile +++ b/doc/manuals/Makefile @@ -33,6 +33,9 @@ clean: -rm aoip-mgw-options*.png -rm aoip-mgw-options*.svg -rm aoip-mgw-options*.check + -rm osmux-reference__*.svg + -rm osmux-reference__*.png + -rm osmux-reference__*.check gen-bsc-vty-docbook: FORCE $(call command,xsltproc -o generated/combined1.xml \ diff --git a/doc/manuals/osmux-reference.adoc b/doc/manuals/osmux-reference.adoc index 068bc19e0..b2767f3b6 100644 --- a/doc/manuals/osmux-reference.adoc +++ b/doc/manuals/osmux-reference.adoc @@ -144,14 +144,22 @@ previous OSmux message. === LAPD Signalling (0) - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -|X|FT |X X X X X| PL-LENGTH | LAPD header + payload | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +[packetdiag] +---- +{ + colwidth = 32 + node_height = 40 + + 0: - + 1-2: FT + 3-7: ---- + 8-15: PL-LENGTH + 16-31: LAPD header + payload +} +---- Field Type (FT): 2 bits:: -The Field Type allocated for AMR codec is "0". +The Field Type allocated for LAPD Signalling is "0". This frame type is not yet supported inside OsmoCom and may be subject to change in future versions of the protocol. @@ -162,11 +170,23 @@ change in future versions of the protocol. This OSmux packet header is used to transport one or more RTP-AMR packets for a specific RTP stream identified by the Circuit ID field. - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -|M|FT | CTR |F|Q| Red. TS/SeqNR | Circuit ID |AMR FT |AMR CMR| -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +[packetdiag] +---- +{ + colwidth = 32 + node_height = 40 + + 0: M + 1-2: FT + 3-5: CTR + 6: F + 7: Q + 8-15: Red. TS/SeqNR + 16-23: Circuit ID + 24-27: AMR FT + 28-31: AMR CMR +} +---- Marker (M): 1 bit:: This is a 1:1 mapping from the RTP Marker (M) bit as specified in RFC3550 @@ -246,11 +266,22 @@ private port and the public port and start sending packets to it. When opening a connection, the peer is expected to send dummy packets until it starts sending real audio, at which point dummy packets are not needed anymore. - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -|X|FT | CTR |X X|X X X X X X X X X| Circuit ID |AMR FT |X X X X| -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +[packetdiag] +---- +{ + colwidth = 32 + node_height = 40 + + 0: - + 1-2: FT + 3-5: CTR + 6-7: -- + 8-15: ---- + 16-23: Circuit ID + 24-27: AMR FT + 28-31: ---- +} +---- Field Type (FT): 2 bits:: The Field Type allocated for AMR codec is "2". -- cgit v1.2.3 From 1ce6c62914305ea5ee1cc82df476dc1e30e5f05f Mon Sep 17 00:00:00 2001 From: Pau Espin Pedrol Date: Wed, 19 Jul 2017 13:21:25 +0200 Subject: osmux-reference: Add sequence charts Change-Id: Ic2c63e4d9e67b877dc06a206ec7f07d0704329a5 --- doc/manuals/osmux-reference.adoc | 189 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 189 insertions(+) diff --git a/doc/manuals/osmux-reference.adoc b/doc/manuals/osmux-reference.adoc index b2767f3b6..0f66118e0 100644 --- a/doc/manuals/osmux-reference.adoc +++ b/doc/manuals/osmux-reference.adoc @@ -307,6 +307,195 @@ of 17 bytes is to be allocated after the header. * On receival of this kind of OSmux frame, it's usually enough for the reader to discard the header plus the calculated padding and keep operating. +== Sequence Charts + +=== Trunking + +Following chart shows how trunking works for 3 concurrent calls from different +MS on a given BTS. In this case only uplink data is shown, but downlink follows +the same idea. Batching factor is set to 1 to easily illustrate trunking mechanism. + +It can be seen how 3 RTP packets from 3 different Ms (a, b, and c) arrive to the +BSC from the BTS. The BSC generates 3 OSmux frames and stores and sends them +together in one UDP packet to the BSC-NAT. The BSC-NAT decodes the three OSmux +frames, identifies each of them through CID values and transform them back to +RTP before sending them to the MGW. + +["mscgen"] +---- +msc { + hscale = 2; + bts [label="BTS"], bsc [label="BSC"], bscnat [label="BSC-NAT"], mgw [label="MGW"]; + + ...; + --- [label="3 Regular RTP-AMR calls using OSmux (has been ongoing for some time)"]; + + bts => bsc [label="RTP-AMR[seq=y,ssrc=MSa]"]; + bts => bsc [label="RTP-AMR[seq=x,ssrc=MSb]"]; + bts => bsc [label="RTP-AMR[seq=z,ssrc=MSc]"]; + bsc => bscnat [label="UDP[Osmux[ft=2,cid=i,seq=m,AMR(y)],Osmux[ft=2,cid=i+1,seq=n,AMR(x)],Osmux[ft=2,cid=i+2,seq=l,AMR(z)]]"]; + bscnat => mgw [label="RTP-AMR[seq=o,ssrc=r] (originally seq=y,ssrc=MSa)"]; + bscnat => mgw [label="RTP-AMR[seq=p,ssrc=s] (originally seq=x,ssrc=MSb)"]; + bscnat => mgw [label="RTP-AMR[seq=q,ssrc=t] (originally seq=z,ssrc=MSc)"]; + bts => bsc [label="RTP-AMR[seq=y+1,ssrc=MSa]"]; + bts => bsc [label="RTP-AMR[seq=x+1,ssrc=MSb]"]; + bts => bsc [label="RTP-AMR[seq=z+1,ssrc=MSc]"]; + bsc => bscnat [label="UDP[Osmux[ft=2,cid=i,seq=m+1,AMR(y+1)],Osmux[ft=2,cid=i+1,seq=n+1,AMR(x+1)],Osmux[ft=2,cid=i+2,seq=l+1,AMR(z+1)]]"]; + bscnat => mgw [label="RTP-AMR[seq=o+1,ssrc=r] (originally seq=y+1,ssrc=MSa)"]; + bscnat => mgw [label="RTP-AMR[seq=p+1,ssrc=s] (originally seq=x+1,ssrc=MSb)"]; + bscnat => mgw [label="RTP-AMR[seq=q+1,ssrc=t] (originally seq=z+1,ssrc=MSc)"]; + bts => bsc [label="RTP-AMR[seq=y+2,ssrc=MSa]"]; + bts => bsc [label="RTP-AMR[seq=x+2,ssrc=MSb]"]; + bts => bsc [label="RTP-AMR[seq=z+2,ssrc=MSc]"]; + bsc => bscnat [label="UDP[Osmux[ft=2,cid=i,seq=m+2,AMR(y+2)],Osmux[ft=2,cid=i+1,seq=n+2,AMR(x+2)],Osmux[ft=2,cid=i+2,seq=l+2,AMR(z+2)]]"]; + bscnat => mgw [label="RTP-AMR[seq=o+2,ssrc=r] (originally seq=y+2,ssrc=MSa)"]; + bscnat => mgw [label="RTP-AMR[seq=p+2,ssrc=s] (originally seq=x+2,ssrc=MSb)"]; + bscnat => mgw [label="RTP-AMR[seq=q+2,ssrc=t] (originally seq=z+2,ssrc=MSc)"]; +} +---- + +=== Batching + +Following chart shows how batching with a factor of 3 works. To easilly +illustrate batching, only uplink and one concurrent call is considered. + +It can be seen how 3 RTP packets from MSa arrive to the BSC from the BTS. The +BSC queues the 3 RTP packets and once the batchfactor is reached, an OSmux frame +is generated and sent to the BSC-NAT. The BSC-NAT decodes the OSmux frames, +transforms each AMR payload into an RTP packet and each RTP packet is scheduled +for delivery according to expected proportional time delay (and timestamp field +is set accordingly). + +["mscgen"] +---- +msc { + hscale = 2; + bts [label="BTS"], bsc [label="BSC"], bscnat [label="BSC-NAT"], mgw [label="MGW"]; + + ...; + --- [label="Regular RTP-AMR call using OSmux with batch factor 3 (has been ongoing for some time)"]; + + bts => bsc [label="RTP-AMR[seq=x,ssrc=MSa]"]; + bts => bsc [label="RTP-AMR[seq=x+1,ssrc=MSa]"]; + bts => bsc [label="RTP-AMR[seq=x+2,ssrc=MSa]"]; + bsc => bscnat [label="UDP[Osmux[ft=2,cid=i,seq=m,AMR(x),AMR(x+1),AMR(x+2)]]"]; + bscnat => mgw [label="RTP-AMR[seq=o,ssrc=r] (originally seq=x,ssrc=MSa)"]; + bscnat => mgw [label="RTP-AMR[seq=o+1,ssrc=r] (originally seq=x+1,ssrc=MSa)"]; + bscnat => mgw [label="RTP-AMR[seq=o+2,ssrc=r] (originally seq=x+2,ssrc=MSa)"]; + bts => bsc [label="RTP-AMR[seq=x+3,ssrc=MSa]"]; + bts => bsc [label="RTP-AMR[seq=x+4,ssrc=MSa]"]; + bts => bsc [label="RTP-AMR[seq=x+5,ssrc=MSa]"]; + bsc => bscnat [label="UDP[Osmux[ft=2,cid=i,seq=m+1,AMR(x+3),AMR(x+4),AMR(x+5)]]"]; + bscnat => mgw [label="RTP-AMR[seq=o+3,ssrc=r] (originally seq=x+3,ssrc=MSa)"]; + bscnat => mgw [label="RTP-AMR[seq=o+4,ssrc=r] (originally seq=x+4,ssrc=MSa)"]; + bscnat => mgw [label="RTP-AMR[seq=o+5,ssrc=r] (originally seq=x+5,ssrc=MSa)"]; + bts => bsc [label="RTP-AMR[seq=x+6,ssrc=MSa]"]; + bts => bsc [label="RTP-AMR[seq=x+7,ssrc=MSa]"]; + bts => bsc [label="RTP-AMR[seq=x+8,ssrc=MSa]"]; + bsc => bscnat [label="UDP[Osmux[ft=2,cid=i,seq=m+2,AMR(x+6),AMR(x+7),AMR(x+8)]]"]; + bscnat => mgw [label="RTP-AMR[seq=o+6,ssrc=r] (originally seq=x+6,ssrc=MSa)"]; + bscnat => mgw [label="RTP-AMR[seq=o+7,ssrc=r] (originally seq=x+7,ssrc=MSa)"]; + bscnat => mgw [label="RTP-AMR[seq=o+8,ssrc=r] (originally seq=x+8,ssrc=MSa)"]; +} +---- + +=== Trunking and Batching + +Following chart shows how trunking and batching work together. The chart shows 2 +concurrent calls from different MS on a given BTS, and BSC is configured with a +batch factor of 3. Again only uplink data is shown, but downlink follows the +same idea. Batching factor is set to 1 to easily illustrate trunking mechanism. + +["mscgen"] +---- +msc { + hscale = 2; + bts [label="BTS"], bsc [label="BSC"], bscnat [label="BSC-NAT"], mgw [label="MGW"]; + + ...; + --- [label="2 Regular RTP-AMR call using OSmux with batch factor 3 (has been ongoing for some time)"]; + + bts => bsc [label="RTP-AMR[seq=x,ssrc=MSa]"]; + bts => bsc [label="RTP-AMR[seq=y,ssrc=MSb]"]; + bts => bsc [label="RTP-AMR[seq=x+1,ssrc=MSa]"]; + bts => bsc [label="RTP-AMR[seq=y+1,ssrc=MSb]"]; + bts => bsc [label="RTP-AMR[seq=x+2,ssrc=MSa]"]; + bts => bsc [label="RTP-AMR[seq=y+2,ssrc=MSb]"]; + bsc => bscnat [label="UDP[Osmux[ft=2,cid=i,seq=m,AMR(x),AMR(x+1),AMR(x+2)],Osmux[ft=2,cid=i+1,seq=n,AMR(y),AMR(y+1),AMR(y+2)]]"]; + bscnat => mgw [label="RTP-AMR[seq=o,ssrc=r] (originally seq=x,ssrc=MSa)"]; + bscnat => mgw [label="RTP-AMR[seq=p,ssrc=s] (originally seq=y,ssrc=MSb)"]; + bscnat => mgw [label="RTP-AMR[seq=o+1,ssrc=r] (originally seq=x+1,ssrc=MSa)"]; + bscnat => mgw [label="RTP-AMR[seq=p+1,ssrc=s] (originally seq=y+1,ssrc=MSb)"]; + bscnat => mgw [label="RTP-AMR[seq=o+2,ssrc=r] (originally seq=x+2,ssrc=MSa)"]; + bscnat => mgw [label="RTP-AMR[seq=p+2,ssrc=s] (originally seq=y+2,ssrc=MSb)"]; + bts => bsc [label="RTP-AMR[seq=x+3,ssrc=MSa]"]; + bts => bsc [label="RTP-AMR[seq=y+3,ssrc=MSb]"]; + bts => bsc [label="RTP-AMR[seq=x+4,ssrc=MSa]"]; + bts => bsc [label="RTP-AMR[seq=y+4,ssrc=MSb]"]; + bts => bsc [label="RTP-AMR[seq=x+5,ssrc=MSa]"]; + bts => bsc [label="RTP-AMR[seq=y+5,ssrc=MSb]"]; + bsc => bscnat [label="UDP[Osmux[ft=2,cid=i,seq=m+1,AMR(x+3),AMR(x+4),AMR(x+5)],Osmux[ft=2,cid=i+1,seq=n+1,AMR(y+3),AMR(y+4),AMR(y+5)]]"]; + bscnat => mgw [label="RTP-AMR[seq=o+3,ssrc=r] (originally seq=x+3,ssrc=MSa)"]; + bscnat => mgw [label="RTP-AMR[seq=p+3,ssrc=s] (originally seq=y+3,ssrc=MSb)"]; + bscnat => mgw [label="RTP-AMR[seq=o+4,ssrc=r] (originally seq=x+4,ssrc=MSa)"]; + bscnat => mgw [label="RTP-AMR[seq=p+4,ssrc=s] (originally seq=y+4,ssrc=MSb)"]; + bscnat => mgw [label="RTP-AMR[seq=o+5,ssrc=r] (originally seq=x+5,ssrc=MSa)"]; + bscnat => mgw [label="RTP-AMR[seq=p+5,ssrc=s] (originally seq=y+5,ssrc=MSb)"]; +} +---- + +=== Marker bit + +As described earlier, the Marker bit is always expected to relate to the first +AMR payload of an OSmux frame. Thus, special considerations may be followed when +the OSmux encoder receives an RTP packet with a marker bit. For instance, +previously enqueued RTP packets may be sent even if the configured batch factor +is not reached. + +We again use the scenario with 2 concurrent calls and a batch factor of 3. + +["mscgen"] +---- +msc { + hscale = 2; + bts [label="BTS"], bsc [label="BSC"], bscnat [label="BSC-NAT"], mgw [label="MGW"]; + + ...; + --- [label="2 Regular RTP-AMR call using OSmux with batch factor 3 (has been ongoing for some time)"]; + + bts => bsc [label="RTP-AMR[seq=x,ssrc=MSa]"]; + bts => bsc [label="RTP-AMR[seq=y,ssrc=MSb]"]; + bts => bsc [label="RTP-AMR[seq=x+1,ssrc=MSa]"]; + bts => bsc [label="RTP-AMR[seq=y+1,ssrc=MSb]"]; + bts => bsc [label="RTP-AMR[seq=x+2,ssrc=MSa]"]; + bts => bsc [label="RTP-AMR[seq=y+2,ssrc=MSb]"]; + bsc => bscnat [label="UDP[Osmux[ft=2,cid=i,seq=m,AMR(x),AMR(x+1),AMR(x+2)],Osmux[ft=2,cid=i+1,seq=n,AMR(y),AMR(y+1),AMR(y+2)]]"]; + bscnat => mgw [label="RTP-AMR[seq=o,ssrc=r] (originally seq=x,ssrc=MSa)"]; + bscnat => mgw [label="RTP-AMR[seq=p,ssrc=r] (originally seq=y,ssrc=MSb)"]; + bscnat => mgw [label="RTP-AMR[seq=o+1,ssrc=r] (originally seq=x+1,ssrc=MSa)"]; + bscnat => mgw [label="RTP-AMR[seq=p+1,ssrc=s] (originally seq=y+1,ssrc=MSb)"]; + bscnat => mgw [label="RTP-AMR[seq=o+2,ssrc=r] (originally seq=x+2,ssrc=MSa)"]; + bscnat => mgw [label="RTP-AMR[seq=p+2,ssrc=s] (originally seq=y+2,ssrc=MSb)"]; + bts => bsc [label="RTP-AMR[seq=x+3,ssrc=MSa]"]; + bts => bsc [label="RTP-AMR[seq=y+3,ssrc=MSb]"]; + bts => bsc [label="RTP-AMR[seq=x+4,ssrc=MSa]"]; + bts => bsc [label="RTP-AMR[seq=y+4,ssrc=MSb] with Marker bit set M=1"]; + bsc => bscnat [label="UDP[Osmux[ft=2,cid=i,seq=m+1,AMR(x+3),AMR(x+4)],Osmux[ft=2,cid=i+1,seq=n+1,AMR(y+3)]]"]; + bscnat => mgw [label="RTP-AMR[seq=o+3,ssrc=r] (originally seq=x+3,ssrc=MSa)"]; + bscnat => mgw [label="RTP-AMR[seq=p+3,ssrc=s] (originally seq=y+3,ssrc=MSb)"]; + bscnat => mgw [label="RTP-AMR[seq=o+4,ssrc=r] (originally seq=x+4,ssrc=MSa)"]; + bts => bsc [label="RTP-AMR[seq=x+5,ssrc=MSa]"]; + bts => bsc [label="RTP-AMR[seq=y+5,ssrc=MSb]"]; + bts => bsc [label="RTP-AMR[seq=x+6,ssrc=MSa]"]; + bts => bsc [label="RTP-AMR[seq=y+6,ssrc=MSb]"]; + bsc => bscnat [label="UDP[Osmux[ft=2,cid=i,seq=m+2,AMR(x+5),AMR(x+6)],Osmux[ft=2,cid=i+1,seq=n+2,AMR(y+4),AMR(y+5),AMR(y+6)]]"]; + bscnat => mgw [label="RTP-AMR[seq=p+4,ssrc=s] (originally seq=y+4,ssrc=MSb)"]; + bscnat => mgw [label="RTP-AMR[seq=o+5,ssrc=r] (originally seq=x+5,ssrc=MSa)"]; + bscnat => mgw [label="RTP-AMR[seq=p+5,ssrc=s] (originally seq=y+5,ssrc=MSb)"]; + bscnat => mgw [label="RTP-AMR[seq=o+6,ssrc=r] (originally seq=x+6,ssrc=MSa)"]; + bscnat => mgw [label="RTP-AMR[seq=p+6,ssrc=s] (originally seq=y+6,ssrc=MSb)"]; +} +---- == Evaluation: Expected traffic savings -- cgit v1.2.3 From 53ce68f9770580cf13069b888228cb48ad26908d Mon Sep 17 00:00:00 2001 From: Pau Espin Pedrol Date: Wed, 19 Jul 2017 15:31:55 +0200 Subject: osmux-reference: Add traffic saving plot Change-Id: I8fa60c1f95436c39fd1ff9424a907876d367484e --- doc/manuals/osmux-reference.adoc | 134 ++++++++++++++++----------------------- 1 file changed, 55 insertions(+), 79 deletions(-) diff --git a/doc/manuals/osmux-reference.adoc b/doc/manuals/osmux-reference.adoc index 0f66118e0..4d03a4b05 100644 --- a/doc/manuals/osmux-reference.adoc +++ b/doc/manuals/osmux-reference.adoc @@ -499,91 +499,67 @@ msc { == Evaluation: Expected traffic savings -The following figure shows the traffic saving (in %) depending on the number -of concurrent numbers of callings (asumming trunking but no batching at all): ----- - Traffic savings (%) - 100 ++-------+-------+--------+--------+-------+--------+-------+-------++ - + + + + + + batch factor 1 **E*** + - | | - 80 ++ ++ - | | - | | - | ****E********E - 60 ++ ****E*******E********E*** ++ - | **E**** | - | **** | - 40 ++ *E** ++ - | ** | - | ** | - | ** | - 20 ++ E ++ - | | - + + + + + + + + + - 0 ++-------+-------+--------+--------+-------+--------+-------+-------++ - 0 1 2 3 4 5 6 7 8 - Concurrent calls ----- - -The results shows a saving of 15.79% with only one concurrent call, that -quickly improves with more concurrent calls (due to trunking). +The following figure shows the growth in traffic saving (in %) depending on the +number of concurrent numbers of callings for a given set of batching factor +values: -We also provide the expected results by batching 4 messages for a single call: +["python2"] ---- - Traffic savings (%) - 100 ++-------+-------+--------+--------+-------+--------+-------+-------++ - + + + + + + batch factor 4 **E*** + - | | - 80 ++ ++ - | | - | | - | ****E********E*******E********E*******E********E - 60 ++ ****E**** ++ - | E*** | - | | - 40 ++ ++ - | | - | | - | | - 20 ++ ++ - | | - + + + + + + + + + - 0 ++-------+-------+--------+--------+-------+--------+-------+-------++ - 0 1 2 3 4 5 6 7 8 - Concurrent calls +from pychart import * +theme.get_options() +theme.scale_factor = 5 +theme.use_color = 1 +theme.reinitialize() + +IP_HEADER=20 +UDP_HEADER=8 +RTP_HEADER=12 +OSMUX_HEADER=4 +AMR59_PAYLOAD=17 + +def osmux_get_size(calls, payloads): + return IP_HEADER + UDP_HEADER + (OSMUX_HEADER + AMR59_PAYLOAD * payloads) * calls + +def rtp_get_size(calls, payloads): + return calls * payloads * (IP_HEADER + UDP_HEADER + RTP_HEADER + AMR59_PAYLOAD) + +def calc_traffic_saving(calls, payloads): + return 100 - 100.0 * osmux_get_size(calls, payloads) / rtp_get_size(calls, payloads) + +# The first value in each tuple is the X value, and subsequent values are Y values for different lines. +def gen_table(): + data = [] + for calls in range(1, 9): + col = (calls,) + for factor in range(1, 9): + col += (calc_traffic_saving(calls, factor),) + data.append(col) + return data + +def do_plot(data): + xaxis = axis.X(format="/hL%d", tic_interval = 1, label="Concurrent calls") + yaxis = axis.Y(format="%d%%", tic_interval = 10, label="Traffic Saving") + ar = area.T(x_axis=xaxis, y_axis=yaxis, y_range=(None,None), x_grid_interval=1, x_grid_style=line_style.gray70_dash3) + for y in range(1, len(data[0])): + plot = line_plot.T(label="bfactor "+str(y), data=data, ycol=y, tick_mark=tick_mark.circle1) + ar.add_plot(plot) + ar.draw() + +data = gen_table() +do_plot(data) ---- -The results show a saving of 56.68% with only one concurrent call. Trunking -slightly improves the situation with more concurrent calls. +The results show a saving of 15.79% with only one concurrent call and with +batching disabled (bfactor 1), that quickly improves with more concurrent calls +(due to trunking). -We also provide the figure with batching factor of 8: ----- - Traffic savings (%) - 100 ++-------+-------+--------+--------+-------+--------+-------+-------++ - + + + + + + batch factor 8 **E*** + - | | - 80 ++ ++ - | | - | ****E*******E********E - | ****E********E********E*******E**** | - 60 ++ E*** ++ - | | - | | - 40 ++ ++ - | | - | | - | | - 20 ++ ++ - | | - + + + + + + + + + - 0 ++-------+-------+--------+--------+-------+--------+-------+-------++ - 0 1 2 3 4 5 6 7 8 - Concurrent calls ----- +By increasing the batching of messages to 4, the results show a saving of 56.68% +with only one concurrent call. Trunking slightly improves the situation with +more concurrent calls. -That shows very little improvement with regards to batching 4 messages. -Still, we risk to degrade user experience. Thus, we consider a batching factor -of 3 and 4 is adecuate. +A batching factor of 8 provides very little improvement with regards to batching +4 messages. Still, we risk to degrade user experience. Thus, we consider a +batching factor of 3 and 4 is adecuate. == Other proposed follow-up works -- cgit v1.2.3 From 9980b4aa1c8844173705fbe507d566cc26d521f6 Mon Sep 17 00:00:00 2001 From: Pau Espin Pedrol Date: Wed, 19 Jul 2017 16:29:23 +0200 Subject: osmux-reference-docinfo: Add latest changes to revhistory Change-Id: I01e513a71a3f830d393c57c43678d7e4c8d2d151 --- doc/manuals/osmux-reference-docinfo.xml | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/doc/manuals/osmux-reference-docinfo.xml b/doc/manuals/osmux-reference-docinfo.xml index 06b2d7edd..7e31ec72b 100644 --- a/doc/manuals/osmux-reference-docinfo.xml +++ b/doc/manuals/osmux-reference-docinfo.xml @@ -28,6 +28,14 @@ Update frame bits according to implementation. + + 0.4 + 19 July 2017 + Pau Espin Pedrol + + Add sequence charts, generate packet header structure with packetdiag, generate traffic saving plot with pychart. + + -- cgit v1.2.3 From 1293ee10ba8396a7551cf243a9e75af9a1215675 Mon Sep 17 00:00:00 2001 From: Pau Espin Pedrol Date: Fri, 11 Aug 2017 15:04:40 +0200 Subject: osmux: Fix description for Dummy frames FT field Change-Id: Ia421655bd1be45101da3db2a0af44fbb3cc111c1 --- doc/manuals/osmux-reference.adoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/manuals/osmux-reference.adoc b/doc/manuals/osmux-reference.adoc index 4d03a4b05..929f44203 100644 --- a/doc/manuals/osmux-reference.adoc +++ b/doc/manuals/osmux-reference.adoc @@ -159,7 +159,7 @@ previous OSmux message. ---- Field Type (FT): 2 bits:: -The Field Type allocated for LAPD Signalling is "0". +The Field Type allocated for LAPD Signalling frames is "0". This frame type is not yet supported inside OsmoCom and may be subject to change in future versions of the protocol. @@ -197,7 +197,7 @@ this OSmux header, it is guaranteed that the first AMR frame is the first in the talkspurt. Field Type (FT): 2 bits:: -The Field Type allocated for AMR codec is "1". +The Field Type allocated for AMR Codec frames is "1". Frame Counter (CTR): 2 bits:: Provides the number of batched AMR payloads (starting 0) after the header. For @@ -284,7 +284,7 @@ starts sending real audio, at which point dummy packets are not needed anymore. ---- Field Type (FT): 2 bits:: -The Field Type allocated for AMR codec is "2". +The Field Type allocated for Dummy frames is "2". Frame Counter (CTR): 2 bits:: Provides the number of dummy batched AMR payloads (starting 0) after the header. -- cgit v1.2.3 From d9400a977f7e9557c282b0ecb8ac5ef4a822e981 Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Thu, 17 Aug 2017 16:31:47 +0200 Subject: mgw: Fix endpoint names for new MGW According to RFC3435, an RTP bridge forrwarding packets, transcoding or otherwise, is a single endpoint with two connections. Let's treat it as such. We introduce the "rtpbridge/" prefix to identify such special RTP endpoints. Change-Id: Id1f079307225faf05d298dcb12aa1c421bfa680a --- doc/manuals/mgw/osmo-bsc-new-mgw-e1.msc | 8 ++++---- doc/manuals/mgw/osmo-bsc-new-mgw.msc | 24 ++++++++++++------------ 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/doc/manuals/mgw/osmo-bsc-new-mgw-e1.msc b/doc/manuals/mgw/osmo-bsc-new-mgw-e1.msc index 7912a73f5..04b114fff 100644 --- a/doc/manuals/mgw/osmo-bsc-new-mgw-e1.msc +++ b/doc/manuals/mgw/osmo-bsc-new-mgw-e1.msc @@ -17,9 +17,9 @@ msc { ms <-> bsc [label="Assignment"]; ...; - mgcp <- bsc [label="MGCP CRCX ts1/ss2@abis (MSC:4000)"]; + mgcp <- bsc [label="MGCP CRCX ts1/ss2@mgw (MSC:4000)"]; mgcp box mgcp [label="Bind to MGW-local RTP Port (3000)\nConnect to MSC:4000"]; - mgcp -> bsc [label="MGCP CRCX ts1/ss2@a OK (MGW:3000)"]; + mgcp -> bsc [label="MGCP CRCX ts1/ss2@mgw OK (MGW:3000)"]; ...; bsc -> m_sc [label="BSSAP ASSGN CMPL (3GPP AoIP MGW:3000)"]; @@ -44,7 +44,7 @@ msc { bsc <- m_sc [label="SCCP RLSD"]; bsc -> m_sc [label="SCCP RLC"]; ...; - mgcp <- bsc [label="MGCP DLCX ts1/ss2@a"]; + mgcp <- bsc [label="MGCP DLCX ts1/ss2@mgw"]; mgcp box mgcp [label="Release MSC-facing local RTP port (3000)"]; - mgcp -> bsc [label="MGCP DLCX ts1/ss2@a OK"]; + mgcp -> bsc [label="MGCP DLCX ts1/ss2@mgw OK"]; } diff --git a/doc/manuals/mgw/osmo-bsc-new-mgw.msc b/doc/manuals/mgw/osmo-bsc-new-mgw.msc index 2bab84dec..e618bb721 100644 --- a/doc/manuals/mgw/osmo-bsc-new-mgw.msc +++ b/doc/manuals/mgw/osmo-bsc-new-mgw.msc @@ -20,19 +20,19 @@ msc { bts <- bsc [label="IPA CRCX"]; bts box bts [label="Bind to BTS-local RTP Port (1000)"]; bts -> bsc [label="IPA CRCX ACK (BTS:1000)"]; - bsc -> mgcp [label="MGCP CRCX 2@abis (BTS:1000)"]; + bsc -> mgcp [label="MGCP CRCX rtpbridge/2@mgw (BTS:1000)"]; mgcp box mgcp [label="Bind to MGW-local RTP Port (2000)\nConnect to BTS:1000"]; - bsc <- mgcp [label="MGCP CRCX 2@abis OK (MGW:2000)"]; - bts <- bsc [label="IPA MDCX 2@abis (MGW:2000)"]; + bsc <- mgcp [label="MGCP CRCX rtpbridge/2@mgw OK (MGW:2000)"]; + bts <- bsc [label="IPA MDCX (MGW:2000)"]; bts box bts [label="Connect RTP socket to remote (MGW) RTP Port"]; - bts -> bsc [label="IPA MDCX 2@abis ACK"]; - #bsc -> mgcp [label="MGCP MDCX 2@abis (optional)"]; - #bsc <- mgcp [label="MGCP MDCX 2@abis OK (optional)"]; + bts -> bsc [label="IPA MDCX ACK"]; + #bsc -> mgcp [label="MGCP MDCX rtpbridge/2@mgw (optional)"]; + #bsc <- mgcp [label="MGCP MDCX rtpbridge/2@mgw OK (optional)"]; ...; - mgcp <- bsc [label="MGCP CRCX 1@a (MSC:4000)"]; + mgcp <- bsc [label="MGCP CRCX rtpbridge/2@mgw (MSC:4000)"]; mgcp box mgcp [label="Bind to MGW-local RTP Port (3000)\nConnect to MSC:4000"]; - mgcp -> bsc [label="MGCP CRCX 1@a OK (MGW:3000)"]; + mgcp -> bsc [label="MGCP CRCX rtpbridge/2@mgw OK (MGW:3000)"]; ...; bsc -> m_sc [label="BSSAP ASSGN CMPL (3GPP AoIP MGW:3000)"]; @@ -57,13 +57,13 @@ msc { bsc <- m_sc [label="SCCP RLSD"]; bsc -> m_sc [label="SCCP RLC"]; ...; - mgcp <- bsc [label="MGCP DLCX 1@a"]; + mgcp <- bsc [label="MGCP DLCX rtpbridge/2@mgw"]; mgcp box mgcp [label="Release MSC-facing local RTP port (3000)"]; - mgcp -> bsc [label="MGCP DLCX 1@a OK"]; + mgcp -> bsc [label="MGCP DLCX rtpbridge/2@mgw OK"]; - bsc -> mgcp [label="MGCP DLCX 2@abis"]; + mgcp <- bsc [label="MGCP DLCX rtpbridge/2@mgw"]; mgcp box mgcp [label="Release BTS-facing local RTP port (2000)"]; - bsc <- mgcp [label="MGCP DLCX 2@abis OK"]; + mgcp -> bsc [label="MGCP DLCX rtpbridge/2@mgw OK"]; bts <- bsc [label="IPA DLCX"]; bts box bts [label="Release BTS-local RTP port (1000)"]; -- cgit v1.2.3 From f77da129a86cf7e11d4032f273328b1d70a32577 Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Thu, 17 Aug 2017 16:35:27 +0200 Subject: MGW: Include MGCP endpoint naming scheme of old IPA/SCCPlite approach Change-Id: Ib1fe96f0041534fa027b70ee67978cb7c6bc5207 --- doc/manuals/mgw/osmo-bsc-old-sccplite.msc | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/manuals/mgw/osmo-bsc-old-sccplite.msc b/doc/manuals/mgw/osmo-bsc-old-sccplite.msc index f7298bfac..067721c46 100644 --- a/doc/manuals/mgw/osmo-bsc-old-sccplite.msc +++ b/doc/manuals/mgw/osmo-bsc-old-sccplite.msc @@ -24,12 +24,12 @@ msc { bts box bts [label="Connect RTP socket to remote (bsc_mgcp) RTP Port"]; bts -> bsc [label="IPA MDCX ACK"]; - mgcp <- m_sc [label="MGCP CRCX"]; + mgcp <- m_sc [label="MGCP CRCX 1@mgw"]; mgcp box mgcp [label="Bind to BTS-local RTP Port"]; - mgcp -> m_sc [label="MGCP CRCX OK"]; - mgcp <- m_sc [label="MGCP MDCX (recvonly) "]; + mgcp -> m_sc [label="MGCP CRCX 1@mgw OK"]; + mgcp <- m_sc [label="MGCP MDCX 1@mgw (recvonly) "]; mgcp box mgcp [label="Connect RTP socket to remote (MSC) RTP Port"]; - mgcp -> m_sc [label="MGCP MDCX OK"]; + mgcp -> m_sc [label="MGCP MDCX 1@mgw OK"]; mgcp <= m_sc [label="RTP Audio"]; bts <= mgcp [label="RTP Audio"]; ms <= bts [label="Um Audio (unidirectional)"]; @@ -45,9 +45,9 @@ msc { ...; ms <- m_sc [label="DTAP CC CONNECT"]; ms -> m_sc [label="DTAP CC CONNECT ACK"]; - mgcp <- m_sc [label="MGCP MDCX (sndrecv) "]; + mgcp <- m_sc [label="MGCP MDCX 1@mgw (sndrecv) "]; mgcp box mgcp [label="Why?"]; - mgcp -> m_sc [label="MGCP MDCX OK"]; + mgcp -> m_sc [label="MGCP MDCX 1@mgw OK"]; --- [label="Voice Call in Progress"]; ms <- m_sc [label="DTAP CC DISCONNET"]; ms <- m_sc [label="DTAP CC RELEASE"]; @@ -58,7 +58,7 @@ msc { bsc <- m_sc [label="SCCP RLSD"]; bsc -> m_sc [label="SCCP RLC"]; ...; - mgcp <- m_sc [label="MGCP DLCX"]; + mgcp <- m_sc [label="MGCP DLCX 1@mgw"]; mgcp box mgcp [label="Release local RTP port"]; - mgcp -> m_sc [label="MGCP DLCX OK"]; + mgcp -> m_sc [label="MGCP DLCX 1@mgw OK"]; } -- cgit v1.2.3 From 88faeefdc955bc16ecffe43cb1479f2beafb15f3 Mon Sep 17 00:00:00 2001 From: Pau Espin Pedrol Date: Thu, 31 Aug 2017 16:32:40 +0200 Subject: Allow easily disabling GFDL references All parts referencing GFDL can be easily disabled by removing the 'gfdl-enabled' attribute from the document. Change-Id: I2489726ad2e90301bceadfada926e31ae0f85986 --- doc/manuals/osmobsc-usermanual.adoc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/manuals/osmobsc-usermanual.adoc b/doc/manuals/osmobsc-usermanual.adoc index 9323373b3..b455897b3 100644 --- a/doc/manuals/osmobsc-usermanual.adoc +++ b/doc/manuals/osmobsc-usermanual.adoc @@ -1,3 +1,5 @@ +:gfdl-enabled: + OsmoBSC User Manual =================== Harald Welte -- cgit v1.2.3 From ea9a44dade04598047187147d622473b512063d6 Mon Sep 17 00:00:00 2001 From: Neels Hofmeyr Date: Thu, 19 Oct 2017 05:11:57 +0200 Subject: refactor Makefile build rules, don't use the FORCE The initial goal was to make sure we don't have overall FORCE rules causing unnecessary rebuilds -- annoying while writing documentation. As I looked through possible dependencies, I finally understood what's going on here. Remove code dup and nicely sort which belongs where in build/Makefile.*.inc. In each, describe in a top comment how to use it, and also unify how they are used: - Rename Makefile.inc to Makefile.docbook.inc and refactor - Add Makefile.vty-reference.inc - Add Makefile.common.inc Make sure that we accurately pick up all dependencies. Drop use of the macro called 'command', that silenced the actual command lines invoked and replaced them with short strings: it obscures what is actually going on and makes the Makefiles hard to read and understand. Each manual's makefile is greatly reduced to few definitions and a Makefile include, e.g. one for asciidoc, one for VTY reference. Move common/bsc_vty_additions.xml to OsmoBSC/vty/libbsc_vty_additions.xml, link from OsmoNITB. It applies only to OsmoBSC and OsmoNITB. Add a script that combines a VTY reference file with *all* additions files found in a manual's vty/ dir. Call this from Makefile.vty-reference.inc. Change-Id: I9758e04162a480e28c7dc83475b514cf7fd25ec0 --- doc/manuals/Makefile | 55 +------ doc/manuals/vty/libbsc_vty_additions.xml | 244 +++++++++++++++++++++++++++++++ 2 files changed, 250 insertions(+), 49 deletions(-) create mode 100644 doc/manuals/vty/libbsc_vty_additions.xml diff --git a/doc/manuals/Makefile b/doc/manuals/Makefile index 35f50da00..153348258 100644 --- a/doc/manuals/Makefile +++ b/doc/manuals/Makefile @@ -1,54 +1,11 @@ -# XSL stylesheets downloaded from http://docbook.sourceforge.net/release/xsl/current/html/ -# Makefile from BitBake/OpenEmbedded manuals - - -EXTRA_DEPS = gen-bsc-vty-docbook - -topdir = . -bsc_reference = $(topdir)/osmobsc-vty-reference.xml -manuals = $(bsc_reference) -# types = pdf txt rtf ps xhtml html man tex texi dvi -# types = pdf txt -types = $(docbooktotypes) -docbooktotypes = pdf -# htmlcssfile = -# htmlcss = - -TOPDIR := .. -ASCIIDOCS := osmobsc-usermanual osmux-reference aoip-mgw-options +TOPDIR = .. +ASCIIDOC = osmobsc-usermanual.adoc osmux-reference.adoc aoip-mgw-options.adoc include $(TOPDIR)/build/Makefile.asciidoc.inc -include $(TOPDIR)/build/Makefile.inc - osmobsc-usermanual.pdf: chapters/*.adoc -osmux-reference.pdf: osmux-reference.adoc -aoip-mgw-options.pdf: aoip-mgw-options.adoc +aoip-mgw-options.pdf: aoip-mgw-options.adoc mgw/*.msc -clean: - -rm -rf $(cleanfiles) - -rm osmobsc-usermanual__*.png - -rm osmobsc-usermanual__*.svg - -rm osmobsc-usermanual*.check - -rm osmux-reference*.check - -rm aoip-mgw-options*.png - -rm aoip-mgw-options*.svg - -rm aoip-mgw-options*.check - -rm osmux-reference__*.svg - -rm osmux-reference__*.png - -rm osmux-reference__*.check +VTY_REFERENCE = osmobsc-vty-reference.xml +include $(TOPDIR)/build/Makefile.vty-reference.inc -gen-bsc-vty-docbook: FORCE - $(call command,xsltproc -o generated/combined1.xml \ - --stringparam with $(PWD)/../common/vty_additions.xml \ - $(MERGE_DOC) vty/bsc_vty_reference.xml, \ - XSLTPROC,Merging Common VTY) - $(call command,xsltproc -o generated/combined2.xml \ - --stringparam with $(PWD)/../common/bsc_vty_additions.xml \ - $(MERGE_DOC) generated/combined1.xml, \ - XSLTPROC,Merging Common BSC VTY) - $(call command,xsltproc -o generated/combined3.xml \ - --stringparam with $(PWD)/vty/bsc_vty_additions.xml \ - $(MERGE_DOC) generated/combined2.xml, \ - XSLTPROC,Merging BSC VTY) - $(call command,xsltproc ../vty_reference.xsl generated/combined3.xml > generated/docbook_vty.xml, \ - XSLTPROC,Converting BSC VTY to DocBook) +include $(TOPDIR)/build/Makefile.common.inc diff --git a/doc/manuals/vty/libbsc_vty_additions.xml b/doc/manuals/vty/libbsc_vty_additions.xml new file mode 100644 index 000000000..868539850 --- /dev/null +++ b/doc/manuals/vty/libbsc_vty_additions.xml @@ -0,0 +1,244 @@ + + + + GSM Network Configuration + This is the base node for all configuration of + GSM network related configuration, it includes the LAC, CI + access criteria but also the configuration of each BTS in this + network. + + + + BTS Configuration + This is the configuration of a single BTS. + + + Set the IPA stream identifier for the OML link within the IPA + multiplex. Must be the same as on the BTS side. The default + value is 255. Only applies to BTSs connected via Abis/IP + interface. + + + + + Only applies to Ericsson OML2000 based BTSs. + + + + + Only applies to Ericsson OML2000 based BTSs. + + + + + Only applies to Ericsson OML2000 based BTSs. + + + + + Configure whether the IMSI ATTACH (and DETACH) procedures + shall be used by MS in this cell. The default should be enabled. + + + + + Configure the IP address of the BSC used for RSL. Abis/IP + BTSs, including OsmoBTS and the nanoBTS will be instructed to + connect their RSL links to that IP address. + + + + + Configure the BSIC of the cell. It is a 6-bit value + consisting of a 3-bit NCC (network color code) in the upper 3 + bits, and a 3-bit BCC (base station color code) in the lower 3 + bits. + + + + + Configure the default TSC for all timeslots on all TRX of the BTS. + The normal default is to use the BCC part of the BSIC as TSC. + Not all BTS models support a TSC != BCC. + + + + + Add or remove an ARFCN to/from the list of neighbor cells + advertised in dedicated mode via SACCH. This command is only + available in manual-si5 neighbor-list mode. + + + + + Add or remove an ARFCN to/from the list of neighbor cells. + This command is only available in manual neighbor-list mode. + + + + + + + + + If a cell advertises a cell reselection offset (CRO), it will + become more attractive during cell re-selection, despite not + being received at a higher level than other cells. The CRO + of each neighbor cell is added to the respective received + signal level before comparing their values for re-selection. + + + + + The Cell Re-Selection Hysteresis determines how many dB a + neighbor cell must be stronger than the current serving cell + before the MS considers that neighbor cell as a candidate for + re-selection. + + + + + The ip.access unit ID is a parameter of the IPA + Signalling-over-IP multiplex. It is administratively + configured on the BTS side, and used by the BTS to identify + itself to the BSC. The BSC then selects the BTS configuration + for this Unit ID. It consists of three parts, the Site ID, + the BTS ID and the TRX ID. The TRX ID automatically + corresponds to to the transceiver number and is thus not + configurable here. + + + + + Configures the maximum transmit power (in dBm) that any MS may + use within this cell. + + + + + The periodic location updating interval determines how often + the MS will periodically perform a LOCATION UPDATE procedure, + despite not having actuall changed location. The value is + specified in minutes. + + + + + Using this command, you can enable/disable barring of the cell. + Barred cells are not visible/accessible to regular phones. + Only some special operator testing phones can be configured in + a way to ignore cell barring. + + + + + Using this command, you can determine the minimum downlink + signal receive level (RxLev), at which the BTS must be + received by the MS in order to attempt establishing dedicated + channels via the RACH. + + + + + Using this command, you can configure which access control + classes are permitted to access this cell. The access control + class of a MS is determined by the contents of the EF.ACC file + on the SIM card. + + Access Control Class 10 corresponds to Emergency Calls, and is + thus not configurable this way. + + + + + Using this command, you can determine if this cell permits the + use of the 'EMERGENCY CALL' feature. + + Unless you operate a public network with connection to the + public emergency services in compliance with applicable regulatory + requirements, you should always have emergency calls disabled (allowed + 0) - which is also the default configuration. + + + + + Using this command, you can specify how many blocks of the + downlink CCCH should be reserved for exclusive usage as AGCH. + + Not all BTS models currently support non-default configuration + of this parameter. + + + + + Set the LAPD TEI used for the OML connection of this BTS. + Only applies to classic E1 based A-bis. + + + + + + TRX Configuration + This is the configuration of a TRX. + + + Inform the BSC about the nominal RF transmit power of the BTS in dBm. + This value must be entered depending on the BTS model and + external setup such as amplifiers. Changing this value will + not change the actually transmitted power, it will just affect + the reporting in the BSC VTY. + + + + + Request the actual RF transmit power of the BTS to be reduced + by the specified number of dB. + + + + + Set the LAPD TEI used for the RSL connection of this TRX. + Only applies to classic E1 based A-bis. + + + + + Enable (1) or disable (0) the RF locking for this TRX. RF + locking is a mechanism by which the transmitter can be shut + down by administrative means, e.g. via the control interface. + + + + + + TS Configuration + This is the configuration of a TS. + + + Configure the timeslot to run on a different TSC than the + default TSC of the BTS (which is derived from the BCC part of the BSIC). + Please note that not all BTS models support timeslot-specific TSC! + + + + + Enable or disable frequency hopping for this timeslot. Please + note that not all BTS models may support frequency hopping, + and that frequency hopping is only permitted for secondary + TRXs, so TRX 0 must always be non-hopping. + + + + + + OML Commands + This node allows to manipulate the OML state of + a connected BTS. It is meant for testing during development. + + + + OML2000 Commands + This node allows to issue OML2000 commands for + Ericsson BTS. It is meant for testing during development. + + -- cgit v1.2.3 From cef1d72ba82402b57a1c93288fc28b8d71acf0b4 Mon Sep 17 00:00:00 2001 From: Max Date: Thu, 2 Nov 2017 15:09:53 +0100 Subject: OsmoBSC: update CTRL docs * use proper naming scheme for BTS-specific CTRL commands * add/update oml-* commands Change-Id: I5b2cd940b4d84c140fce871f236aeab091b27360 Related: OS#2486 --- doc/manuals/chapters/control.adoc | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/doc/manuals/chapters/control.adoc b/doc/manuals/chapters/control.adoc index a1d6b435b..327e5b4af 100644 --- a/doc/manuals/chapters/control.adoc +++ b/doc/manuals/chapters/control.adoc @@ -4,10 +4,10 @@ The actual protocol is described in <>, the variables common to all programs using it are described in <>. Here we describe variables specific to OsmoBSC. The commands starting with prefix -"net.btsN." are specific to a certain BTS so N have to be replaced with BTS -number when issuing command e. g. "net.bts1.channel-load". Similarly the +"bts.N." are specific to a certain BTS so N have to be replaced with BTS +number when issuing command e. g. "bts.1.channel-load". Similarly the TRX-specific commands are additionally prefixed with TRX number e. g. -"net.bts1.trx2.arfcn". +"bts.1.trx.2.arfcn". .Variables available over control interface [options="header",width="100%",cols="20%,5%,5%,50%,20%"] @@ -28,16 +28,17 @@ TRX-specific commands are additionally prefixed with TRX number e. g. |ussd-notify-v1|WO|No|",,"| See <> for details. |rf_locked|RW|No|"0","1"|See <> for details. |number-of-bts|RO|No|""|Get number of configured BTS. -|net.btsN.location-area-code|RW|No|""|Set/Get LAC (value between (0, 65535)). -|net.btsN.cell-identity|RW|No|""|Set/Get Cell Identity (value between (0, 65535)). -|net.btsN.apply-configuration|WO|No|Ignored|Restart BTS via OML. -|net.btsN.send-new-system-informations|WO|No|Ignored|Regenerate System Information messages for given BTS. -|net.btsN.channel-load|RO|No|",,"|See <> for details. -|net.btsN.oml-connection-state|RO|No|"connected", "disconnected"|Indicate the status of OML connection of BTS. -|net.btsN.gprs-mode|RW|No|""|See <> for details. -|net.btsN.rf_state|RO|No|",,"|See <> for details. -|net.btsN.trxM.arfcn|RW|No|""|Set/Get ARFCN (value between (0, 1023)). -|net.btsN.trxM.max-power-reduction|RW|No|""|See <> for details. +|bts.N.location-area-code|RW|No|""|Set/Get LAC (value between (0, 65535)). +|bts.N.cell-identity|RW|No|""|Set/Get Cell Identity (value between (0, 65535)). +|bts.N.apply-configuration|WO|No|Ignored|Restart BTS via OML. +|bts.N.send-new-system-informations|WO|No|Ignored|Regenerate System Information messages for given BTS. +|bts.N.channel-load|RO|No|",,"|See <> for details. +|bts.N.oml-connection-state|RO|No|"connected", "disconnected", "degraded"|Indicate the status of OML connection of BTS. +|bts.N.oml-uptime|RO|No||Return OML link uptime in seconds. +|bts.N.gprs-mode|RW|No|""|See <> for details. +|bts.N.rf_state|RO|No|",,"|See <> for details. +|bts.N.trx.M.arfcn|RW|No|""|Set/Get ARFCN (value between (0, 1023)). +|bts.N.trx.M.max-power-reduction|RW|No|""|See <> for details. |=== [[notif]] -- cgit v1.2.3 From b4045a0c69caa616a469b36bc6df31878570c12d Mon Sep 17 00:00:00 2001 From: Alexander Couzens Date: Tue, 5 Dec 2017 15:22:05 +0100 Subject: OsmoBSC: add rate counter documentation Change-Id: Ia8711dd4bc9db36a7121552dc067c7afb1051b0a --- doc/manuals/chapters/counters.adoc | 4 ++ doc/manuals/chapters/counters_generated.adoc | 76 ++++++++++++++++++++++++++++ doc/manuals/osmobsc-usermanual.adoc | 2 + 3 files changed, 82 insertions(+) create mode 100644 doc/manuals/chapters/counters.adoc create mode 100644 doc/manuals/chapters/counters_generated.adoc diff --git a/doc/manuals/chapters/counters.adoc b/doc/manuals/chapters/counters.adoc new file mode 100644 index 000000000..7fbb10c6f --- /dev/null +++ b/doc/manuals/chapters/counters.adoc @@ -0,0 +1,4 @@ +[[counters]] +== Counters + +include::./counters_generated.adoc[] diff --git a/doc/manuals/chapters/counters_generated.adoc b/doc/manuals/chapters/counters_generated.adoc new file mode 100644 index 000000000..d55df072f --- /dev/null +++ b/doc/manuals/chapters/counters_generated.adoc @@ -0,0 +1,76 @@ +// autogenerated by show asciidoc counters +These counters and their description based on OsmoBSC (OsmoBSC). + +// generating tables for rate_ctr_group +// rate_ctr_group table E1 Input subsystem +.e1inp - E1 Input subsystem +[options="header"] +|=== +| Name | Reference | Description +| hdlc:abort | <> | HDLC abort +| hdlc:bad_fcs | <> | HLDC Bad FCS +| hdlc:overrun | <> | HDLC Overrun +| alarm | <> | Alarm +| removed | <> | Line removed +|=== +// rate_ctr_group table base station controller +.bsc - base station controller +[options="header"] +|=== +| Name | Reference | Description +| chreq:total | <> | Received channel requests. +| chreq:no_channel | <> | Sent to MS no channel available. +| handover:attempted | <> | Received handover attempts. +| handover:no_channel | <> | Sent no channel available responses. +| handover:timeout | <> | Count the amount of timeouts of timer T3103. +| handover:completed | <> | Received handover completed. +| handover:failed | <> | Receive HO FAIL messages. +| paging:attempted | <> | Paging attempts for a MS. +| paging:detached | <> | Counts the amount of paging attempts which couldn't sent out any paging request because no responsible bts found. +| paging:completed | <> | Paging successful completed. +| paging:expired | <> | Paging Request expired because of timeout T3113. +| chan:rf_fail | <> | Received a RF failure indication from BTS. +| chan:rll_err | <> | Received a RLL failure with T200 cause from BTS. +| bts:oml_fail | <> | Received a TEI down on a OML link. +| bts:rsl_fail | <> | Received a TEI down on a OML link. +| bts:codec_amr_f | <> | Count the usage of AMR/F codec by channel mode requested. +| bts:codec_amr_h | <> | Count the usage of AMR/H codec by channel mode requested. +| bts:codec_efr | <> | Count the usage of EFR codec by channel mode requested. +| bts:codec_fr | <> | Count the usage of FR codec by channel mode requested. +| bts:codec_hr | <> | Count the usage of HR codec by channel mode requested. +|=== +// rate_ctr_group table mobile switching center +.msc - mobile switching center +[options="header"] +|=== +| Name | Reference | Description +| loc_update_type:attach | <> | Received location update imsi attach requests. +| loc_update_type:normal | <> | Received location update normal requests. +| loc_update_type:periodic | <> | Received location update periodic requests. +| loc_update_type:detach | <> | Received location update detach indication. +| loc_update_resp:failed | <> | Rejected location updates. +| loc_update_resp:completed | <> | Successful location updates. +| sms:submitted | <> | Received a RPDU from a MS (MO). +| sms:no_receiver | <> | Counts SMS which couldn't routed because no receiver found. +| sms:delivered | <> | Global SMS Deliver attempts. +| sms:rp_err_mem | <> | CAUSE_MT_MEM_EXCEEDED errors of MS responses on a sms deliver attempt. +| sms:rp_err_other | <> | Other error of MS responses on a sms delive attempt. +| sms:deliver_unknown_error | <> | Unknown error occured during sms delivery. +| call:mo_setup | <> | Received setup requests from a MS to init a MO call. +| call:mo_connect_ack | <> | Received a connect ack from MS of a MO call. Call is now succesful connected up. +| call:mt_setup | <> | Sent setup requests to the MS (MT). +| call:mt_connect | <> | Sent a connect to the MS (MT). +| call:active | <> | Count total amount of calls that ever reached active state. +| call:complete | <> | Count total amount of calls which got terminated by disconnect req or ind after reaching active state. +| call:incomplete | <> | Count total amount of call which got terminated by any other reason after reaching active state. +|=== +// generating tables for osmo_stat_items +// generating tables for osmo_counters +// ungrouped osmo_counters +.ungrouped osmo counters +[options="header"] +|=== +| Name | Reference | Description +| msc.active_calls | <> | +|=== + diff --git a/doc/manuals/osmobsc-usermanual.adoc b/doc/manuals/osmobsc-usermanual.adoc index b455897b3..2ff985da0 100644 --- a/doc/manuals/osmobsc-usermanual.adoc +++ b/doc/manuals/osmobsc-usermanual.adoc @@ -13,6 +13,8 @@ include::chapters/running.adoc[] include::chapters/control.adoc[] +include::chapters/counters.adoc[] + include::../common/chapters/vty.adoc[] include::../common/chapters/logging.adoc[] -- cgit v1.2.3 From 9d0e3a7f2d9ce0cca634a0bf9dbf94327f680408 Mon Sep 17 00:00:00 2001 From: Neels Hofmeyr Date: Thu, 7 Dec 2017 19:30:38 +0100 Subject: OsmoBSC: update overview to explain both SCCPlite and SCCP/M3UA Change-Id: I1f105b3febd4f99f4491e217ff1b1d0b28912980 --- doc/manuals/chapters/overview.adoc | 168 ++++++++++++++++++++----------------- 1 file changed, 91 insertions(+), 77 deletions(-) diff --git a/doc/manuals/chapters/overview.adoc b/doc/manuals/chapters/overview.adoc index 3bb22ccc0..9b619fb24 100644 --- a/doc/manuals/chapters/overview.adoc +++ b/doc/manuals/chapters/overview.adoc @@ -7,18 +7,65 @@ aspects of configuring and running the OsmoBSC. [[intro_overview]] === About OsmoBSC -OsmoBSC is one particular version of the OpenBSC software suite. +OsmoBSC is the Osmocom implementation of a Base Station Controller. It +implements: -Unlike the highly integrated OmsoNITB, OsmoBSC implements a more classic -GSM Base Station Controller with A-bis interface towards BTSs and A -interface towards a MSC. +- an 'A-bis' interface towards BTSs and +- an 'A' interface towards an MSC. It is important to be aware that there are + two variants of the 'A' interface, see <>. -The difference between classic GSM network architecture and -the OsmoNITB based GSM network architecture is illustrated in -<> and <>. +=== Software Components + +OsmoBSC contains a variety of different software components, which +we'll briefly describe in this section. + +==== A-bis Implementation + +OsmoBSC implements the ETSI/3GPP specified A-bis interface, including TS 08.56 +(LAPD), TS 08.58 (RSL) and TS 12.21 (OML). In addition, it supports a variety +of vendor-specific extensions and dialects in order to communicate with BTSs +from Siemens, Nokia, Ericsson, ip.access, Octasic and sysmocom, as well as +various USRP based BTS implementations, using OsmoBTS and OsmoTRX (like the +Ettus B200 series, the Fairwaves XTRX or the LimeSDR, to name a few). + +For more information, see <> and <>. + +[[a-interface]] +==== A Implementation + +OsmoBSC implements a sub-set of the GSM A interface as specified in TS 08.08 +(BSSAP) and TS 04.08 (DTAP). + +Osmocom offers two variants of the 'A' interface's protocol stacking: -[[fig-gsm-classic]] -.Classic GSM network architecture (simplified) +- 'A/SCCPlite' +- 'A/SCCP/M3UA' + +Traditionally, OsmoBSC only implemented the A/SCCPlite protocol, but since a +proper M3UA implementation is available from 'libosmo-sigtran' +('libosmo-sccp.git'), the stock OsmoBSC now supports only A/SCCP/M3UA. (The +idea is that SCCPlite support may be added to libosmo-sigtran at some point +in the future, after which the new `osmo-bsc` would support both variants of +the A interface.) + +The difference between an A/SCCPlite and A/SCCP/M3UA is illustrated in +<> and <>. + +===== A/SCCPlite + +Unlike classic A interface implementations for E1 interfacs, +`osmo-bsc-sccplite` implements a variant of encapsulating the A interface over +IP. To do so, the SCCP messages are wrapped in an IPA multiplex and then +communicated over TCP. The audio channels are mapped to RTP streams. + +This protocol stacking is sometimes called "SCCPlite". + +At the time of writing, if you would like to use the old A/SCCPlite protocol, +look for binary packages named `osmo-bsc-sccplite`, or compile `osmo-bsc` from +the 'openbsc.git' repository. + +[[fig-sccplite]] +.`osmo-bsc-sccplite` operation using 'A/SCCPlite' [graphviz] ---- digraph G { @@ -29,26 +76,37 @@ digraph G { MS3 [label="MS"]; BTS0 [label="BTS"]; BTS1 [label="BTS"]; - BSC; - MSC [label="MSC/VLR"]; - HLR [label="HLR/AUC"]; - EIR; - SMSC; - MS0->BTS0 [label="Um"]; - MS1->BTS0 [label="Um"]; - MS2->BTS1 [label="Um"]; - MS3->BTS1 [label="Um"]; - BTS0->BSC [label="Abis"]; - BTS1->BSC [label="Abis"]; - BSC->MSC [label="A"]; - MSC->HLR [label="C"]; - MSC->EIR [label="F"]; - MSC->SMSC; + BSC [label="OsmoBSC-SCCPlite"]; + MSC [label="3rd party MSC"]; + {MS0,MS1}->BTS0 [label="Um"]; + {MS2,MS3}->BTS1 [label="Um"]; + {BTS0,BTS1}->BSC [label="Abis\nTCP\nIP"]; + BSC->MSC [label="A\nSCCP\nTCP\nIP"]; } ---- -[[fig-gsm-nitb]] -.GSM system architecture using OsmoNITB +===== A/SCCP/M3UA + +The default OsmoBSC's A interface uses the M3UA variant of SIGTRAN protocol +stacking: + +|===== +|A +|SCCP +|M3UA +|SCTP +|IP +|===== + +To use the now-default A/SCCP/M3UA protocol, look for binary packages named +`osmo-bsc`, or compile `osmo-bsc` from the 'osmo-bsc.git' repository. It is +recommended to use the M3UA variant, which is required to operate with OsmoMSC. + +To route SCCP/M3UA messages between OsmoBSC and and MSC, an STP instance like +OsmoSTP is required. + +[[fig-sccp-m3ua]] +.`osmo-bsc` operation using 'A/SCCP/M3UA' [graphviz] ---- digraph G { @@ -59,60 +117,16 @@ digraph G { MS3 [label="MS"]; BTS0 [label="BTS"]; BTS1 [label="BTS"]; - EXTMNCC [label="Linux Call Router / SoftSwitch / PBX\n(optional)"]; - MS0->BTS0 [label="Um"]; - MS1->BTS0 [label="Um"]; - MS2->BTS1 [label="Um"]; - MS3->BTS1 [label="Um"]; - BTS0->BSC [label="Abis"]; - BTS1->BSC [label="Abis"]; - subgraph cluster_nitb { - label = "OsmoNITB"; - BSC; - MSC [label="MSC/VLR"]; - SMSC; - EIR; - HLR [label="HLR/AUC"]; - BSC->MSC; - MSC->HLR; - MSC->EIR; - MSC->SMSC; - } - MSC -> EXTMNCC [label="external MNCC"]; + BSC [label="OsmoBSC"]; + STP [label="OsmoSTP"]; + MSC [label="OsmoMSC\n(or 3rd-party MSC)"]; + {MS0,MS1}->BTS0 [label="Um"]; + {MS2,MS3}->BTS1 [label="Um"]; + {BTS0,BTS1}->BSC [label="Abis\nTCP\nIP"]; + BSC->STP->MSC [label="A\nSCCP\nM3UA\nSCTP\nIP"]; } ---- - -=== Software Components - -OsmoBSC contains a variety of different software components, which -we'll quickly describe in this section. - -==== A-bis Implementation - -OsmoBSC implements the ETSI/3GPP specified A-bis interface, including -TS 08.56 (LAPD), TS 08.58 (RSL) and TS 12.21 (OML). In addition, it -supports a variety of vendor-specific extensions and dialects in order -to communicate with BTSs from Siemens, Nokia, Ericsson, ip.access and -sysmocom. - -For more information, see <> and <>. - -==== A Implementation - -OsmoBSC implements a minimal sub-set of the GSM A interface as specified -in TS 08.08. - -Unlike classic A interface implementations for E1 interfacs, OsmoBSC -implements a variant of encapsulating the A interface over IP. To do -so, the SCCP messages are wrapped in an IPA multiplex and then -communicated over TCP. The audio channels are mapped to RTP streams. - -This protocol stacking is sometimes called "SCCPlite". - -For more information, see <>. - - ==== BSC Implementation The BSC implementation covers the classic functionality of a GSM Base -- cgit v1.2.3 From d22e31fc9b0639b87c1b394286492549b433b0e8 Mon Sep 17 00:00:00 2001 From: Neels Hofmeyr Date: Thu, 7 Dec 2017 19:41:54 +0100 Subject: common / OsmoBSC: drop unused alink.adoc Change-Id: Ia3219359be891c161d20eccb7bbcb65af35ef42b --- doc/manuals/chapters/alink.adoc | 15 --------------- doc/manuals/osmobsc-usermanual.adoc | 2 -- 2 files changed, 17 deletions(-) delete mode 100644 doc/manuals/chapters/alink.adoc diff --git a/doc/manuals/chapters/alink.adoc b/doc/manuals/chapters/alink.adoc deleted file mode 100644 index 0321c0e02..000000000 --- a/doc/manuals/chapters/alink.adoc +++ /dev/null @@ -1,15 +0,0 @@ -== A-link including SCCP/BSSAP/DTAP - -OsmoBSC implements a minimal sub-set of the GSM A interface as specified -in TS 08.08. - -Unlike classic A interface implementations for E1 interfaces, OsmoBSC -implements a variant of encapsulating the A interface over IP. To do -so, the SCCP messages are wrapped in an IPA multiplex and then -communicated over TCP. The audio channels are mapped to RTP streams. - -This protocol stacking is sometimes called "SCCPlite". - -=== - -FIXME diff --git a/doc/manuals/osmobsc-usermanual.adoc b/doc/manuals/osmobsc-usermanual.adoc index 2ff985da0..e3eadafbb 100644 --- a/doc/manuals/osmobsc-usermanual.adoc +++ b/doc/manuals/osmobsc-usermanual.adoc @@ -27,8 +27,6 @@ include::../common/chapters/bsc.adoc[] include::../common/chapters/abis.adoc[] -#include::../common/chapters/alink.adoc[] - include::../common/chapters/control_if.adoc[] include::../common/chapters/cell-broadcast.adoc[] -- cgit v1.2.3 From 3a6ad2a2a22b13cc2d9d6b3d873032f187aeae2c Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Thu, 21 Dec 2017 20:57:27 +0100 Subject: add message sequence chart MS/BTS/BSC/MSC for 3GPP aoIP MO call Change-Id: I7e41234cfe1483bb73589dc959851a54f9aafa36 --- doc/manuals/message-sequences/mo_call-abis_a.msc | 146 +++++++++++++++++++++++ 1 file changed, 146 insertions(+) create mode 100644 doc/manuals/message-sequences/mo_call-abis_a.msc diff --git a/doc/manuals/message-sequences/mo_call-abis_a.msc b/doc/manuals/message-sequences/mo_call-abis_a.msc new file mode 100644 index 000000000..4597ab126 --- /dev/null +++ b/doc/manuals/message-sequences/mo_call-abis_a.msc @@ -0,0 +1,146 @@ +msc { + hscale=2; + ms [label="MS"], + bts [label="BTS"], + bsc_l [label="BSC(lchan SDCCH)"], + bsc_l2 [label="BSC(lchan TCH)"], + bsc [label="BSC"], + mgw [label="MGW@BSC"], + m_sc [label="MSC"]; + + ...; + --- [label="MS Requests dedicated channel"]; + ms -> bts [label="RACH: REQ"]; + bts -> bsc [label="RSL Cchan CHAN RQD"]; + bsc_l <= bsc [label="allocate lchan (RR IMM ASS)", textcolor="red", linecolor="red"]; + bts <- bsc_l [label="RSL Dchan (SDCCH) CHAN ACT"]; + bts -> bsc_l [label="RSL Dchan (SDCCH) CHAN ACT ACK"]; + bts <- bsc_l [label="RSL Cchan IMM ASS (RR IMM ASS)"]; + bsc_l box bsc_l [label="Start T3101"]; + ms <- bts [label="AGCH: RR IMM ASS"]; + --- [label="MS Establishes SDCCH"]; + ms -> bts [label="SDCCH: SABM (CM SERV REQ)"]; + ms <- bts [label="SDCCH: UA (CM SERV REQ)"]; + bts -> bsc_l [label="RSL RLL (SDCCH, SAPI0, DCCH) EST IND", textcolor="green", linecolor="green"]; + bsc_l box bsc_l [label="Stop T3101"]; + bsc_l => bsc [label="GSCON_EV_A_CONN_REQ", textcolor="red", linecolor="red"]; + bsc -> m_sc [label="SCCP CR (BSSMAP COMPL L3 (CM SERV REQ))"]; + bsc <- m_sc [label="SCCP CC"]; + bsc -> bsc [label="GSCON_EV_A_CONN_CFM", textcolor="red", linecolor="red"]; + ms box m_sc [label="Authentication, MM info, ..."]; + bsc <- m_sc [label="SCCP DT1 (DTAP (CM SERV ACK)"]; + bsc -> bsc [label="GSCON_EV_MT_DTAP", textcolor="red", linecolor="red"]; + bsc_l <= bsc [label="lchan_submit_dtap(CM SERV ACK)", textcolor="red", linecolor="red"]; + bts <- bsc_l [label="RSL RLL (SDCCH) DATA REQ (CM SERV ACK)", textcolor="green", linecolor="green"]; + ms <- bts [label="SDCCH: I (CM SERV ACK)"]; + ms -> bts [label="SDCCH: I (CC SETUP)"]; + bts -> bsc_l [label="RSL RLL (SDCCH) DATA IND (CC SETUP)", textcolor="green", linecolor="green"]; + bsc_l -> bsc [label="GSCON_EV_MO_DTAP", textcolor="red", linecolor="red"]; + bsc -> m_sc [label="SCCP DT1 (DTAP (CC SETUP))"]; + ...; + + --- [label="MSC assigns Voice Channel (TCH)"]; + bsc <- m_sc [label="SCCP DT1 (BSSMAP ASSIGNMENT CMD)"]; + bsc -> bsc [label="GSCON_EV_A_ASSIGNMENT_CMD", textcolor="red", linecolor="red"]; + bsc_l2 <= bsc [label="allocate lchan", textcolor="red", linecolor="red"]; + bts <- bsc_l2 [label="RSL Dchan (TCH) CHAN ACT"]; + bts -> bsc_l2 [label="RSL Dchan (TCH) CHAN ACT ACK"]; + bts <- bsc_l [label="RSL RLL (SDDCH) DATA REQ (RR ASSIGNMENT CMD)", textcolor="green", +linecolor="green"]; + bsc_l2 box bsc_l2 [label="Start T3107"]; + ms <- bts [label="SDCCH: I (RR ASSIGNMENT CMD)"]; + ms box ms [label="local-end RLL release", textcolor="green", linecolor="green"]; + bts -> bsc_l [label="RSL RLL (SDCCH) REL IND", textcolor="gray", linecolor="green"]; + bsc_l => bsc [label="GSCON_EV_RLL_REL_IND", textcolor="gray", linecolor="red"]; + bts -> bsc_l [label="RSL Dchan (SDCCH) CONN FAIL IND", textcolor="gray", linecolor="green"]; + bsc_l => bsc [label="GSCON_EV_CONN_FAIL", textcolor="gray", linecolor="red"]; + bsc_l box bsc_l [label="BSC must ignore failures on old channel"]; + ms -> bts [label="TCH: SABM (RR ASSIGNMENT CMPL)"]; + ms <- bts [label="TCH: UA (RR ASSIGNMENT CMPL)"]; + bts -> bsc_l2 [label="RSL RLL (TCH, SAPI0, DCCH) EST IND", textcolor="green", linecolor="green"]; + bsc_l2 box bsc_l2 [label="Stop T3107"]; + bsc_l2 => bsc [label="GSCON_EV_RR_ASS_COMPL", textcolor="red", linecolor="red"]; + + bsc_l <= bsc [label="release_lchan(SDCCH)", textcolor="red", linecolor="red"]; + bts box bsc_l [label="local-end RLL release", textcolor="green", linecolor="green"]; + bts <- bsc_l [label="RSL Dchan (SDCCH) RF CHAN REL"]; + bts <- bsc_l [label="RSL RLL (SDCCH, SAPI0, DCCH) REL REQ", textcolor="gray", linecolor="green"]; + bts <- bsc_l [label="RSL DChan (SDCCH) DEACTIVATE SACCH", textcolor="gray", linecolor="black"]; + bts -> bsc_l [label="RSL RLL (SDCCH, SAPI0, DCCH) RF FAIL IND", textcolor="gray", linecolor="green"]; + bts -> bsc_l [label="RSL Dchan (SDCCH, SAPI0, DCCH) RF CHAN REL ACK"]; + + # connect BTS RTP with BSC-MGW RTP + --- [label="BSC configures RTP on BTS and both sides of MGW"]; + bts <- bsc [label="RSL IPA CRCX", textcolor="blue", linecolor="blue"]; + bts box bts [label="Bind to BTS-local RTP Port (1000)", textcolor="blue", linecolor="blue"]; + bts -> bsc [label="IPA CRCX ACK (BTS:1000)", textcolor="blue", linecolor="blue"]; + bsc -> mgw [label="MGCP CRCX rtpbridge/2@mgw (BTS:1000)", textcolor="blue", linecolor="blue"]; + mgw box mgw [label="Bind to MGW-local RTP Port (2000)\nConnect to BTS:1000", textcolor="blue", linecolor="blue"]; + bsc <- mgw [label="MGCP CRCX rtpbridge/2@mgw OK (MGW:2000)", textcolor="blue", linecolor="blue"]; + bts <- bsc [label="IPA MDCX (MGW:2000)", textcolor="blue", linecolor="blue"]; + bts box bts [label="Connect RTP socket to remote (MGW) RTP Port", textcolor="blue", linecolor="blue"]; + bts -> bsc [label="IPA MDCX ACK", textcolor="blue", linecolor="blue"]; + bsc >> mgw [label="MGCP MDCX rtpbridge/2@mgw", textcolor="gray", linecolor="gray"]; + bsc << mgw [label="MGCP MDCX rtpbridge/2@mgw OK", textcolor="gray", linecolor="gray"]; + ...; + + --- [label="BSC finally can report successful TCH assignment"]; + bsc -> m_sc [label="SCCP DT1 (BSSMAP ASSGN CMPL (3GPP AoIP MGW:3000))"]; + m_sc box m_sc [label="Connect remote RTP to MGW addr from ASSGN CMPL"]; + ...; + + mgw <-> m_sc [label="RTP Audio MGW:3000 MSC:4000", textcolor="blue", linecolor="blue"]; + bts <-> mgw [label="RTP Audio BTS:1000 MGW:2000", textcolor="blue", linecolor="blue"]; + ms <-> bts [label="Um Audio (bidirectional)", textcolor="blue", linecolor="blue"]; + ms <-> m_sc [label="DTAP CC ALERTING"]; + ...; + + --- [label="Further signalling in parallel with RTP (simplified)"]; + ms <- m_sc [label="DTAP CC CONNECT"]; + ms -> m_sc [label="DTAP CC CONNECT ACK"]; + --- [label="Voice Call in Progress"]; + ...; + --- [label="B-end hangs up"]; + ms <- m_sc [label="DTAP CC DISCONNET"]; + ms <- m_sc [label="DTAP CC RELEASE"]; + ms <- m_sc [label="DTAP CC RELEASE COMPL"]; + ...; + bsc <- m_sc [label="SCCP DT1 (BSSMAP CLEAR CMD)"]; + bsc -> bsc [label="GSCON_EV_A_CLEAR_CMD", textcolor="red", linecolor="red"]; + --- [label="BSC must release terrestrial resoures before reporting CLEAR COMPLETE"]; + mgw <- bsc [label="MGCP DLCX rtpbridge/2@mgw", textcolor="blue", linecolor="blue"]; + mgw box mgw [label="Release MSC-facing local RTP port (3000)", textcolor="blue", linecolor="blue"]; + mgw -> bsc [label="MGCP DLCX rtpbridge/2@mgw OK", textcolor="blue", linecolor="blue"]; + + mgw <- bsc [label="MGCP DLCX rtpbridge/2@mgw", textcolor="blue", linecolor="blue"]; + mgw box mgw [label="Release BTS-facing local RTP port (2000)", textcolor="blue", linecolor="blue"]; + mgw -> bsc [label="MGCP DLCX rtpbridge/2@mgw OK", textcolor="blue", linecolor="blue"]; + + bts <- bsc [label="IPA DLCX", textcolor="blue", linecolor="blue"]; + bts box bts [label="Release BTS-local RTP port (1000)", textcolor="blue", linecolor="blue"]; + bts -> bsc [label="IPA DLCX OK", textcolor="blue", linecolor="blue"]; + + bsc -> bsc [label="GSCON_EV_RSL_CLEAR_COMPL", textcolor="red", linecolor="red"]; + bsc -> m_sc [label="SCCP DT1 (BSSMAP CLEAR COMPL)"]; + bsc <- m_sc [label="SCCP RLSD"]; + bsc -> bsc [label="GSCON_EV_A_DISC_IND", textcolor="red", linecolor="red"]; + bsc -> m_sc [label="SCCP RLC"]; + + --- [label="BSC releases radio resources after CLEAR COMPLETE"]; + bsc_l2 <= bsc [label="release_lchan(TCH)", textcolor="red", linecolor="red"]; + bts <- bsc_l2 [label="RSL RLL (TCH, SAPI0, DCCH) DATA REQ (RR CHANNEL RELEASE)", textcolor="green", linecolor="green"]; + bsc_l2 box bsc_l2 [label="Start T3109"]; + bts <- bsc_l2 [label="RSL Dchan (TCH) DEACTIVATE SACCH"]; + ms <- bts [label="TCH: I (RR CHANNEL RELEASE)"]; + ms -> bts [label="TCH: DISC (RR CHANNEL RELEASE)"]; + bts -> bsc_l2 [label="RSL RLL (TCH, SAPI0, DCCH) REL IND", textcolor="green", linecolor="green"]; + bsc_l2 => bsc [label="GSCON_EV_RLL_REL_IND", textcolor="red", linecolor="red"]; + bsc_l2 box bsc_l2 [label="Stop T3109; Start T3111"]; + # optional: Conn Fail? + bts <- bsc_l2 [label="RSL Dchan (TCH, SAPI0, DCCH) RF CHAN REL"]; + bts -> bsc_l2 [label="RSL Dchan (TCH, SAPI0, DCCH) RF CHAN REL ACK"]; + bsc_l2 box bsc_l2 [label="T3111 timeout: Channel can be used again"]; + + ...; + +} -- cgit v1.2.3 From 9f157571ad20aa61e20a064e336b1fb11c4ce05f Mon Sep 17 00:00:00 2001 From: Neels Hofmeyr Date: Tue, 6 Mar 2018 14:59:00 +0100 Subject: OsmoBSC: update VTY reference This is the first update since the libosmocore changes to the 'show online-help' generated output. Hence the produced document now benefits from the structural improvements: - not repeating common commands for every node; - using section names that match the VTY prompt. Update bsc_vty_additions.xml to match the new node ID scheme. Change-Id: I0d856563eee88527fda4c6940aa6cea779175aaa --- doc/manuals/vty/bsc_vty_additions.xml | 8 +- doc/manuals/vty/bsc_vty_reference.xml | 7847 ++++++++++++++++++++------------- 2 files changed, 4790 insertions(+), 3065 deletions(-) diff --git a/doc/manuals/vty/bsc_vty_additions.xml b/doc/manuals/vty/bsc_vty_additions.xml index 2764eb8f9..f62f8b1c0 100644 --- a/doc/manuals/vty/bsc_vty_additions.xml +++ b/doc/manuals/vty/bsc_vty_additions.xml @@ -1,13 +1,9 @@ - - - MSC Connection Commands + This node allows to configure the MSC connection related settings. - - - BSC Commands + This node allows to configure the BSC connection related settings. diff --git a/doc/manuals/vty/bsc_vty_reference.xml b/doc/manuals/vty/bsc_vty_reference.xml index 3b61b4235..29a61bcd1 100644 --- a/doc/manuals/vty/bsc_vty_reference.xml +++ b/doc/manuals/vty/bsc_vty_reference.xml @@ -1,3059 +1,4788 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - \ No newline at end of file + + + Common Commands + These commands are available on all VTY nodes. They are listed here only once, to unclutter the VTY reference. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + view + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + enable + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + config + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + config-log + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + config-stats + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + config-line + + + + + + + + + + + + + + + + + + + + config-e1_input + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + config-ctrl + + + + + + + + + config-cs7 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + config-cs7-as + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + config-cs7-asp + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + config-cs7-sccpaddr + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + config-cs7-sccpaddr-gt + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + config-net + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + config-net-bts + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + config-net-bts-trx + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + config-net-bts-trx-ts + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + oml + + + + + + + + + + + + + + + + + config-msc + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + om2k + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + om2k-con-group + + + + + + + + + + + + + + + + + + + + + + + + + config-bsc + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + -- cgit v1.2.3 From 8a357681d2737a409e5d897702ba020995b2b945 Mon Sep 17 00:00:00 2001 From: Harald Welte Date: Sat, 17 Mar 2018 14:15:38 +0100 Subject: vty-ref: Update URI of docbook 5.0 schema ... to match the /etc/xml/catalog file on debian (no "www" in hostname) Change-Id: Id9f3579c7f2bc3af13fe30b5268f249b6f59ed0d --- doc/manuals/osmobsc-vty-reference.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/manuals/osmobsc-vty-reference.xml b/doc/manuals/osmobsc-vty-reference.xml index 6e60357c7..6d993b458 100644 --- a/doc/manuals/osmobsc-vty-reference.xml +++ b/doc/manuals/osmobsc-vty-reference.xml @@ -3,8 +3,8 @@ ex:ts=2:sw=42sts=2:et -*- tab-width: 4; c-basic-offset: 4; indent-tabs-mode: nil -*- --> - ]> -- cgit v1.2.3 From 8c14a942d2c08cc59827b805105794eb576ff2d3 Mon Sep 17 00:00:00 2001 From: Neels Hofmeyr Date: Fri, 21 Sep 2018 14:00:08 +0200 Subject: bsc: document handover Add chapter "Handover", explaining: - intra- and - inter-BSC handover, - HO algorithm 1 and - algorithm 2 - new neighbor configuration Adjust copyright, add revision and add me as author. Change-Id: I7afb3f66c98abda07fc8acc76e00c46091fe55e2 --- doc/manuals/Makefile | 2 +- doc/manuals/chapters/handover.adoc | 552 ++++++++++++++++++++++++++++ doc/manuals/chapters/handover_inter_bsc.dot | 35 ++ doc/manuals/chapters/handover_intra_bsc.dot | 31 ++ doc/manuals/osmobsc-usermanual-docinfo.xml | 22 +- doc/manuals/osmobsc-usermanual.adoc | 2 + 6 files changed, 642 insertions(+), 2 deletions(-) create mode 100644 doc/manuals/chapters/handover.adoc create mode 100644 doc/manuals/chapters/handover_inter_bsc.dot create mode 100644 doc/manuals/chapters/handover_intra_bsc.dot diff --git a/doc/manuals/Makefile b/doc/manuals/Makefile index 153348258..b9f50d0d9 100644 --- a/doc/manuals/Makefile +++ b/doc/manuals/Makefile @@ -2,7 +2,7 @@ TOPDIR = .. ASCIIDOC = osmobsc-usermanual.adoc osmux-reference.adoc aoip-mgw-options.adoc include $(TOPDIR)/build/Makefile.asciidoc.inc -osmobsc-usermanual.pdf: chapters/*.adoc +osmobsc-usermanual.pdf: chapters/*.adoc chapters/*.dot aoip-mgw-options.pdf: aoip-mgw-options.adoc mgw/*.msc VTY_REFERENCE = osmobsc-vty-reference.xml diff --git a/doc/manuals/chapters/handover.adoc b/doc/manuals/chapters/handover.adoc new file mode 100644 index 000000000..11206908b --- /dev/null +++ b/doc/manuals/chapters/handover.adoc @@ -0,0 +1,552 @@ +== Handover + +Handover is the process of moving a continuously used channel (lchan) from one +cell to another. Usually, that is an ongoing call, so that phones are able to +move across cell coverage areas without interrupting the voice transmission. + +A handover can + +- stay within one given cell (intra-cell, i.e. simply a new RR Assignment Command); +- occur between two cells that belong to the same BSS (intra-BSC, via RR Handover Command); +- cross BSS boundaries (inter-BSC, via BSSMAP handover procedures); +- move to another MSC (inter-MSC, inter-PLMN); +- move to another RAN type, e.g. from 2G to 3G (inter-RAT, inter-Radio-Access-Technology). + +The physical distance is by definition always very near, but handover +negotiation may range from being invisible to the MSC all the way to +orchestrating completely separate RAN stacks. + +OsmoBSC currently supports handover within one BSS and between separate BSS. +Whether inter-MSC is supported depends on the MSC implementation (to the BSC, +inter-MSC handover looks identical to inter-BSC handover). Inter-RAT handover +is currently not implemented. + +At the time of writing, OsmoMSC's inter-BSC handover support is not complete +yet, so OsmoBSC can perform handover between separate BSS only in conjunction +with a 3rd party MSC implementation. + +.Handover support in Osmocom at the time of writing +[cols="^,^,^,^,^"] +|==== +| | intra-BSC HO (local BSS) | inter-BSC HO (remote BSS) | inter-MSC HO | inter-RAT HO +| OsmoBSC | rxlev, load-based | rxlev | (planned) | - +| OsmoMSC | (not involved, except for codec changes) | (planned) | (planned) | - +|==== + + +=== How Handover Works + +This chapter generally explains handover operations between 2G cells. + +==== Internal / Intra-BSC Handover + +The BSS is configured to know which cell is physically adjacent to which other +cells, its "neighbors". On the MS/BTS/BSS level, individual cells are +identified by ARFCN+BSIC (frequency + 6-bit identification code). + +Each BTS is told by the BSC which cells identified by ARFCN+BSIC are its +adjacent cells. Via System Information, each MS receives a list of these +ARFCN+BSIC, and the MS then return measurements of reception levels. + +The BSC is the point of decision whether to do handover or not. This can be a +hugely complex combination of heuristics, knowledge of cell load and codec +capabilites. The most important indicator for handover though is: does an MS +report a neighbor with a better signal than the current cell? See +<>. + +[[intra_bsc_ho_dot]] +.Intra-BSC Handover stays within the BSS (shows steps only up to activation of the new lchan -- this would be followed by an RR Handover Command, RACH causing Handover Detection, Handover Complete, ...) +[graphviz] +---- +include::handover_intra_bsc.dot[] +---- + +If the BSC sees the need for handover, it will: + +- activate a new lchan (with a handover reference ID), +- send an RR Handover Command to the current lchan, and +- wait for the MS to send a Handover RACH to the new lchan ("Handover Detect"). +- The RTP stream then is switched over to the new lchan, +- an RSL Establish Indication is expected on the new lchan, +- and the old lchan is released. + +Should handover fail at any point, e.g. the new lchan never receives a RACH, or +the MS reports a Handover Failure, then the new lchan is simply released again, +and the old lchan remains in use. If the RTP stream has already been switched +over to the new lchan, it may actually be switched back to the old lchan. + +This is simple enough if the new cell is managed by the same BSC: the OsmoMGW +is simply instructed to relay the BTS-side of the RTP stream to another IP +address and port, and the BSC continues to forward DTAP to the MSC +transparently. The operation happens completely within the BSS. If the voice +codec has remained unchanged, the MSC/MNCC may not even be notified that +anything has happened at all. + +==== External / Inter-BSC Handover + +If the adjacent target cell belongs to a different BSS, the RR procedure for +handover remains the same, but we need to tell the _remote_ BSC to allocate the +new lchan. + +The only way to reach the remote BSC is via the MSC, so the MSC must be able +to: + +- identify which other BSC we want to talk to, +- forward various BSSMAP Handover messages between old and new BSC, +- redirect the core-side RTP stream to the new BSS at the appropriate time, +- and must finally BSSMAP Clear the connection to the old BSS to conclude the + inter-BSC handover. + +[[inter_bsc_ho_dot]] +.Inter-BSC Handover requires the MSC to relay between two BSCs (shows steps only up to the BSSMAP Handover Command -- this would be followed by an RR Handover Command, RACH causing Handover Detection, Handover Complete, ...) +[graphviz] +---- +include::handover_inter_bsc.dot[] +---- + +The first part, identifying the remote BSC, is not as trivial as it sounds: as +mentioned above, on the level of cell information seen by BTS and MS, the +neighbor cells are identified by ARFCN+BSIC. However, on the A-interface and in +the MSC, there is no knowledge of ARFCN+BSIC configurations, and instead each +cell is identified by a LAC and CI (Location Area Code and Cell Identifier). + +NOTE: There are several different cell identification types on the A-interface: +from Cell Global Identifier (MCC+MNC+LAC+CI) down to only LAC. OsmoBSC supports +most of these (see <>). For simplicity, this description +focuses on LAC+CI identification. + +The most obvious reason for using LAC+CI is that identical ARFCN+BSIC are +typically re-used across many cells of the same network operator: an operator +will have only very few ARFCNs available, and the 6bit BSIC opens only a very +limited range of distinction between cells. As long as each cell has no more +than one neighbor per given ARFCN+BSIC, these values can be re-used any number +of times across a network, and even between cells managed by one and the same +BSC. + +The consequence of this is that + +- the BSC needs to know which remote-BSS cells' ARFCN+BSIC correspond to + exactly which global LAC+CI, and +- the MSC needs to know which LAC+CI are managed by which BSC. + +In other words, each BSC requires prior knowledge about the cell configuration +of its remote-BSS neighbor cells, and the MSC requires prior knowledge about +each BSC's cell identifiers; i.e. these config items are spread reduntantly. + +=== Configuring Neighbors + +The most important step to enable handover in OsmoBSC is to configure each cell +with the ARFCN+BSIC identities of its adjacent neighbors -- both local-BSS and +remote-BSS. + +For a long time, OsmoBSC has offered configuration to manually enter the +ARFCN+BSIC sent out as neighbors on various System Information messages (all +`neighbor-list` related commands). This is still possible, however, +particularly for re-using ARFCN+BSIC within one BSS, this method will not work +well. + +With the addition of inter-BSC handover support, the new `neighbor` config item +has been added to the `bts` config, to maintain explicit cell-to-cell neighbor +relations, with the possibility to re-use ARFCN+BSIC in each cell. + +It is recommended to completely replace `neighbor-list` configurations with the +new `neighbor` configuration described below. + +[[neighbor_conf_list]] +.Overview of neighbor configuration on the `bts` config node +[frame="none",grid="none",cols="^10%,^10%,80%"] +|==== +| Local | Remote BSS | +| ✓ | | neighbor bts 5 +| ✓ | | neighbor lac 200 +| ✓ | | neighbor lac-ci 200 3 +| ✓ | | neighbor cgi 001 01 200 3 +| ✓ | ✓ | neighbor lac 200 arfcn 123 bsic 1 +| ✓ | ✓ | neighbor lac-ci 200 3 arfcn 123 bsic 1 +| ✓ | ✓ | neighbor cgi 001 01 200 3 arfcn 123 bsic 1 +|==== + +==== Local-BSS Neighbors + +Local neighbors can be configured by just the local BTS number, or by LAC+CI, +or any other supported A-interface type cell identification; also including the +ARFCN+BSIC is optional, it will be derived from the local configuration if +omitted. + +OsmoBSC will log errors in case the configuration includes ambiguous ARFCN+BSIC +relations (when one given cell has more than one neighbor for any one +ARFCN+BSIC). + +Neighbor relations must be configured explicitly in both directions, i.e. each +cell has to name all of its neighbors, even if the other cell already has an +identical neighbor relation in the reverse direction. + +.Example: configuring neighbors within the local BSS in osmo-bsc.cfg, identified by local BTS number +---- +network + bts 0 + neighbor bts 1 + bts 1 + neighbor bts 0 +---- + +.Example: configuring neighbors within the local BSS in osmo-bsc.cfg, identified by LAC+CI +---- +network + + bts 0 + # this cell's LAC=23 CI=5 + location_area_code 23 + cell_identity 5 + # reference bts 1 + neighbor lac-ci 23 6 + + bts 1 + # this cell's LAC=23 CI=6 + location_area_code 23 + cell_identity 6 + # reference bts 0 + neighbor lac-ci 23 5 +---- + +It is allowed to include the ARFCN and BSIC of local neighbor cells, even +though that is redundant with the already known local configuration of the +other cell. The idea is to ease generating the neighbor configuration +automatically, since local-BSS and remote-BSS neighbors then share identical +configuration formatting. For human readability and maintainability, it may +instead be desirable to use the `neighbor bts <0-255>` format. + +.Example: configuring neighbors within the local BSS in osmo-bsc.cfg, redundantly identified by LAC+CI as well as ARFCN+BSIC +---- +network + + bts 0 + # this cell's LAC=23 CI=5 + location_area_code 23 + cell_identity 5 + # this cell's ARFCN=1 BSIC=1 + trx 0 + arfcn 1 + base_station_id_code 1 + # reference bts 1 + neighbor lac-ci 23 6 arfcn 2 bsic 2 + + bts 1 + # LAC=23 CI=6 + location_area_code 23 + cell_identity 6 + # this cell's ARFCN=2 BSIC=2 + trx 0 + arfcn 2 + base_station_id_code 2 + # reference bts 0 + neighbor lac-ci 23 5 arfcn 1 bsic 1 +---- + +If the cell identification matches a local cell, OsmoBSC will report errors if +the provided ARFCN+BSIC do not match. + +==== Remote-BSS Neighbors + +Remote-BSS neighbors _always_ need to be configured with full A-interface +identification _and_ ARFCN+BSIC, to allow mapping a cell's neighbor ARFCN+BSIC +to a _BSSMAP Cell Identifier_ (see 3GPP TS 48.008 3.1.5.1 Handover Required +Indication and 3.2.1.9 HANDOVER REQUIRED). + +.Example: configuring remote-BSS neighbors in osmo-bsc.cfg, identified by LAC+CI (showing both BSCs' configurations) +---- +# BSC Alpha's osmo-bsc.cfg +network + bts 0 + # this cell's LAC=23 CI=6 + location_area_code 23 + cell_identity 6 + # this cell's ARFCN=2 BSIC=2 + trx 0 + arfcn 2 + base_station_id_code 2 + # fully describe the remote cell by LAC+CI and ARFCN+BSIC + neighbor lac-ci 42 3 arfcn 1 bsic 3 + +# BSC Beta's osmo-bsc.cfg +network + bts 0 + # this cell's LAC=42 CI=3 + location_area_code 42 + cell_identity 3 + # this cell's ARFCN=1 BSIC=3 + trx 0 + arfcn 1 + base_station_id_code 3 + # fully describe the remote cell by LAC+CI and ARFCN+BSIC + neighbor lac-ci 23 6 arfcn 2 bsic 2 +---- + +NOTE: It is strongly recommended to stick to a single format for remote-BSS +neighbors' cell identifiers all across an OsmoBSC configuration; i.e. decide +once to use `lac`, `lac-ci` or `cgi` and then stick to that within a given +osmo-bsc.cfg. The reason is that the _Cell Identifier List_ sent in the _BSSMAP +Handover Required_ message must have one single cell identifier type for all +list items. Hence, to be able to send several alternative remote neighbors to +the MSC, the configured cell identifiers must be of the same type. If in doubt, +use the full CGI identifier everywhere. + +=== Configuring Handover Decisions + +For a long time, OsmoBSC has supported handover based on reception level +hysteresis (RXLEV) and distance (TA, Timing Advance), known has `algorithm 1`. + +Since 2018, OsmoBSC also supports a load-based handover decision algorithm, +known as `algorithm 2`, which also takes cell load, available codecs and +oscillation into consideration. Algorithm 2 had actually been implemented for +the legacy OsmoNITB program many years before the OsmoMSC split, but remained +on a branch, until it was forward-ported to OsmoBSC in 2018. + +.What handover decision algorithms take into account +[frame="none",grid="none",cols="^10%,^10%,80%"] +|==== +| algorithm 1 | algorithm 2 | +| ✓ | ✓| RXLEV +| ✓ | ✓| RXQUAL +| ✓ | ✓| TA (distance) +| ✓ | ✓| interference (good RXLEV, bad RXQUAL) +| | ✓| load (nr of free lchans, minimum RXLEV and RXQUAL) +| | ✓| penalty time to avoid oscillation +| | ✓| voice rate / codec bias +| ✓ | | inter-BSC: RXLEV hysteresis +| | ✓| inter-BSC: only below minimum RXLEV, RXQUAL +|==== + +==== Common Configuration + +Handover is disabled by default; to disable/enable handover, use `handover +(0|1)`. + +Once enabled, algorithm 1 is used by default; choose a handover algorithm with +`handover algorithm (1|2)`: + +---- +network + # Enable handover + handover 1 + + # Choose algorithm + handover algorithm 2 + + # Tweak parameters for algorithm 2 (optional) + handover2 min-free-slots tch/f 4 + handover2 penalty-time failed-ho 30 + handover2 retries 1 +---- + +All handover algorithms share a common configuration scheme, with an overlay of +three levels: + +* immutable compile-time default values, +* configuration on the `network` level for all cells, +* individual cells' configuration on each `bts` node. + +Configuration settings relevant for algorithm 1 start with `handover1`, for +algorithm 2 with `handover2`. + +The following example overrides the compile-time default for all cells, and +furthermore sets one particular cell on its own individual setting, for the +`min-free-slots tch/f` value: + +---- +network + handover2 min-free-slots tch/f 4 + bts 23 + handover2 min-free-slots tch/f 2 +---- + +The order in which these settings are issued makes no difference for the +overlay; i.e., this configuration is perfectly identical to the above, and the +individual cell's value remains in force: + +---- +network + bts 23 + handover2 min-free-slots tch/f 2 + handover2 min-free-slots tch/f 4 +---- + +Each setting can be reset to a default value with the `default` keyword. When +resetting an individual cell's value, the globally configured value is used. +When resetting the global value, the compile-time default is used (unless +individual cells still have explicit values configured). For example, this +telnet VTY session removes above configuration first from the cell, then from +the global level: + +---- +OsmoBSC(config)# network +OsmoBSC(config-net)# bts 23 +OsmoBSC(config-net-bts)# handover2 min-free-slots tch/f default +% 'handover2 min-free-slots tch/f' setting removed, now is 4 +OsmoBSC(config-net-bts)# exit +OsmoBSC(config-net)# handover2 min-free-slots tch/f default +% 'handover2 min-free-slots tch/f' setting removed, now is 0 +---- + +==== Handover Algorithm 1 + +Algorithm 1 takes action only when RR Measurement Reports are received from a +BTS. As soon as a neighbor's average RXLEV is higher than the current cell's +average RXLEV plus a hysteresis distance, handover is triggered. + +If a handover fails, algorithm 1 will again attempt handover to the same cell +with the next Measurement Report received. + +Configuration settings relevant for algorithm 1 start with `handover1`. For +further details, please refer to the OsmoBSC VTY Reference +(<>) or the telnet VTY online documentation. + +==== Handover Algorithm 2 + +Algorithm 2 is specifically designed to distribute load across cells. A +subscriber will not necessarily remain attached to the cell that has the best +RXLEV average, if that cell is heavily loaded and a less loaded neighbor is +above the minimum allowed RXLEV. + +Algorithm 2 also features penalty timers to avoid oscillation: for each +subscriber, if handover to a specific neighbor failed (for a configurable +number of retries), a holdoff timer prevents repeated attempts to handover to +that same neighbor. Several hold-off timeouts following specific situations are +configurable (see `handover2 penalty-time` configuration items). + +Configuration settings relevant for algorithm 2 start with `handover2`. For +further details, please refer to the OsmoBSC VTY Reference +<> or the telnet VTY online documentation. + +===== Load Distribution + +Load distribution is only supported by algorithm 2. + +Load distribution occurs: + +- explicitly: every N seconds, OsmoBSC considers all local cells and actively + triggers handover operations to reduce congestion, if any. See + `min-free-slots` below, and the `congestion-check` setting. + +- implicitly: when choosing the best neighbor candidate for a handover + triggered otherwise, a congested cell (in terms of `min-free-slots`) is only + used as handover target if there is no alternative that causes less cell + load. + +In either case, load distribution will only occur towards neighbor cells that +adhere to minimum reception levels and distance, see `min rxlev` and `max +distance`. + +Load distribution will take effect only for already established voice channels. +An MS will always first establish a voice call with its current cell choice; in +load situations, it might be moved to another cell shortly after that. +Considering the best neighbor _before_ starting a new voice call might be +desirable, but is currently not implemented. Consider that RXLEV/RXQUAL ratings +are averaged over a given number of measurement reports, so that the neighbor +ratings may not be valid/reliable yet during early call establishment. In +consequence, it is recommended to ensure a sufficient number of unused logical +channels at all times, though there is no single correct configuration for all +situations. + +Most important for load distribution are the `min-free-slots tch/f` and +`min-free-slots tch/h` settings. The default is zero, meaning _no_ load +distribution. To enable, set `min-free-slots` >= 1 for `tch/f` and/or `tch/h` +as appropriate. This setting refers to the minimum number of voice channels +that should ideally remain unused in each individual BTS at all times. + +NOTE: it is not harmful to configure `min-free-slots` for a TCH kind that is +not actually present. Such settings will simply be ignored. + +NOTE: the number of TCH/F timeslots corresponds 1:1 to the number indicated by +`min-free-slots tch/f`, because each TCH/F physical channel has exactly one +logical channel. In contrast, for each TCH/H timeslot, there are two logical +channels, hence `min-free-slots tch/h` corresponds to twice the number of TCH/H +timeslots configured per cell. In fact, a more accurate naming would have been +"min-free-lchans". + +Think of the `min-free-slots` setting as the threshold at which load +distribution is considered. If as many logical channels as required by this +setting are available in a given cell, only changes in RXLEV/RXQUAL/TA trigger +handover away from that cell. As soon as less logical channels remain free, the +periodical congestion check attempts to distribute MS to less loaded neighbor +cells. Every time, the one MS that will suffer the least RXLEV loss while still +reducing congestion will be instructed to move first. + +If a cell and its neighbors are all loaded past their `min-free-slots` +settings, the algorithmic aim is equal load: a load-based handover will never +cause the target cell to be more congested than the source cell. + +The min-free-slots setting is a tradeoff between immediate voice service +availability and optimal reception levels. A sane choice could be: + +- Start off with `min-free-slots` set to half the available logical channels. +- Increase `min-free-slots` if you see MS being rejected too often even though + close neighbors had unused logical channels. +- Decrease `min-free-slots` if you see too many handovers happening for no + apparent reason. + +Choosing the optimal setting is not trivial, consider these examples: + +- Configure `min-free-slots` = 1: load distribution to other cells will occur + exactly when the last available logical channel has become occupied. The next + time the congestion check runs, at most one handover will occur, so that one + channel is available again. In the intermediate time, all channels will be + occupied, and some MS might be denied immediate voice service because of + that, even though, possibly, other neighbor cells would have provided + excellent reception levels and were completely unloaded. For those MS that + are already in an ongoing voice call and are not physically moving, though, + this almost guarantees service by the closest/best cell. + +- Set `min-free-slots` = 2: up to two MS can successfully request voice service + simultaneously (e.g. one MS is establishing a new voice call while another MS + is travelling into this cell). Ideally, two slots have been kept open and are + immediately available. But if a third MS is also traveling into this cell at + the same time, it will not be able to handover into this cell until load + distribution has again taken action to make logical channels available. The + same scenario applies to any arbitrary number of MS asking for voice channels + simultaneously. The operator needs to choose where to draw the line. + +- Set `min-free-slots` >= the number of available channels: as soon as any + neighbor is less loaded than a given cell, handover will be attempted. But + imagine there are only two active voice calls on this cell with plenty of + logical channels still unused, and the closest neighbor rates only just above + `min rxlev`; then moving one of the MS _for no good reason_ causes all of: + increased power consumption, reduced reception stability and channel + management overhead. + +NOTE: In the presence of dynamic timeslots to provide GPRS service, the number +of voice timeslots left unused also determines the amount of bandwidth +available for GPRS. + +==== External / Inter-BSC Handover Considerations + +There currently is a profound difference for inter-BSC handover between +algorithm 1 and 2: + +For algorithm 1, inter-BSC handover is triggered as soon as the Measurement +Reports and hysteresis indicate a better neighbor than the current cell, +period. + +For algorithm 2, a subscriber is "sticky" to the current BSS, and inter-BSC +handover is only even considered when RXLEV/TA drop below minimum requirements. + +- If your network topology is such that each OsmoBSC instance manages a single + BTS, and you would like to encourage handover between these, choose handover + algorithm 1. Load balancing will not be available, but RXLEV hysteresis will. + +- If your network topology has many cells per BSS, and/or if your BSS + boundaries in tendency correspond to physical/semantic boundaries that favor + handover to remain within a BSS, then choose handover algorithm 2. + +The reason for the difference between algorithm 1 and 2 for remote-BSS +handovers is, in summary, the young age of the inter-BSC handover feature in +OsmoBSC: + +- So far the mechanisms to communicate cell load to remote-BSS available in the + BSSMAP Handover messages are not implemented, so, a handover due to cell load + across BSS boundaries would be likely to cause handover oscillation between + the two BSS (continuous handover of the same MS back and forth between the + same two cells). +- Algorithm 1 has no `min rxlev` setting. +- Algorithm 1 does not actually use any information besides the Measurement + Reports, and hence can trivially treat all neighbor cells identically. diff --git a/doc/manuals/chapters/handover_inter_bsc.dot b/doc/manuals/chapters/handover_inter_bsc.dot new file mode 100644 index 000000000..0cc655401 --- /dev/null +++ b/doc/manuals/chapters/handover_inter_bsc.dot @@ -0,0 +1,35 @@ +digraph G { +rankdir=LR + +subgraph cluster_bss_a { + label="BSS Alpha" + BTS_a0 [rank=min,label="bts 0\nARFCN=1 BSIC=1\nLAC=23 CI=5"] + BTS_a1 [rank=min,label="bts 1\nARFCN=2 BSIC=2\nLAC=23 CI=6"] + BSC_a [label="BSC Alpha"]; + {BTS_a0,BTS_a1} -> BSC_a [arrowhead=none,label=Abis] +} + +subgraph cluster_bss_b { + label="BSS Beta" + BTS_b0 [rank=min,label="bts 0\nARFCN=1 BSIC=3\nLAC=42 CI=3"] + BTS_b1 [rank=min,label="bts 1\nARFCN=2 BSIC=4\nLAC=42 CI=1"] + BSC_b [label="BSC Beta"] + {BTS_b0,BTS_b1} -> BSC_b [arrowhead=none,label=Abis] +} + +MS -> BTS_a1 [label="(3) Measurement:\nARFCN=1 BSIC=3 RXLEV"] +BTS_a1 -> MS [label="(1) my neighbors:\nARFCN=1 BSIC=1\nARFCN=1 BSIC=3"] +BTS_b0 -> MS [label="(2) good RXLEV",style=dotted] +MS -> {BTS_a0,BTS_b0,BTS_b1} [style=invisible,arrowhead=none] + +BTS_a1 -> BSC_a [label="(4) Measurement\nReport",style=dashed] +BTS_a1 -> BTS_b0 [label="(5) BSC decides to do\ninter-BSC Handover",style=dashed,constraint=false] + +{BSC_a,BSC_b} -> MSC [arrowhead=none,label=A] + +BSC_a -> MSC [label="(6) --> Handover Required\nto LAC=42 CI=6\n(10) <-- Handover Command",style=dashed,constraint=false,arrowhead=none] +MSC -> BSC_b [label="(7) <-- Handover Request\n(9) --> Handover Request ACK",style=dashed,constraint=false,arrowhead=none] + +BSC_b -> BTS_b0 [label="(8) activate new lchan",style=dashed,constraint=false] + +} diff --git a/doc/manuals/chapters/handover_intra_bsc.dot b/doc/manuals/chapters/handover_intra_bsc.dot new file mode 100644 index 000000000..2a4f6cf15 --- /dev/null +++ b/doc/manuals/chapters/handover_intra_bsc.dot @@ -0,0 +1,31 @@ +digraph G { +rankdir=LR + +subgraph cluster_bss_a { + label="BSS Alpha" + BTS_a0 [rank=min,label="bts 0\nARFCN=1 BSIC=1\nLAC=23 CI=5"] + BTS_a1 [rank=min,label="bts 1\nARFCN=2 BSIC=2\nLAC=23 CI=6"] + BSC_a [label="BSC Alpha"]; + {BTS_a0,BTS_a1} -> BSC_a [arrowhead=none,label=Abis] +} + +subgraph cluster_bss_b { + label="BSS Beta" + BTS_b0 [rank=min,label="bts 0\nARFCN=1 BSIC=3\nLAC=42 CI=3"] + BTS_b1 [rank=min,label="bts 1\nARFCN=2 BSIC=4\nLAC=42 CI=1"] + BSC_b [label="BSC Beta"] + {BTS_b0,BTS_b1} -> BSC_b [arrowhead=none,label=Abis] +} + +MS -> BTS_a1 [label="(3) Measurement:\nARFCN=1 BSIC=1 RXLEV"] +BTS_a1 -> MS [label="(1) my neighbors:\nARFCN=1 BSIC=1\nARFCN=1 BSIC=3"] +BTS_a0 -> MS [label="(2) good RXLEV",style=dotted] +MS -> {BTS_a0,BTS_b0,BTS_b1} [style=invisible,arrowhead=none] + +BTS_a1 -> BSC_a [label="(4) Measurement\nReport",style=dashed] +BTS_a1 -> BTS_a0 [label="(5) BSC decides to do\nintra-BSC Handover",style=dashed,constraint=false] +BSC_a -> BTS_a0 [label="(6) activate new lchan",style=dashed,constraint=false] + +{BSC_a,BSC_b} -> MSC [arrowhead=none,label=A] + +} diff --git a/doc/manuals/osmobsc-usermanual-docinfo.xml b/doc/manuals/osmobsc-usermanual-docinfo.xml index 5ac374201..6de53b2ac 100644 --- a/doc/manuals/osmobsc-usermanual-docinfo.xml +++ b/doc/manuals/osmobsc-usermanual-docinfo.xml @@ -7,6 +7,15 @@ Initial OsmoBSC manual, recycling OsmoNITB sections + + 2 + October 2018 + NH + + Add Handover chapter: document new neighbor configuration, HO algorithm 2 + and inter-BSC handover. + + @@ -32,10 +41,21 @@ Managing Director + + Neels + Hofmeyr + nhofmeyr@sysmocom.de + NH + + sysmocom + sysmocom - s.f.m.c. GmbH + Developer + + - 2012-2016 + 2012-2018 sysmocom - s.f.m.c. GmbH diff --git a/doc/manuals/osmobsc-usermanual.adoc b/doc/manuals/osmobsc-usermanual.adoc index e3eadafbb..0ec15e54b 100644 --- a/doc/manuals/osmobsc-usermanual.adoc +++ b/doc/manuals/osmobsc-usermanual.adoc @@ -15,6 +15,8 @@ include::chapters/control.adoc[] include::chapters/counters.adoc[] +include::chapters/handover.adoc[] + include::../common/chapters/vty.adoc[] include::../common/chapters/logging.adoc[] -- cgit v1.2.3 From 48758488533d93017c0a2a1c93122e5d95b09734 Mon Sep 17 00:00:00 2001 From: Neels Hofmeyr Date: Wed, 31 Oct 2018 02:18:39 +0100 Subject: bsc: handover: clarify default of all-cells-are-neighbors Change-Id: I61f877c7a60419132bdd27c1b4e64150c0520751 --- doc/manuals/chapters/handover.adoc | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/doc/manuals/chapters/handover.adoc b/doc/manuals/chapters/handover.adoc index 11206908b..b76370100 100644 --- a/doc/manuals/chapters/handover.adoc +++ b/doc/manuals/chapters/handover.adoc @@ -166,6 +166,22 @@ new `neighbor` configuration described below. | ✓ | ✓ | neighbor cgi 001 01 200 3 arfcn 123 bsic 1 |==== +==== Default: All Local Cells are Neighbors + +For historical reasons, the default behavior of OsmoBSC is to add all local-BSS cells as neighbors. To +maintain a backwards compatible configuration file format, this is still the case: as soon as no explicit +neighbor cell is configured with a `neighbor` command (either none was configured, or all configured +neighbors have been removed again), a cell automatically lists all of the local-BSS cells as neighbors. +These are implicit mappings in terms of the legacy neighbor configuration scheme, and re-using ARFCN+BSIC +combinations within a BSS will not work well this way. + +As soon as the first explicit neighbor relation is added to a cell, the legacy behavior is switched off, +and only explicit neighbors are in effect. + +NOTE: If a cell is required to not have any neighbors, it is recommended to rather switch off handover +for that cell with `handover 0`. An alternative solution is to set `neighbor-list mode manual` and not +configure any `neighbor-list` entries. + ==== Local-BSS Neighbors Local neighbors can be configured by just the local BTS number, or by LAC+CI, -- cgit v1.2.3 From aa4a3e7259ad8c1421f6e1b1b0bfbd70d66d9bc9 Mon Sep 17 00:00:00 2001 From: Neels Hofmeyr Date: Wed, 31 Oct 2018 02:27:28 +0100 Subject: bsc: handover: mention the need to resend SI for telnet neighbor cfg Change-Id: I305ef558b75697015e2532aa7c135f7995662e0d --- doc/manuals/chapters/handover.adoc | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/doc/manuals/chapters/handover.adoc b/doc/manuals/chapters/handover.adoc index b76370100..297eafc1f 100644 --- a/doc/manuals/chapters/handover.adoc +++ b/doc/manuals/chapters/handover.adoc @@ -307,6 +307,15 @@ list items. Hence, to be able to send several alternative remote neighbors to the MSC, the configured cell identifiers must be of the same type. If in doubt, use the full CGI identifier everywhere. +==== Reconfiguring Neighbors in a Running OsmoBSC + +When modifying a cell's neighbor configuration in a telnet VTY session while a cell is already active, +the neighbor configuration will merely be cached in the BSC's local config. To take actual effect, it is +necessary to + +- either, re-connect the cell to the BSC (e.g. via `drop bts connection <0-255> oml`) +- or, re-send the System Information using `bts <0-255> resend-system-information`. + === Configuring Handover Decisions For a long time, OsmoBSC has supported handover based on reception level -- cgit v1.2.3 From c3d839390a9d83818ab03ff2342391b0f62f3041 Mon Sep 17 00:00:00 2001 From: Neels Hofmeyr Date: Wed, 31 Oct 2018 00:10:18 +0100 Subject: author info: add "former" to Holger's job title It doesn't seem to have an effect on the generated PDFs though. Change-Id: I0556a3f8dafc051f20a3854fc9006edf4ec1a0d3 --- doc/manuals/osmobsc-usermanual-docinfo.xml | 2 +- doc/manuals/osmux-reference-docinfo.xml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/manuals/osmobsc-usermanual-docinfo.xml b/doc/manuals/osmobsc-usermanual-docinfo.xml index 6de53b2ac..9c0d1c85d 100644 --- a/doc/manuals/osmobsc-usermanual-docinfo.xml +++ b/doc/manuals/osmobsc-usermanual-docinfo.xml @@ -27,7 +27,7 @@ sysmocom sysmocom - s.f.m.c. GmbH - Managing Director + former Managing Director diff --git a/doc/manuals/osmux-reference-docinfo.xml b/doc/manuals/osmux-reference-docinfo.xml index 7e31ec72b..a902c5c1a 100644 --- a/doc/manuals/osmux-reference-docinfo.xml +++ b/doc/manuals/osmux-reference-docinfo.xml @@ -47,7 +47,7 @@ sysmocom sysmocom - s.f.m.c. GmbH - Managing Director + former Managing Director -- cgit v1.2.3 From 5397326b400211d7c4ce2d5ab51ad6f5ad99968e Mon Sep 17 00:00:00 2001 From: Daniel Willmann Date: Tue, 23 Oct 2018 18:17:28 +0200 Subject: OsmoBSC/HLR/MSC: Fix default config file name Mention that the default is not openbsc.cfg, but osmo-*.cfg Change-Id: I139e6004e28d6f918f31792e634214a6153edd0e --- doc/manuals/chapters/running.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/manuals/chapters/running.adoc b/doc/manuals/chapters/running.adoc index 6747a2919..f62ba6e8b 100644 --- a/doc/manuals/chapters/running.adoc +++ b/doc/manuals/chapters/running.adoc @@ -21,7 +21,7 @@ arguments: Fork the process as a daemon into background. *-c, --config-file 'CONFIGFILE'*:: Specify the file and path name of the configuration file to be - used. If none is specified, use `openbsc.cfg` in the current + used. If none is specified, use `osmo-bsc.cfg` in the current working directory. *-s, --disable-color*:: Disable colors for logging to stderr. This has mostly been -- cgit v1.2.3 From 39e1215cbc466c8c881a5a23b4ab1d75a01bbe07 Mon Sep 17 00:00:00 2001 From: Neels Hofmeyr Date: Mon, 5 Nov 2018 02:56:09 +0100 Subject: OsmoBSC: update VTY reference Re-generate bsc_vty_reference.xml from osmo-bsc, including updates to: - handover and neighbor config - SCCP timers - logging Change-Id: Ia9ba8d5eba531b1156de57573ab42517e0c1ca15 --- doc/manuals/vty/bsc_vty_reference.xml | 952 ++++++++++++++++++---------------- 1 file changed, 505 insertions(+), 447 deletions(-) diff --git a/doc/manuals/vty/bsc_vty_reference.xml b/doc/manuals/vty/bsc_vty_reference.xml index 29a61bcd1..f56b951ec 100644 --- a/doc/manuals/vty/bsc_vty_reference.xml +++ b/doc/manuals/vty/bsc_vty_reference.xml @@ -85,12 +85,6 @@ - - - - - - @@ -125,6 +119,12 @@ + + + + + + @@ -138,6 +138,12 @@ + + + + + + @@ -182,22 +188,10 @@ - - - - - - - - - - - - - + @@ -282,7 +276,7 @@ - + @@ -290,6 +284,7 @@ + @@ -299,30 +294,18 @@ - - - - - - - - - - + - - - + - @@ -330,6 +313,10 @@ + + + + @@ -348,7 +335,6 @@ - @@ -356,6 +342,38 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -406,6 +424,26 @@ + + + + + + + + + + + + + + + + + + + + @@ -537,6 +575,57 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + enable @@ -590,12 +679,6 @@ - - - - - - @@ -643,6 +726,12 @@ + + + + + + @@ -656,6 +745,12 @@ + + + + + + @@ -700,6 +795,21 @@ + + + + + + + + + + + + + + + @@ -712,19 +822,16 @@ - - - - - - - - + - - - - + + + + + + + + @@ -800,7 +907,7 @@ - + @@ -808,6 +915,7 @@ + @@ -817,30 +925,18 @@ - - - - - - - - - - + - - - + - @@ -848,6 +944,10 @@ + + + + @@ -866,7 +966,6 @@ - @@ -874,6 +973,38 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -924,6 +1055,26 @@ + + + + + + + + + + + + + + + + + + + + @@ -1249,6 +1400,57 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + config @@ -1577,7 +1779,7 @@ - + @@ -1585,23 +1787,21 @@ + - + - - - + - @@ -1609,6 +1809,10 @@ + + + + @@ -1627,7 +1831,6 @@ - @@ -1635,6 +1838,38 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -1903,15 +2138,6 @@ - - - - - - - - - @@ -1925,6 +2151,21 @@ + + + + + + + + + + + + + + + config-cs7-as @@ -2214,121 +2455,34 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + - - - - + + + + - + - - - - + + + - + - - - + + + - - - - - - - - - - - - - - - - - + - - - + + + @@ -2410,8 +2564,8 @@ - - + + @@ -2470,8 +2624,8 @@ - - + + @@ -2487,7 +2641,7 @@ - + @@ -2496,7 +2650,7 @@ - + @@ -2505,7 +2659,7 @@ - + @@ -2514,34 +2668,34 @@ - + - + - + - + - + - + - + @@ -2550,7 +2704,7 @@ - + @@ -2559,7 +2713,7 @@ - + @@ -2567,7 +2721,7 @@ - + @@ -2576,7 +2730,7 @@ - + @@ -2585,7 +2739,7 @@ - + @@ -2594,75 +2748,15 @@ - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + @@ -2739,12 +2833,6 @@ - - - - - - @@ -3780,6 +3868,97 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -3878,8 +4057,8 @@ - - + + @@ -3938,8 +4117,8 @@ - - + + @@ -3955,7 +4134,7 @@ - + @@ -3964,7 +4143,7 @@ - + @@ -3973,7 +4152,7 @@ - + @@ -3982,34 +4161,34 @@ - + - + - + - + - + - + - + @@ -4018,7 +4197,7 @@ - + @@ -4027,7 +4206,7 @@ - + @@ -4035,7 +4214,7 @@ - + @@ -4044,7 +4223,7 @@ - + @@ -4053,7 +4232,7 @@ - + @@ -4062,71 +4241,11 @@ - + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - config-net-bts-trx @@ -4218,12 +4337,6 @@ - - - - - - @@ -4340,54 +4453,6 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @@ -4508,6 +4573,20 @@ + + + + + + + + + + + + + + @@ -4532,6 +4611,14 @@ + + + + + + + + @@ -4575,47 +4662,18 @@ - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - + + + - + - - - + + + -- cgit v1.2.3 From 27683cbe1305c1c2e4c49a1a9333167aa6e30c3c Mon Sep 17 00:00:00 2001 From: Oliver Smith Date: Thu, 15 Nov 2018 11:24:47 +0100 Subject: copy NITB's osmobsc-usermanual.adoc to OsmoBSC Includes from other projects don't work anymore when moving project specific manuals into other repositories. Related: OS#3385 Change-Id: I96933dd4dd6cac159847647f1c642215051a9aad --- doc/manuals/chapters/bts-examples.adoc | 281 +++++++++++++++++++++++++++++++++ doc/manuals/osmobsc-usermanual.adoc | 2 +- 2 files changed, 282 insertions(+), 1 deletion(-) create mode 100644 doc/manuals/chapters/bts-examples.adoc diff --git a/doc/manuals/chapters/bts-examples.adoc b/doc/manuals/chapters/bts-examples.adoc new file mode 100644 index 000000000..b15fb9921 --- /dev/null +++ b/doc/manuals/chapters/bts-examples.adoc @@ -0,0 +1,281 @@ +[[bts-examples]] +== OsmoNITB example configuration files + +The `openbsc/doc/examples/osmo-nitb` directory in the OpenBSC source +tree contains a collection of example configuration files, sorted by BTS +type. + +This chapter is illustrating some excerpts from those examples + +[[bts_example_bs11]] +=== Example configuration for OsmoNITB with one dual-TRX BS-11 + +.OsmoNITB with BS11, 2 TRX, no frequency hopping +==== + +---- +e1_input + e1_line 0 driver misdn +network + network country code 1 + mobile network code 1 + short name OpenBSC + long name OpenBSC + timer t3101 10 + timer t3113 60 + bts 0 + type bs11 <1> + band GSM900 + cell_identity 1 + location_area_code 1 + training_sequence_code 7 + base_station_id_code 63 + oml e1 line 0 timeslot 1 sub-slot full <2> + oml e1 tei 25 <3> + trx 0 + arfcn 121 + max_power_red 0 + rsl e1 line 0 timeslot 1 sub-slot full <4> + rsl e1 tei 1 <5> + timeslot 0 + phys_chan_config CCCH+SDCCH4 + e1 line 0 timeslot 1 sub-slot full + timeslot 1 + phys_chan_config TCH/F + e1 line 0 timeslot 2 sub-slot 1 <6> + timeslot 2 + phys_chan_config TCH/F + e1 line 0 timeslot 2 sub-slot 2 + timeslot 3 + phys_chan_config TCH/F + e1 line 0 timeslot 2 sub-slot 3 + timeslot 4 + phys_chan_config TCH/F + e1 line 0 timeslot 3 sub-slot 0 + timeslot 5 + phys_chan_config TCH/F + e1 line 0 timeslot 3 sub-slot 1 + timeslot 6 + phys_chan_config TCH/F + e1 line 0 timeslot 3 sub-slot 2 + timeslot 7 + phys_chan_config TCH/F + e1 line 0 timeslot 3 sub-slot 3 + trx 1 + arfcn 123 + max_power_red 0 + rsl e1 line 0 timeslot 1 sub-slot full <4> + rsl e1 tei 2 <5> + timeslot 0 + phys_chan_config TCH/F + e1 line 0 timeslot 4 sub-slot 0 <6> + timeslot 1 + phys_chan_config TCH/F + e1 line 0 timeslot 4 sub-slot 1 + timeslot 2 + phys_chan_config TCH/F + e1 line 0 timeslot 4 sub-slot 2 + timeslot 3 + phys_chan_config TCH/F + e1 line 0 timeslot 4 sub-slot 3 + timeslot 4 + phys_chan_config TCH/F + e1 line 0 timeslot 5 sub-slot 0 + timeslot 5 + phys_chan_config TCH/F + e1 line 0 timeslot 5 sub-slot 1 + timeslot 6 + phys_chan_config TCH/F + e1 line 0 timeslot 5 sub-slot 2 + timeslot 7 + phys_chan_config TCH/F + e1 line 0 timeslot 5 sub-slot 3 +---- +==== + +<1> The BTS type must be set to __bs11__ +<2> The OML E1 timeslot needs to be identical with what was on the BTS side using LMT. +<3> The OML TEI value needs to be identical with what was configured on the BTS side using LMT. +<4> The RSL E1 timeslot can be identical for all TRX. +<5> The RSL TEI values __must__ be different if multiple TRX share one E1 signalling timeslot. +<6> The TCH all need to be allocated one 16k sub-slot on the E1 + +[[bts_example_nbts]] +=== Example configuration for OsmoNITB with one single-TRX nanoBTS + +.OsmoNITB with one single-TRX nanoBTS +==== + +---- +e1_input + e1_line 0 driver ipa <1> +network + network country code 1 + mobile network code 1 + short name OpenBSC + long name OpenBSC + auth policy closed + location updating reject cause 13 + encryption a5 0 + neci 1 + rrlp mode none + mm info 1 + handover 0 + bts 0 + type nanobts <2> + band DCS1800 <3> + cell_identity 0 + location_area_code 1 + 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 <4> + oml ip.access stream_id 255 line 0 + gprs mode none + trx 0 + rf_locked 0 + arfcn 871 <5> + nominal power 23 + max_power_red 20 <6> + rsl e1 tei 0 + timeslot 0 + phys_chan_config CCCH+SDCCH4 + timeslot 1 + phys_chan_config SDCCH8 + timeslot 2 + phys_chan_config TCH/F + timeslot 3 + phys_chan_config TCH/F + timeslot 4 + phys_chan_config TCH/F + timeslot 5 + phys_chan_config TCH/F + timeslot 6 + phys_chan_config TCH/F + timeslot 7 + phys_chan_config TCH/F +---- +==== + +<1> You have to configure one virtual E1 line with the + IPA driver in order to use Abis/IP. One e1_line is + sufficient for any number of A-bis/IP BTSs, there is no + limit like in physical E1 lines. +<2> The BTS type must be set using `type nanobts` +<3> The GSM band must be set according to the BTS hardware. +<4> The IPA Unit ID parameter must be set to what has been configured on + the BTS side using the __BTS Manager__ or `ipaccess-config`. +<5> The ARFCN of the BTS. +<6> All known nanoBTS units have a nominal transmit power of 23 dBm. If + a `max_power_red` of 20 (dB) is configured, the resulting output + power at the BTS Tx port is 23 - 20 = 3 dBm. + +[NOTE] +==== +The `nominal_power` setting does __not__ influence the transmitted power +to the BTS! It is a setting by which the system administrator tells the +BSC about the nominal output power of the BTS. The BSC uses this as +basis for calculations. +==== + + +[[bts_example_nbts_multi]] +=== Example configuration for OsmoNITB with multi-TRX nanoBTS + +.OsmoNITB configured for dual-TRX (stacked) nanoBTS +==== + +---- +e1_input + e1_line 0 driver ipa +network + network country code 1 + mobile network code 1 + short name OpenBSC + long name OpenBSC + auth policy closed + location updating reject cause 13 + encryption a5 0 + neci 1 + rrlp mode none + mm info 0 + handover 0 + bts 0 + type nanobts + band DCS1800 + cell_identity 0 + location_area_code 1 + 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 1800 0 <1> + oml ip.access stream_id 255 line 0 + gprs mode none + trx 0 + rf_locked 0 + arfcn 871 + nominal power 23 + max_power_red 0 + rsl e1 tei 0 + timeslot 0 + phys_chan_config CCCH+SDCCH4 + timeslot 1 + phys_chan_config SDCCH8 + timeslot 2 + phys_chan_config TCH/F + timeslot 3 + phys_chan_config TCH/F + timeslot 4 + phys_chan_config TCH/F + timeslot 5 + phys_chan_config TCH/F + timeslot 6 + phys_chan_config TCH/F + timeslot 7 + phys_chan_config TCH/F + trx 1 + rf_locked 0 + arfcn 873 + nominal power 23 + max_power_red 0 + rsl e1 tei 0 + timeslot 0 + phys_chan_config SDCCH8 + timeslot 1 + phys_chan_config TCH/F + timeslot 2 + phys_chan_config TCH/F + timeslot 3 + phys_chan_config TCH/F + timeslot 4 + phys_chan_config TCH/F + timeslot 5 + phys_chan_config TCH/F + timeslot 6 + phys_chan_config TCH/F + timeslot 7 + phys_chan_config TCH/F +---- +==== + +<1> In this example, the IPA Unit ID is specified as `1800 0`. Thus, the + first nanoBTS unit (`trx 0`) needs to be configured to 1800/0/0 and + the second nanoBTS unit (`trx 1`) needs to be configured to 1800/0/1. + You can configure the BTS unit IDs using the `ipaccess-config` + utility included in OpenBSC. + +[NOTE] +==== +For building a multi-TRX setup, you also need to connect the TIB cables +between the two nanoBTS units, as well as the coaxial/RF AUX cabling. +==== diff --git a/doc/manuals/osmobsc-usermanual.adoc b/doc/manuals/osmobsc-usermanual.adoc index 0ec15e54b..19846785c 100644 --- a/doc/manuals/osmobsc-usermanual.adoc +++ b/doc/manuals/osmobsc-usermanual.adoc @@ -23,7 +23,7 @@ include::../common/chapters/logging.adoc[] include::../common/chapters/bts.adoc[] -include::../OsmoNITB/chapters/bts-examples.adoc[] +include::{srcdir}/chapters/bts-examples.adoc[] include::../common/chapters/bsc.adoc[] -- cgit v1.2.3